Worst-case Execution Time - Finding WCET

Finding WCET

Since the early days of embedded computing, embedded software developers have either used:

• end-to-end measurements of code, for example performed by setting an I/O pin on the device to high at the start of the task, and to low at the end of the task and using a logic analyzer to measure the longest pulse width, or by measuring within the software itself using the processor clock or instruction count.
• manual static analysis techniques such as counting assembler instructions for each function, loop etc. and then combining them.

Both of these techniques have limitations. End to end measurements place a high burden on software testing to achieve the longest path; counting instructions is only applicable to simple software and hardware. In both cases a margin for error is often used to account for untested code, hardware performance approximations or mistakes. A margin of 20% is often used, although there is very little justification used for this figure, save for historical confidence (“it worked last time”).

As software and hardware have increased in complexity, it has driven the need for tool support. Complexity is increasingly becoming an issue in both static analysis and measurements. It is difficult to judge how wide the error margin should be and how well tested the software system is. System safety arguments based on a high-water mark achieved during testing are widely used, but become harder to justify as the software and hardware are less predicable.

In the future, it is likely that a requirement for safety critical systems is that they are analyzed using both static and measurement-based approaches.