In this lesson, you will learn how the functional consequences of a missed deadline define whether an embedded task is classified as hard, firm, or soft real-time.
The Spectrum of Consequences
In real-time systems, the correctness of an operation depends not just on the logical result, but on the time at which that result is produced. We categorize tasks based on what happens when the processor fails to meet a timing constraint.
- Hard Real-Time: If the deadline is missed, the system is considered a total failure. This is typical in life-critical or mission-critical systems where the physical environment is at risk. For example, an airbag deployment controller must fire within a strict millisecond window; a late response is effectively the same as no response.
- Firm Real-Time: Missing a deadline renders the result useless, but it does not cause catastrophic system failure. The system simply discards the outdated data. A good example is a high-speed video frame processor; dropping a single frame is acceptable, but displaying it late is worse than not showing it at all.
- Soft Real-Time: Missing a deadline degrades performance, but the system remains functional. The value of the result diminishes over time rather than dropping to zero. Think of a user interface; if a button press takes 200ms to register instead of 50ms, the user is annoyed, but the system continues to operate safely.
Illustrative Example
Consider a simple task handler where we check a deadline against a system tick counter:
void process_task() {
uint32_t current_time = get_system_ticks();
if (current_time > DEADLINE) {
// Hard RT: System.reset() or trigger safety state
// Firm RT: discard_packet(); return;
// Soft RT: log_performance_jitter(); process_anyway();
}
}
In Hard RT, the logic implies that if current_time > DEADLINE, the system has entered an undefined, unsafe state. In Soft RT, you prioritize completing the task even if it arrives late, acknowledging that while the latency is suboptimal, the system stability is preserved.
Key Takeaway: Categorizing tasks by the impact of failure—catastrophic, useless, or degraded—is essential for determining the scheduling priority and resource allocation in your RTOS.