Model-based design (MBD) is a development approach where a digital model of a system serves as the central artifact throughout the entire engineering process, from initial concept through testing, code generation, and production. Instead of writing traditional specification documents and then manually translating them into code, engineers build a working simulation of the system and use that model as the single source of truth for every downstream activity.
The approach is most widely used in the automotive, aerospace, and embedded systems industries, where complex control systems need to work correctly the first time. But its core idea applies broadly: replace document-heavy, error-prone handoffs between engineering stages with a single, executable model that everyone works from.
How the Workflow Differs From Traditional Development
In a traditional engineering workflow, requirements get written in documents, handed to design engineers, then passed to software developers who write code by hand, and finally given to test engineers who verify the result. Each handoff introduces the risk of misinterpretation. A requirement described in plain English can mean different things to the person who wrote it and the person who codes it.
Model-based design compresses these handoffs. Engineers build a mathematical or graphical model of the system early in development, typically using block diagrams and state charts that represent the system’s behavior visually. This model can be simulated immediately, so you can test whether the design meets requirements before any physical hardware exists or any production code is written. When the design works in simulation, production code is generated directly from the model rather than written by hand. The model stays connected to every stage: requirements trace back to specific model elements, tests run against the model itself, and the generated code can be verified against the model for equivalence.
The Four Stages of Testing
One of MBD’s most distinctive features is a structured sequence of testing stages that progressively move the design from pure simulation toward real hardware. Each stage catches different types of errors, and catching them early is dramatically cheaper than finding them late.
Model-in-the-Loop (MIL) is the first phase. The entire system, both the controller and the thing it controls, exists as a software simulation. Engineers verify that the control algorithm meets initial design requirements in a purely virtual environment. If the logic is wrong, this is where you find out. Any errors in the controller model get corrected here so they don’t propagate to later stages.
Software-in-the-Loop (SIL) comes next. The controller model is replaced with actual generated source code, but it still runs on a desktop computer against a simulated environment. This stage validates that the code behaves identically to the model it came from. Because no physical hardware is needed yet, SIL testing can begin early in development and catch coding errors before any circuit boards are manufactured.
Processor-in-the-Loop (PIL) takes the generated code and runs it on the actual target processor, the specific microcontroller or chip that will be used in the final product. This reveals issues related to the processor itself: timing behavior, memory limitations, and numerical precision differences between a desktop computer and an embedded chip.
Hardware-in-the-Loop (HIL) is the final stage before deploying to a real system. The physical controller hardware runs its embedded code while interacting with a real-time simulation of the surrounding environment. For a satellite control system, for example, simulated models replace the satellite’s sensors and actuators so the hardware can be tested under realistic conditions while still on the ground. HIL testing validates the complete embedded system under conditions that closely mirror real-world operation.
Automatic Code Generation
Generating production code directly from a model is one of the biggest practical advantages of MBD. Instead of a developer manually translating a design into thousands of lines of C or C++ code, specialized tools convert the model into source code automatically. This eliminates a large portion of the manual coding effort and significantly reduces the chance of human errors creeping in during translation.
The generated code maintains traceability back to the model, meaning every line of code can be mapped to a specific block or element in the original design. This traceability is especially valuable in safety-critical industries where regulators need proof that the final software matches the approved design. Tools like MathWorks Embedded Coder and dSPACE TargetLink are widely used in the automotive industry for exactly this purpose, generating code from Simulink models while preserving full traceability chains.
Automatic code generation also accelerates iteration. When a design change happens (and it always does), engineers update the model and regenerate the code rather than manually editing source files and hoping nothing breaks. The consistency between what was designed and what actually runs on the hardware is maintained by the toolchain, not by human diligence.
Why Safety-Critical Industries Rely on It
Automotive and aerospace companies were early adopters of MBD because their products must meet rigorous functional safety standards. In aerospace, the DO-178C standard governs airborne software development and requires extensive evidence that software behaves as specified. In automotive, ISO 26262 imposes similar requirements for electronic systems in vehicles. Both standards demand requirements traceability, thorough testing coverage, and proof that the final code matches the verified design.
MBD workflows align naturally with these demands. Requirements link directly to model elements. Testing at each stage (MIL, SIL, PIL, HIL) generates coverage data that satisfies verification objectives. Tools can demonstrate structural and algorithmic equivalence between a model and its generated code, providing the kind of evidence that certification authorities require. Code analysis tools then verify that the generated code complies with coding standards and is robust against runtime errors like division by zero or buffer overflows.
Without MBD, meeting these standards requires enormous amounts of manual documentation and review. With it, much of the required evidence is produced as a natural byproduct of the development process.
Common Tools and Platforms
The most widely recognized MBD platform is MATLAB/Simulink from MathWorks, which provides the graphical modeling environment, simulation engine, and code generation tools that form the backbone of most MBD workflows. Its ecosystem includes tools for requirements management, test coverage analysis, and formal verification.
Altair offers a suite of alternatives. Twin Activate handles multi-disciplinary system modeling, letting engineers simulate mechanical, electrical, and thermal components together as interconnected 1D models. It supports open standards like Modelica and FMU for coupling simulations of different fidelity levels. Altair Embed focuses specifically on embedded firmware development, supporting block diagram and state chart design with automatic code generation targeting microcontrollers from manufacturers like Texas Instruments, STMicroelectronics, Arduino, and Raspberry Pi. It includes built-in HIL testing with a high-speed communication link for real-time data collection and tuning.
MapleSim, available through the Altair Partner Alliance, emphasizes system-level modeling with a focus on reducing model development time. The choice of tool often depends on the industry, the target hardware, and what’s already established within an organization’s workflow.
Where MBD Is Heading
The growing complexity of modern products is pushing MBD adoption further. In the automotive sector, the shift toward electrification, connectivity, and automated driving has multiplied the number of interacting subsystems in a vehicle. Managing these interactions through traditional document-based engineering becomes impractical at a certain scale, which has heightened the industry’s reliance on model-based approaches to reduce costs and speed up development timelines.
Digital twins represent a natural extension of MBD thinking. A digital twin is a model that stays connected and synchronized to a physical asset throughout its operational life, not just during development. The same engineering models created during MBD can serve as the foundation for these twins, though keeping them faithful to a continuously evolving real-world system remains a significant engineering challenge. Model-based systems engineering provides the methodological framework for tackling that complexity, offering structured ways to define, build, and maintain digital twins for systems like manufacturing lines or operational vehicles.
Organizations already practicing MBD generally report positive perceptions of the value they receive relative to the time and investment required. The upfront cost of adopting the tools and retraining teams is real, but it pays off through fewer late-stage defects, faster iteration cycles, and a development process where the design, the code, and the tests all trace back to one shared model.