Real-Time Systems
Introduction
Real-time does not mean "real fast." It means the system must produce a correct result within a time constraint. Missing a deadline in a motor controller or medical device can be as bad as computing the wrong answer — sometimes worse.
Embedded engineers constantly trade average speed against worst-case behaviour. This article explains hard, firm, and soft real-time, and how operating systems support deadline-driven design.
Three levels of real-time
| Type | Deadline | If missed |
|---|---|---|
| Hard real-time | Must always be met | System failure, unsafe state, catastrophe |
| Firm real-time | Should be met | Quality of service degrades; result may be discarded |
| Soft real-time | Should be met on average | Gradual degradation (e.g. video stutter) |
Examples:
- Hard: airbag deployment, engine ignition timing, industrial safety PLC
- Firm: packet loss in VoIP if frame is too late to play
- Soft: weather dashboard refresh — occasional delay is annoying, not fatal
Why embedded cares
General-purpose OS schedulers optimize throughput and fairness. Embedded control loops optimize determinism:
- Sensor sample every 1 ms ± 10 µs
- PWM update synchronized to timer
- CAN message response within protocol limit
Jitter (variation in response time) matters as much as average latency.
Design techniques
| Technique | Purpose |
|---|---|
| Hardware timers | Precise periodic ticks |
| Interrupts | Fast reaction to pins and peripherals |
| RTOS with priority scheduling | Guarantee high-priority tasks run first |
| Rate Monotonic Scheduling (RMS) | Assign higher priority to shorter-period tasks |
| Earliest Deadline First (EDF) | Dynamic priority by nearest deadline |
| Avoid blocking | No long waits in critical paths |
| Watchdog timer | Reset if main loop hangs |
See Operating systems for RMS, EDF, and RTOS concepts.
Real-time vs "as fast as possible"
Profiling average loop time is insufficient. You need worst-case execution time (WCET) analysis or measurement under load for safety-related systems.
Testing real-time behaviour
- Oscilloscope / logic analyzer on GPIO toggle in loop — measure jitter
- Timestamp logs on serial (mind logging overhead)
- Load testing — run network + UI + sensor together; deadlines must still hold
- Fault injection — slow I/O, drop packets; verify safe defaults
Relevant topics
- Embedded systems overview
- Operating systems
- Firmware architecture
- Rate-monotonic scheduling (Wikipedia)
Starting points
- Classify your current project: hard, firm, or soft real-time — write one sentence why.
- Measure loop period with a GPIO pin and scope — note min, max, average.
- List deadlines explicitly (e.g. "read sensor ≤ 5 ms").
- Define safe state when a deadline is missed.
Focus points
- Real-time = timeliness + correctness, not maximum MHz.
- Hard deadlines need proof or rigorous test, not hope.
- Logging and printf can break real-time — use sparingly in hot paths.
- RTOS helps but does not replace bad architecture.
Key points
- Hard / firm / soft real-time classify consequences of missing deadlines.
- Embedded systems often need bounded jitter, not just low average latency.
- Use timers, ISRs, RTOS priorities, and scheduling theory (RMS, EDF) deliberately.
- Validate under worst-case load, not idle bench conditions.