Processor-in-the-Loop testing (PiL) refers to the testing and validation of embedded software on the processor that will later be used in the Electronic Control Unit (ECU). The algorithms and functions are usually developed on a PC within a development environment either directly in C, C++ or model-based. This could be, for example, a Simulink, TargetLink, ASCET or ASCET-DEVELOPER model. The resulting C/ C++ code must be compiled with a special “target” compiler for the processor, which is later used in the ECU in the vehicle. PiL tests are performed to check whether the compiled code also works on the target processor. The control algorithms for the PiL test are usually executed on a so-called evaluation board. Sometimes PiL tests are also executed on the real ECU. Both variants use the real processor used in the controller and not the PC as in Software-in-Loop (SiL) testing. Using the target processor has the advantage that compiler errors can be detected.
“In-the-loop” in PiL tests means that the controller is embedded in the real hardware and the environment of the software under test is simulated. Environment models such as MiL, SiL, and HiL are rather unusual in PiL testing, since embedding such models on the target processor is complex or impossible. When environment models come together with the processor, you usually speak of Hardware-in-the-Loop testing (HiL).
PiL Testing Environments with TPT
TPT enables PiL testing via so-called debuggers. TPT controls the debugger like Lauterbach TRACE32 or PLS UDE remotely to execute the compiled code directly on the processor. What’s primarily being tested via PiL testing are single functions or smaller groups of functions.
Give TPT a try with a free evaluation license
You can request a free evaluation license to give TPT a try.