4. Model-based systems engineering (MBSE) in vehicle programs

In a modern vehicle program, the number of interacting functions, ECUs, sensors, actuators, and software components grows far faster than any document-based specification process can absorb. Model-Based Systems Engineering (MBSE) replaces the document-centric exchange of requirements and design descriptions with a coherent, version-controlled system model. In automotive practice, that model is usually expressed in SysML (Systems Modeling Language), and it becomes the single authoritative source for architecture, interfaces, and traceability from stakeholder requirements down to component-level design.

The value of MBSE is not the diagram itself. It is that every element in the model — a requirement, a function, a logical component, a physical ECU, a signal — is a uniquely identified object with typed relationships. When a requirement changes, the model can show which functions, interfaces, and test cases are affected. This is what makes MBSE practical in a program with thousands of signals and dozens of suppliers.

SysML Diagram Types and Their Role in a Vehicle Program

SysML is a profile of UML 2 adapted for systems engineering. Not all of its nine diagram types are equally useful in automotive work. The following table summarizes the ones most commonly applied, together with the vehicle-program question each one answers.

A common mistake is to treat these as separate deliverables produced by different teams. In a healthy MBSE workflow they are views onto one model. A block defined in a BDD is the same element that appears as a part in an IBD and as a lifeline in a sequence diagram. This identity is what enables automated consistency checking.

Architecture Modeling: From Logical to Physical

Vehicle architecture modeling typically proceeds through two layers. The logical architecture describes what the system must do and how functions are decomposed, independent of which ECU hosts them. The physical architecture allocates those logical functions to concrete hardware and software nodes. Keeping these layers separate is essential: it allows function allocation to change (for example, moving a function from a domain ECU to a central compute platform) without rewriting the functional description.

In SysML terms, the logical layer is modeled with blocks representing functions and logical components, connected by item flows. The physical layer is modeled with blocks representing ECUs, sensors, actuators, and buses, with allocation relationships linking the two. A typical allocation statement reads: Logical function "Lane Keeping Control" is allocated to physical component "ADAS Domain Controller". When the program later migrates that function to a zonal architecture, only the allocation changes; the logical model remains stable.

Consider a concrete example. A vehicle program defines a logical function AdaptiveCruiseControl with sub-functions ObjectDetection, TargetTracking, and LongitudinalControl. In the logical BDD, these are composed under a CruiseControlSystem block. In the physical BDD, the program has an ADAS_ECU and a Brake_ECU. Allocation maps ObjectDetection and TargetTracking to ADAS_ECU, and LongitudinalControl to Brake_ECU. The IBD then shows the connectors between these physical blocks, carrying the item flows TargetObjectList and DecelerationRequest.

Interface Management

Interface management is where MBSE delivers its most tangible program benefit. In document-based programs, interface definitions live in separate ICDs (Interface Control Documents) maintained by different teams, and mismatches are discovered late — often during integration. In an MBSE approach, interfaces are first-class model elements: ports, item flows, and interface blocks with typed properties.

An interface in SysML is typically modeled as an interface block (a special class) that defines the flow properties exchanged. For example, an interface block ICruiseControlInterface might define flow properties targetObjectList : TargetObjectList and decelerationRequest : DecelerationRequest. Ports on the ADAS and brake ECUs are typed by this interface block, and connectors in the IBD must be compatible with it. The modeling tool can then check that every connector's ends have matching types — a check that catches errors before any code is written.

Practical interface management in a vehicle program involves several concrete activities:

• Interface catalog: a model package listing all interface blocks with their flow properties, units, and update rates.
• Signal-level detail: each flow property maps to one or more signals with defined data types, ranges, and scaling. For CAN, this includes message ID, DLC, and signal start bit and length.
• Ownership and versioning: each interface block has an owning team and a version. Changes require review by both producer and consumer.
• Consistency checks: automated rules verify that every port is connected, every flow property is typed, and no connector joins incompatible interfaces.

Worked Example: Modeling a Cruise Control Interface

Suppose the program needs to define the interface between the ADAS ECU and the brake ECU for adaptive cruise control. The steps in the model are:

1. Create an interface block ICruiseControlInterface in the interface package.
2. Add flow properties: decelerationRequest : DecelerationRequest [m/s²] with range −5.0 to 0.0, and accStatus : ACCStatus as an enumeration.
3. Define a port accOut : ICruiseControlInterface on the ADAS_ECU block and a conjugate port accIn : ICruiseControlInterface on the Brake_ECU block.
4. In the IBD, connect accOut to accIn with a connector typed by the interface block.
5. Run the consistency check: the tool reports any unconnected ports or type mismatches.

The expected observable result is a clean IBD with no validation errors, and a generated interface report listing the two flow properties with their types and units. A typical failure symptom is a validation error stating that the connector ends have incompatible types — usually caused by one port being typed by a different interface block or by a missing conjugate. The fix is to align both ports to the same interface block and ensure the consumer port is marked conjugate.

Traceability and Change Impact

The final pillar of MBSE in vehicle programs is traceability. Every requirement in the model should be satisfied by at least one design element, and every design element should trace back to a requirement. In SysML this is expressed with «satisfy» and «derive» relationships. When a stakeholder requirement changes — for example, the maximum deceleration request is extended from −5.0 to −6.0 m/s² — the model can immediately show which interface blocks, ports, and test cases are affected. This impact analysis is what turns MBSE from a documentation exercise into an engineering control mechanism.

In practice, a program should define a small set of model quality gates: no orphan requirements, no unconnected ports, no unallocated functions, and no interface block without an owner. These gates can be automated in the modeling tool and run as part of the regular model review. The result is an architecture description that stays consistent as the vehicle program evolves, rather than drifting into a collection of outdated documents.