Real-time behaviour
Design for the right result at the right time: express deadlines, control interference and demonstrate timing under credible worst-case conditions.
After this module, you should be able to:
- Translate behaviour into timing requirements
- Choose an appropriate execution model
- Recognise scheduling and concurrency hazards
- Plan convincing timing verification
Study guide · Updated · About 9 minutes reading + 20–30 minutes practice
Before you start: Read TEA-102 and TEA-104. Basic periodic-task and interrupt concepts are assumed.
Real-time means bounded response, not simply fast execution.
A system is real-time when correctness depends on both the logical result and when that result is produced. Average performance is therefore insufficient: the architecture must make important timing limits explicit and control the conditions that can delay them.
| Term | Meaning | Why it matters |
|---|---|---|
| Latency | Delay from an event to the start or completion of its response. | Determines whether an external event is handled in time. |
| Jitter | Variation in timing between otherwise comparable executions. | Can disturb sampling, control loops and communications. |
| WCET | Worst-case execution time for a bounded software operation. | Supports response-time and schedulability analysis. |
| Period | Required interval between repeated releases or executions. | Defines sampling and control cadence. |
| Deadline | Latest acceptable completion relative to a defined event. | Separates acceptable timing from failure. |
Choose an execution model whose timing can be understood.
| Model | Strengths | Typical risks |
|---|---|---|
| Cyclic executive | Simple sequence, low overhead and timing that can be easy to inspect. | One long activity delays everything; rates and blocking operations need discipline. |
| Interrupt-driven | Low response latency for asynchronous hardware events. | Excess work, nesting, shared data and priority interactions make behaviour opaque. |
| RTOS tasks | Explicit priorities, blocking, timers and separation of activities. | Priority inversion, starvation, deadlock, stack use and configuration errors. |
| Event / state model | Clear behavioural transitions and work triggered by meaningful events. | Queues can overflow; long handlers and event storms can break assumptions. |
Many products combine these models: a short interrupt captures an event, a high-priority task performs time-critical processing, and lower-priority tasks handle reporting or storage. The design must still have one coherent priority and resource-sharing policy.
Control interference deliberately
- Keep interrupt service routines short, bounded and non-blocking.
- Assign priorities from deadlines and interference analysis, not perceived importance.
- Use queues, immutable messages or carefully bounded critical sections for shared data.
- Give blocking calls, retries and memory allocation explicit timing policies.
- Monitor missed deadlines, queue high-water marks, execution time and stack margin.
Trace the complete timing path.
- Start from the physical need. Derive sampling, actuation and fault-response deadlines from system behaviour.
- Map the path. Include sensors, buses, DMA, interrupts, tasks, algorithms, outputs and mechanical response.
- Bound each contributor. Account for execution, pre-emption, blocking, transfer time, retries and clock tolerance.
- Analyse interference. Consider higher-priority work, shared resources, interrupt bursts and simultaneous events.
- Define overload behaviour. Decide what may be dropped, deferred, degraded or treated as a fault.
- Measure under stress. Exercise maximum load, longest messages, cold start, diagnostic activity and credible faults.
Worked example: 1 kHz motor-control loop
The loop has a 1 ms period, but the useful deadline is earlier because the PWM register must update before the next hardware latch point.
If acquisition consumes 80 µs, release and interference can consume 120 µs, the algorithm takes up to 210 µs and the output update needs 20 µs, the design has a 430 µs bounded path before adding margin. Trace measurements should confirm the bound while communications and diagnostics generate their maximum credible load.
Make timing claims reviewable and repeatable.
Defined events, periods, deadlines, jitter limits, overload responses and rationale.
Tasks, interrupts, priorities, activation sources, shared resources and blocking policy.
WCET assumptions, response-time calculations, bus timing and allocated margins.
Timestamped evidence showing release, execution, pre-emption and completion.
Measurements at maximum credible CPU, bus, interrupt, storage and fault load.
Overrun counters, queue depth, watchdog servicing, stack margin and diagnostic handling.
Common failure patterns
Typical measurements look comfortable, but a rare worst-case path misses the deadline.
Tasks called “critical” receive high priority without analysing deadlines and interference.
Convenient processing inside an interrupt creates uncontrolled latency elsewhere.
Instrumentation changes timing, while the released configuration is not equivalently characterised.
Build an end-to-end timing model
Define the event that starts the clock and the physical condition that stops it. A requirement to stop motion within 50 ms includes sensing, filtering, scheduling, decision, output switching and mechanical response. Measuring the stop function’s execution time covers only one contributor.
Separate period, deadline, jitter and execution time. A task that runs every 20 ms may need a 5 ms response to a separate event. Polling alone cannot meet that demand unless its phase and all other delays fit. Use a more suitable activation or change the allocation.
Account for timing variation from interrupt masking, cache state, DMA contention, flash operations and communications bursts. An observed maximum is valuable evidence from a defined experiment. Calling it a worst-case bound requires an argument about the relevant unobserved conditions.
Analyse scheduling and blocking together
Processor utilisation is a capacity check, not a general deadline proof. Periodic tasks taking 1 ms every 10 ms and 2 ms every 20 ms use 20% of CPU capacity before overhead. A long non-pre-emptible operation can still delay the urgent task beyond its deadline.
For a simplified pre-emptive fixed-priority model, a response-time calculation iterates execution time plus blocking plus interference from higher-priority tasks. The model must match release jitter, task dependencies and interrupt behaviour. Use an established analysis method appropriate to the actual scheduler rather than applying a formula without its assumptions.
Bound lock duration and avoid slow I/O while holding resources needed by urgent work. Priority inheritance can limit some inversion patterns but does not remove excessive critical-section duration. Define the maximum amount of queued work and the overload policy as part of the timing design.
Define what happens when time assumptions fail
A missed sample should not disappear into an average-rate metric. Record gaps, sequence loss and deadline violations in a bounded way. Decide whether the product skips stale work, recomputes using elapsed time, enters a degraded mode or stops. Rapidly executing old control steps may issue physically inappropriate commands.
Use a monotonic time base for durations. Wall-clock corrections can make elapsed-time calculations jump backwards or forwards. Timer wrap handling needs an explicit interval limit and checking cadence. Test at the boundary rather than assuming an unsigned counter makes every duration safe.
| Timing evidence | What it establishes |
|---|---|
| GPIO or hardware capture | Observed physical start and response timing. |
| Scheduler trace | Ready, running, blocked and interrupted intervals. |
| Static or analytical model | A bound under stated execution and interference assumptions. |
| Stress experiment | Behaviour at selected load and environmental extremes. |
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Check a protective response budget
A protective response must complete within 50 ms. Allocations are 8 ms sensing, up to 10 ms polling delay, 4 ms processing and 18 ms physical stopping.
- Calculate the total allocation and remaining margin.
- Assess an added 15 ms flash operation that blocks the processing task.
- Define measurement points and two stressful event phases.
Show the worked answer
The allocation totals 40 ms, leaving 10 ms. A fully blocking 15 ms flash operation could increase the response to 55 ms and invalidate the budget. Move or restructure the operation, provide an adequately independent response path, or demonstrate a tighter justified bound. Average spare CPU capacity does not resolve the blocking problem.
Measure from the defined physical hazard indicator to the required stopped condition. Trigger just after the polling check and during the longest blocking interval, with relevant communications and interrupts active. Include instrument uncertainty and physical stopping variation. Report observed values separately from the budget, then reconcile discrepancies before accepting the timing claim.
Review criteria
- All physical and software delays appear in the budget.
- The added blocking is assessed against the deadline.
- Tests challenge phase alignment and observe the final physical state.
Check your understanding
Does low average CPU load prove deadlines?
No. Blocking, bursts, priority and event phase can produce a long response while average utilisation remains low.
Why distinguish wall time from monotonic time?
Wall time may change during synchronisation. Duration measurement needs a stable elapsed-time basis and defined wrap behaviour.
Further learning
- FreeRTOS task schedulingScheduling behaviour for single-core and multicore kernel configurations.
- Arm CMSIS-RTOS2 theory of operationThreads, states, scheduling, inter-thread communication and timing concepts.
Deadlines must survive interference.
Real-time assurance comes from defined timing requirements, bounded execution and evidence collected under credible worst-case conditions—not from a fast processor or low average CPU load.