MBSE in 15 minutes

This page explains model-based systems engineering (MBSE) to someone who has never used it. It takes about fifteen minutes. One small example runs through the whole page: a home heating system, with a thermostat on the wall and a boiler in the basement.

The next page, the tutorial, builds that model from a blank page.

The problem MBSE solves

Engineers who build a system write a lot about it: what the customer needs, what the system must do, how it is split into parts, which part does what, how each requirement is tested. Traditionally each of these lives in its own document: a requirements spreadsheet, an architecture slide deck, a test plan, an interface table.

The documents describe the same system, but nothing connects them. When a requirement changes, someone must find every slide, table and test that depends on it. Some are missed. The test plan still tests last year's requirement; the slide still shows a part that was removed. Nobody can answer simple questions with confidence, such as "which requirements does this part serve?" or "is every requirement tested?".

One model instead of documents

Model-based systems engineering replaces those documents with one model: a structured description of the system that a computer can read and check.

A model is made of elements (a requirement, a function, a component, a test) and relationships between them (this component satisfies that requirement, this test verifies it). Diagrams, tables and reports are views of the model. They are produced from it, so they cannot disagree with each other.

Because the model is structured, a tool can answer questions about it:

• Which requirement has no test?
• Which part does nothing that a requirement asks for?
• If I remove the radio link, what breaks?
• Does the chain from temperature reading to burner command fit in 2 seconds?

In ArcLang, the model is plain text that a compiler checks, and the diagrams are drawn from that text. You can also draw on a diagram: the drawing is written back into the text.

Needs before solutions

The first idea of MBSE is to describe the need before the solution.

For the heating system, the need is: the people who live in the home want it to stay at the temperature they choose. That sentence says nothing about thermostats, boilers or radio. It is true whatever technology you pick.

The solution comes later: a wall thermostat measures the temperature and sends it by radio to a control board that fires the burner. Another team could pick another solution for the same need.

Keeping the two apart has a practical benefit. When you change the solution (a wired thermostat instead of a radio one), the need does not move, and the model shows you which parts of the solution must still meet it.

Requirements

A requirement is a statement the system must meet, written so that it can be checked. "The home is comfortable" cannot be checked. These can:

• REQ-001: The system shall keep the living room within 0.5 °C of the set temperature.
• REQ-002: The system shall start or stop the burner within 2 s of a reading that crosses the set temperature.
• REQ-003: The occupant shall be able to change the set temperature on the thermostat.

In a model, each requirement is an element with a stable identifier (REQ-001), so other elements can point at it.

Functions and components

The second idea is to separate what the system does from what it is made of.

A function is something the system does, named with a verb: measure the room temperature, decide the heating demand, drive the burner. Functions pass data to each other through functional exchanges: the measured temperature flows from measure to decide.

A component is a part of the system: thermostat, heating controller, burner unit. Components are connected by component exchanges that carry the data between them.

You then allocate each function to a component: the thermostat measures, the controller decides, the burner unit fires. Functions describe the behavior, components the structure, allocation links the two. If you later merge the controller into the thermostat, the functions do not change; only their allocation does.

Levels of abstraction

MBSE describes the system at several levels of abstraction, from the most general to the most concrete. Each level answers one question. The Arcadia method, which ArcLang follows, uses these:

Each level is more detailed than the one above, and it must still serve it. That is checked with traceability.

Traceability

Traceability means every element is linked to the reason it exists. In a model these links are traces, and they have a kind:

• a component satisfies a requirement: the heating controller satisfies REQ-001;
• a lower-level element realizes a higher-level one: the system function decide the heating demand realizes the operational activity keep the rooms warm;
• a test verifies a requirement.

With traces in place, both directions of the question have an answer. From a requirement, you find the parts that meet it and the tests that prove it. From a part, you find why it exists. A part that traces to nothing is a part nobody asked for.

Here is a small piece of the heating model in ArcLang. It declares one requirement, one component, the trace between them, and a test:

requirements {
  req "REQ-001" "Comfort" {
    description: "The system shall keep the living room within 0.5 °C of the set temperature"
  }
}

logical_architecture "Logical Architecture" {
  component "Heating controller" { id: "LC-CTRL" }
}

trace "LC-CTRL" satisfies "REQ-001" { rationale: "Closes the loop between the reading and the set point" }

test_case "TC-001" {
  verifies: ["REQ-001"]
  method: "test"
  description: "Record the room temperature for 24 h in a test house"
}

The compiler checks every reference. A trace to a requirement that does not exist stops the build with a line and a column.

Verification

Verification answers the question "did we build the system right?". Each requirement needs at least one verification case (a test_case in ArcLang) that says how it is checked. There are four methods:

• test: measure it on the real system or a prototype;
• analysis: compute it, for example by adding up latencies;
• inspection: look at the design or the product;
• demonstration: show it working.

Some checks can run on the model itself. The heating model gives each function a latency (500 ms, 200 ms, 1 s) and gives the chain from reading to burner a budget of 2 s. The compiler adds the latencies along the chain and compares the sum with the budget, every time the model changes. If someone later makes the burner slower, the model says so before any hardware is built.

What you get

When the model is complete, a tool can decide whether it is ready for a design review. ArcLang's production gate gives a PASS or FAIL verdict: every requirement satisfied and verified, every budget met, every safety level justified. The verdict comes with the list of what is missing.

That is the practical value of MBSE: questions that used to need a meeting are answered by the model, and the answers stay true as the system changes.

Next

• Build the heating model yourself in the tutorial, from a blank page.
• Learn the five levels of the Arcadia method, the method of the Capella tool.
• Or model with the concepts of the SysML v2 standard.