Model-based systems engineering (MBSE) is a formalized methodology that is used to support the requirements, design, analysis, verification, and validation associated with the development of complex systems. In contrast to document-centric engineering, MBSE puts models at the center of system design. The increased adoption of digital-modeling environments during the past few years has led to increased adoption of MBSE. In January 2020, NASA noted this trend by reporting that MBSE, "has been increasingly embraced by both industry and government as a means to keep track of system complexity." In this blog post, I provide a brief introduction to MBSE.

One area of concern within complex systems is cybersecurity. The SEI CERT Division has begun researching how MBSE can be used to mitigate security risks early in the system-development process so that systems are secure by design, in contrast to the common practice of adding security features later in the development process. Capturing system attributes in models enables systems engineers to perform threat-modeling analysis of the system early and incorporate mitigation strategies into the system design, thereby reducing the system's overall security-related risks.

MBSE in a digital-modeling environment provides advantages that document-based systems engineering cannot provide. For example, in a document-based approach, many documents are generated by different authors to capture the system's design from various stakeholder views, such as system behavior, software, hardware, safety, security, or other disciplines. Using a digital-modeling approach, a single source of truth for the system is built in which discipline-specific views of the system are created using the same model elements.

A digital-modeling environment also creates a common standards-based approach to documenting the system that can be programmatically validated to remove inconsistencies within the models and enforce the use of a standard by all stakeholders. This common modeling environment improves the analysis of the system and reduces the number of defects that are commonly injected in a traditional document-based approach. The availability of digitalized system data for analysis across disciplines provides consistent propagation of corrections and incorporation of new information and design decisions (i.e., state it once and automatically propagate to various views of the data) to all stakeholders. When MBSE is done properly, the result is an overall reduction of development risks.

MBSE brings together three concepts: model, systems thinking, and systems engineering:

• A model is a simplified version of something--a graphical, mathematical, or physical representation that abstracts reality to eliminate some complexity. This definition implies formality or rules in simplifying, representing, or abstracting. To model a system, a systems architect must represent the system with less detail so that its structure and behavior are apparent and its complexity is manageable. In other words, models should sufficiently represent the system, and the system should confirm the models.
• Systems thinking is a way of looking at a system under consideration not as a self-sufficient entity, but as part of a larger system. Systems thinking is not the same as a systematic adherence to following good plans, collecting statistics, or being methodical. The systems engineer observes the system from a distance; explores its boundaries, context, and lifecycle; notes its behavior; and identifies patterns. This method can help the engineer to identify issues (e.g., missing interaction, a missing step in a process, duplication of effort, missed opportunity for automation) and manage a system's complexity. Although systems engineers must break down and analyze the system in the beginning--identify parts and describe connections between them--with systems thinking, they later synthesize the parts back into a coherent whole. Parts are not just connected to other parts, they depend on each other to work properly. Systems thinking emphasizes this interconnectedness. The behavior of the system emerges from the activities of the system's subparts. Observing the system's interconnections, the systems engineer identifies feedback loops and causality patterns that may not be apparent at first. Systems thinking can help make issues more apparent and easier to identify, balance the system, and manage the system's complexity.
• Systems engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods. It brings together a number of techniques to make sure that all requirements are satisfied by the designed system. It concentrates on architecture, implementation, integration, analysis, and management of a system during its lifecycle. It also considers software, hardware, personnel, processes, and procedural aspects of the system.

If an organization has decided to adopt MBSE as an internal systems-engineering approach and chosen one of the four or five existing products for digital modeling that are on the market, the organization's systems engineers should consider whether it is going to follow any architectural frameworks. Although a comprehensive discussion of this topic is beyond the scope for this blog post, the choice of a particular architectural framework will provide additional guidance and structure to the modeling activities, especially if the systems engineers are already familiar with the framework.

MBSE is a multidisciplinary and multifaceted endeavor. It requires its own actors, processes, environment, and information flows. To create a successful model of a complex system or system of systems, an organization must support the modeling process. The support needed is not much different from what is required for an organization to successfully develop and deliver a complex system or system of systems. MBSE can be effectively integrated into a development process, but the organization must commit to the effort that will be required to model the system.

Applying systems thinking, we can recognize that there are three systems involved in the modeling process: the designed system, the designed system's context, and the modeling organization for the designed system. The designed system operates in the context of a larger system, and the modeling organization must understand both the designed system and the designed system's context. The organization must also be aware of its own behavior, successes, and failures.

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.

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.

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.

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.

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.