What is the state of the practice in WCET (part 3) - what is the alternative?

Last time we looked at the limitations of a common approach to finding WCET: measuring end-to-end times.

We noted that it is difficult and effort-intensive to identify worst-case paths through the code. What's worse is that the measurements you make can be affected by two sources of variability:

• Variations within the execution path;
• Variations due to context switches.

RapiTime builds on the current state of practice, not only automating the process we've already described, but going beyond this to address the challenges we've identified.

Overcoming variations in timing caused by executing different paths through the code can be overcome by:

• Instrumenting every decision point in the code;
• Measuring the execution times between each pair of decision points;
• Based on a structural model of the code, identify the "critical path" through the code that leads to the longest execution time.

There are also a number of approaches we can take to overcome variations due to context switches:

• Instrument context switches so that either:

   

  • execution times between decision points featuring context switches can be discarded;
  • time spent executing interrupts or switched to processes is recorded so that it can be removed from the execution times of interrupted code.
• Take multiple measurements of each piece of code between decision points so it's obvious if a pre-emption occurs in any given code segments;
• If the only sources of interrupts are periodic interrupts, use knowledge of the period to identify where interrupts take place (this relies on very low jitter).

What we (and our customers) like about this approach is it presents an evolutionary improvement over what's being done right now (recall Part 1), but with some significant reductions in effort, schedule and risk.