An Introduction to Model-Based Systems Engineering (MBSE)

Modeling

We have all seen, used, or created models throughout our lives, ranging from toys that represent cars or planes to mathematical formulas that describe and explain physical phenomena such as thermodynamics or gravity. While fundamentally different, those models all connect an idea to a reality and provide sufficient abstraction for the purpose. When modeling a system, the systems engineer decides what aspects of the production system are most important, such as structure, energy or matter flow, internal communication, or safety and security. Those types of aspects will become the focus of the model. The top objective of the modeling activity is to model the salient aspects on which the model is focused as closely to the real system as is possible and feasible.

Modeling as a technique uses four instruments:

• language
• structure
• argumentation
• presentation

A modeling language is a common terminology for clearly communicating an abstract idea that the model captures. The modeling language can be formal, with strict syntax and rules. A few system-modeling languages exist, including general-purpose languages such as the Systems Modeling Language (SysML) and Unified Modeling Language (UML), as well as specialized languages such as Architecture Analysis Design Language (AADL). Although SysML and UML are not mathematically formal, a valid model requires that the modeling language’s rules for entities and relationships be followed. SysML has strict syntax and rules for relationships and connections between elements, which helps to avoid ambiguity. If a model is well built, several types of standard SysML diagrams can be dynamically simulated, and at least one type of SysML diagram can be mathematically simulated. UML is semi-formal; SysML is similar to UML, but more formal.

A model must have a structure. A well-structured model can make the model understandable, usable, and maintainable, which is particularly important for complex systems. The goal of a model is to show stakeholders that the presented design satisfies the system’s requirements. The model should demonstrate, in an easily comprehensible way, how the system must be built to be successful. Visualization is a key way to ensure comprehensibility. Visualizing abstract ideas enables people to take the leap of imagination that is needed to “see” the system.

Modeling Domains

Even though MBSE does not dictate any specific process, essentially any process chosen should cover four systems-engineering domains:

• requirements/capabilities
• behavior
• architecture/structure
• verification and validation

Descriptions of these domains are well documented and discussed by, among others, Defense Acquisition University (DAU), NASA, and Avi Sharma. The difference that MBSE makes is that these fundamental systems-engineering domains are defined not as a set of documents, but in the model itself, i.e., in a formal way using a modeling language. The model represents an argument for how the system must be designed for it to be successful.

MBSE also fosters communication among stakeholders, systems engineers, and developers. Since system design is performed in the integrated modeling environment, all systems engineers, managers, and other stakeholders can have access to the generated information–such as requirements, behavior flows, and architecture–as soon as necessary.

The most common modeling activity is the creation of diagrams representing some part of the system–a view. This activity is so common that some engineers mistakenly equate creating a view with creating a model. This mistake is so pervasive that there is even an emerging term for it: zombie model. This term refers to a model that is full of diagrams, but with no interconnectivity and dependencies identified among the elements.

Anyone who is about to start modeling must realize that a set of views is not a model. Although a view or even a set of views can represent a part of the system’s design and can be useful for documenting and communicating some aspects of the system, views are only facets or portions of the true system model. A real model can produce many views and matrices, perform analyses, and run simulations.

Language of System Modeling

While a system-modeling language such as SysML is a formal syntactic language, it is still based on elements of human language. Its formality adds clarity and discipline that are critical for describing the design of a system. Such a language is easy to read and understand. Terms of MBSE’s language simply map to parts of speech:

• noun: actors, blocks, components, requirements
• verb: operational activities, functions, use cases
• adjective: attributes
• adverb: relationships, needlines, exchanges, interfaces

This view of the modeling language helps its users to mentally map real-life concepts to abstract ideas, and eases the formalization of the modeling process.

Four Quadrants of the MBSE Model

Now that I have described the basics of a model’s language and domains, I will describe the modeling approach. A model must describe both a problem that the designed system solves, and the designed system itself (the solution). The model must have these two sides, the problem side and the solution side. These are sometimes referred to as the operational and system points of view.

The operational point of view is the perspective of users, operators, and business people. It should represent business processes, objectives, organizational structure, use cases, and information flows. The operational side of the model can contain the description of “the world as-is” and the future state.

The system point of view is the solution, the architecture of the system that solves the problem posed in the operational side of the model. It should describe the behavior of the system, its structure, dataflows between components, and allocation of functionality. It should describe how the system will be deployed in the real world. It can contain solution alternatives and analyses of them.

Each of these points of view has two parts, logical and physical. Separating logical and physical aspects of the model is a way to manage a system’s complexity. Logical parts of the model usually change little over time, while physical changes are often initiated by technology advances.

If the model is built properly, all four quadrants should be tightly connected, as shown in Figure 1 below. Statements of the problem should be traced to elements of the solution, and logical elements allocated to physical structures. The user of the model should be able to see clearly how the top-level concepts and components decompose to the lower level features. Users should be able to perform system analysis, create dependency matrices, run simulations, and produce a view of the system for every stakeholder. If the physical part of the system must change, the logical side of the model identifies exactly what functionality will be affected. If a requirement or business process must be changed, the model will easily discover the impact on the solutions.

Figure 1: Components of A Model

Wrapping Up and Looking Ahead

In this post, I explained what MBSE is, showed how it relates to systems engineering, and discussed the fundamentals of model and modeling. My next post will take a more practical approach and discuss requirements and requirements models.