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
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.
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.