EC-20.1 Real Time as a Requirement: Deadlines, Latency and Jitter

What this is and why it exists

Most embedded arguments about speed are really arguments about timing, and the two are not the same thing.

A system that answers in one millisecond almost always, and in forty milliseconds once an hour, is not slow. It is unpredictable. A faster processor does not fix it, because the problem is the structure of the software rather than the speed of the machine.

This topic exists to turn "fast enough" into a number somebody else can test. Everything later in this module is a technique for meeting a requirement, and none of it means anything until the requirement is written down.

The vocabulary

• Deadline — the latest moment at which a response is still useful.
• Hard deadline — one whose miss is a failure of the system.
• Soft deadline — one whose miss degrades the result without breaking it.
• Latency — the time between an event and the response to it.
• Jitter — the variation in that time from one occasion to the next.
• Worst-case execution time — the longest a piece of code can take to run.
• Periodic task — work that arrives at a fixed interval.
• Sporadic task — work that arrives irregularly, with a known minimum gap.
• Superloop — a single endless loop that calls every piece of work in turn.

The mental model

Think of a timing requirement as three things written together: an event, a deadline, and a consequence.

The event is what starts the clock. A button is pressed, a sample is ready, a message arrives. If you cannot point at the event, you do not have a requirement yet.

The deadline is a number with a unit. Ten milliseconds. Two hundred microseconds. It is not "quickly" and it is not "before the user notices", because neither of those can be measured on a bench.

The consequence is what happens on a miss, and it is the part that is usually left out. A dropped frame in a display is nothing. A dropped sample in a motor controller can burn a winding. The same code is correct in the first system and dangerous in the second. The consequence is what decides how much effort the deadline deserves.

Once the requirement exists, two measurements matter. Latency is the straightforward one to measure. Set a pin high when the event arrives, set it low when the response completes, and look at the pin. Jitter is the distribution of that time, and it is what actually breaks systems.

The reason is worst-case execution time. Caches, interrupts and loops whose length depends on the data all make the longest run much longer than the usual one. A system sized on the average works nearly always, which is the worst possible failure mode. It fails rarely, unpredictably, and in the field.

The superloop is where most people start, and it works until one of two things happens. Either a piece of work becomes long, or a deadline becomes short. The first symptom is a response time that grows whenever an unrelated feature is added. That symptom means the structure is wrong, not the code, and the answer is a scheduler.

What you should now be able to explain or do

• Write a timing requirement with an event, a deadline in milliseconds, and a consequence.
• Distinguish latency from jitter, and say why jitter is usually the more dangerous of the two.
• Measure both on real hardware with a spare pin and an oscilloscope.
• Explain why the worst-case execution time matters and the average does not.
• Recognise the symptom that says a superloop has run out.
• Classify a piece of work as periodic, aperiodic or sporadic, and say why the label matters.

Check yourself