MBSE with SysML v2: Moving from Diagrams to Decisions

Systems Engineering has a reputation problem. MBSE (Model-Based Systems Engineering) is often perceived as a documentation exercise imposed by large aerospace primes — a box to check before the real work starts. That's the wrong mental model, and it costs projects dearly.

The Actual Problem MBSE Solves

On complex embedded projects, requirements drift is fatal. A hardware engineer designs a signal conditioning circuit for a sensor range that the firmware engineer already changed. A UART baud rate gets updated in a prototype without propagating to the DFM checklist. A medical device ships with a requirement that was tested but never formally traced to a validation record. These are not process failures — they're communication failures at the system level.

What SysML v2 Changes

SysML v2 (the 2024 revision) is a substantial improvement over v1:

• •Cleaner syntax for block definitions and port connections.
• •First-class support for requirement traceability (satisfy, verify relationships).
• •Better integration with model execution tools.
• •A specification designed to be machine-readable, not just human-readable.

The last point matters most for embedded engineers. A SysML model that can be queried programmatically — "show me all requirements not yet covered by a test" — is a live project management tool, not a PDF appendix.

A Practical Starting Point

You don't need to model everything. The highest-value SysML artifacts for embedded projects:

• •Use Case Diagram — who uses the system and what do they expect? Forces early alignment between hardware, software, and the client.
• •Block Definition Diagram (BDD) — defines subsystem boundaries and interfaces. Prevents the "I thought you were handling the CAN framing" conversations.
• •Requirements Diagram — links each requirement to a test. Makes V&V traceable without a separate spreadsheet.

Real Example: Battery Test Platform

For the Volthium battery platform, a SysML BDD in the early design phase would have made the multi-protocol interface boundary explicit from day one: the SmartBridge as a hardware block with defined ports (CAN, UART, Ethernet, Bluetooth), each connected to software adapter blocks. Instead of discovering the architecture through iteration, we'd have had it on paper before writing the first line of firmware.

That's what MBSE done right looks like — not diagrams for stakeholders, but decisions captured early enough to prevent late-stage rework.

Where to Start

Start with one project, one diagram type. Pick the BDD. Map your subsystems and their interfaces. Run a review with hardware and software together. You'll find at least three assumptions that don't match between the two teams. Fix them before writing code. That's MBSE in practice.