At the most basic level, a PIL simulation can be summarized as follows:
- Input variables on the embedded processor, such as current and voltage measurements, are overridden with values provided by the PLECS simulation.
- The control algorithms are executed for one control period.
- Output variables on the target, such as PWM peripheral register values, are read and fed back into the simulation.
Why PIL?
Engineers developing embedded control algorithms often test such code, or portions thereof, by executing it inside a circuit simulator. Using PLECS, this can be easily done with a C-Script or DLL block. This approach is referred to as Software-in-the-loop (SIL). A SIL simulation compiles the embedded source code for the native environment of the simulation tool (e.g. Win64) and executes the algorithms within the simulation environment.
The PIL approach, on the other hand, executes the control algorithms on the real embedded hardware. Instead of reading the actual sensors of the power converter, values calculated by the simulation tool are used as inputs to the embedded algorithm. Similarly, outputs of the control algorithms executing on the processor are being fed back into the simulation to drive the virtual environment. Note that SIL and PIL testing are also relevant when the embedded code is automatically generated from the simulation model.
A major advantage of PIL over SIL is that during PIL testing, actual compiled code is executed on the real MCU. This detects platform-specific software defects such as overflow conditions and casting errors. Also, although PIL testing does not execute the control algorithms in true real-time, the control tasks do execute at the normal rate between two simulation steps. Therefore, PIL simulation can be used to expose and analyze potential problems related to the multi-threaded execution of control algorithms, including jitter and resource corruption.