Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Software-in-the-Loop testing, also called SiL testing, means testing embedded software, algorithms or entire control loops with or without environment model on a PC, thus without ECU hardware. In fact, SiL Testing is an integral part of automotive software testing. The source code for the embedded system is compiled for execution on the PC and then tested on the PC.
The biggest advantage of Software-in-Loop testing is that you can identify system bugs and errors as early as possible. This not only allows for quick fixes, but consequently reduces development time and keeps development cost to a minimum.
The term “in-the-loop” (“in-loop”) means that parts of the software environment, that is the controlled system or hardware, are simulated. The simulation of a closed control loop is not necessarily mandatory, since some systems under test, especially in module testing, do not require closed control loops.
SiL Testing as Part of MBD
In the case of module or unit test, the Software-in-Loop test is conducted in the first test stage for hand-coded software. Within the context of so-called model-based development (MBD), Software-in-Loop testing is conducted in the second phase, i.e. after Model-in-Loop testing (MiL testing). The consecutive development phases are oftentimes Processor-in-Loop testing (PiL testing), Hardware-in-Loop testing (HiL testing), and automated driving test.
Software-in-Loop testing is used for module, unit, and integration testing. The software integration test uses more complex SiL environments and co-simulation environments as well as hardware virtualization.
For Software-in-Loop testing, the source code must be compiled in advance. Common software compilers such as Microsoft Visual Studio or MinGW are often used. If special functions are used in the software that are not supported by the compiler or the PC processor, these functions must be “stubbed“, meaning replaced by dummy functions.
Code Coverage is a Test Exit Criterion of SiL Testing
A major test exit criterion in Software-in-Loop testing is code coverage. Decision coverage, condition coverage and MC/DC, for example, help determine when sufficient testing is done. To increase code coverage you can use the automatic test case generation tool TASMO, which is a feature of TPT. Unlike the structural test cases that are relevant for code coverage, the functional test cases are usually created or modeled manually.
TPT offers several solutions for Software-in-Loop testing:
- MATLAB/Simulink SiL testing: In the case of automated code generation from Simulink and TargetLink models using Simulink Coder, Embedded Coder, or TargetLink, TPT automatically puts the Simulink model into SiL mode and simulates it for test purposes.
- ASCET & ASCET-DEVELOPER: SiL testing of implementation models created with ASCET and ASCET-DEVELOPER is supported by TPT.
- For handwritten C/C++ code, TPT offers the automatic creation of the test environment directly (C/C++-Platform or EXE-Platform) or a co-simulation environment (FUSION). These test environments are included in the standard scope of TPT.
- AUTOSAR Software can be tested directly, similar to C/C++-Code, or via FUSION. TPT automatically generates the RTE for test purposes.
- Other SiL environments such as VeOS from dSPACE (via ASAM XiL API), Silver from Synopsys, or RT-Lab are supported by TPT.
Give TPT a Try with a Free Evaluation License
You can request a free evaluation license to give TPT a try.
Continue Reading
Blog
2 min read
/
Sep 12, 2024
Industry First Verification IP for Arm AMBA DTI-G
