In TPT 19, there is for the first time an early warning system for the worst-case execution time – already for test executions on the local host.
The basic principle: For each test step the execution time is measured. This allows you to quickly and easily identify which tests and which conditions affect the execution times on the local host.
The indicator reveals which tests and which test stimulation drive execution times up. You can therefore use the indicator
- as an early warning system for code changes
- to derive relevant tests for measuring the true WCET on the target
This will save you time, give you faster feedback, and provide you with relevant insights for your developers.
How does it work?
The execution time measurement is switched on in the platform configurator and the execution time of each called function is measured and stored. TPT automatically creates a struct called __suttimes__ and for each function one element of the structs is added. In the signal viewer you can then view and visualize the measurements.
This feature is only available for the C platform; C and C++ are supported.
As usual, you can perform evaluations on these measurements with our popular Assesslets.
What is the Worst Case Execution Time needed for?
Normally, an application in the automotive environment is called cyclically by a scheduler (in the basic software or by the operating system). The scheduler works on basis of fixed time specifications – the call times of a function is in the range of milliseconds. If your application needs more time than the scheduler allows, the calculation of your application will be aborted. This can lead to serious errors. Knowing the worst-case execution time allows you to adjust the planner accordingly.
How is the Worst Case Execution Time determined?
There are two basic approaches:
- measurement on the target environment
- calculation after building the application for a target environment
Measurement on the target environment
This is easy to set up and usually done during PiL testing – meaning, when the software is executed on the target ECU. Unfortunately, to determine the maximum execution time, the necessary test scenarios are not trivial to determine – often only the maximum execution time of the executed tests is measured. It can therefore happen that the true worst case execution time is not determined.
Calculation after building the application for a target environment
Here, test data and scenarios are not required. The calculation is therefore independent of measurements and is based on analysis of the code and architecture of the controller on which it will be executed. There are product manufacturers, such as the company Absinth, that offer specialized tools for exactly such calculations.
How can you benefit from TPT’s Worst Case Execution Time Indicator?
The Worst Case Execution Time Indicator can serve as an early warning system – already during tests on the local host or in your Continuous Integration environment. Even though it will not replace a measurement or calculation approach.
But you do not have to wait for the true Worst Case Execution Time when making changes and thus have faster feedback in case of changes already during SiL testing.