10/10/23, 5:58 PM An Introduction to Model-Based Systems Engineering (MBSE)

Home Publications Blog An Introduction to Model-Based Systems Engineeri…

An Introduction to Model-Based Systems

Engineering (MBSE)
NATALIYA SHEVCHENKO

DECEMBER 21, 2020

CITE

Get Citation

TAGS

Digital Engineering Data Modeling and Analytics Model-Based Systems Engineering

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.

https://insights.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/ 1/4
10/10/23, 5:58 PM An Introduction to Model-Based Systems Engineering (MBSE)
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.

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.
https://insights.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/ 2/4
10/10/23, 5:58 PM An Introduction to Model-Based Systems Engineering (MBSE)
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.

https://insights.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/ 3/4
10/10/23, 5:58 PM An Introduction to Model-Based Systems Engineering (MBSE)
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.

https://insights.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/ 4/4