An Introduction to Model-Based Systems Engineering (MBSE) https://insights.sei.cmu.edu/blog/introduction-model-based-systems-eng...

Search the blog

Software Engineering
Institute
SEI Blog
Home › Publications › Blog › An Introduction to Model-Based Systems En…

1 de 10 16/11/2023, 10:46
An Introduction to Model-Based Systems Engineering (MBSE) https://insights.sei.cmu.edu/blog/introduction-model-based-systems-eng...

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, veri�cation, 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 di�erent

2 de 10 16/11/2023, 10:46
An Introduction to Model-Based Systems Engineering (MBSE) https://insights.sei.cmu.edu/blog/introduction-model-based-systems-eng...

document-based approach, many documents are generated by di�erent

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-speci�c 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 simpli�ed version of something--a graphical, mathematical,

or physical representation that abstracts reality to eliminate some
complexity. This de�nition 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
su�ciently represent the system, and the system should con�rm the
models.
• Systems thinking is a way of looking at a system under consideration not
as a self-su�cient 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 identi�es patterns. This method can help the
engineer to identify issues (e.g., missing interaction, a missing step in a
process, duplication of e�ort, 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

3 de 10 16/11/2023, 10:46
An Introduction to Model-Based Systems Engineering (MBSE) https://insights.sei.cmu.edu/blog/introduction-model-based-systems-eng...

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 identi�es feedback loops and
causality patterns that may not be apparent at �rst. 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 scienti�c,
technological, and management methods. It brings together a number of
techniques to make sure that all requirements are satis�ed 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 �ve 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 �ows. 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
di�erent from what is required for an organization to successfully develop
and deliver a complex system or system of systems. MBSE can be e�ectively
integrated into a development process, but the organization must commit to
the e�ort 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

4 de 10 16/11/2023, 10:46
An Introduction to Model-Based Systems Engineering (MBSE) https://insights.sei.cmu.edu/blog/introduction-model-based-systems-eng...

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 di�erent, those models all connect an idea to a reality and
provide su�cient 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 �ow, 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 Uni�ed 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

5 de 10 16/11/2023, 10:46
An Introduction to Model-Based Systems Engineering (MBSE) https://insights.sei.cmu.edu/blog/introduction-model-based-systems-eng...

complex systems. The goal of a model is to show stakeholders that the

presented design satis�es 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 speci�c process, essentially any
process chosen should cover four systems-engineering domains:

• requirements/capabilities
• behavior
• architecture/structure
• veri�cation and validation

Descriptions of these domains are well documented and discussed by,

among others, Defense Acquisition University (DAU), NASA, and Avi Sharma.
The di�erence that MBSE makes is that these fundamental systems-
engineering domains are de�ned 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
�ows, 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 identi�ed 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

6 de 10 16/11/2023, 10:46
An Introduction to Model-Based Systems Engineering (MBSE) https://insights.sei.cmu.edu/blog/introduction-model-based-systems-eng...

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 �ows. 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, data�ows between

7 de 10 16/11/2023, 10:46
An Introduction to Model-Based Systems Engineering (MBSE) https://insights.sei.cmu.edu/blog/introduction-model-based-systems-eng...

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
identi�es exactly what functionality will be a�ected. 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

8 de 10 16/11/2023, 10:46
An Introduction to Model-Based Systems Engineering (MBSE) https://insights.sei.cmu.edu/blog/introduction-model-based-systems-eng...

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.

ADDITIONAL RESOURCES

Watch the SEI video, What Would Convince DoD Program Managers to
Use Model-Based System Engineering?

Read the SEI blog post, Modeling Capabilities with Model-Based Systems
Engineering (MBSE)

Read the SEI blog post, Requirements in Model-Based Systems

Engineering (MBSE)

Read the SEI blog post, Evaluating Threat-Modeling Methods for Cyber-
Physical Systems.

Read the SEI blog post, Threat Modeling: 12 Available Methods.

WRITTEN BY

Nataliya Shevchenko
AUTHOR PAGE 
DIGITAL LIBRARY PUBLICATIONS 
SEND A MESSAGE 

MORE BY THE AUTHOR

9 de 10 16/11/2023, 10:46
An Introduction to Model-Based Systems Engineering (MBSE) https://insights.sei.cmu.edu/blog/introduction-model-based-systems-eng...

Modeling Capabilities with Model-Based Systems Engineering

(MBSE)
NOVEMBER 28, 2022 • BY NATALIYA SHEVCHENKO

A Case Study in Applying Digital Engineering

APRIL 18, 2022 • BY NATALIYA SHEVCHENKO, PETER CAPELL

Requirements in Model-Based Systems Engineering (MBSE)

FEBRUARY 22, 2021 • BY NATALIYA SHEVCHENKO

Evaluating Threat-Modeling Methods for Cyber-Physical

Systems
FEBRUARY 4, 2019 • BY NATALIYA SHEVCHENKO

Threat Modeling: 12 Available Methods

DECEMBER 3, 2018 • BY NATALIYA SHEVCHENKO

Get updates on our latest

work.
Subscribe

 Get our RSS feed

10 de 10 16/11/2023, 10:46