A real-time embedded system is a computer built into a larger device whose job is not just to compute the right answer, but to compute it at the right time. The airbag controller that fires 20 milliseconds too late, the motor drive that misses a current-loop update, or the video pipeline that drops frames under load all have one thing in common: the logic may be perfect, yet the system still fails because time is part of its specification.
This guide explains what “real-time” really means, how it differs from “fast,” and how engineers classify timing requirements as hard, firm or soft. It also introduces the vocabulary (periods, deadlines, worst-case execution time, jitter) you will need for the more advanced articles on this site, from comparing Rate Monotonic and EDF scheduling to computing worst-case response times by hand.
Key takeaways
- A real-time system is one whose correctness depends on both the logical result and the time at which it is produced.
- Real-time means predictable, not necessarily fast: a guaranteed 10 ms response beats an average 1 ms response that occasionally takes 50 ms.
- Deadlines are classified as hard (a miss is a failure), firm (a late result is worthless but not catastrophic) or soft (a late result loses value gradually).
- Most real-time workloads are modeled as tasks with a period or minimum inter-arrival time, a relative deadline and a worst-case execution time (WCET).
- Timing guarantees come from combining a predictable platform, a suitable scheduling policy and a schedulability analysis, not from testing alone.
Defining real-time: when correctness depends on time
The classic definition, used in textbooks by Kopetz, Buttazzo and Burns & Wellings, is that a real-time system is one in which the correctness of the system depends not only on the logical result of computation but also on the time at which the results are produced. A temperature reading that is accurate but arrives after the control decision has already been made is, for practical purposes, a wrong reading.
This definition has an important consequence: real-time behavior is a property of the whole system and its environment, not of a single piece of software. The environment, whether it is a combustion engine, a robotic arm or a network of sensors, imposes the time constraints. The computer must keep pace with it.
Real-time is not the same as fast
A common misconception is that real-time simply means “high performance.” In reality, a real-time designer cares about the worst case, not the average. A desktop operating system is optimized for throughput; it may usually answer in microseconds and occasionally in hundreds of milliseconds because of paging or a background task. For a spreadsheet that is fine. For a fuel-injection controller it is unacceptable.
Rule of thumb: if you can state an upper bound on how long every critical operation can take, and you can justify that bound, you are doing real-time engineering. If you can only quote averages or percentiles from benchmarks, you are doing performance engineering.
Event-triggered and time-triggered systems
Real-time systems are often described as event-triggered, where activities start in response to interrupts or messages, or time-triggered, where activities start at predetermined instants of a global time base. Time-triggered designs such as cyclic executives are highly predictable and easy to certify but inflexible. Event-triggered designs with preemptive priority scheduling handle sporadic workloads efficiently but need analysis to bound interference. Many products mix both.
What makes a system “embedded”
An embedded system is a computer dedicated to a specific function inside a larger mechanical or electronic product. Users interact with the product, not with the computer: they press a brake pedal, not a key on a terminal. Embedded systems typically share several characteristics:
- Resource constraints: limited memory, CPU frequency, energy budget and cost per unit, often measured in cents at high production volumes.
- Direct interaction with the physical world through sensors and actuators, which is exactly why timing matters.
- Long lifetimes and high dependability requirements: an industrial controller may run unattended for 15 years.
- Specialized hardware: microcontrollers, DSPs, FPGAs, systems-on-chip with accelerators, and increasingly multicore processors.
Not every embedded system is real-time, and not every real-time system is embedded (trading platforms have strict latency requirements too). The intersection, however, is enormous: automotive ECUs, avionics, medical devices, industrial automation, robotics, drones and railway signaling.
Hard, firm and soft deadlines explained
The deadline is the time by which a computation must complete. What distinguishes the three classic categories is what happens when a deadline is missed. A useful mental model is a utility function: how much value does a result deliver as a function of its completion time?
Hard deadlines
Missing a hard deadline is a system failure, potentially with catastrophic consequences: loss of life, injury, major equipment damage or environmental harm. The utility of a late result is not just zero; it can be strongly negative. Examples include flight-control surface updates, airbag deployment, anti-lock braking and pacemaker pacing. Systems with hard deadlines require an a priori guarantee, which in practice means static schedulability analysis based on safe WCET bounds.
Firm deadlines
A firm deadline means that a late result is useless and is simply discarded, but an occasional miss does not cause a failure. A video decoder that cannot finish a frame in time drops it; a sensor fusion step that produces an estimate after the next sample has arrived throws it away. Firm systems are often specified with constraints such as “no more than m misses in any k consecutive jobs” (the so-called (m,k)-firm or weakly-hard model).
Soft deadlines
With a soft deadline, a late result still has some value, but that value decreases as lateness grows. User-interface responsiveness, audio buffering with some slack, and logging are typical examples. Soft real-time systems are often evaluated with statistical metrics such as average tardiness or the percentage of deadlines met, and they benefit from resource reservation techniques like the constant bandwidth server used by Linux SCHED_DEADLINE.
| Category | Value of a late result | Consequence of a miss | Typical guarantee | Examples |
|---|---|---|---|---|
| Hard | Zero or negative | System failure, possible harm | Static analysis with safe WCET, 100% of deadlines | Flight control, ABS, airbag, pacemaker |
| Firm | Zero (result discarded) | Degraded quality, tolerable if rare | Bounded miss patterns, e.g. (m,k)-firm | Video frames, radar tracking updates, sensor fusion |
| Soft | Decreases with lateness | Reduced quality of service | Statistical or reservation-based guarantees | UI, streaming audio buffers, telemetry |
In practice, a single product almost always contains all three. A car’s electronic stability control has hard deadlines, its camera-based lane detection may be firm, and its infotainment is soft. Running these on shared hardware without letting the soft parts endanger the hard ones is the central problem addressed by mixed-criticality systems and by contract-based scheduling.
The task model: periods, deadlines, WCET and jitter
To reason about timing mathematically, engineers abstract software into tasks (also called threads or processes), each of which releases a sequence of jobs. The most widely used abstraction is the sporadic task model, in which each task τi is characterized by a few parameters. You can find all of these terms in our real-time systems glossary.
- Period or minimum inter-arrival time (Ti)
- For a periodic task, the fixed interval between releases; for a sporadic task, the minimum separation between consecutive releases.
- Relative deadline (Di)
- The time after release by which each job must complete. Deadlines can be implicit (D = T), constrained (D ≤ T) or arbitrary.
- Worst-case execution time (Ci)
- An upper bound on the processor time a job needs when running alone, without preemption. Obtaining a safe and tight value is the subject of WCET analysis.
- Release jitter (Ji)
- The variation between the nominal arrival of an event and the moment the task actually becomes ready, for example due to interrupt latency or polling.
- Worst-case response time (Ri)
- The longest possible time from release to completion, including interference from other tasks and blocking on shared resources. A task set is schedulable if R ≤ D for every task.
A worked example: a motor-control node
Consider a small motor-control microcontroller running three tasks. The figures are illustrative but realistic in proportion.
| Task | Function | Period T (ms) | Deadline D (ms) | WCET C (ms) | Utilization C/T |
|---|---|---|---|---|---|
| τ1 | Current control loop | 1 | 1 | 0.25 | 0.250 |
| τ2 | Speed control loop | 10 | 10 | 2 | 0.200 |
| τ3 | CAN communication and diagnostics | 50 | 50 | 10 | 0.200 |
Total processor utilization is U = 0.25 + 0.20 + 0.20 = 0.65. Under fixed-priority preemptive scheduling with Rate Monotonic priorities (shorter period, higher priority), the Liu & Layland test guarantees schedulability whenever U ≤ n(2^(1/n) − 1), which for three tasks is about 0.780. Since 0.65 ≤ 0.780, all deadlines are met in the worst case. Here the periods are also harmonic (each divides the next), which allows Rate Monotonic to reach 100% utilization, so the margin is generous.
Now suppose a firmware update adds a logging feature to τ3, increasing its WCET to 20 ms. Utilization rises to 0.85, above the 0.780 bound. The basic Liu & Layland test can no longer prove schedulability; you need either the harmonic-period result or an exact method such as response-time analysis, which gives a worst-case response time of 37.5 ms for τ3, comfortably inside its 50 ms deadline. You can try exactly this scenario in our interactive schedulability calculator, which plots the resulting schedule as a Gantt chart.
Predictability: the real goal
Because guarantees rest on worst-case bounds, everything that makes timing variable is an enemy of real-time design. Key sources of unpredictability include:
- Hardware features optimized for the average case: caches, branch predictors, out-of-order pipelines, DRAM refresh and, on multicore chips, contention for shared caches, buses and memory controllers.
- Operating system behavior: non-preemptible kernel sections, unbounded interrupt handlers, dynamic memory allocation and demand paging.
- Shared resources: a high-priority task waiting for a lock held by a low-priority one can suffer unbounded priority inversion unless a protocol such as priority inheritance or the priority ceiling protocol is used.
- Software structure: unbounded loops, recursion and data-dependent algorithms make WCET hard or impossible to bound.
Testing is not a guarantee. Running a system for thousands of hours and observing no deadline misses shows that misses are rare under the tested conditions. It does not prove that the worst-case combination of input data, cache state and task phasing has ever occurred. For hard deadlines, measurements must be complemented by analysis.
How real-time embedded systems are built
Delivering timing guarantees requires three ingredients working together.
1. A predictable execution platform
At the bottom sits hardware with analyzable timing, and above it either bare-metal code or a real-time operating system (RTOS). An RTOS provides deterministic context-switch and interrupt latencies, priority-based preemptive scheduling, and synchronization primitives with bounded blocking. Popular choices range from small kernels such as FreeRTOS and Zephyr to POSIX-oriented systems like RTEMS and NuttX, and Linux with the PREEMPT_RT patch set for richer platforms. Our guide to choosing an RTOS in 2026 compares them in detail.
2. A scheduling policy
The scheduler decides which ready job runs. The two most studied uniprocessor policies are fixed-priority scheduling (with Rate Monotonic or Deadline Monotonic priorities) and Earliest Deadline First (EDF). Fixed priorities dominate industry because they are simple and supported by virtually every RTOS; EDF is optimal on a uniprocessor and underpins reservation-based schedulers.
3. A schedulability analysis
Finally, the designer must prove that every task meets its deadline. Utilization tests give quick sufficient answers; response-time analysis and processor-demand analysis give exact answers for fixed priorities and EDF respectively. All depend on correct WCET values and on accounting for overheads.
When systems grow to include many independently developed components, analyzing everything together becomes impractical. This is where resource reservations and contracts help: each component is given a guaranteed budget, analyzed in isolation, and integrated without re-verifying the whole system. Exploring that idea for embedded platforms was the core aim of the EU-funded FRESCOR research project (2006–2009), whose results are preserved in the project archive.
Common pitfalls and a short design checklist
Teams new to real-time development tend to stumble over the same issues. Before committing to an architecture, check the following:
- Write down every timing requirement with its period, deadline, jitter tolerance and criticality.
- Budget utilization early and leave headroom for growth and overheads.
- Keep interrupt handlers short and defer work to analyzed tasks.
- Avoid unbounded constructs in time-critical code: dynamic allocation, unbounded loops, blocking I/O.
- Use priority inheritance or ceiling protocols for mutexes shared across priorities.
- Measure and analyze: trace on target hardware and combine measurements with static or hybrid WCET methods.
- Re-verify after every change to execution times, priorities or periods.
If you would rather have an independent review of an existing design, our real-time schedulability audit follows essentially this checklist and documents the evidence.
Frequently asked questions
Is a real-time system the same as a fast system?
No. Real-time means that timing behavior is predictable and bounded. A slower processor with guaranteed worst-case response times can be far more suitable for a hard real-time application than a faster one with unpredictable latency spikes.
What is the difference between a firm and a soft deadline?
With a firm deadline, a late result has no value and is discarded, although occasional misses are tolerated. With a soft deadline, a late result still has some value that decreases as it gets later. Both differ from hard deadlines, where any miss counts as a failure.
Do I always need an RTOS for a real-time embedded system?
Not always. Simple systems can meet their deadlines with a bare-metal super-loop or a cyclic executive. An RTOS becomes valuable when you have several concurrent activities with different rates and priorities, need preemption, or want standardized synchronization and communication primitives.
Can Linux be used for real-time applications?
Yes, within limits. Since the PREEMPT_RT work was merged into the mainline kernel in version 6.12, a configured Linux system can achieve low and fairly bounded latencies, and SCHED_DEADLINE offers EDF-based reservations. However, formally certifying hard real-time guarantees on Linux remains difficult, so safety-critical functions often run on a dedicated RTOS or a separate core.
How do I know whether my task set will meet its deadlines?
Start with the utilization tests for your scheduling policy, then apply an exact test such as response-time analysis for fixed priorities or processor-demand analysis for EDF. These tests need accurate WCET values and should include system overheads.
References and further reading
- Real-time computing — Wikipedia
- Embedded system — Wikipedia
- Liu, C. L. and Layland, J. W. (1973). “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment.” Journal of the ACM, 20(1).
- Kopetz, H. (2011). Real-Time Systems: Design Principles for Distributed Embedded Applications, 2nd ed. — Springer
- Buttazzo, G. C. (2011). Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications, 3rd ed. — Springer
- Burns, A. and Wellings, A. (2009). Real-Time Systems and Programming Languages, 4th ed. — Addison-Wesley
- Real-time operating system — Wikipedia
- FRESCOR project record — CORDIS, European Commission
