Model-Based Systems Engineering PDF

2 Model-Based Systems Engineering In this chapter, the main approach to Systems Engineering will be introduced and discussed, and its key properties described. This approach is known as Model-Based Systems Engineering, or MBSE, which is the common abbreviation. The information contained in this chap...

2 Model-Based Systems Engineering In this chapter, the main approach to Systems Engineering will be introduced and discussed, and its key properties described. This approach is known as Model-Based Systems Engineering, or MBSE, which is the common abbreviation. The information contained in this chapter concerning MBSE is essential learning for any modern-day Systems engineer. A good MBSE approach will provide a set of effective tools and techniques that will enable the realization of successful Systems while managing the complexity of today’s connected Systems, and allowing all relevant aspects of the System to be understood in as simple a manner as possible. This will also enable all information concerning the System to be communicated to the appropriate Stakeholders. This chapter covers the following topics: An introduction to MBSE: Here, the key concepts associated with MBSE will be introduced, discussed, and collected together using “MBSE in a slide.” The evolution of MBSE: Here, the transition from a document-based approach to a model-based approach to Systems Engineering will be discussed. Modeling with MBSE: In this section, the fundamentals of modeling for MBSE will be described. The spoken language – the Systems Modeling Language (SysML): Here, the chosen notation, the Systems Modeling Language, or SysML, is described and an example is given. The domain-specific language – the Ontology: At this point, the Ontology that forms the cornerstone of any MBSE endeavor will be introduced in detail. Model-Based Systems Engineering 32 This chapter will provide the basis for all of the techniques that are used throughout the rest of this book. An introduction to MBSE Before the main concepts of MBSE are discussed, it is important to understand a key philosophical point. Firstly, MBSE is not a subdivision, nor a subset, of Systems Engineering; MBSE is a complete approach to Systems Engineering and, therefore, is used for all aspects of Systems Engineering. One way to look at MBSE is that it is Systems Engineering achieved through a rigorous approach, illustrated in the following diagram: Figure 2.1: MBSE is a type of Systems Engineering The diagram in Figure 2.1 shows that MBSE is actually a type of Systems Engineering, rather than a subset or component part of Systems Engineering. This is essential to understand, and you must be very clear about this matter. The International Council on Systems Engineering (INCOSE) defines a worldwide vision of the future of Systems Engineering on a periodic basis. The INCOSE Vision 2035 (INCOSE 2022), predicts that by the year 2035, all Systems Engineering will be moving “towards a fully Model-Based Systems Engineering environment” and that it is key to all digital transformation. The question arises, therefore, of what exactly is meant by MBSE and how is it different from traditional Systems Engineering. The next few sections will discuss these questions in some detail. Chapter 2 33 Abstracting the System When considering Systems Engineering, it is important to never lose sight of the goal of Systems Engineering, which is to develop a successful System. This seems like an obvious statement, but it is essential that every activity that is carried out as part of Systems Engineering contributes to this goal. When considering MBSE, compared to traditional Systems Engineering, the main thing that must be understood is where the knowledge, information, and data concerning the System resides. In the case of traditional Systems Engineering, all of the knowledge concerning a System resides in the set of documents that describes the System. In the case of MBSE, all of the knowledge concerning the System resides in the Model that abstracts the System: Figure 2.2: The concept of the Model The diagram in Figure 2.2 shows the most fundamental concept of MBSE, which is that the Model abstracts the System. An abstraction may be thought of as a representation or simplification of the System. The Model must be a simplification of the System; otherwise, it would be the System. As the Model is a simplification of the System, it then follows, by its very nature, that the information contained in the Model is incomplete. This sometimes leads to the fatuous argument that all Models are wrong. The aim of a Model in MBSE is to provide an abstraction of the System to realize that System successfully. The aim of the Model in MBSE is not to contain as much information as possible, nor to attempt to capture all of the information concerning a System. The aim is to capture enough relevant information to realize the System successfully. It is important to always remember this, as it is very easy to generate more and more information as part of the Model that is of no use to anyone. It is essential that all information contained in the Model is useful. Model-Based Systems Engineering 34 The information contained in the Model is grouped into specific collections known as Views, as shown in the next diagram: Figure 2.3: The Model is made up of Views The diagram in Figure 2.3 shows that the Model is made up of a number of Views. Each of these Views represents a collection of information; however, it is essential that this is relevant information that adds value to the overall Systems Engineering endeavor – otherwise, it is a waste of time. Therefore, to ascertain whether a collection of information is a View and, therefore, a valid part of the overall Model, there are a number of questions that must be answered: Which Stakeholders would want to look at the View? To answer this question, it is essential that each View is related to a set of Stakeholders who are interested in the System. The concept of Stakeholders was discussed in Chapter 1, Introduction to Systems Engineering, and it was stated that identifying the correct set of Stakeholders is an essential part of Systems Engineering. Whenever any information is requested concerning the System, it is the Stakeholders who make these requests. Chapter 2 35 Why would these Stakeholders want to look at the View? It is essential to understand why each relevant Stakeholder wants to look at the View. Every View created as part of the Model must add value to the Systems Engineering endeavor. To do that, at least one Stakeholder must gain some sort of benefit from looking at the View. What information must be contained in the View? It is important to know what information, out of the complete Model, must be made available for the relevant Stakeholders to look at. If it is not possible to answer these three questions for each of the Views, then the result is quite simple – it is not a valid View and, therefore, must not be considered as part of the Systems Engineering endeavor. It is very easy to generate information, in the form of Views, that is of no use to anyone. By asking these questions each time a View is considered, means that the validity of each View can be guaranteed. There is also a fourth question that should be considered once the first three have been answered successfully: What language is the Stakeholder expecting to use when looking at the View? It is imperative when communicating with various Stakeholders that the communication is carried out in a language that the Stakeholder is fluent in. This applies to both the spoken and the domain-specific language, each of which will be discussed later in this chapter. The importance of communication was discussed in Chapter 1, Introduction to Systems Engineering, and this is one of the areas where effective communication comes into play. Stakeholders may speak different languages and, when considering MBSE, this translates into the fact that different Stakeholders may want to see a single View visualized in different ways. It is essential that these questions are asked for every View; otherwise, there will be information contained in the Model that adds no value, which is one of the biggest risks associated with MBSE. The other big risk associated with the Views that comprise the Model is associated with the fact that the Views must be consistent with each other. An essential and defining part of any Model is consistency. If there is a set of Views where each View is consistent with all other Views, then it is a Model. If there is a set of Views where each View is not consistent with all other Views, then it is data. Model-Based Systems Engineering 36 Once the Model has been established (all Views add value and are consistent), then it is used as the main repository for all information that relates to the System. This means that whenever any Stakeholder wants to know anything concerning the System, then it is the Model that is interrogated to ascertain the answer. The Model is sometimes referred to as a single source of truth. This is an important definition and consists of two main points: The Model is the only representation of the System – it is the single source. All information in the Model is viewed as being the truth as far as can be determined, hence the single source of truth. This definition can be misleading as it does not imply that the Model is contained in a single location. The idea is that conceptually, the Model is a single entity, even though, in reality, it may be split across several locations, databases, or tools. The Model may be imagined to be a large, complex collection of information, and each View is analogous to opening up a small window into that Model. It is necessary to open up enough of these windows to provide confidence to all of the Stakeholders that the Model is understood well enough to realize a successful System or, to put it another way, to carry out Systems Engineering. One final aspect of Views that needs to be understood is that a View may be visualized in many different ways or, to put it another way, may be communicated in any number of different languages. This is the same concept as different Stakeholders speaking different languages and will be the focus of the next section. Visualizing the Model The way that each View is visualized is crucial to the successful communication and understanding of the System among its Stakeholders. In terms of MBSE, the various languages that each Stakeholder may speak are referred to as Notation, as shown in the following diagram: Chapter 2 37 Figure 2.4: Notations, diagrams, and visualization The diagram in Figure 2.4 introduces the concepts of Notations and Diagrams to the original definition of Systems and Models. The Notation represents some sort of language that is used to communicate with a number of Stakeholders. This Notation represents the spoken language that was introduced in Chapter 1, Introduction to Systems Programming, or, to put it another way, it represents a basic communication mechanism that can be used to communicate with a set of Stakeholders. The Notation comprises a set of Diagrams that provide the actual communication mechanism that is used by the Notation. The term Diagram is used in its most general sense here and the concept of a Diagram may not even be graphical, as the Notation may be realized by almost any language, as follows: The Notation may be a visual, or graphical, language that uses graphics as its communication mechanism. Examples of this include the Unified Modeling Language (UML) (UML 2019), SysML (SysML 2017), SysML2.0 (SysML 2022), the Business Process Modeling Notation (BPMN) (BPMN 2011), Flowcharts (ISO 1985), and so on. Model-Based Systems Engineering 38 The Notation may be mathematically based, using equations or some sort of formal method as its communication mechanism. Examples of this include languages based on first-order predicate calculus and set theory, such as the Vienna Development Method (VDM) (VDM 1998), Z (Z 1998), the Object Constraint Language (OCL 2014), and so on. The Notation may be based on a natural language that uses structured or unstructured text as its basic communication mechanism. The Notation and its Diagrams are used to visualize the Views that comprise the Model. If the Model is imagined to be a large, complex collection of information and each View is analogous to opening up a small window into that Model, then the Diagrams may be thought of as applying different filters or lenses to each window. In the same way that it is possible to apply a number of different optical filters to change the appearance of whatever is on the other side of a window, it is possible to visualize each View in any number of different ways. As an example of this, consider a View that contains text-based descriptions of a number of Need statements, which will be referred to as a Need Description View. It needs to be established whether or not this is a valid View, and the following points address this: The Stakeholders that are interested in the Need Description View are the requirements engineer and the requirements manager. The Need Description View is required so that the Stakeholders can both gain a high-level appreciation for the number of needs and get a brief idea of what each need entails. The Need Description View contains a set of needs, each of which has a number of properties identified with it, such as its name, identifier, description, and priority. The three basic questions have now been answered, so the View can be confirmed as a valid View. The next question to ask is which language do the Stakeholders speak? and this will dictate how they are spoken to. In terms of the modeling, this will mean that different Notations may be used, as follows: The Need Description View may be visualized using structured text, with each need being a paragraph and the properties being bullet points displayed under each paragraph. The Need Description View may be visualized using UML Notation – specifically, a Diagram known as the class diagram, where each need is represented as a UML class and each property is represented by a UML attribute. Class diagrams in UML are very similar to block definition diagrams in SysML and, indeed, are the basis for block definition diagrams. Chapter 2 39 The Need Description View may be visualized using SysML using a requirement diagram, where each need is represented by a SysML requirement block and each of its properties is represented by a SysML property. This list represents just three possible options for visualizing the same View, making the point that any View may be visualized in any number of different ways. For the purposes of this book, a single Notation will be selected and used for all of the examples throughout. The Notation that will be adopted is SysML, which will be discussed in a lot more detail later in this chapter; therefore, the spoken language selected will be SysML. The next section will add to these concepts by introducing the two main concepts that comprise the approach. Defining the approach When developing a Model by creating a number of Views, it is obviously important that all of the Views are created in the same way, and this is one of the areas where the approach comes into play, as shown in the following diagram: Figure 2.5: Introducing the approach for MBSE The diagram in Figure 2.5 introduces part of the overall approach that is required for MBSE in the form of the Framework and its associated Viewpoints and Ontology. Consider a situation where it is desirable to ensure that all documents of a similar type have the same structure and contents. When dealing with documents, the answer to this is quite straightforward, in that a template would be defined for the document to ensure that all future documents are consistent and have the same look and feel. When considering MBSE and the creation of Views, the answer is the same, in that a template of sorts is considered. The template for the Views is referred to as a Viewpoint, which, when defined properly, will ensure that all of the Views that are created and that are based on the same Viewpoint will be consistent. Model-Based Systems Engineering 40 This is achieved by answering three basic View questions and storing the answers as part of the Viewpoint. Therefore, each Viewpoint contains the answers to the following questions: Which Stakeholders are interested in looking at the View? Why are they interested in looking at the View – or, to put it another way, what value will they realize? What information is contained in the View? Each Viewpoint, therefore, contains the answers to these three questions, which ensures that the structure and content of all Views that are based on the Viewpoint are consistent. In order to ensure that all of these Viewpoints are consistent with all of the other Viewpoints, it is necessary to have a common set of concepts and associated terminology that form the basis of the content for the Views. This is referred to as Ontology and is actually the domain-specific language that was introduced and discussed in Chapter 1, Introduction to Systems Engineering. Ontology is arguably the single most important part of MBSE as all of the other elements that make up MBSE are ultimately traceable back to the Ontology. Ontology will be discussed in a lot more detail in Domain Specific Language. When the Ontology and the Viewpoints are put together, they form what is known as a Framework. A Framework is created as a template, or blueprint, for a complete Model. One of the common terms that you may have encountered is that of the architecture Framework, which provides the template for System architecture. There is a very close relationship between modeling and architecture, but it is beyond the scope of this book to enter into a lengthy discussion and dialog concerning this relationship. It is sufficient for us to think about the two in this way: all architectures are Models, but not all Models are architectures. The second part of the overall approach that must be considered is that of the Process Set, as shown in the following diagram: Chapter 2 41 Figure 2.6: Introducing the Process Set for MBSE The diagram in Figure 2.6 introduces the concept of the Process Set to the overall approach to MBSE. The Process Set represents the collective set of individual processes that are used by the Framework in a number of ways: The Process Set is used to show how to develop the Framework, its Ontology, and its associated Viewpoints. The Process Set is used to show how to develop the Views that comprise the Model, based on the definition of the Viewpoints in the Framework. It is the combination of the Framework and the Process Set that provides the overall approach to MBSE. There are some key points to bear in mind when considering these two parts of the approach: The Framework focuses only on defining the structure, content, and consistency of the information that is produced and that is used to develop the Model in terms of its Views. The Framework, therefore, may be thought of as defining the “what” of the approach: what information must be produced to develop the Model? The Process Set focuses on the steps involved with both developing and using the Framework. The Process Set, therefore, may be thought of as the “how” of the approach: how is the Framework developed and used? Model-Based Systems Engineering 42 This conceptual separation between the Framework (what) and Process Set (how) means that it is possible to have a number of different Process Sets that use the same Framework. This is important, as different projects may follow different processes, depending on the nature of the project, but the underlying Framework will be the same. So, for example, there may be a research demonstrator project that has a timescale of only a few weeks that follows a set of high-level, technically light processes to develop its Model. In the same organization, there may be another project that is business-critical that may take a number of years to complete. The processes that are followed as part of this project will be far more detailed and rigorous and take far more time. However, the point here is that each project, despite following different Process Sets, may actually share the same Framework. This means that the Model produced by each project will use the same Framework and, therefore, the Views from each project may be compared and contrasted on a like-for-like basis. At this point, it is a good idea to take a short interlude and reconsider what has been discussed so far in this chapter. Grouping the MBSE concepts The information discussed so far is crucial to understanding MBSE, so it is worthwhile to take a brief pause to revisit the information collated so far and to add another level of information. To this end, the diagram that has evolved so far in this chapter has been grouped into three main areas, as shown in the following diagram, which is known in the Systems Engineering community as MBSE in a slide (Holt & Perry 2019): Figure 2.7: “MBSE in a slide” – adding the groups Chapter 2 43 The diagram in Figure 2.7 is used widely in the Systems Engineering community to disseminate the key concepts associated with MBSE. The three groups that have been added here are as follows: Approach: Groups together the Framework that comprises the Ontology and Viewpoints and the Process Set. Remember, the Framework focuses on what information must be produced for the Model, whereas the Process Set focuses on how that information must be produced and used. Goal: Groups together the System and the Model and its associated Views. Remember that the goal of any Systems Engineering endeavor is to develop the System. The goal of MBSE is also to develop the System, but this is achieved by developing the Model and its associated Views. Remember that each View is like opening a window to look at a small, focused part of the Model. Visualization: Groups together the Notation and its associated Diagrams. The Notation is the set of spoken languages that are being used as a basic communication mechanism for Systems Engineering. Remember that each Diagram is like opening a small window into the Model and looking at it through a lens or filter. All of the concepts that have been discussed so far may now be expanded upon by considering the Implementation and Compliance associated with MBSE. Implementing the Notation The next step in looking at essential elements for MBSE is to look at how the visualizations of the Views may be implemented in a pragmatic manner as part of an MBSE project. At this point, therefore, it is pertinent to introduce the idea of tools by expanding MBSE in a slide, as shown in the following diagram: Model-Based Systems Engineering 44 Figure 2.8: Expanding “MBSE in a slide” to include Implementation Tools are an important part of MBSE and will allow the full range of benefits of MBSE to be realized. There are two relationships that come out of the tools in the diagram: the Tool implements the Notation and the Tool implements the Framework. Let’s take a look at them: The Tool implements the Notation: This is important, as whichever Notation is adopted must be adopted correctly according to the syntax and semantics of the underlying language. When considering tools, it should be kept in mind that different tools will offer different levels of support for the Notation. For example, if a tool for a graphical Notation such as SysML is being considered, then it is possible to use any tool with a basic drawing capability to create the Diagrams, such as an Office tool. There is more to using SysML, however, than simply drawing the correct shapes and lines on a page, as the language itself has an underlying syntax and semantics that must be followed. When using a good MBSE modeling tool, the knowledge of the syntax and semantics will be built into the tool and, therefore, the tool can enforce the correct Notation by running syntactical and semantic checks on the Model. When producing a text-based document that is written in English, any good word processor will allow the author to run spelling and grammatical checks on the text. Imagine the syntax and semantics checks on a modeling tool to be analogous to the spelling and grammar checks in an Office-based tool. Remember that the Notation is the spoken language, so the tool will help to ensure that this spoken language is implemented correctly. Choosing an appropriate modeling tool means that the tool will speak the spoken language straight out of the box. Chapter 2 45 The Tool implements the Framework: This is important, as the Framework is a large part of the overall approach and it means that the tool will, therefore, implement a large part of the approach. The approach itself may be implemented by embedding the Ontology into the tool and by defining the set of Viewpoints (by answering the key questions for each View) into the tool. The approach contains the Ontology and, as the Ontology is the domain-specific language, this means that the tool can be tailored to speak the domain-specific language for the System. The tool will not be able to do this straight out of the box, and this Framework must be programmed into it. All good tools have the ability to create profiles that allow the tools to be tailored to implement, among other things, a specific Framework. Tools are an essential part of MBSE, and it is important to choose one that satisfies the modeling needs of the project. The next section introduces the final new concept, that of compliance. Showing compliance The final enhancement to the MBSE in a slide diagram is to add the concept of Compliance. When this has been added, the diagram is complete and is referred to in the MBSE community as MBSE in a slide and a bit, as shown in the following diagram: Figure 2.9: Completed diagram – “MBSE in a slide and a bit” Model-Based Systems Engineering 46 The final piece of information that has been added is that of Compliance, which contains Best Practice, as it is important in Systems Engineering that every activity performed is carried out in a rigorous, robust, and repeatable manner. This is achieved by demonstrating that the MBSE approach complies with various best practice sources. These sources may be the following: Process-based standards, which may exist at different levels, such as international standards, industry standards, in-house standards, and so on. Typically, standards that relate to how to carry out an approach are based on processes; therefore, the Process Set must be shown to be compliant with the best practices. There are many process-based standards that exist, and the most widely used standard for Systems Engineering is ISO 15288 – Software and Systems Engineering life cycles and processes (ISO 2015). Framework-based standards, which may exist at different levels, such as international standards, industry standards, and in-house standards. Typically, standards that are based on the information that must be produced as part of an approach are based on the Framework; therefore, this Framework must be shown to be compliant with the best practices. There are many Framework-based standards that exist. At the international level, the most widely used standard is ISO 42010 – Systems and software engineering — Architecture description (ISO 2011). There are also many industry standards, such as MODAF (MODAF 2010), DoDAF (DoDAF 2007), and NAF (NAF 2007), as well as the UAF (UAF 2017) for the defense industry. Zachman (Zachman 2008) is also used extensively in the IT industry, among others. Application-based standards, some applications of Systems Engineering have their own specific standards that may be used in any number of different industries. Examples of such standards include best practice sources for areas such as safety, security, usability, maintainability, and so on. This set of best practice sources is not intended to be exhaustive but provides an indication of the types of standards and related sources that may be considered. The next section focuses on how to use the information presented so far in the context of MBSE. Using MBSE The concepts shown in Figure 2.7 and Figure 2.9 must be understood in order to properly understand and, therefore, be able to implement Systems Engineering using MBSE. These diagrams are also important for a number of other practical reasons when it comes to deploying MBSE into an organization. Chapter 2 47 These diagrams may be used as an indication of the current MBSE capability within an organization or organizational unit. Every organization must start its MBSE deployment somewhere, and this diagram provides an overview of the five main areas, shown as the groups that must be considered as part of this deployment. It must be stressed that the diagram is not read from left to right, and it is certainly not the case that the MBSE activities are also put into place in the same way. The diagram should be used in the first instance as a checklist to ascertain what capability exists for each group. Once the capability for each group has been determined, it is then possible to perform a gap analysis and decide which groups need to be implemented, and then prioritize each group. In order to illustrate this, consider these two common examples: An organization has decided that it wants to implement MBSE and, as a first step, has decided to adopt the SysML Notation and, as part of this adoption, has purchased a number of tools. There is nothing wrong with this as a first step per se, but the mistake that many organizations make is to think that MBSE can be successfully implemented simply by buying tools. It is clear from the diagram that there is no approach in place and, therefore, compliance cannot be demonstrated. Also, it will not be possible to tailor the tool to adopt the approach, as there is no approach in place. In this situation, it may be appropriate to look at getting the approach in place and then the compliance in order to deploy MBSE. An organization has decided that it wants to implement MBSE and so has identified an architecture Framework that is used by a similar company, and has also identified that ISO 15288 is the standard that they would like to follow. Again, there is nothing wrong with this as a first step. The organization may think that it has a good approach in place, but it has confused the approach (architecture Framework) with the compliance (standard). A Process Set must be developed that complies with the standard and suits the way that the organization works. Also, what is to say that the architecture Framework that has been chosen is actually suitable for the nature of the business? Problems such as the ones illustrated here are not necessarily easy to address, and one way to get additional insight into them is to consider the maturity of MBSE in the business by looking at its evolution. This will be discussed in the next section. Model-Based Systems Engineering 48 The evolution of MBSE One key factor that must be considered when implementing MBSE into an organization is the maturity of the MBSE activities, which may be addressed by looking at the evolution of MBSE. The evolution of MBSE may be thought of as ranging from a document-based approach to Systems Engineering, all the way to a full Model-based approach to Systems Engineering. This is not a simple transition, however, and there are five conceptual stages that must be considered, as shown in the following diagram (Holt & Perry 2020): Figure 2.10: The evolution of MBSE (Holt & Perry 2020) The diagram in Figure 2.10 shows the evolution of MBSE by identifying five key stages that help to understand how MBSE can be implemented and deployed in an organization. Each stage will be described by discussing the following criteria: Outcomes: In Chapter 1, Introduction to Systems Engineering, the implementation of MBSE was covered very briefly by discussing how the people, processes, and tools need to be effectively managed and balanced. Each stage, therefore, considers the people, process, and tools outcomes that will typically be in place for each of the stages. Knowledge ownership: The ownership of the knowledge and where the knowledge resides will change as the evolution progresses through the five stages, and it is important to understand exactly how this happens. Pre-conditional activities: In order to be in any one of the stages, there are a number of activities that must have been performed before the stage can be entered. Each stage will now be discussed according to these criteria. Chapter 2 49 Stage 1 – Document-Based Systems Engineering Stage 1 of the evolution of MBSE is referred to as Document-Based Systems Engineering. For Stage 1 in the diagram in Figure 2.10, a large pile of documents is depicted. This implies that there are lots of documents associated with this stage of evolution. While this is true, it must also be kept in mind that the knowledge associated with the System is spread throughout these documents, rather than being contained in a single location. At this stage, the people, process, and tools outcomes may be considered as follows: People: The people involved in this stage are assumed to have basic competence in Systems Engineering. The reality is that any organization that is delivering Systems must have a Systems Engineering capability, even if it is a tacit capability that is not formally captured or documented. When people are in this situation, it may be that they claim to want to put a basic Systems Engineering capability in place before considering MBSE. This is a huge mistake. Remember that MBSE is Systems Engineering, so there is no point in doing both – just aim straight for MBSE. Process: The process that is in place may or may not be documented, but there will be a process in place. In either case, the main artifacts, that is, the inputs and outputs of the process, will be documents. These documents will be predominantly text-based and also include tables, graphs, lists, and so on. Tools: The tools involved in Stage 1 will usually be Office-based tools, such as word processors, presentation applications, and spreadsheets. In Stage 1, all of the knowledge, information, and data concerning the System will be contained solely in the document set that is created as a result of executing the process. There is no Model whatsoever in place, so everything is both contained and owned by the documentation. The basic pre-condition for Stage 1 is that there must be some sort of basic need for MBSE that has been identified within the organization. Stage 2 – Document-Centric Systems Engineering Stage 2 of the evolution of MBSE is referred to as Document-Centric Systems Engineering. For Stage 2 in the diagram in Figure 2.10, a large pile of documents is again depicted, but this time, with two main changes. Firstly, the pile of documents has increased slightly. Secondly, rather than being mainly text-based, there is some evidence of people starting to use Notations as part of the documents. The knowledge associated with the System is still entirely contained in the documents, as there is still no presence of a Model. Model-Based Systems Engineering 50 In this stage, the people, process, and tools outcomes may be considered as follows: People: The people involved in this stage are assumed to have a basic competence in Systems Engineering, the same as in Stage 1. This time, however, there will be evidence of people applying Notations at an informal level. The reality of this is that what is being produced is a set of pictures rather than true Views that will make up a Model, but this is typical at this stage, as the people will be experimenting with different Notations in an ad hoc manner. Process: In this stage, the artifacts associated with the process are still documents but, in line with the previous point, there will be the beginning of Notations being used to support the text descriptions. Tools: In this stage, the tools will be the same as in Stage 1 but the difference is that actual drawing packages may have been used to create the diagrams that form part of the documentation. In Stage 2, all of the knowledge, information, and dates concerning the Systems are still solely contained in the document set. This is important, as the diagrams that have been produced are not truly part of a Model and cannot, therefore, own any of the knowledge associated with the System. Also notice that, at this stage, the pile of documents has actually become slightly taller, which represents the increase in information. At this stage, like Stage 1, all of the data, information, and knowledge associated with the System is contained in the documents. As the data, information, and knowledge are contained in the document and this is the only place where it resides, the documents may be thought of as owning all of this information. The basic pre-conditions for Stage 2 are the following: The goals for MBSE must be formally captured. This will include what the scope of MBSE implementation will be and which Stakeholders exist. For each of the Stakeholders, a set of benefits must be identified. This is crucial as, otherwise, it cannot be demonstrated whether the MBSE initiative has been successful or not. If the goals or needs for the initiative have not been identified and defined, then it is impossible to validate these needs. A basic assessment of the current MBSE in the organization must be ascertained. This will include identifying the current MBSE capability of the organization, which can be realized by looking at the MBSE in a slide that was introduced in the previous section in Figure 2.7 and Figure 2.9. The second part of the assessment is that the current maturity of the MBSE capability must also be ascertained. This can be realized by looking at the evolution of MBSE in Figure 2.10. Chapter 2 51 During this stage, it may also be that some MBSE may be used to carry out the previous points without people actually realizing it. When this happens, it is often referred to as MBSE by stealth, where MBSE is actually being used in order to implement MBSE without people realizing that this is going on. Stage 3 – Model-Enhanced Systems Engineering Stage 3 of the evolution of MBSE is referred to as Model-Enhanced Systems Engineering. This is interesting, as it is the first stage where the term Model is introduced. The diagram in Figure 2.10 shows the Model starting to emerge from the pile of documents, which implies that the knowledge is now split between the Model and the document set. In this stage, the people, process, and tools outcomes may be considered as follows: People: The people involved in this stage have now investigated Notations in more detail and have received some sort of formal notational training so that they exhibit notational competence. Also, the people will have an awareness level of the competence of MBSE concepts or, to put it another way, they are familiar with the “MBSE in a slide” concepts that were introduced and described in Figure 2.7 and Figure 2.9. Process: In this stage, the true Model comes into existence and emerges from the documents. The Model contains and owns some of the knowledge associated with the System. The knowledge is now split between the Model and documents, rather than being solely owned by the documents. Also, the pile of documents starts to reduce in size. In this stage, MBSE will start to be applied in a serious manner, usually by implementing the emerging MBSE approach on a pilot project with a limited scope. By doing this, it is possible to demonstrate the benefits of MBSE, based on the goals identified previously, before rolling it out across the rest of the organization. Tools: In Stage 3, there is typically more than one tool that is being used as part of the modeling. It is always advisable to carry out a full tool evaluation where possible and, in such cases, there will be a set of candidate tools that have been previously identified for potential use in the organization. In Stage 3, all of the knowledge, information, and data associated with the System are split between the now-emerging Model and the documentation set. This is important, as it really represents the first time that MBSE is being applied properly in any project. Model-Based Systems Engineering 52 The basic pre-conditions for Stage 3 are the following: People will have had some formal Notation training to enable them to start modeling in an effective way, rather than in the ad hoc way that it has been applied previously. A formal tool evaluation should have been considered in order to narrow down the set of candidate tools to a single preferred tool. In many cases, Stage 3 may be an initial goal for MBSE in the short term in order to demonstrate the benefits of applying such an approach. Indeed, for some organizations, achieving Stage 3 may actually be the final goal, but it is more usual for Stage 3 to be a short-term goal. Stage 4 – Model-Centric Systems Engineering Stage 4 of the evolution of MBSE is referred to as Model-Centric Systems Engineering. At this stage, the Model is almost complete, as shown in the diagram in Figure 2.10, and owns most of the knowledge associated with the System. At this stage, the people, process, and tools outcomes may be considered as follows: People: The people involved at this stage now exhibit competence in MBSE and also in the use of the candidate tool. The people now have a very strong understanding of MBSE and are using it to great effect. The tool is being used in an efficient manner and is being driven by the MBSE approach that is in place. Process: In this stage, the approach is almost fully MBSE-based. The initial Framework is now in place, including the Ontology, and as a set of Viewpoints that are being used as a basis for the modeling. Consistency is also enforced through the use of the Framework, and the Views in the Model are created according to an initial Process Set. In this stage, the pilot project that was introduced in the previous stage is measured and assessed in order to demonstrate how effective the MBSE approach has been. The pilot project must be measured and assessed according to the goals that were established prior to Stage 2. Tools: In Stage 4, the preferred tool has been selected and is now being used on real projects. In Stage 4, almost all of the knowledge, information, and data associated with the System are contained and owned by the Model with only small pockets still residing in the document set. As a consequence of this, the pile of documents is now significantly reduced. The basic pre-conditions for Stage 4 are as follows: Formal MBSE training has now taken place so that all relevant team members now have the right set of skills to implement the MBSE approach. Chapter 2 53 The initial Process Set has been defined and is being applied to generate the Views that make up the Model. The initial Framework, including the Ontology and Viewpoints, has now been developed and is being applied to real projects. The preferred tool(s) has now been selected from the set of candidate tools. In large organizations, it is not unusual for several to have been selected. The people have been trained formally in the use of the preferred tools. Stage 4 sees MBSE being applied at an advanced level, with many of the benefits that were anticipated now being realized. Stage 5 – MBSE The final stage of MBSE evolution, Stage 5, is the ultimate goal for any MBSE endeavor. Stage 5 sees all of the knowledge associated with the System being contained and owned in the Model, which has now fully emerged and exists as an entity in its own right. This stage is, of course, MBSE. In this stage, the people, process, and tools outcomes may be considered as follows: People: The people involved in this stage now have mastery over MBSE and its application in the organization. The people strive to continuously maintain and even improve their competence so that the approach can be enabled as efficiently and effectively as possible. Process: The approach is now entirely Model-based. The Framework and Process Set are now mature and are being applied on multiple projects as part of a company rollout. Advanced application of MBSE is now being implemented, including the implementation of advanced applications, such as pattern identification, definition, and application; process and competence modeling; variant modeling; and so on. Tools: The tools that are being used are now tailored to allow the approach to be enforced automatically. This will include applying automatic domain-specific language consistency checks based on Ontology, automatic document generation, and other advanced tool functionality using profiles. In this stage, various different types of tools will also interoperate in a seamless fashion so, for example, management tools will interact with MBSE modeling tools, which will interact with mathematical modeling tools, and so on. In Stage 5, all of the knowledge, information, and data associated with the System are contained and owned by the Model. The diagram in Figure 2.10 shows that the Model is now fully formed and exists in its own right. Although no documents are shown here, there will always be some documents that exist. Model-Based Systems Engineering 54 The point here is that the documents do not own any of the knowledge and, in fact, should be perceived as just another set of Views that make up the Model, albeit text-based Views. The basic pre-conditions for Stage 5 are as follows: Advanced applications are being applied, including competence and process modeling, variant modeling, project-related applications, and so on. The MBSE approach that is in place is being continually measured, assessed, and improved by applying competency assessment, process maturity assessment, and Model maturity assessment. The tool has been tailored by creating profiles that enable various types of automation to be possible. Stage 5 is the ultimate goal, but it is essential that the whole MBSE approach is always continuously assessed and improved. The next section introduces concepts that may be applied across all of our MBSE in the form of cross-cutting concepts. Cross-cutting concerns As can be seen in the evolution of MBSE, the Model has its origins in Stage 2, starts to emerge in Stage 3, is almost complete in Stage 4, and is whole in Stage 5. From the point of making the decision to implement MBSE (which is Stage 1), it is important that several key mechanisms are put into place in order to ensure that the Model can be properly managed and controlled throughout the whole evolution. These mechanisms are referred to as cross-cutting concerns and include the following: Configuration management: The Model is a living entity and its evolution must be controlled by applying effective configuration management. Change control: It needs to be clear how changes are managed and what the process is for requesting and making changes to the Model. Also, the permission must clearly define which Stakeholders are allowed to view, edit, or create different parts of the Model. Consistency: The Model must be valid and, therefore, consistency must be ensured throughout the life of the System. Traceability: It is essential that all parts of the Model, whether directly or indirectly, are traceable to all other parts of the Model. This is important for impact analysis, change control, and so on. Chapter 2 55 Maintenance: The Model must be able to be edited, checked, and appended according to the change control processes, but the Model must also be available to the relevant Stakeholders using the tool. Most of these cross-cutting concerns will be covered to a certain extent by existing engineering processes within a business. Modeling with MBSE This section introduces the key concepts of modeling, as well as the spoken language that will be used throughout the rest of this book – the Systems Modeling Language, or SysML, as it is commonly known. It is important to understand exactly what is meant by modeling and also why modeling is needed in the first place. It is also very important to understand exactly what SysML is and what it is not, as there are many misconceptions associated with SysML and much confusion about how it fits in with the whole of MBSE. Indeed, one of the most common misconceptions is that SysML is actually the same as MBSE! Before the main discussion begins, it should be pointed out that there are many different types of modeling, as discussed previously in this book. For the purposes of the discussion in this chapter and for the remainder of the book, when the term modeling is used, it is referring to visual modeling, which means that diagrams are being used as a basis for the spoken language. At the heart of MBSE lies the act of modeling, so it is crucial that some key concepts concerning MBSE are both well defined and well understood, and it is also necessary to understand the need for modeling in the first instance. The need for modeling The fundamental reasons why modeling is needed come back to the same fundamental reasons of why it is necessary to carry out Systems Engineering: the three evils of Systems Engineering, as discussed in Chapter 1, Introduction to Systems Engineering. These three evils will be revisited now, but with an emphasis on how and why modeling can help to address them. The first evil of Systems Engineering is identified as being the complexity that is manifested by a System, whether it is essential (inherent in the System) or accidental (caused by the people, process, and tools associated with the approach). 56 Model-Based Systems Engineering Modeling can help with complexity, as the visual nature of the Views that are created provides an instant visual assessment of both the complexity and, importantly, where the complexity lives within the Model. Identifying the complexity is key to managing and controlling it. For essential complexity, once the complexity has been identified, then the dependency on the parts of the System where the complexity manifests itself the most can be limited and, therefore, controlled. For accidental complexity, once the complexity has been identified, it can be rationalized and minimized to keep the level of complexity as low as possible. The second evil of Systems Engineering is a lack of understanding at various points in the life cycle. Modeling can help here, as there are two very simple rules that can be applied when modeling any sort of information. Rule 1 is that if the Model is easy to generate, then it means that the source information is well specified and, therefore, well understood. In such situations, the Model seems to naturally fall out of the source information, and the modeling activity is very quick and straightforward. Rule 2 is the complement of Rule 1. If the Model is very difficult to generate with lots of ambiguity, uncertainty, and missing information, then the source information is poorly understood and poorly specified. In such situations, the Model is very difficult to abstract from the source information, and the whole modeling activity is time-consuming and effort-intensive. The third evil of Systems Engineering is identified as poor communication between various Stakeholders. Modeling helps in two ways here. It was discussed, in Chapter 1, Introduction to Systems Engineering, how efficient and effective communication requires a common language, which actually requires both a spoken language and a domain-specific language. Modeling helps to realize both of these; the choice of Notation is the spoken language and the definition of Ontology is the domain-specific language. Each of these is explored in more detail in the next two major sections. So, modeling helps to address the three evils of Systems Engineering, which also explains why MBSE is such a powerful approach to realizing Systems Engineering itself. The next section covers how we begin to define the Model. Defining the Model The Model was defined earlier in this chapter as being an abstraction of the System. Think of abstraction as being a simplified representation of the System, in this case, using graphics or diagrams as the medium. As the Model is an abstraction of the System, it is, by necessity, a simplification of the System, which means that it cannot contain every single possible piece of information associated with the System. The Model must be a simplification of the System and, therefore, there will be information associated with the System that is not contained in the Model. Chapter 2 57 This does not mean that the Model is wrong or incomplete, providing that all of the relevant and necessary information is contained in the Model. There is an inherent danger in this, as it means that it is important to be able to ascertain whether there is any missing relevant information or not. There is no way that this can be guaranteed 100%, but by applying a good, solid MBSE approach in the form of a Process Set and Framework, the risk of omitting such information is vastly reduced. As well as being an abstraction of the System, the Model was defined as comprising a number of Views, each of which has a target audience, a need, and a defined set of information contained therein. The definition of each Viewpoint is key in order to have confidence that no relevant information is missing. The next part of the definition of the Model was that each View must be consistent with every other View. This is essential. If the Views are modeled and they are not consistent, there is no Model, just a collection of pictures. If the Views are modeled and they are consistent with each other, then there is a Model. Consistency is key when it comes to modeling, and this cannot be stressed enough. The use of a good Notation, such as SysML, is important as it will provide mechanisms within the Notation that will demonstrate whether the diagrams that are used to visualize the Views are consistent or not. Two aspects of the Model When creating a Model, it is important to understand there are always two aspects to the Model: the structure and the behavior. Let’s look at these in more detail: Structure: The structure of the Model defines the what of the Model – what the main elements in the Model are, what the relationships between these elements are, and what each of the elements does. The structure will also allow hierarchies of the System, both in terms of taxonomy (types of System elements) and the breakdown of conceptual levels (compositions of System elements). The relationships between the System elements are just as important as the System elements themselves, which is the key tenet of Systems thinking. Behavior: The behavior of the Model defines the how of the Model. Here, we look at what order things happen, under what conditions they happen, and what the timing constraints are. While structure allows the Model to be broken down into hierarchies, the behavior tends to apply to specific levels of the hierarchy. Also, the relationships are considered dynamically, rather than statically. Model-Based Systems Engineering 58 Every Model will have both structure and behavior associated with it, which, in real terms, means that there will be structural Views and behavioral Views that make up the Model. As all of the Views in the Model must be consistent in order for it to be considered a Model, this means that the structural and behavioral aspects of the Model must be consistent with each other. The Notation that is used in this book is SysML, which describes nine different diagrams that can be used to visualize the structural and behavioral aspects of the Model. When and where to Model There is often a lot of debate about at which point in the life cycle (where) and under what circumstances (when) modeling should be applied. The answers to these two points are quite simple. Modeling should be applied at any stage in the life cycle where the following apply: There is unidentified, unmanaged, or uncontrolled complexity in the System (evil number 1). There is a need to understand any aspect of the System (evil number 2). There is a need to communicate effectively and efficiently with any of the Stakeholders (evil number 3). In terms of under what conditions, or when, modeling should be applied, it should only be applied when value is being added by carrying out the modeling. This last point is quite abstract but crucial. Every activity that is performed as part of MBSE must add value and contribute toward realizing the System successfully. If this is not the case, then it should not be done! Sometimes, it is necessary to go a step too far with the modeling and to arrive at the conclusion that, as there is no longer any value being added, the modeling should be stopped. The use of an effective Framework will address this because the reasons why each View is needed will have already been decided and, providing that people adhere to the Framework, no Views will ever be created where there is no defined need or benefit. The spoken language – the Systems Modeling Language SysML is a general-purpose visual modeling language. SysML is itself based on another general-purpose visual modeling language, known as UML. UML is a language that has its roots firmly in the software engineering world and was created for very pragmatic reasons. Prior to 1997, when the first version of UML was released, there was a whole plethora of modeling notations and methodologies that were being used for software engineering. In fact, there were over 150 different recognized approaches available. Chapter 2 59 Bearing in mind that one of the aims of a modeling notation is to provide a basic mechanism for communication, there were simply way too many available, which made the choice of Notation both bewildering and difficult. In the mid-1990s, therefore, the software industry collectively decided that there were too many languages and that there should be a single, standardized, common language that everybody could use. It was important that the language would not be proprietary and, therefore, it was decided that the Object Management Group (OMG), which is an international standards body that manages and configures standards relating to object technology, would own the new language. In 1997, UML was formally released to the software engineering world. As UML was a general-purpose modeling language, it actually had a far wider scope than just software and, indeed, it was used extensively in the Systems Engineering community (Holt 2001). UML was adopted so widely that, in 2004, it was decided by INCOSE that there should be a variation of UML that could be applied specifically to the Systems Engineering world, hence SysML was born. SysML is still owned, managed, and configured by OMG, and the standard itself can be downloaded from the OMG website. SysML is technically a profile of UML. You should think of the relationship between these two languages as UML being the parent language and SysML as a dialect of that language. This section will begin by discussing exactly what SysML is and what it is not. This is important, as there are many myths concerning the nature of SysML. Nine SysML diagrams will then be introduced at a high level and more specific examples of structural and behavioral Models will be provided. What SysML is (and what it is not) Many of the previously available modeling Notations were actually methodologies in that they had an in-built process that was used alongside the Notation that dictated which diagrams to use and at which point in the development. SysML is purely a Notation and has no inherent process. This is a very important point that needs to be very clear and well-understood. Looking back to “MBSE in a slide” in Figure 2.7 and Figure 2.8, SysML sits on the right-hand side of the Visualization group. SysML is just one, albeit an essential, part of an overall MBSE solution; it is not MBSE. Model-Based Systems Engineering 60 The SysML diagrams SysML may be thought of as a toolbox that contains nine different diagrams that collectively allow both the structural and behavioral aspects of the Model to be visualized. The structural diagrams are as follows: The block definition diagram (bdd) is by far the most widely used of all the SysML diagrams. Every Model will contain Views that are visualized using bdds, and it is important to have a good grasp of the basics of this diagram. The internal block diagram (ibd) is actually a variation on the bdd and is used to show the structure inside specific blocks and configurations. The requirement diagram (rd) is a block diagram with a few specialized elements of Notation that can be used to specify text-based requirements, or needs, and a set of predefined properties for each. Requirement diagrams are used primarily for requirements management, as opposed to requirements engineering. The parametric diagram (par) allows properties of blocks (contained in block diagrams and internal block diagrams) to be reasoned about by applying constraints, such as equations and heuristics. The parametric diagram forms the bridge between the visual world of MBSE modeling and the formal, mathematical world of Model-Based Engineering (MBE) modeling. The package diagram (pd) allows groups of elements on other diagrams to be collected together and partitioned. It is one of the lesser-used SysML diagrams, but packages can also appear on other diagrams, which is a more typical use. One of the key points to observe here is that all the structural diagrams are closely related. In fact, they are all either a variation of, or very closely linked to, the bdd. When beginning with SysML, it is a good idea to simply default to using bdds for the structural aspect of the Model and to bring in the other diagrams as and when they are required. The behavioral diagrams are as follows: The use case diagram (uc) allows high-level behavior, such as context, to be visualized. It is particularly useful for needs modeling, such as requirements engineering. Use case diagrams are one of the more widely used SysML diagrams, but are also undoubtedly the most badly used of all the SysML diagrams! Chapter 2 61 The sequence diagram (sd) allows scenarios to be modeled and focuses on the interactions between Model elements, such as blocks. Sequence diagrams are typically used at high levels of the Model and are a key tool for any Systems Model. The state machine diagram (smd) focuses on the behavior inside individual blocks and their instances. State machine diagrams are typically used at a low level of detail and may be driven by states or events, and are widely used throughout Systems Engineering. The activity diagram (ad) allows very detailed behavior inside specific operations to be modeled. Activity diagrams are often used for the implementation modeling and reverse engineering of legacy Systems, and are based on classic flow charts for their notation, (whereas the semantics are based on token-flow semantics, such as Petri nets). Hence, many people will feel comfortable using them, as they have seen something similar before in terms of syntax. Behavioral diagrams are typically applied at different levels of abstraction, whereas structural diagrams allow multiple levels of abstraction to be shown on the same diagram. There is obviously a very close relationship between diagrams of the same type (structure or behavior), but also between diagrams of different types (structure and behavior). It is these relationships that form the basis of the Notation and of the consistency checks that can be applied to any SysML Model to demonstrate that it is compliant with the underlying SysML Notation. It should be remembered that this book is not a book that is focused on SysML, but rather, one that uses SysML as its preferred Notation. With this in mind, the full syntax of SysML will not be covered in great detail, but the basics of SysML will be introduced as and when they are used throughout the book. The next section will introduce some of the key SysML diagrams by considering the existing example System of a car, but this time, using SysML, rather than the generic “squares and lines” Notation that has been used thus far in the book. Example structural modeling It was mentioned in the last section that the go-to diagram for structural modeling in SysML is the bdd, which is an abbreviation of the term block definition diagram. In this section, the basics of bdds will be introduced and discussed. It should be remembered that these are only the basics, and this is not intended to be an exhaustive description of bdd elements. Model-Based Systems Engineering 62 Identifying basic blocks and relationships A bdd comprises two main elements, which are as follows: The block: This represents a concept of something that forms part of the System. A block is represented graphically by a rectangle with the word in it. The word is used to reference that it is a stereotype of a UML element called a class. Stereotypes are an advanced modeling concept that will be discussed later in the book. For now, it is enough to understand that the term is used simply to identify a block. The relationship: This relates one or more blocks in the System to one another. There are various types of relationships that will be discussed as this section progresses. In order to illustrate these two elements, consider the following diagram: Figure 2.11: bdd – simple block and association The diagram in Figure 2.11 shows two blocks – Driver and Car – which are somehow related. The blocks are shown as rectangles with the term , and the relationship, known as an association, is shown by simply drawing a line between the two blocks. Any SysML diagram should be able to be read out loud and it should make sense. If this diagram was read out loud, it would read as “there are two blocks – Driver and Car – and there is a relationship between them.” This does read as a good sentence but does not convey too much information about the car or driver and about the relations between them. This diagram can be easily enhanced by adding some more information about the relationship, as shown: Figure 2.12: bdd – named association Chapter 2 63 The diagram in Figure 2.12 includes some adornment on the relationship, as the association has now been given a name and a direction. The name is drives and the direction shows that the association is to be read from left to right, which is indicated by the small triangle that is shown above the association line. This diagram now reads Driver drives Car, which is far more precise than what was shown in Figure 2.11. Each block represents the concept of something, so both Driver and Car represent the concepts of Driver and Car rather than any specific, real-life examples of them. Such specific, real-life examples of a block are referred to as instances. So, for example, Car is a concept, whereas Jon’s car is a specific, real-life example of a car and is, therefore, an instance. When naming associations, the words written on the line are typically verb constructs that, when read out loud, will form a natural sentence. Here, Driver drives Car is a perfectly correct English sentence that will make sense to most people when they hear it. The direction indicator shows which direction to read the association name in and is very important for the overall meaning of the diagram. It is also possible to show a two-way, or bidirectional, association by simply omitting the small triangle. Caution must be exercised here, however, as if the direction is accidentally omitted, it has meaning in SysML! This diagram may be enhanced further by showing numbers between the two blocks: Figure 2.13: bdd – multiplicity The diagram in Figure 2.13 shows how numbers may be added to each end of the association, which is known in SysML as multiplicity. This diagram may be read as one Driver drives one Car. This sentence is correct, but there is a subtlety to the numbering that can easily be mistaken. The numbers on each end of the association do not refer to absolute numbers but actually refer to the ratio of instances of each block at each end of the association. This diagram does not imply that there is only one driver and only one car, which it may look like at first glance. What this actually states is that for each real-life example of Driver, there will be one real-life example of Car. The word “each” is important here, as it conveys this meaning far less ambiguously than using the term “one.” This diagram should be read, therefore, as each Driver drives one Car. Model-Based Systems Engineering 64 Each end of the association has its multiplicity shown, and there are a number of standard options that can be used: 1 indicates one instance, as shown in this example. 1…* indicates one to many instances. 0…1 indicates zero to one instance. 0…* indicates zero to many instances. 1…10 indicates a range of between 1 and 10 instances. 2,4,6,8 indicates one of a set number of instances. As an example of this, consider the following diagram: Figure 2.14: bdd – adding more blocks and multiplicities The diagram shown in Figure 2.14 has added a new block called Passenger that has an association with Car. This section of the diagram is read as between zero and four passengers ride in each car. Note how the multiplicity this time is shown as 0…4, which shows that there may not even be any passengers, and that passengers are optional, whereas Driver is not optional and must always be present. It should also be noted that when writing the names of the blocks and the words that make up the association, the singular should always be used. Therefore, the block is Passenger and never Passengers and the verb constructs assume the singular, so the verb is rides in rather than ride in. Always show the blocks and verbs in their singular form and imply the plurality using multiplicity. Associations typically show the relationships between multiple blocks, but it is also possible to show a self-association – that is, a relationship from one block back to itself, with the same multiplicity rules applying. Chapter 2 65 There is also a variation of an association that shows a relationship from a block to an association, rather than to another block, as shown in the following diagram: Figure 2.15: bdd – the association block The diagram in Figure 2.15 shows an association block that is named Control Panel. An association block relates a block to an association, rather than to another block. It is a good way to provide more detailed information about a relationship or interaction between blocks. The expression to use when reading an association block out loud is the word via. The diagram here, therefore, reads as “Each Driver drives a Car via a Control Panel.” Describing a block in more detail Each block may also be described in more detail, by identifying and defining its features – mainly, its properties that describe what the block looks like and its operations that describe what the block does. When describing any block, there is the option to add more detail by identifying a number of properties that describe specific features of a block, as shown in the following diagram: Figure 2.16: Describing blocks – identifying properties Model-Based Systems Engineering 66 The diagram in Figure 2.16 shows the Car block, but this time, a number of properties have been added that describe specific features of the block. Properties are shown by adding an additional compartment underneath the name of the block. A number of properties may then be added inside that compartment. Each property should describe a single feature of the block and should be a singular noun. In the example here, there are three properties that have been identified, which are as follows: Make, which refers to the manufacturer of the car. Model, which refers to the specific variation or configuration of the car that is available to buy. Registration, which refers to the unique registration number that is allocated to the actual car. It is important that each of these properties can take on a number of different values and these values are defined when the block is initiated. To illustrate this, consider the Car block, which has three generic properties that will apply to all instances of Car. When a real-life example of Car is considered, let’s use the instance of Jon’s car, then the properties will have their actual values defined, so the Make property may be set to the value Mazda, the Model property may be set to the value Bongo, and so on. When properties have been identified, it is also important that they are defined in more detail, to avoid any unnecessary ambiguity, as shown in the following diagram: Figure 2.17: Describing blocks – defining properties The diagram in Figure 2.17 shows the same Car block with its three properties but, this time, more information has been added to define the nature or type of values that each property may take. In SysML, everything is “typed,” which means that everything must have a definition of the types of values that it may take on. These types may be simple or more complex. Chapter 2 67 Simple types are similar to standard variable types from the software engineering world, such as the following: int: Integer number char: Character real: Real number bool: Boolean, true or false The list continues, but these are well-established types that are generally known and well understood. Each type is indicated by having a colon after the property name and then showing the type name immediately after it. It is also possible to show ranges of values and default values for each property, and these shall be described where appropriate as the book progresses. It is also possible to define more-complex types, in which case it is possible to create another block, identify and define its properties, and then use that as a type. An example of this is shown in the diagram with the block Reg_Type. The Registration property is not a simple type but is a construct of a number of alpha-numeric characters in a specific order with a specific meaning. In the UK, the standard registration number comprises three main elements, which are as follows: Area_ID: A set of two letters that indicate where the car originated Year_ID: A set of two single-digit numbers that indicate which year, and which half of the year, the car was manufactured Number_ID: A set of three letters that provide the final part of the unique identifier for the car This block may now be used as the type for the property of Registration on the Car block. When defining the set of properties, SysML states that they should appear in alphabetical, rather than logical, order as, strictly speaking, no order should be inferred from the set of properties. 68 Model-Based Systems Engineering The properties of a block describe what a block looks like, and it is also possible to show what a block does by describing its operations, as shown in the following diagram: Figure 2.18: Describing blocks – identifying operations The diagram in Figure 2.18 shows a more-complete diagram, with more properties shown for the blocks that have been identified so far. Note that the two blocks Driver and Passenger each have a default value for Age indicated by showing it after the equals (=) sign after the type definition. In addition to the properties, the Driver block has an additional compartment shown that has an operation identified as drive in it. Operations allow elements of behavior to be identified and defined that are associated with a specific block. It should be noted that operations show what the behaviors are, rather than how they behave – that is, they’re done by using behavioral diagrams in SysML. Chapter 2 69 Each operation should be a verb to reflect its behavioral nature. These operations have parentheses after them, which allow return values and various parameters to be defined. Again, these will be dealt with when the need arises throughout the book. Describing relationships in more detail In the same way that blocks may be described in more detail, there are also several special types of relationships that allow more details to be added to the diagrams. The basic type of relationship is the association, which has been discussed already and shows a simple relationship between one or more blocks. A variation on this, the association block, was also described, which allows a via relationship to be added. Another standard type of relationship, which is actually a special type of association in SysML, is known as composition, and is used to show structural hierarchies, as shown in the following diagram: Figure 2.19: Describing relationships – composition The diagram shown in Figure 2.19 shows the concept of composition, which is shown graphically as a filled-in diamond shape at one end of the association. When this symbol is seen, the words is composed of or comprises should be used when reading the diagram. The composition is read from the diamond end, and the usual rules of multiplicity apply. This diagram, therefore, reads as Car is composed of one Body, one Chassis, one Interior, and one Drive Train. The diagram actually has four separate compositions on it, one for each lower-level block, but these are usually shown as overlapping, as is the case here, for reasons of clarity and readability. Model-Based Systems Engineering 70 Composition allows a block to be decomposed into lower-level blocks so that structural hierarchies may be shown. The diagram here only has a single level of decomposition, but there is no reason why multiple levels cannot be shown on the same diagram, and, indeed, this is quite common. There is also a variation in a composition that is known as aggregation. An aggregation also shows an is made up of-type relationship, but the main difference is that of ownership. Consider the following diagram: Figure 2.20: Describing relationships – aggregation The diagram in Figure 2.20 shows a more complete and, as is often the case, more complex View that focuses on the breakdown of the Drive Train block. This increase in complexity is partly due to the fact that there are simply more blocks in this diagram, but also because this diagram is also showing the associations that exist between the various blocks, as well as the compositions. There is also an example of aggregation, which is represented by an empty diamond, as opposed to the filled-in diamond of the composition relationship. In order to illustrate the difference between the composition and aggregation relationships, consider the following: The Drive Train is made up of a Gear Box, a Motor or two, a Control Unit, and a Battery. This is expressed using composition, and it means that the four blocks that are part of the Drive Train via the composition are owned by that block. That is to say, the Drive Train owns the Gear Box, Motor, Control Unit, and Battery. The Drive Train is made up of a Charger. This is expressed using aggregation, and it means that the Charger is part of the Drive Train, but that it is not owned by the Drive Train. Chapter 2 71 This is a subtle difference, but an important one. The diagram actually shows that the Drive Train is made up of five blocks, four of which it owns, and one of which it does not. This means that the Charger is required to make sure the Drive Train is complete, but that it is owned by some other System element. The Drive Train needs the Charger; otherwise, it will not work, as there is nothing to charge the Battery. However, this Charger may be part of any other Systems element that happens to own a Charger. The difference between composition and aggregation is, therefore, one of ownership. Both composition and aggregation are actually special types of association, but there is another very widely used type of relationship that is not a type of association and stands on its own. This is the type of relationship, referred to as either specialization or generalization. This is demonstrated as follows: Figure 2.21: Describing relationships – generalization and specialization Model-Based Systems Engineering 72 The diagram in Figure 2.21 shows the type of relationship that allows generalization and specialization to be modeled, and it is shown graphically as an empty triangle. This is a very powerful concept, as it allows classification hierarchies, or taxonomies, to be modeled. The diagram shows that there are two types of Motor, which are Combustion Engine and Electric Motor. Also, Combustion Engine has two types, which are Petrol Engine and Diesel Engine. The fact that there are two different terms for this type of relationship can lead to confusion, but the reality is actually straightforward, as the difference between generalization and specialization is simply one of the reading direction of the relationship. This relationship can, therefore, be read in the following two ways: Combustion Engine and Electric Motor are both types of Motor. When reading up the relationship (toward the triangle), the blocks are becoming more abstract or more general. This is referred to as generalization. Motor has the Combustion Engine and Electric Motor types. When reading down the relationship (away from the triangle), the blocks are becoming less abstract or more specific. This is referred to as specialization. The difference, therefore, is simply one of reading direction, which is purely a personal preference for the person reading the diagram. When two specializations of a block are present, there must be something that distinguishes them from each other, or that makes them “special.” This is usually the set of properties, operations, or relationships that are specific to each specialized block. When showing generalization and specialization, there is a very important concept known as inheritance that applies to any properties, operations, or relationships that relate to the blocks in the taxonomy. The Motor block has a property named Power Rating defined. As both Combustion Engine and Electric Motor are both types of Motor, then it is reasonable to assume that they will also have the same property, as they are specializations. This is known as inheritance, which states that any specializations associated with a block will inherit all of the properties and operations associated with its generalized block. To put this another way, both Combustion Engine and Electric Motor will inherit the Power Rating property from the Motor block as they are types of Motor. Furthermore, as Combustion Engine has two types, Petrol Engine and Diesel Engine, these will also inherit the Power Rating property as the concept of inheritance applies to all levels of specialization. Note that the Combustion Engine block has its own property, which is Fuel Type, which will be inherited by its specialization. It is not inherited by its generalized block, Motor, as inheritance only applies to specializations and not generalizations. Chapter 2 73 Inherited properties and operations are usually not shown on the blocks – therefore, the Electric Motor block actually has the Power Rating property despite it not being shown on the block. The exception to this is when inherited properties are constrained in some way, such as with the Petrol Engine and Diesel Engine blocks, whose inherited properties are as follows: The Petrol Engine block shows its inherited property, as the property value is always set to Petrol and it can never be changed. The Diesel Engine block shows its inherited property, as the property value is always set to Diesel and it can never be changed. When a property has a value that can never be changed, it is referred to as an invariant in SysML, and invariants are often the distinguishing feature between two specialized blocks. Example behavioral modeling The other aspect of modeling that must be considered as part of any Model is the behavior. So far, the structural aspect of the Model has been discussed, but the Model cannot be complete without modeling the behavior. As was seen with modeling structure with bdds, it is possible for several levels of abstraction to be shown on the same diagram, by using composition, aggregation, and generalization/specialization. It helps to think about this as a structure being able to show multiple levels of abstraction vertically. Behavior, however, does not work like this, and behavior Views apply across single levels of abstraction. It helps to think about this as behavior being able to show a single level of abstraction horizontally. Typically, these horizontal levels may be applied like so: At the highest, contextual level: This will focus on interactions between the System and its Stakeholders, or enabling Systems, and will allow interaction across the System boundary to be modeled. Typical SysML diagrams that will be used at this level include use case diagrams and sequence diagrams. At the high level, between System elements: This will focus on interactions between System elements, such as blocks on a bdd. Typical diagrams that are used at this level are sequence diagrams. At the medium level, within a System element: This will focus on interactions within a single System element, such as a block on a bdd. Typical diagrams that are used at this level are state machine diagrams. Model-Based Systems Engineering 74 At the low level, within System element behaviors: This will focus on interactions within a single System element behavior, such as an operation on a block in a bdd. Typical diagrams that are used at this level are activity diagrams. It should be stressed that these are the typical diagrams that are used at each level and that the levels indicated here are generic. The common thread among all of these points is the word interaction, as behavioral modeling is concerned with how interactions occur at various levels of abstraction. In order to illustrate modeling behavior, two of these levels will be considered in the first instance: modeling interactions within a System element and between System elements. Modeling interactions within a System element The first level of abstraction that will be considered is the medium level, where we will be looking at interactions within a System element. In SysML, any block in a block diagram may have its behavior defined using a state machine diagram. For this example, consider again the following diagram: Figure 2.22: Focus on Charger and Battery The diagram in Figure 2.22 shows a bdd that is a subset of the diagram shown in Figure 2.20, but this time, it is specifically using the Battery and Charger blocks. Notice how each block has a number of features (properties and operations) defined. It is quite usual to show a high-level View with no features and then to focus on a subset in a separate View showing these features. Chapter 2 75 Each of these blocks may now have its behavior defined using a state machine diagram, so consider the behavior of Battery, as shown in the following diagram: Figure 2.23: Modeling behavior within a System element – state machine diagram for the Battery block Model-Based Systems Engineering 76 The diagram in Figure 2.23 shows the behavior within a System element (in this case, the behavior of the Battery block), using a state machine diagram. A state machine is created for each System element that has a behavior at the conceptual level. In SysML terms, this means that a state machine diagram will be defined for a specific block. This state machine, like the block, is conceptual. When the block is instantiated, its state machine is executed. This means that if a block is instantiated multiple times, then the same state machine will be copied and executed multiple times. Therefore, it is entirely possible and usual for multiple copies of the same state machine to be executed simultaneously. Remember, define a state machine once for the block, then execute for each instance. The basic Model elements of a state machine are as follows: The state, which describes the situation of a block at a specific moment during its execution. The transition, which shows the legal paths to leave one state and execute another. The event and condition, which show what criteria must be met in order to cross a transition. There are three types of state shown in Figure 2.23, which are as follows: Start state, which is shown graphically by the filled-in circle and represents the creation of an instance, or the birth, of a block End state, which is shown graphically by the bull’s-eye symbol and represents the destruction, or the end of life, of a block State, which is shown graphically by a box with rounded corners and represents a specific moment in time when the block is satisfying a particular condition, is performing an action, or is waiting for something else to occur There are a number of transitions in this diagram, which are shown graphically by directed lines (lines with arrows on them) and show the possible execution paths between the various states. There are also two types of events that are shown in the diagram, which are as follows: Send event, which represents sending some sort of message outside the boundary of the state machine. This is represented graphically by the five-sided shape showing a convex point. Receive event, which represents receiving some sort of message from outside the boundary of the state machine. This is represented graphically by the five-sided shape showing a concave point. Chapter 2 77 There are also two conditions that are shown in the diagram, each of which is shown in square brackets ([ ]) and represents a logical decision that is represented graphically by the diamond symbol. When making a decision and checking the values of a property, that property must exist on the block that owns the state machine diagram. This is the first of many examples of consistency between the two different types of diagrams. One of the key points to check when considering more than one diagram is the consistency between different diagrams. Remember that the difference between pictures and a Model is consistency. In this diagram, it can be seen that the property that is being checked as part of the decision check is also present on the parent block. In the following example, several more examples of consistency will be identified and discussed: Figure 2.24: Modeling behavior within a System element – state machine diagram for the Charger block Model-Based Systems Engineering 78 The diagram in Figure 2.24 shows a state machine diagram for the Charger block. In this diagram, there is more detail and consistency with the Charger parent block. This diagram shows some explicit executable behavior, which, in SysML, may be defined at two levels of granularity: Action: This represents atomic behavior. This means that once started, the execution of the action cannot be interrupted. As a result of this, actions are often (but not always) short in terms of the time that they take to execute. In fact, many people consider actions to be instantaneous and take zero time, despite this being impossible. Actions are shown graphically by the / symbol followed by the action. In the diagram shown here, the actions are used to show how the value of the Status property is set at different points in the state machine. Actions may exist on transitions or inside states. Activity: This represents non-atomic behavior, which means that once started, it may be interrupted. As a result of this, activities are often perceived as taking time. Activities are shown graphically by the do keyword, which is immediately followed by / and that then references an operation from the parent block. Activities are shown inside blocks and may not be shown on transitions. The use of actions and activities allows behavior to be added to the state machine as well as allows consistency to be enforced with the parent block. Another aspect of consistency that may also be enforced is the send and receive events that are sent and received across the boundary of the various state machines. Consider the start charge and start discharge send events; they must go somewhere to be received. Now consider again the state machine diagram for Battery that is shown in Figure 2.25. It can be seen that these same messages are also seen, but this time, as receive events. Remember that send and receive events show the broadcast and receipt of messages, which must be consistent. Modeling behavior between elements This leads neatly to looking at behavior modeling at a higher level of abstraction by modeling behavior between Systems elements using sequence diagrams, as shown in the following diagram: Chapter 2 79 Figure 2.25: Modeling behavior between System elements – sequence diagram showing a basic charging scenario The diagram in Figure 2.25 shows an example of modeling behavior between System elements using a sequence diagram. Sequence diagrams are the most widely used of all the behavior diagrams and they have a multitude of uses that will be explored throughout the book. In the first instance, sequence diagrams will be used to help us to understand how messages are passed between System elements in a single, simple scenario. A scenario shows a specific sequence of occurrences that result in a specific outcome and that allow “what ifs” to be explored. Unlike the state machine diagram, it is not possible to show all possible execution paths on a single diagram, which is why there will usually be several scenarios (using sequence diagrams) for different combinations of interacting blocks. The basic modeling elements that comprise a sequence diagram are as follows: Life lines: These represent a number of instances to be shown. These are shown graphically as boxes with a block name preceded by a colon. This box has a dotted line underneath it that represents the passage of logical time, or the sequence of interactions that enter or leave the life line. As life lines represent collections of instances, they must relate directly back to blocks. Model-Based Systems Engineering 80 Interactions: These show the communications between different life lines and allow the flow of messages to be visualized. Interactions are instances of associations from block diagrams and show messages that can be seen in other behavioral diagrams, such as the state machine diagram. Gates: These show an entry point to the sequence diagram without necessarily showing where it comes from. These are represented graphically by small boxes. The sequence diagram in Figure 2.25 shows several examples of consistency: The :Battery and :Charger life lines are consistent with the Battery and Charger blocks from the bdd. The plug in and start charge interactions are consistent with the charge association from the bdd. The shut down self-interaction is consistent with the shut down operation on the bdd. The start charge and start discharge interactions are consistent with the start charge and start discharge events on the state machine diagram. The sequence diagram here shows a single normal scenario, where Charger is plugged in and Battery charges successfully. Of course, there are a number of other normal scenarios that may be explored, such as discharging. One of the powerful uses of scenario modeling is to show abnormal, or atypical, scenarios, such as where things go wrong. The combination of normal and abnormal scenarios is often referred to as sunny day and rainy day scenario modeling. This will be explored in more detail when needs modeling is considered. The domain-specific language – the Ontology The previous section provided a detailed discussion about the spoken language and, in particular, the use of SysML as this language. This section looks at the other half of having a common language – the domain-specific language or, to use the modeling term, the Ontology. The importance of Ontology will be discussed and then example Ontology Views will be presented that will be used throughout this book. Understanding Ontology – the cornerstone of MBSE The Ontology is the single most important construct within MBSE, as it provides the basis for the Model. The Ontology is used for almost every aspect of MBSE, including the following: Chapter 2 81 The domain-specific language: The main concepts and their associated terminology must be defined for successful Systems Engineering, as discussed in Chapter 1, Introduction to Systems Engineering. The Ontology is the visualization of the domain-specific language. The basis for structure and content of Viewpoints: The Model comprises a number of Views, and the consistency and rigor of the Views are ensured through the use of templates or Viewpoints that define the structure and content of each View. The Viewpoint uses subsets of the Ontology to identify and define what exactly is permitted to be visualized in each View. The basis for consistency of the Model: The Model must be consistent, otherwise it is a random collection of pictures, rather than a consistent set of Views. This consistency must be enforced in terms of the spoken language, which is achieved through the use of SysML, and the domain-specific language, which is achieved through the use of the Ontology. The relationships between all of the ontological elements provide all of the consistency paths needed to assure that the Model is correct. The basis for traceability: It is essential that any artifact that is produced as part of the Systems Engineering approach can be followed backward (known as traceability) or forward (known as impact) in the Model. This ensures that if any changes are made at any point in the project to any part of the Model, then it can be easily and quickly established which other parts of the Model may be affected. The Ontology, therefore, is an essential part of MBSE and one that it is important to get right. The next section will introduce the Ontology that will be used and built upon throughout the book. Visualizing Ontology The domain-specific language was introduced in Chapter 1, Introduction to Systems Engineering, and a number of simple diagrams were used to show how the concepts related to one another. By using the SysML that has been introduced so far in this chapter, it is now possible to define the Ontology using the SysML Notation to make it more precise and meaningful than the informal diagrams that were used in Chapter 1, Introduction to Systems Engineering, and at the beginning of this chapter. The Ontology that will be presented here will now be built upon and used for the rest of the book. This will be referred to as the MBSE Ontology and is based on the best-practice MBSE Ontology that is used extensively in the MBSE community (Holt & Perry 2014). Model-Based Systems Engineering 82 For reasons of clarity and readability, the MBSE Ontology will be broken down into four diagrams. Here is the first one: Figure 2.26: The MBSE Ontology – Systems Engineering The diagram in Figure 2.26 shows the MBSE Ontology with a focus on Systems Engineering. This diagram may be read as follows. Chapter 2 83 Systems Engineering realizes successful Systems. There are three evils that hinder Systems Engineering, which are Understanding, Communication, and Complexity. MBSE is a type of Systems Engineering that mitigates these evils via the Model. Each System exhibits complexity, of which there are two types: Essential Complexity and Accidental Complexity. A number of Stakeholders have an interest in the System and they communicate with each other via a Common Language. The Common Language has two Aspects, which are the Spoken Language and the Domain-Specific Language. The next diagram follows directly f