Articles

Model-based systems engineering (MBSE) is the practice of keeping the description of a system in one structured model instead of spreading it across a set of documents. Requirements, structure, interfaces, and behavior become elements in that model, with typed links between them. A diagram becomes a view of the model rather than a drawing that lives on its own.

INCOSE’s definition, word by word

INCOSE gives the definition most people quote, in its Systems Engineering Vision 2020 (INCOSE-TP-2004-004-02, September 2007):

the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.

The definition is denser than it looks. The words that matter are “formalized,” “support,” and “throughout.” “Formalized” means the model follows a language with rules, which is what lets a tool check it instead of a reviewer.

“Support” means the model exists to serve engineering decisions rather than to be a deliverable in its own right. A good deal of MBSE trouble starts when that gets reversed. “Throughout” means the model starts at the concept and stays current through verification and beyond, which is the part that turns out to be hard.

Documents copy each fact; a model keeps it once

In document-centric systems engineering, each team writes its own artifacts. The requirements specification, the interface control document, the architecture description, and the test plan are separate files, and each one carries its own copy of the same facts.

When a signal changes from 12 V to 5 V, somebody has to find every copy and update it by hand. Review catches some of the differences, never all of them.

In model-centric work, the fact “this signal is 5 V” exists exactly once. The interface diagram, the requirement trace, and the generated interface table are all views of that one element, so a change to the element changes every view. Documents do not disappear; the tool generates them from the model, and a generated document is disposable in a way a hand-written one never is.

The digital thread is this idea extended past the systems model. The Defense Acquisition University glossary describes it as a framework for the controlled flow of authoritative technical data across a system’s life cycle.

In practice the system model links out to CAD geometry, analysis results, software repositories, test results, and production data. An engineer can then follow a requirement to the part that satisfies it, the test that verifies it, and the result of that test. MBSE is the systems engineering piece of the thread, and without a model the thread has nothing to attach to.

SysML v1: nine diagram types over one model

SysML is the most widely used MBSE language. The Object Management Group (OMG) maintains it, and the latest v1 release is SysML 1.7. SysML v1 is a UML profile: it reuses seven UML diagram types, modifies some of them, and adds two of its own, the requirement diagram and the parametric diagram.

What new users miss is that the nine diagrams share one model. The block you add to a BDD is the same element you wire up in an IBD and trace to a requirement. Draw a second box with the same name instead of reusing the element, and you are back to documents.

SysML v2 is a new language with a text form and an API

Despite the name, SysML v2 is a new language rather than a revision of v1. In July 2025 the OMG approved final adoption of three specifications together:

• SysML 2.0, the language itself.
• KerML 1.0, the Kernel Modeling Language that supplies SysML v2’s semantics.
• The Systems Modeling API and Services 1.0, a standard interface for tools and model repositories.

The OMG specification page now lists SysML 2.0 as a formal specification dated September 2025.

The textual notation matters most for working engineers. A SysML v2 model has a standard text form alongside the graphical one, and both show the same model. Text means Git and code review, and it means a model can be checked by the same CI pipeline as the software it describes.

The UML base is gone. SysML v2 sits on KerML instead, which gives it a more precise semantics than a UML profile could.

There is also a standard API. Tools read and write models through one interface instead of each vendor’s own. The SysML v2 submission team publishes a pilot implementation with Eclipse and Jupyter editors, and a separate API pilot with a REST interface.

Tool support for v2 is still filling in. Check what your tool supports today before anyone writes a v2 migration into a plan.

Common MBSE tools, and why the choice is made for you

These are the tools engineering teams mention most often. Your contracts, your partners, and the licenses you already hold decide the tool.

We modeled our own satellite-sensor prototype’s architecture in SysML, using Cameo Systems Modeler. The model holds block definition diagrams for the subsystems, internal block diagrams for the parts, and an activity diagram for the flow from camera to processing. Five days of work: a satellite sensor proven in the wilderness tells that project’s story.

Use the tool your customer and your partners already use: models do not move cleanly between tools, so a shared tool beats a better one on paper.

Thermostat example, modeled end to end

A room thermostat is small enough to model in a few minutes and still exercises the full chain from requirement to block to interface to behavior. Step by step:

1. Requirement. R1: hold room temperature within 0.5 °C of the set point.
2. Blocks. Three parts: a sensor, a controller, and a heater.
3. Interfaces. The sensor sends a temperature to the controller; the controller sends an on or off command to the heater. Each interface is a port with a direction and a type.
4. Behavior. The controller has two states, Idle and Heating. A “too cold” event moves it to Heating, and a “warm enough” event moves it back to Idle.
5. Trace. The controller block satisfies R1, and a test case later verifies R1.

The same model in SysML v2 textual notation, structure first:

package ThermostatExample {
    private import ScalarValues::*;

    port def TempPort { out attribute temperature : Real; }
    port def HeaterCmdPort { out attribute heaterOn : Boolean; }

    part def Sensor { port reading : TempPort; }
    part def Controller {
        attribute setPoint : Real;
        port reading : ~TempPort;          // conjugated: receives temperature
        port command : HeaterCmdPort;
    }
    part def Heater { port command : ~HeaterCmdPort; }

    requirement def <'R1'> HoldTemperature {
        doc /* The controller shall hold room temperature
             * within 0.5 degrees C of the set point. */
        subject controller : Controller;
    }

    part thermostat {
        part sensor : Sensor;
        part controller : Controller;
        part heater : Heater;
        connect sensor.reading to controller.reading;
        connect controller.command to heater.command;
    }
    requirement holdTemp : HoldTemperature;
    satisfy holdTemp by thermostat.controller;
}

The controller’s state machine goes in the same package:

    attribute def TooCold;
    attribute def WarmEnough;

    state def ControllerStates {
        first start then idle;
        state idle;
        transition idle_to_heating first idle accept TooCold then heating;
        state heating;
        transition heating_to_idle first heating accept WarmEnough then idle;
    }

A reviewer can read that text without a modeling tool, and a tool can draw the BDD, the IBD, and the state machine from it.

The payoff arrives with the first change. Suppose the sensor starts reporting a raw voltage instead of a temperature. In the model you change the type on TempPort, and the tool lists every element that touches the port.

That list is the controller, the connection, the requirement the controller satisfies, and the tests behind that requirement. In a document set, an engineer searches each document for the old signal and hopes to find every copy.

Why MBSE efforts stall

Most MBSE efforts that stall do so for reasons that are more organizational than technical.

• Diagrams as drawings. An engineer draws a box on one diagram and a different box with the same name on another. The tool now holds two elements, and the model has inherited the duplication it was meant to remove.
• A model of everything. The team models every bolt before the first review, and the model grows faster than anyone can keep it correct.
• No owner. Nobody is responsible for the model after the design phase, so it freezes at the first baseline while the system keeps changing.
• No link to tests. The requirements in the model never connect to verification. The trace stops at design, and the model cannot say what has been verified.

Where the model meets the code

For a software team, the model earns its keep only when it connects to the code and the tests. The links that do most of the work are requirement IDs, generated interfaces, and documents from CI.

Requirement IDs in code and tests. Each test names the requirement it verifies, test_R1_holds_setpoint for instance. A script then builds a trace matrix from the test results and the requirement list in the model, and a requirement with no passing test is visible at once.

Interfaces generated from the model. Port and message definitions in the model are the source for interface tables, and sometimes for generated headers or schemas. The code and the interface document then agree by construction instead of by diligence.

Documents from CI. When the model is text in Git, the CI pipeline can validate it and regenerate the interface control document on every merge. The model and the documents change in the same review, which is the only arrangement that keeps them in step for long.

When a model pays for itself, and when it does not

MBSE costs tool licenses, training, and the discipline to keep the model current, and the last of those is the expensive one. A model nobody updates is worse than a good document, because engineers trust it.

A model pays for itself when:

• The system has many interfaces between teams or companies.
• The system has a long life with many changes after the first release.
• The customer requires model deliverables or a digital engineering approach.
• Safety or certification requires traceability from requirement to verification.

A requirement list and tests serve better when:

• One small team builds a system with few interfaces.
• The system is mostly software, and a well-kept requirement list with tests gives the same traceability.
• Nobody will own the model after the first design review.

Start small either way. Model one subsystem with its requirements, interfaces, and states, and connect it to real tests. If that model answers questions faster than the documents did, extend it; if it does not, you have lost little and learned something about your program.

Recommendations

• Model only what a decision or a test needs, and extend the model when it answers questions faster than the documents did.
• Keep every element in exactly one place, and reuse it across diagrams instead of drawing a second box with the same name.
• Name an owner for the model before the first design review, so it stays current after the first baseline.
• Link each requirement to the test that verifies it, so the model can say what has been verified.
• Choose the tool your customer and partners already use, and check its SysML v2 support before planning a migration.

References

• INCOSE, Systems Engineering Vision 2020, INCOSE-TP-2004-004-02, September 2007.
• OMG: SysML 1.7
• OMG: SysML 2.0
• OMG: KerML 1.0
• OMG: Systems Modeling API and Services 1.0
• Defense Acquisition University: Digital thread (glossary)

If your program keeps a SysML model and the software has to trace to it, see Scientific and HPC software or get a free estimate.

Related case studies