The world of Systems Engineering is changing. In recent years, the whole field of Systems Engineering has been seen as no longer an emerging discipline but as a valid approach to realising successful systems. Systems Engineering is a broad field, but what do we mean by systems? What life cycles can Systems Engineering be applied to? And what areas can Systems Engineering be applied to? The main aim of this chapter is to tackle these topics.

This short chapter introduces the basic approach that will be taken in all of the following chapters that discuss specific applications of MBSE using Systems Modelling Language (SysML).

This chapter discusses the main systems engineering concepts that were introduced briefly in Chapter 1. Understanding the concepts is, therefore, essential, and these concepts will be defined using the MBSE Ontology. This Ontology will then be used throughout the rest of this book for all of the examples, approaches and applications of MBSE.

This is a book concerned with model-based systems engineering (MBSE), and thus modelling is fundamental to everything that is presented in it. It makes sense, therefore, before we consider MBSE in detail in Parts 3-5, to first consider the modelling aspects. This chapter discusses why modelling is so important in the context of the “three evils”of engineering, briefly discusses the history of the systems engineering modelling language (SysML), establishes the basic requirements for modelling, introduces the concept of modelling and introduces to the SysML that is used as the modelling language throughout the rest of the book. Only the briefest of syntax will be looked at in this chapter - for a more full description of the SysML syntax see Chapter 5.

This chapter describes the nine SysML diagrams. Following this introduction, the terminology used throughout the chapter is explained and the structure of SysML diagrams is discussed. This is followed by a discussion of stereotypes and then of the SysML meta-model, which forms the basis of this chapter. Following this, each of the nine diagrams is described in turn. For each diagram type there is a brief introduction, a discussion of the diagram elements through its meta-model and notation, examples of how to use the diagram and a summary.

Producing consistent SysML (and Unified Modelling Language (UML)) diagrams that have a common look and feel is crucial to efficient and effective modelling. One of the easiest ways of helping to ensure consistency within SysML models is to set and follow effective naming and diagramming conventions that ensure a common look and feel across diagrams and help to ensure that diagrams are easy to read. Such guidelines should also save time by limiting the number of stylistic choices faced, allowing focus to be directed to the modelling rather than the drawing. This chapter defines a set of rules and guidelines to be followed when producing SysML diagrams. Following this introduction, Section 6.2 defines rules to be applied to elements on SysML structural and behavioural diagrams together with stereotypes. This is followed by Section 6.3 which defines rules for naming SysML diagrams. Finally, Section 6.4 defines rules for specific diagram types and gives some guidelines on producing diagrams using SysML CASE tools. The guidelines presented here are those used by the authors and are, in part, based on [1]. The guidelines form part of their SysML modelling Standard, i.e. the adoption by the authors is not optional. Of course, for the reader, these are only guidelines and can therefore be followed, changed or ignored. Nevertheless, it is recommended that a defined SysML modelling standard be produced and enforced as part of the reader's systems engineering processes.

This chapter looks at a model-based approach to Process modelling, which, although at first appearances, may seem quite simple, it will be shown that the application of modelling Processes has myriad uses in Systems Engineering. The basic “seven views”approach that is described in this chapter may be applied to many other areas of Systems Engineering, such as modelling Standards, compliance, Life Cycle modelling, Competence modelling and project management. These examples will be expanded upon in Chapter 8. The definition of the “seven views”follows the basic `Ontology, Framework and Views' approach, which is used throughout this book.

This chapter considers how the “seven views”approach that was introduced in the previous chapter may be used as a basis for various model-based systems engineering (MBSE) applications.

This chapter introduces a model-based approach to requirements engineering. This approach is known as ACRE - Approach to Context-based Requirements Engineering [1]. The approach uses the `Ontology, Framework and Views' techniques that are used throughout this book.

The current chapter looks at expanding the approach to context-based requirements engineering (ACRE) introduced in Chapter 9 so that it can be applied to Systems of Systems. The adoption of the naming notation defined in Chapter 2 applies throughout the whole book to every term - except one! This term is System of Systems, and the confusion comes into play with the plural of term. Therefore, when referring the standard term from the model-based systems engineering (MBSE) Ontology, the usual term System of Systems will be used. However, when this term is used in the plural, the term Systems of Systems will be used (note the plural of the first word).

This chapter considers two essential enabling concepts for model-based systems engineering: the Architecture and the Architectural Framework (AF). After considering the basic Context for Architectures and AFs, the chapter describes a model-based approach to the definition of an AF. This defines a framework for the definition of an AF, FAF (Framework for AF). The definition of FAF follows the basic Ontology, Framework and Views approach that is used throughout the book. A set of Processes are also introduced that can be used, along with FAF, to define an AF. These Processes are briefly described in this chapter and the full definition is available from the authors.

Many organisations find it difficult to know where to apply limited resources for the most return. Having a healthy sales funnel is vital, but what is the best way to use a limited marketing budget? All face questions like `Should we attend the ACME Conference this year?' and `E-Corp want another meeting. We have already had three and got no work. Should we bother?' This chapter outlines an initial Value Chain Framework (VCF) that the authors have developed (and are continuing to develop) to help them capture current and past business in order to analyse and decide where to target limited sales and marketing resources in the best way to answer the kinds of questions posed above and to help generate future business. In keeping with the rest of this book, you should not be surprised to find that the VCF has been developed using MBSE best practice - the Framework for Architectural Frameworks (FAF) as described in Chapter 11. The use of MBSE was also one of the key drivers in the development of the VCF: the authors are both firm believers that the best MBSE starts at home. Do not just preach (and hopefully practice) MBSE with you customers and the Systems you are developing for them, but preach and most definitely practice MBSE in your own Organisation, by applying MBSE to understanding and improving the way the Organisation works and to how it (and you) carry out MBSE. This is, all too sadly, very rare in many Systems Engineering Organisations; there are many that are great advocates of Systems Engineering (if not MBSE) but who never turn such a powerful tool on themselves and the way they work. Trying to understand the value of using MBSE for a non-systems engineering activity was of great interest to the authors and this, of course, meant that thinking about and capturing value chain had to be done using MBSE techniques. Following this introduction, the aims of the VCF are presented. The main concepts used by the VCF are then defined and described and its Viewpoints identified. Each Viewpoint is defined, with an example View that conforms to the Viewpoint. Rules are then defined that constrain the use of the VCF. The chapter concludes with some observations on issues and future work that are being considered.

In order to demonstrate the concepts, principles and notation in Parts 1-3, a case study will be used. This case study is presented in Chapter 14. The current chapter sets the case study in Context by considering the Needs that it addresses in Section 13.1.1. This is followed, in Section 13.2, by the definition of an Architectural Framework that will be used as the main means of presentation of the case study in Chapter 14. This is followed by a discussion of the use of SysML auxiliary constructs in the definition of Viewpoints. Finally, the chapter concludes with a summary and references.

This chapter presents an extended example that, as discussed in Chapter 13, is intended to demonstrate the MBSE concepts covered in this book using the SysML as the main means of presentation. Rather than trying to retrospectively apply the many and varied techniques, concepts, Frameworks and Views to an actual Project and System, we have rather chosen to model a System from scratch. There is always a danger when doing this that, if a real System is chosen, there will always be those readers who know more about the System than the authors. This can have a serious impact on the learning experience as the reader inevitably notices mistakes in the modelling of the System which detracts from the learning experience. For this reason, we have chosen a fictional example, albeit one that allows all the Perspectives defined in the MBSE Architectural Framework in Section 4.1 to be explored. The example we have chosen is one from popular culture that can be traced back to at least 1898 when H.G. Wells published one of his most famous novels. Our example, though, is inspired by more recent examples from the 1960s onwards. The example we have chosen is the Martian invasion of Earth. If you are interested in our sources, see [1-3]. Each of the Perspectives defined in Section 4.1 is considered, with at least one example of each View from each Perspective given. The intention in this chapter is not to describe the thinking behind each View; that can be found in the relevant chapter of the book on which the Perspective is based. Rather, the discussion will focus on aspects of each View that are worthy of discussion, as well as commentary on the way each View is realised.

One of the problems facing any person trying to implement MBSE into an organisation is one of the biggest issues that the authors have experienced. It is not the technical side, nor is it having the tools in place, nor the training. Perhaps the single biggest hurdle is one that can kill any initiative before it has even begun, and this is selling MBSE or, to put it more accurately, conveying the benefits of MBSE to relevant Stakeholders within the business. A common pitfall at this point is to go to the Internet and to perform a search on `benefits of MBSE' which seems both obvious and intuitive. The downside of this is that, invariably, all of the first hits will be from tool vendors who will essentially state the capabilities of their tools. There is nothing wrong with this per se, but these capabilities will typically excite Systems Engineers, but may not necessarily excite the people who have responsibility for budgets in the organisation. The key thing to bear in mind here is that different Stakeholders will look for different benefits from MBSE because, you have guessed it, they each have their own context. It is essential to understand the “why”of each Stakeholder Role. If we cannot understand their “why”, then we have failed before we have begun. In order to illustrate the benefits of MBSE, we shall be using a simple analogy of “the old lady who swallowed a fly”which is a traditional nursery rhyme in some parts of the world. If you are not familiar with this children's verse, then stop reading, get on the Internet and search it out. The chapter will make a lot more sense if you do this!

This chapter looks at the pragmatic issues involved when trying to realise the model-based Systems Engineering (MBSE) approach in this book in any Organisation or business. In particular, this chapter looks at how it is possible to ensure that the right people are in the right place, doing the right job - in other words, competent people. By way of a recap, the diagram in Figure 16.1 shows the three main elements that must be in place in order to realise successful MBSE, in particular: : The `Person', by which we mean competent people, rather than just any people. : The `Process', which is in place in order to realise the approach. : The `Tool', which may range from a whiteboard or log book, to standard office tools, to a full-blown automated tool set, to any combination of these. In order to understand the basic needs for providing competent people, the `People Context' shown in Figure 16.2 was generated. The diagram in Figure 16.2 shows the Context for the people aspect of MBSE. An essential element of having competent people is `Provide resource' that is needed to carry out the MBSE activities, which may cover their `...for knowledge', ` ...for skills' and `...for attitude'. This chapter, therefore, contains a teaching guide that may be used to develop a bespoke teaching or training course based around many of the ideas in this book. It must be appreciated that MBSE is a very large subject; therefore, the ideas presented here should be seen as a good starting point for course development, rather than covering every aspect of the subject. Being competent, however, involves far more than just training people to give them the right skill-set as it must also be ascertained what the Person's role will be (`Define role'), which will depend on the processes that describe the capability of the Organisation. Therefore, it is essential that the Stakeholder Roles define map onto (`Ensure mapping to process') whatever source Process (`Standard') is required. This section also contains, therefore, a set of Competency Scopes (`Define competency needs') that reflect current best practice (`Ensure mapping to frameworks') for the MBSE Stakeholder Roles identified in this book. These Competency Scopes may then be used as a basis for assessing the Competence (`Assess competency') of people who are required to work in MBSE. In order to assess Competence, a set of Processes will be introduced that can be used to carry out assessments. In order to satisfy these Needs, it is first necessary to revisit the people aspects of the MBSE Ontology.

The current chapter looks at the pragmatic issues involved when trying to realise the model-based systems engineering approach in this book in any Organisation or business. In particular, this chapter looks at how it is possible to ensure that the right approach is in place - in other words, the Process.

This chapter looks at the pragmatic issues involved when trying to realise the model-based Systems Engineering (MBSE) approach in this book in any organisation or business. In particular this chapter looks at how it is possible to ensure that effective Tools are in place. This chapter is clearly heavily related to Chapters 14 and 15 and, as such, should not be read in isolation, but should bear in mind the totality of this part of the book.

What is the best way to structure a SysML model? This is a question often asked of the authors. Unfortunately, as with much of modelling, the only valid answer that can be given is “It depends”. It depends on who are the main users of the model, on the level of sophistication of the document generation facilities within a SysML tool, on the life cycle stage you are in, on the Processes you are following and the Architectural Framework you are using. It can also depend on the SysML tool you are using. Section 19.2 of this chapter gives some thoughts on possible ways of structuring a model. They are only suggestions, and the reality is that the structure may well change considerably throughout the lifetime of the model. The second topic covered by this chapter, in Section 19.3, is that of model management. Again, this is a huge topic that is very much dependent on the SysML tool being used. Nevertheless, some of our thoughts on model management are presented. The topics presented in this chapter, together with those diagramming guidelines discussed in Chapter 6, should be incorporated into an organisational SysML modelling standard that is used and enforced as part of the reader's systems engineering processes.

A common problem that many industries face is how to know when it is appropriate to start to adopt and integrate new technologies into their systems. The problem is that when a technology is at a low level of maturity, the risks associated with adopting the new technology are high. Of course, this may be a necessary adoption of technology, but it is important that maturity of that technology is known. The same is true for Models - how do we know when a Model is ready to be implemented or is complete? There are several problems that will be faced by Modellers when applying MBSE: : Some people will think that the existence of a Model implies that it is both complete and correct. : If a non-MBSE person looks at a Model periodically over a project, it may not be apparent how the Model has matured. Just counting the number of Views, for example, is no indication of the maturity of a Model, just the size. : Size of a Model does not imply quality of the Model. In this chapter, we discuss how the concept of Maturity Levels, which are used extensively in the industry, can be adopted for MBSE.

This appendix provides a summary of the model-based systems engineering (MBSE) Ontology (Figure A.1). For full details, see Chapter 2; no explanation or additional details are given in this appendix.

This appendix provides a summary of the meta-model and notation diagrams for SysML that are used in Chapter 5. For each of the nine SysML diagram types, grouped into structural and behavioural diagrams, three diagrams are given: ; A partial meta-model for that diagram type. : The notation used on that diagram type. : An example of that diagram type. The same information is also given for the SysML auxiliary constructs. The appendix concludes with a diagram that illustrates some of the main relationships between the SysML diagrams. This appendix does not add further information to that found in Chapter 5 but is intended to provide a single summary section of the noted diagrams. See Chapter 5 for a discussion of each diagram.

This Appendix summarises what is perhaps the most widely used systems engineering Standard in the world: ISO/IEC 15288:2015 Systems and software engineering - System Life Cycle Processes [1]. The Appendix presents information on ISO15288:2015 using the “seven views”approach to Process modelling that is discussed in Chapter 7, five out of the seven possible Views are presented; no Information Views or Process Behaviour Views are given as the Standard is written at a level which does not allow these Views to be abstracted and modelled. The Views are given without commentary and are intended to be used as a reference in conjunction with a reading of the Standard. As an aid to understanding the content of ISO15288:2015, the reader is also directed to the INCOSE Systems Engineering Handbook [2].

This appendix describes the MBSE Competency Framework that can be used as a basis for carrying out assessments as described in Chapter 16. This appendix also defines a number of Competency Scopes for the Stakeholder Roles identified as being important for the realisation of MBSE in an Organisation. The diagram in Figure D.1 shows a recap of the key concepts associated with Competence taken from the MBSE Ontology that has been used throughout this book. An example Competency Framework, the MBSE Competency Framework will now be described that is based and, therefore, is consistent with the MBSE Ontology. It should be stressed that the Competency Framework provided here is for guidance only and is not intended to be definitive for all MBSE activities in all Organisations. The Competency Framework presented here is based on real work and has been applied in industry.

A memory palace is a mnemonic device that has been used for thousands of years as an aid to remembering large amounts of information [1,2]. The memory palace uses a series of points, or loci, that make up a pathway or route that is well known to you. At each point, a set of unusual images is constructed that make up a memorable, if somewhat peculiar, story. Generally speaking, the more ludicrous, bizarre and downright obscene these images are, the more memorable the whole memory palace will be. The following section provides a simple memory palace that may be used to remember all (almost all) of the concepts that make up the MBSE Ontology that is used throughout this book.