What are MIL, SIL, PIL, and HIL, and how do they integrate with the Model-Based Design approach?

What are MIL, SIL, PIL, and HIL and how do they integrate with the Model-Based Design approach?

Answer 1

[MathWorks Support Team]

MIL, SIL, PIL, and HIL testing come in the verification part of the Model-Based Design approach after you have recognized the requirement of the component/system you are developing and they have been modeled at the simulation level (e.g. Simulink platform). Before the model is deployed to the hardware for production, a few verification steps take place which are listed below. Here, I am taking an example of designing a controller for a DC motor and putting the code generated from the model of the Controller in a supported System-on-Chip.

1) Model-in-the-Loop (MIL) simulation or Model-Based Testing

First, you have to develop a model of the actual plant (hardware) in a simulation environment such as Simulink, which captures most of the important features of the hardware system. After the plant model is created, develop the controller model and verify if the controller can control the plant (which is the model of the motor in this case) as per the requirement. This step is called Model-in-Loop (MIL) and you are testing the controller logic on the simulated model of the plant. If your controller works as desired, you should record the input and output of the controller which will be used in the later stage of verification.

See how Mathworks products facilitate model-based testing: https://www.mathworks.com/discovery/model-based-testing.html

2) Software-in-the-Loop (SIL) simulation

Once your model has been verified in MIL simulation, the next stage is Software-in-Loop(SIL), where you generate code only from the controller model and replace the controller block with this code. Then run the simulation with the Controller block (which contains the C code) and the Plant, which is still the software model (similar to the first step). This step will give you an idea of whether your control logic i.e., the Controller model can be converted to code and if it is hardware implementable. You should log the input-output here and match it with what you have achieved in the previous step. If you experience a huge difference in them, you may have to go back to MIL and make necessary changes and then repeat steps 1 and 2. If you have a model which has been tested for SIL and the performance is acceptable you can move forward to the next step.

See how to run SIL simulations using Embedded Coder: https://www.mathworks.com/help/ecoder/software-in-the-loop-sil-simulation.html

3) Processor-in-the-Loop (PIL) or FPGA-in-the-Loop (FIL) simulation

The next step is Processor-in-the-Loop (PIL) testing. In this step, we will put the Controller model onto an embedded processor and run a closed-loop simulation with the simulated Plant. So, we will replace the Controller Subsystem with a PIL block which will have the Controller code running on the hardware. This step will help you identify if the processor is capable of running the developed Control logic. If there are glitches, then go back to your code, SIL or MIL, and rectify them.

See how to run PIL simulations using Embedded Coder: https://www.mathworks.com/help/ecoder/processor-in-the-loop.html

In the case of running the simulation on an FPGA instead of an embedded processor, the simulation is called FPGA-in-the-Loop (FIL). See how to run FIL simulations using HDL Verifier: 

https://www.mathworks.com/help/hdlverifier/ug/fpga-in-the-loop-fil-simulation.html

4) Hardware-in-the-Loop (HIL) Simulation

Before connecting the embedded processor to the actual hardware, you can run the simulated plant model on a real-time system such as Speedgoat. The real-time system performs deterministic simulations and have physical real connections to the embedded processor, for example analog inputs and outputs, and communication interfaces such as CAN and UDP. This will help you with identifying issues related to the communication channels and I/O interface, for example, attenuation and delay which are introduced by an analog channel and can make the controller unstable. These behaviors cannot be captured in simulation. HIL testing is typically performed for safety-critical applications, and it is required by automotive and aerospace validation standards. Learn more about MathWorks product for HIL testing: https://www.mathworks.com/products/simulink-real-time.html

5) Actual Hardware

Once your plant model has been verified using PIL, now you can replace the plant model with the original hardware, say lab model and run a test. Let's say, it is a DC motor whose speed controller is being designed and then the controller is in FPGA/processor which is now interfaced to the DC motor by connecting the inputs and outputs/states at the right points of sensors/transducers).

[madhan ravi]

@M. KORAY YILMAZ , VIL stands for Vehicle in the Loop Testing. To test how the hardware works on a vehicle level.

Answer 2

[Kiran Kintali]

In a HIL setup, Simulation of plant models can be pretty compute intensive and challenging for CPU based simulators. Simscape to HDL provides capabilities to run high fidelity simulations on an FPGA.

Simscape Hardware-in-the-Loop Workflow using FPGA / HDL Coder

Simscape support for HDL code generation and workflow to generate HDL code from the models and deploy to target hardware

https://www.mathworks.com/help/hdlcoder/simscape-to-hdl.html

Check the customer story here: Leonardo DRS Performs FPGA-Based Hardware-in-the-Loop Testing of Shipboard Power Electronics Systems

"CPU-based HIL setups running C code were not capable of simulations with microsecond sampling times at the required level of fidelity. ... Simscape to HDL workflow using HDL Coder enabled high fidelity simualations on FPGA to achieve high fidelity simulations reducing design iterations from days to hours"

Answer 3

[Kiran Kintali]

“M”, “S”, “P” and “H” are all referring to the Controller.

PIL uses the Controller Processor only (no I/O connectivity),

HIL uses the full Controller Hardware, including I/O.