Module 1: What is MBSE?
From document-centric to model-centric engineering — why MBSE exists, what problems it solves, and the paradigm shift it represents.
Systems Engineering in 5 Minutes
What is a "system"?
We use the word "system" every day — solar system, transport system, healthcare system — but what does it actually mean in engineering? The International Council on Systems Engineering (INCOSE) defines a system as "an arrangement of parts or elements that together exhibit behaviour or meaning that the individual constituents do not." In plain English: a system is a collection of parts that, when combined, do something none of the parts can do alone.
Think about a bicycle. A wheel on its own cannot take you anywhere. Neither can handlebars, a chain, or pedals. But assemble them together, and you have a vehicle that can carry a person across a city. The bicycle is a system — its value emerges from how its parts work together, not from any single part.
Building a house vs. building a city
If you are building a single house, you might manage with a small team, a few drawings, and some common sense. The plumber, electrician, and carpenter can coordinate over a cup of coffee. But what if you are building an entire city? Now you have thousands of workers, hundreds of suppliers, and millions of interdependencies. The plumber in District 5 needs to know about the water treatment plant being designed by a team on the other side of town. Coffee-table conversations no longer suffice.
This is the fundamental challenge that systems engineering addresses. As systems grow in complexity — aircraft with millions of parts, autonomous vehicles with dozens of interacting subsystems, hospital information networks spanning entire regions — the coordination problem becomes the dominant problem. Systems engineering is the discipline that manages this complexity through structured processes, rigorous documentation, and systematic analysis.
Systems engineering is not about building things — it is about making sure the right things get built, in the right order, and that they all work together. A systems engineer is more like an orchestra conductor than a musician: they ensure every section plays in harmony.
What do systems engineers actually do?
Systems engineers work across the entire lifecycle of a system. They capture what stakeholders need (requirements), design how the system will be structured (architecture), ensure parts work together (integration), and confirm the system does what it should (verification and validation). They are the glue that holds a complex engineering project together.
The Document-Centric Problem
For decades, the primary tool of systems engineering has been the document. Requirements are captured in Word files. System architecture is drawn in PowerPoint or Visio. Interface definitions live in spreadsheets. Test plans occupy yet another set of documents. Each of these artefacts is created by a different team, at a different time, using a different format.
The telephone game
Remember the children's game where a message is whispered from person to person, and by the time it reaches the last player, it has been hilariously distorted? Document-centric engineering suffers from exactly the same problem. Information degrades as it passes between documents, teams, and lifecycle phases.
Imagine a restaurant where the customer writes their order on a napkin. The waiter copies it onto an order slip. The chef reads the slip and interprets it. The sous-chef reads the chef's notes and actually prepares the dish. By the time the plate arrives, the customer's "grilled salmon, no dill, extra lemon" has become "fried salmon with dill sauce." Every handoff introduced a small distortion — and small distortions accumulate into big problems.
A concrete example
Consider a real scenario. The requirements document states: "The system shall respond to user input within 200 milliseconds." The architecture document, written three months later by a different team, interprets this as a guideline and designs for 500ms average response time. The test plan, written six months after that, tests whether the system "responds quickly" — without specifying a number at all. When the system fails in the field, everyone points to their own document and says, "But we followed the spec!"
This is not a hypothetical scenario. It happens routinely in large engineering programmes. Requirements drift, designs diverge from requirements, and tests do not trace back to either. The root cause is always the same: information lives in disconnected documents with no formal linkage between them.
The Mars Climate Orbiter was lost in 1999 because one team used imperial units while another used metric units — a mismatch that was buried in separate documents and never caught by cross-checking. The spacecraft cost $327.6 million. Document-centric engineering does not just cause inconvenience; it causes catastrophic failures when applied to complex systems.
Why documents fail at scale
Documents have several fundamental limitations when used to manage complex systems:
- No single source of truth — the same information is duplicated across many documents, and copies inevitably diverge.
- No formal traceability — links between requirements, designs, and tests are maintained manually (if at all).
- No consistency checking — contradictions between documents go undetected until integration or testing.
- Version chaos — which version of which document is current? Who approved it? Does the design doc reflect the latest requirements change?
- No automated analysis — you cannot "run" a Word document to check whether the design satisfies all requirements.
The Model-Centric Solution
What if, instead of scattering information across dozens of disconnected documents, you had a single, shared, always-current model that every team member could access and contribute to? That is the core idea behind Model-Based Systems Engineering (MBSE).
Think about how document collaboration has evolved. In the old days, you would write a Word document, email it to five colleagues, and receive five different edited versions back — each with conflicting changes. Today, you use Google Docs: everyone edits the same live document, changes are tracked in real time, and there is never any confusion about which version is current. MBSE does the same thing for systems engineering — it replaces the "email Word files back and forth" approach with a single, shared, authoritative model.
The model as the authoritative artefact
In MBSE, the model — not any particular document — is the authoritative source of system information. Requirements, architecture, behaviour, interfaces, and test cases all live within the same model. They are not just stored together; they are formally linked. A requirement is connected to the design element that satisfies it, which is connected to the test case that verifies it. Change the requirement, and you can instantly see which design elements and test cases are affected.
Documents do not disappear in MBSE — they are still generated when needed (for contracts, reviews, certifications) — but they are derived from the model, not created independently. The model is the single source of truth; documents are just views of it.
MBSE replaces disconnected documents with a single, shared, formally-linked model that serves as the authoritative source of truth for all system information.
What does "model-centric" actually mean in practice?
In a model-centric workflow, engineers interact with the model directly. A requirements engineer defines requirements in the model. A system architect creates the system structure in the same model. An analyst runs simulations against model data. A test engineer traces test cases back to requirements — all within one integrated environment. When a requirement changes, every downstream artefact that depends on it is automatically flagged for review.
MBSE does not mean "no documents." It means documents are outputs of the model, not inputs to the engineering process. Think of it like accounting software: the authoritative data is in the database, and reports (documents) are generated from it on demand.
MBSE Defined
Now that we understand the problem and the general solution, let us look at the formal definition. INCOSE defines MBSE as:
"The formalised application of modelling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases."
Let us unpack this definition word by word:
- "Formalised application of modelling" — this is not casual sketching on a whiteboard. MBSE uses rigorous, standardised modelling languages with precise semantics.
- "System requirements, design, analysis, verification, and validation" — the model covers the entire lifecycle, not just one phase.
- "Beginning in the conceptual design phase" — modelling starts early, when decisions have the greatest impact and the cost of change is lowest.
- "Continuing throughout development and later lifecycle phases" — the model evolves with the system. It is not a one-time artefact; it is a living representation.
The three pillars of MBSE
MBSE rests on three interdependent pillars. Think of them as the three legs of a stool — remove any one, and the whole thing collapses.
| Pillar | What it is | Example |
|---|---|---|
| Modelling Language | The vocabulary and grammar used to express the model. Defines what elements exist (requirements, blocks, actions) and how they relate. | SysML, UML, AADL, SysML v2 |
| Modelling Method | The process or methodology that guides how to build the model. Defines which views to create, in what order, and what questions each view answers. | OOSEM, Harmony SE, MagicGrid, ARCADIA/Capella |
| Modelling Tool | The software platform that supports creating, storing, querying, and visualising the model. | Cameo Systems Modeler, Rhapsody, Capella, Eclipse SysML v2 Pilot |
Think of writing a novel. The language is English (vocabulary and grammar). The method is the writing process — outline first, then draft, then revise. The tool is the word processor you use. You need all three to produce a good novel. Similarly, MBSE needs a modelling language, a modelling method, and a modelling tool working together.
These three pillars form a triangle. The language defines what you can express. The method defines how you build the model. The tool provides the environment where you do the work. A strong MBSE practice requires all three to be well-chosen and well-integrated. We will explore each pillar in depth in Module 2.
Benefits and Challenges
Document-centric vs. model-centric: a comparison
The following table compares the document-centric and model-centric approaches across several key dimensions. This is not to say that document-centric engineering is always wrong — for simple systems, it may be perfectly adequate. But as system complexity grows, the advantages of a model-centric approach become overwhelming.
| Dimension | Document-Centric | Model-Centric (MBSE) |
|---|---|---|
| Consistency | Information duplicated across documents; inconsistencies common and hard to detect | Single source of truth; consistency enforced by the model |
| Traceability | Manual cross-references (often incomplete or outdated) | Formal, automated traceability from requirements through design to test |
| Communication | Ambiguous natural language; different readers interpret differently | Precise modelling language with defined semantics; visual and textual views |
| Reuse | Copy-paste from previous project documents (error-prone) | Model libraries with formally defined, reusable components |
| Change Impact Analysis | Manual search across documents to find what is affected | Automated impact analysis: change a requirement and see all affected elements instantly |
| Stakeholder Engagement | Stakeholders must read lengthy documents to understand the system | Interactive model views tailored to each stakeholder's concerns |
| Verification Coverage | Difficult to confirm every requirement has a corresponding test | Model queries can instantly identify untested requirements |
| Knowledge Preservation | Knowledge locked in documents and people's heads; lost when staff leave | Knowledge captured in the model; persists regardless of personnel changes |
The challenges are real
MBSE is not a silver bullet. Adopting it comes with genuine challenges that organisations must plan for:
Learning curve. Engineers accustomed to writing documents must learn new modelling languages and tools. This takes time, training, and patience. A systems engineer who has spent 20 years writing requirements in Word will not become a proficient modeller overnight.
Organisational change. MBSE is not just a technical change; it is a cultural one. It requires new workflows, new roles (such as model librarians or model governance boards), and new ways of collaborating. Processes that were built around document reviews must be redesigned around model reviews.
Tool costs. Professional MBSE tools can be expensive, both in licensing and in the infrastructure needed to support them (servers, training, customisation). Open-source alternatives exist but may lack maturity or support.
Cultural resistance. "We have always done it this way" is a powerful force. Some engineers view MBSE as unnecessary overhead or as a threat to their expertise. Overcoming this resistance requires strong leadership, clear demonstration of value, and early wins.
The most successful MBSE adoptions start small. Pick one project, one team, one subsystem. Demonstrate value there first. Let success spread organically. Trying to transform an entire organisation overnight is a recipe for failure.
MBSE in Context
Relationship to systems engineering standards
MBSE does not replace systems engineering — it enhances it. The international standard ISO/IEC/IEEE 15288 (Systems and Software Engineering — System Life Cycle Processes) defines the processes that govern systems engineering. MBSE provides a model-centric way to execute those same processes. Whether you are performing stakeholder needs analysis, architecture design, or verification, the processes remain the same — but the artefacts change from documents to model elements.
ISO/IEC/IEEE 15288 does not mandate MBSE, but it is fully compatible with it. Many organisations use 15288 as their process framework and MBSE as their implementation approach. The standard defines what to do; MBSE provides a better way of how to do it.
How MBSE differs from software engineering approaches
If you come from a software engineering background, you may have heard of MDD (Model-Driven Development) or MDE (Model-Driven Engineering). While these share the "model-centric" philosophy with MBSE, there are important differences:
- Scope: MDD/MDE focuses on software systems. MBSE addresses entire systems — hardware, software, human operators, processes, and their interactions.
- Goal: MDD often aims for automatic code generation from models. MBSE aims for better understanding, communication, and analysis of the system — code generation is a possible but not primary goal.
- Languages: MDD typically uses UML or domain-specific languages. MBSE uses SysML (or SysML v2), which was specifically designed for systems engineering concerns like requirements, physical interfaces, and cross-domain interactions.
If MDD is like using an architect's CAD tool to design a single building, MBSE is like using a city planning platform to design an entire urban district — including buildings, roads, utilities, public transport, and zoning regulations. The tools and techniques overlap, but the scope and concerns are fundamentally different.
What lies ahead in this series
This module has given you the "why" and "what" of MBSE. The remaining modules in this series will take you through the "how":
- Module 2 explores the three pillars in depth — modelling languages, methods, and tools.
- Modules 3–5 dive into each pillar individually.
- Modules 6–9 cover the core MBSE activities: requirements, architecture, behaviour modelling, and verification.
- Modules 10–12 address practical concerns: integration, organisational adoption, and future trends.
By the end of the series, you will have a solid understanding of MBSE — not just the theory, but the practical knowledge needed to start applying it in real projects.