Blog
- September 5, 2023
- AUTOSAR software components communicate via standardized interfaces
- The prominently used interfaces are Sender/Receiver and Client/Server
- When is it suitable to use one or the other?
Close
How can I create the needed millions of scenarios?
How can I avoid the test explosion problem?
How can I find out if my tests are passed or failed?
How can I create the needed millions of scenarios?
How can I avoid the test explosion problem?
How can I find out if my tests are passed or failed?
Frontload tests on the target for unit and integration level
Processor-in-the-Loop Testing (or PIL Testing) means, that the piece of code we want to test is compiled with the target compiler and executed on the target processor. But why should we do this? Regardless of whether you are developing handwritten code or working in a Model-based environment like Matlab/Simulink, you are most likely performing Software-in-the-loop simulations (SIL) which run in an idealized environment on a host PC. It usually has a much more powerful CPU compared to the target processor and uses a different compiler.
This leads to some questions:
How do we know if the target compiler has an impact on the software behavior (especially relevant for floating point code)?
How can we analyze runtime aspects like execution time or stack size in early development phases?
How can we fulfill the ISO 26262 requirement to test as close as possible to the target?
Testing these target-dependent aspects only on the system level using Hardware-in-the-loop simulators (HIL) is not efficient. To find issues earlier, smaller parts of the software (e.g. a unit) can be compiled individually for the target and executed in a Processor-in-the-loop environment (PIL). To accomplish this, an evaluation board is connected to the host PC (e.g. via USB), and the PC controls the test execution on the board. PIL testing not only allows you to ensure the correct functional behavior – it also demonstrates that the tested function executes fast enough on the target CPU and that the stack on the target can handle the load.
BTC EmbeddedPlatform offers different options for performing Processor-in-the-loop Testing.
If you are working with dSPACE TargetLink models, you can run the Processor-in-the-loop (PIL) simulation directly using the built-in TargetLink mechanism. BTC EmbeddedPlatform automatically detects the available compilers and target boards and makes them available as an additional simulation level in addition to Model-in-the-loop (MIL) and Software-in-the-loop (SIL). TargetLink supports many combinations of evaluation boards and microcontrollers. The complete list can be found at www.dspace.com.
For non-TargetLink users, BTC EmbeddedPlatform can be enhanced with additional Add-Ons enabling Processor-in-the-loop (PIL) Testing by integrating iSYSTEM winIDEA or Lauterbach Trace32.
For larger projects, BTC EmbeddedPlatform also enables you to run your Requirements-based Tests or Back-to-Back Tests in Processor-in-the-loop mode as part of your CI-CD-pipeline. Discover our easy-to-use Jenkins integration or check out our versatile REST API to add early quality gates and ensure high quality every day (and night).
Sie haben Fragen oder Interesse an einer persönlichen Tool Demo? Nutzen Sie unten stehenden Link, um ein unverbindliches Meeting mit unserem Engineering Team zu buchen.
Sie möchten unsere Tools in Ihrer Entwicklungsumgebung testen? Gerne stellen wir Ihnen eine kostenfreie Evaluierungslizenz zur Verfügung., inkl. Kick-Off Trainings-Workshop und Support durch unser Team.
Sie haben Fragen oder Interesse an einer persönlichen Tool Demo? Nutzen Sie unten stehenden Link, um ein unverbindliches Meeting mit unserem Engineering Team zu buchen.
Intelligent Test Generation for fully automated Back-toBack Tests, Regression Tests and Migration Testssee
Wir entwickeln automatisierte und intelligente Test Lösungen, welche unseren Kunden weltweit dabei helfen, eine hohe Software Qualität im Einklang mit dem ISO 26262 Standard zu erreichen
Copyright © 2023 BTC Embedded Systems
