Real-Time Systems Explained: Hard, Soft, and Firm with Examples

In this post, we will discuss and try to understand what real-time systems are.The term “real time” is used widely in many contexts, both technical and conventional. Most people would probably understand “in real time” to mean “at once” or “instantaneously.”Consider a computer system in which data need to be processed at a regular rate. For example, an aircraft uses a sequence of accelerometer pulses to determine its position. Systems other than avionic ones may also require a rapid response to events that occur at nonregular rates, such as handling an overtemperature failure in a nuclear power plant. Even without defining the term “real-time,” it is clear that those events demand timely or “real-time” processing.Now consider a situation in which a passenger approaches an airline check-in counter to pick up his boarding pass for a certain flight from New Delhi to Mumbai, which is leaving in five minutes. The reservation clerk enters appropriate information into the computer, and a few seconds later a boarding pass is printed. Is this a real-time system?Indeed, all three systems—aircraft, nuclear power plant, and airline reservations—are real-time, because they must process information within a specified interval or risk system failure. Although these examples may provide an intuitive definition of a real-time system, it is necessary to clearly comprehend when a system is real-time and when it is not.To properly understand a Real-Time System, we need to clarify a few things first:

Definition: System

A system is a mapping of a set of inputs into a set of outputs. When the internal details of the system are not of particular interest, the mapping function between input and output spaces can be considered as a black box with one or more inputs entering and one or more outputs exiting the system (see Fig. 1.1). Moreover, Vernon lists five general properties that belong to any “system” (Vernon, 1989):

1. A system is an assembly of components connected together in an organized way.
2. A system is fundamentally altered if a component joins or leaves it.
3. It has a purpose.
4. It has a degree of permanence.
5. It has been defined as being of particular interest.

Shown below is an example:Every real-world entity, whether organic or synthetic, can be modeled as a system. In computing systems, the inputs represent digital/analog data from hardware devices or other software systems. The inputs are often associated with sensors, cameras, and other devices that provide analog inputs, which are converted to digital data, or provide direct digital inputs. The digital outputs of computer systems, on the other hand, can be converted to analog outputs to control external hardware devices, such as actuators and displays, or used directly without any conversion.

Definition: Response Time

The time between the presentation of a set of inputs to a system and the realization of the required behavior, including the availability of all associated outputs, is called the response time of the system.How fast and punctual the response time needs to be depends on the characteristics and purpose of the specific system.With these two definitions clear, let us now see Real-Time Systems.

Definition: Real-Time Systems

One definition of Real-Time Systems is:

A real-time system is a computer system that must satisfy bounded response time constraint or risk severe consequences, including failure.

Real-Time System can also be defined as:

A real-time system is one whose logical correctness is based on both the correctness of the outputs and their timeliness.

To simplify the above two definitions, a real-time system is an embedded system that generates correct output within a given timeline. It does not necessarily mean fast.Say, for example, a system has the following features:

1. A button for user interface
2. User can press the button
3. Five seconds after the user releases the button, a buzzer is sounded.

The correct output for this system is the sounding of buzzer. The time constraint is five seconds. Five seconds is a really long time. But this system classifies as a real time system because it gives the expected output within the defined time constraint.

Classifications of Real-Time Systems:

Now that we have gained an understanding of real-time systems, let’s see how they are classified.

Definition: Soft Real-Time Systems

A soft real-time system is one in which performance is degraded but not destroyed by failure to meet response-time constraints.

Conversely, systems where failure to meet response-time constraints leads to complete or catastrophic system failure are called hard real-time systems.

Definition: Hard Real-Time Systems

A hard real-time system is one in which failure to meet even a single deadline may lead to complete or catastrophic system failure.

Definition: Firm Real-Time System

A firm real-time system is one in which a few missed deadlines will not lead to total failure, but missing more than a few may lead to complete or catastrophic system failure.

System	Real-Time Classification	Explanation
Avionics weapons delivery system in which pressing a button launches an air-to-air missile	Hard	Missing the deadline to launch the missile within a specified time after pressing the button may cause the target to be missed, which will result in catastrophe
Navigation controller for an autonomous weedkiller robot	Firm	Missing a few navigation deadlines causes the robot to veer out from a planned path and damage some crops
Console hockey game	Soft	Missing even several deadlines will only degrade performance

All practical systems minimally represent soft real-time systems. There is a lot of room for interpretation of hard, firm, and soft real-time systems. For example, in the automated teller machine, missing too many deadlines will lead to significant customer dissatisfaction and potentially even enough loss of business to threaten the existence of the bank. This extreme scenario represents the fact that every system can often be characterized any way—soft, firm, or hard—real-time by the construction of a supporting scenario. The careful definition of systems requirements (and, hence, expectations) is the key to setting and meeting realistic deadline expectations. In any case, it is a principal goal of real-time systems engineering to find ways to transform hard deadlines into firm ones, and firm ones into soft ones.The following short video summarizes all the above concept:

Hard vs Soft vs Firm Real-Time: Deep Comparison

The classification of real-time systems is based on the consequences of missing a deadline, not on how fast the system responds.

Hard real-time: missing a deadline causes system failure or danger. The system is considered incorrect if even one deadline is missed. Examples:

• Airbag deployment — must inflate within 30 ms of impact detection. Late deployment is worse than no deployment.
• Anti-lock braking system (ABS) — brake pressure must be adjusted within each wheel rotation cycle.
• Cardiac pacemaker — electrical pulses must be delivered within precise timing windows.
• Industrial robot controller — joint motors must receive position commands every 1 ms.

Firm real-time: missing a deadline makes the result useless (no value), but doesn’t cause system failure. The system degrades gracefully. Examples:

• Video frame rendering — a frame that arrives after the display refresh is useless (dropped), but the system continues normally.
• Weather prediction — a forecast computed after the weather event has no value.
• Packet processing in a router — a packet processed after the routing table changes may be sent to the wrong destination.

Soft real-time: missing a deadline reduces quality but the result still has diminishing value. Examples:

• Audio/video streaming — late frames cause quality degradation but the stream continues.
• User interface responsiveness — a button press processed in 200 ms instead of 50 ms is annoying but functional.
• Temperature monitoring in HVAC — reading temperature every 1.5 seconds instead of every 1 second still works, just with slightly less accuracy.

Measuring and Guaranteeing Real-Time Performance

In real-time systems, you must measure and guarantee worst-case execution time (WCET) and worst-case response time (WCRT), not average-case performance.

Worst-Case Execution Time (WCET) is the maximum time a task takes to execute, considering all possible code paths, cache misses, and pipeline stalls. Measuring WCET:

// Measurement approach using a hardware timer (ARM DWT cycle counter)
CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->CYCCNT = 0;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;

void measure_wcet(void) { static uint32_t max_cycles = 0;

uint32_t start = DWT->CYCCNT; control_loop_iteration(); // Function being measured uint32_t elapsed = DWT->CYCCNT – start;

if (elapsed > max_cycles) { max_cycles = elapsed; printf(“New WCET: %lu cycles (%lu us at %lu MHz)n”, max_cycles, max_cycles / (SystemCoreClock / 1000000), SystemCoreClock / 1000000); } } “`

Interrupt latency is the time from when an interrupt is triggered to when its ISR begins executing. On ARM Cortex-M4, the minimum is 12 clock cycles (for zero wait-state memory). Real-world latency includes time to finish the current instruction, save context, and fetch the vector.

Jitter is the variation in response time. A system that usually responds in 50 μs but occasionally takes 500 μs has high jitter. Hard real-time systems must bound jitter — typically to within 1-5% of the period.

Real-Time Scheduling Theory Essentials

Scheduling theory provides mathematical tools to determine if a set of tasks can meet all deadlines on a given processor.

Utilization bound test (for Rate Monotonic Scheduling): a set of n periodic tasks is schedulable if the total CPU utilization U satisfies:

U = Σ(Ci/Ti) ≤ n(2^(1/n) – 1)

Where Ci is the WCET of task i and Ti is its period. For large n, the bound approaches ln(2) ≈ 0.693. This means if your tasks use less than 69.3% of the CPU, they’re guaranteed schedulable under RMS.

Example with 3 tasks:

• Task 1: period 10 ms, WCET 2 ms → U1 = 0.20
• Task 2: period 25 ms, WCET 5 ms → U2 = 0.20
• Task 3: period 50 ms, WCET 10 ms → U3 = 0.20
• Total U = 0.60

The bound for n=3 is 3(2^(1/3) – 1) ≈ 0.779. Since 0.60 < 0.779, all deadlines are guaranteed under RMS.

Priority assignment rules:

• Rate Monotonic (RM): shorter period → higher priority. Optimal for fixed-priority preemptive scheduling with independent tasks and deadlines equal to periods.
• Deadline Monotonic (DM): shorter deadline → higher priority. Used when deadlines differ from periods.
• Earliest Deadline First (EDF): dynamic priority — task with nearest deadline runs first. Can achieve 100% CPU utilization (vs ~69% for RM), but harder to implement and analyze.

Real-Time Systems in Practice: Design Patterns

Building a reliable real-time system requires specific design patterns:

Rate Group Pattern: organize tasks by execution rate. All 1 ms tasks run in one group, all 10 ms tasks in another. This makes scheduling analysis straightforward and debugging easier.

Run-to-Completion Pattern: each task completes within one period — no blocking, no waiting. If a task needs data from a slow source (sensor, network), use a separate task to acquire data and share it through a buffer. The real-time task only reads the latest buffer value.

Temporal Isolation Pattern: critical tasks have reserved CPU time that cannot be consumed by other tasks. Even if a non-critical task goes into an infinite loop, the critical task still runs on schedule. Implemented through time partitioning or watchdog-monitored execution budgets.

Graceful Degradation Pattern: when the system is overloaded, shed non-critical work while maintaining critical deadlines. For example, an automotive ECU drops logging and diagnostics before reducing control loop rates.

Common mistakes in real-time design:

• Using unbounded algorithms (dynamic memory allocation, linked list traversal, recursive parsing)
• Assuming average-case performance instead of worst-case
• Disabling interrupts for too long (increases latency for all other ISRs)
• Using priority ceiling or priority inheritance but not analyzing the impact on WCRT
• Testing only the “happy path” — worst-case behavior often occurs during error recovery

📖 Related: Dynamic Memory Allocation in C • Rate Monotonic Scheduling Explained with Examples