Static Binary Code Analysis Tools
Worst Case Execution Time (WCET) Calculation
Runtime error and concurrency error detection
What is the "Worst Case Execution Time"?
Mission-critical applications require source code to be accurate, consistent and deterministic.
For example, in aerospace applications, DO-178C (ED-12C) requires this target for criticality levels DAL C and above.
Among other activities, the determination and analysis of the worst case execution time (WCET) of all existing tasks is required in order to ensure that the required execution times are met within a certain margin.
How is it calculated?
It is calculated by obtaining the worst execution time of the task or program for any possible execution condition. It is necessary to take into account the different code branches plus the possible asynchronous executions derived from interruptions or changes in the execution context of the different tasks.
There are other lower level effects, such as processor mechanisms to speed up program execution like pipeline and cache, whereby the execution time of an instruction is variable depending on what has been previously executed. Finally, with multi-core processors the calculation of WCET becomes more complicated, since to all of the above must be added the effect of interference between cores.
For all these reasons, obtaining the program execution condition or task that causes the worst execution time is impossible in today's applications. What can be obtained is an upper bound of the WCET that will be higher than the actual one, but with a small margin.
WCET analysis with AbsInt tools
There are three AbsInt tools that calculate a WCET upper bound. These tools are based on static analysis of the final binary code: Timing Profiler, aiT and TimeWeaver.
