What is the state of the practice in WCET (part 1)?

Since 2004 we have worked with companies which need to conduct timing analysis on their embedded real-time systems. Our consultancy work gives us plenty of opportunities to speak with engineers about how they are conducting timing analysis right now, and especially how they determine worst-case execution time (WCET). The reasons for needing the WCET of a piece of software may vary:

• it could be a contractual requirement to provide the information
• In aerospace, DO-178B refers to the need to provide WCET information about software
• Before you can perform schedulability analysis, you need to know the WCET for each task

Although other approaches do exist, the most common approach we see in practice to finding WCET is:

1. Add some form of instrumentation at the start and end of the code we're interested in
2. Review the source code to attempt to identify worst-case paths through the code
3. Devise test cases to cause these paths to be executed
4. Using the instrumentation, measure how long the test cases take to execute

The "code we're interested in" could be:

• a task
• a complete partition;
• a section of code.

Reviewing the source code to identify worst-case paths is a task that requires considerable effort and expertise to do well. One way of doing this is to examine the object code generated by the compiler to get some clue of whether one part of the code takes longer to execute than another.

Measuring the execution time of the code uses some form of instrumentation at the start and end of the section of code. The most common forms of instrumentation we see are:

• Toggle an externally visible I/O pin which can be observed with an oscilloscope or a logic analyser;
• Record start time and stop time. Typically recorded in memory and retrieved subsequently.

Next week we assess the limitations of this approach and compare it to an automated timing analysis tool being used to develop the highest criticality systems on aircraft.