Real-time systems are conventionally divided into hard and soft, according to what happens when a deadline is missed. In a hard real-time system, missing a deadline is a system failure: the result delivered late is no longer correct, and the consequences can be catastrophic. An airbag controller that fires too late, a flight-control loop that misses its update, or a pacemaker that delays a pulse has failed in the only sense that matters, regardless of how good its output would have been on time. In a soft real-time system, a missed deadline degrades quality but does not constitute failure: a dropped video frame, a glitch in audio playback, or a laggy user-interface update is undesirable but tolerable, and the system continues to function.
The “hard” terminology comes directly from the founding literature. C. L. Liu and James W. Layland’s 1973 paper is titled “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment,” and it defines that environment as one in which tasks must be completed within rigid deadlines that cannot be missed. The entire mathematical apparatus of the paper — proving in advance that a set of periodic tasks can always be scheduled to meet their deadlines — exists because in a hard environment “usually meets the deadline” is not good enough.
The practical difference is one of proof obligation. A soft real-time system can be engineered for good average and typical behavior, with occasional lateness absorbed by buffering or graceful degradation. A hard real-time system must be analyzed so that the worst case, not the average case, is shown to meet every deadline. This is why hard real-time engineering leans on worst-case execution-time analysis and on schedulers with provable timing properties.
Real-time operating systems are built to support the hard case. The FreeRTOS scheduler, for example, assigns tasks strict priorities and guarantees that “the highest priority task that is able to execute is given processing time,” so that the most time-critical work is never starved by less urgent work. That priority guarantee is what lets a designer reason about whether the most important deadline can always be met.
The boundary between hard and soft is set by consequences, not by the size of the deadline. A deadline of one second can be hard if missing it crashes an aircraft, and a deadline of one millisecond can be soft if missing it only drops a frame. Classifying each deadline correctly is the first design decision in any embedded system, because it determines how much of the system must be proven rather than merely measured.