What should we really think about measuring WCET?

Following on from my last blog post grumbling about the mixing of terminologies from timing and safety domains, this post explains some of the background to WCET analysis and what RapiTime does.

Understanding what hard and soft real-time actually means

First, we need to think about safety and criticality. I'm going to start by talking about what we mean by hard and soft real-time.

The term "hard real-time" is often misquoted and misused. Hard real-time typically means that missing the deadline implies that the system may fail to achieve its requirements. We should not confuse the "hardness" of a deadline with the system safety.

(As an example, the electronics that controls a camera flash on a mobile phone could be considered hard real-time: if it's too slow then you get dark photos and fail to meet the requirement of taking good photos, but nobody dies. To complete the example, a soft real-time deadline might be the reaction to pressing the button on the camera: if it's too slow, you take a good picture, but perhaps you would have liked it to be a bit quicker).

For most computer systems, if people can be bothered to think about execution times, using a WCET based on a simple end to end maximum, or a maximum + margin is a perfectly adequate method to ensure that their program works well enough for their purposes.

For the remaining (and relatively small percentage of) systems that actually deal with hard deadlines (our customers), what happens if you underestimate the WCET? That depends on the system, how it's been designed and what it's used for. If you're building safety-critical hard real-time systems (say a flight control system), then you might want to understand your WCET really well. If you're building a camera flash, you might want to understand it pretty well (after all, who wants a phone where the camera flash doesn't always work properly).

So, can you use measurements for safety-critical real-time systems?

Of course you can. It's what people have been doing for years. Testing is fundamental to the way we build reliable software. Would you fly in an airplane that had been thoroughly analyzed but had never been tested?

So what does RapiTime do?

1. RapiTime automatically takes many detailed measurements of small parts of your program (not just end-to-end measurements!) to allow you to understand your execution times, worst case execution times and optimize your program.
2. RapiTime computes a WCET estimate based on a careful structural analysis of the source code and lots of test-based evidence.
3. RapiTime helps you to improve your testing, so you can show real, traceable evidence that you have tested your system adequately.

Are RapiTime's WCET results "optimistic" or "pessimistic"?

Contrary to popular rumour, pessimism is the bigger challenge, not optimism! We spend time to reduce the pessimism with various techniques to provide you with a really good WCET value.