Question 3 of 6: RTOS Features, General-Purpose OS Suitability, Commercial RTOS Examples, Hard vs. Soft Real-Time, and RT vs. Non-RT Systems

Question 3: RTOS Features, General-Purpose OS Suitability, Commercial RTOS Examples, Hard vs. Soft Real-Time, and RT vs. Non-RT Systems (20%)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part (1) — desired features of an RTOS. A Real-Time Operating System must guarantee timing correctness, not just eventual correctness, which drives a distinct feature set from a general-purpose OS: (a) Deterministic, bounded response time — interrupt latency, context-switch time and system-call overhead must be known worst-case bounds, not just typical averages. (b) Priority-based preemptive scheduling with a rich, configurable priority space (often 32–256+ levels) so that timing-critical tasks always run ahead of less-urgent ones. (c) Priority inheritance / priority ceiling protocols to bound priority inversion when tasks share mutexes. (d) Predictable, minimal-jitter interrupt handling, typically via a two-level interrupt-service-routine/deferred-procedure-call structure. (e) Fast, deterministic inter-task communication and synchronisation primitives (semaphores, message queues, event flags) with bounded execution time. (f) Fine-grained, high-resolution timers and clocks for scheduling periodic tasks and enforcing deadlines. (g) Small, auditable kernel footprint — a minimal trusted computing base is both a performance requirement (less code to execute on the critical path) and, for hard real-time/safety-critical use, a certification requirement (e.g. DO-178C, IEC 61508). (h) Memory-management determinism — no unbounded-latency paging or garbage collection on the critical path; memory is typically statically allocated or uses bounded-time pool allocators.

Part (2) — why general-purpose desktop OSes are unsuitable. Microsoft Windows and Mac OS are both designed to optimise average-case throughput and interactive responsiveness for a mixed, unpredictable workload of user applications, not to guarantee worst-case timing for any single task. Concretely: their schedulers use complex, dynamically-adjusted, throughput-oriented heuristics (multilevel feedback queues, dynamic priority boosting for I/O-bound and foreground tasks) whose worst-case latency is essentially unbounded and workload-dependent, not analytically provable; virtual-memory subsystems can page a process's memory to disk, introducing latencies of milliseconds and worse at unpredictable moments; device drivers and interrupt handling are not designed for bounded worst-case latency; and background system services (indexing, updates, antivirus scans, garbage-collected runtimes) can consume the CPU for unbounded periods. A general-purpose OS can be made to usually respond quickly, but "usually" is not a guarantee, and a hard real-time system that misses even one deadline has failed by definition — so neither OS, in its standard form, is suitable for hard (or, for anything with a tight deadline, even soft) real-time control. (Real-time variants/patches exist — e.g. RTX for Windows, or real-time kernels that co-run alongside a general-purpose OS — precisely because the stock kernels are unsuitable on their own.)

Part (3) — four commercially available RTOSes. (a) VxWorks (Wind River) — widely used in aerospace, defense, networking and industrial control (flew on multiple NASA Mars rover/lander missions). (b) QNX Neutrino (BlackBerry QNX) — a microkernel RTOS widely used in automotive infotainment/ADAS, industrial and medical systems. (c) Windows CE / Windows Embedded Compact (Microsoft) — a real-time-capable embedded OS distinct from desktop Windows, used in handheld and industrial devices. (d) Integrity RTOS (Green Hills Software) — a partitioned, safety-certified (DO-178B/C) RTOS used in avionics and defense. (Other valid answers include FreeRTOS, ThreadX/Azure RTOS, and LynxOS.)

Part (4) — hard vs. soft real-time systems. A hard real-time system is one in which missing a deadline constitutes a total system failure with potentially catastrophic (safety, financial, or mission) consequences — the correctness of the result is judged jointly on its logical value and on it arriving by the deadline, with zero tolerance for lateness (e.g. an airbag deployment controller, a flight-control law, an anti-lock-brake controller). A soft real-time system is one in which an occasional missed deadline degrades the quality or utility of the system's service but does not constitute outright failure — the value of a late result decays (often gracefully) rather than dropping instantly to zero (e.g. a video-streaming decoder that occasionally drops a frame, or a stock-quote display that is a few hundred milliseconds stale). Between the two, some texts define a firm real-time system, where a late result has zero value (the deadline still matters) but is not itself catastrophic — the task is simply abandoned rather than causing a system failure.

Part (5) — fundamental differences between a real-time system and a non-real-time system. A non-real-time (general-purpose) system's correctness depends only on the logical value of its output — a batch job, a web server or a desktop application is correct if it eventually produces the right answer, and being faster is simply better, with no fixed cut-off. A real-time system's correctness depends on both the logical value of its output and the time at which it is delivered — a result that is logically perfect but late is, for a hard real-time task, as wrong as a result that is logically incorrect. This single distinction cascades into every design difference between the two classes: (a) Performance metric — a non-RT system is judged on average-case throughput and response time (transactions/second, mean latency); a real-time system is judged on worst-case, guaranteed response time, because the mean is irrelevant if even one deadline is missed. (b) Scheduling goal — a non-RT scheduler (e.g. a multilevel feedback queue) tries to be fair and maximise overall throughput; a real-time scheduler (RMS, EDF, LST) tries to guarantee that every task's deadline is met, sacrificing throughput and fairness if necessary. (c) Predictability vs. speed — a real-time system can be, and often is, slower in raw throughput than a general-purpose system, but its worst-case timing must be analytically provable; a non-RT system optimises for the common case and tolerates occasional slow outliers. (d) Resource management — real-time systems favour static/pre-allocated resources (memory pools, fixed-priority interrupt vectors) precisely because dynamic allocation and paging introduce unbounded-latency tails that a non-RT system can absorb but a real-time system cannot. (e) Validation — a non-RT system is validated primarily by functional testing; a hard real-time system additionally requires timing analysis/certification (worst-case execution time analysis, schedulability proofs) as a first-class deliverable, not an afterthought.