Model-Based Software Development is an embedded software initiative where a two-sided model is used to verify control requirements and that the code runs on target electronic hardware.

One side is the Control Model, representing the embedded software of the system. The architecture of the embedded software is modeled with blocks containing algorithms, functions and logic components. Compiled software is auto-generated from this model.

The other side is the Plant Model, representing the physical aspects of the system. Each block contains mathematics that allows it to emulate the behavior of that physical item.

The Stages of Model-Based Software Development

The two sides run interactively in a series of phases that test the embedded software. This includes:

• Model-in-the-Loop (MIL): In this stage, the software is run as the diagram-based model against the plant model in a simulated electronic hardware environment. Once the performance is satisfactory, this provides a nominal baseline against the rest of the testing stages are compared.
• Software-in-the-Loop (SIL): Here, compiled software is auto-generated from the control model and run against the plant model in a simulated electronic hardware environment. This testing reveals any errors in the compiled software architecture.
• Processor-in-the-Loop (PIL): With this stage, compiled software, still auto-generated from the control model, is run against the plant model on the target electronic processor, which is a programmed FPGA or custom ASIC. This reveals any issues with compiled software and target electronic processor interaction.
• Hardware-in-the-Loop (HIL): Finally, in this stage, the compiled software, against auto-generated, is run against the plant model on the full target electronic hardware, often the final Electronic Control Unit (ECU).

Why Pursue Model-Based Software Development?

• Progressive Validation: A fundamental issue in embedded software development is identifying and resolving issues that arise when trying to run the code on target electronic hardware. This is becoming more of an issue as there is an increasing push to move towards lower power electronics. This initiative allows developers to isolate such issues early through fast iterative rounds of virtual prototyping. As a result, engineering organizations can avoid the delays associated with addressing such issues late in development.
• Software Standardization and Certification: Another advantage of this initiative is the standardization of the software code. Because all of the software is auto-generated, it becomes standardized by default, dramatically increasing reuse and improving quality. But furthermore, some regulatory bodies, like the FAA, grant automatic certifications for software code automatically generated from such models, allowing such manufacturers to avoid manual certification processes.

Share this post