Question 3 of 6: RTOS Features, General-Purpose OS Suitability, RTOS Products & Core Terminology

Question 3: RTOS Features, General-Purpose OS Suitability, RTOS Products & Core Terminology (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. An RTOS must guarantee timing correctness, not merely eventual correctness, which drives a distinct feature set from a general-purpose OS: deterministic, bounded response time (interrupt latency, context-switch time and system-call overhead are known worst-case bounds, not just typical averages); priority-based preemptive scheduling with a rich priority space so timing-critical tasks always run ahead of less-urgent ones; priority inheritance/priority-ceiling protocols to bound priority inversion when tasks share mutexes; predictable, low-jitter interrupt handling, typically via a two-level ISR/deferred-procedure-call structure; fast, deterministic inter-task communication and synchronisation (semaphores, message queues, event flags) with bounded execution time; fine-grained, high-resolution timers/clocks for scheduling periodic tasks and enforcing deadlines; a small, auditable kernel footprint (a minimal trusted computing base is both a performance requirement and, for safety-critical use, a certification requirement, e.g. DO-178C, IEC 61508); and deterministic memory management — no unbounded-latency paging or garbage collection on the critical path.

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 across a mixed, unpredictable workload, not to guarantee worst-case timing for any one task. Concretely: their schedulers use complex, dynamically-adjusted, throughput-oriented heuristics (multilevel feedback queues, foreground-priority boosting) whose worst-case latency is essentially unbounded and workload-dependent; virtual-memory subsystems can page a process to disk, introducing millisecond-scale unpredictable latency spikes; device drivers and interrupt handling are not engineered for bounded worst-case service time; and background services (indexing, updates, antivirus, garbage-collected runtimes) can consume the CPU for unbounded periods. A stock desktop OS can be usually fast, but "usually" is not a guarantee — and a real-time system that occasionally misses even one hard deadline has failed by definition, so neither OS in its standard form is suitable (real-time variants/co-kernels, e.g. RTX-for-Windows or a real-time kernel run alongside the general-purpose OS, exist precisely because the stock kernels are not).

Part (3) — four commercially available RTOSes. (a) VxWorks (Wind River) — aerospace, defense, networking, industrial control (flown 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 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. (FreeRTOS, ThreadX/Azure RTOS and LynxOS are also valid answers.)

Part (4) — Interrupt. A hardware- or software-generated signal that asynchronously suspends the CPU's current instruction stream and transfers control to a fixed or vectored interrupt-service routine (ISR), independent of what the currently executing task is doing. Interrupts are the mechanism by which a real-time system becomes aware of an external event (sensor trip, timer expiry, I/O completion) without having to continuously poll for it.

Part (5) — Interrupt latency. The elapsed time from the moment an interrupt is asserted by the hardware to the moment the corresponding ISR (or the task it releases) actually begins executing useful work. It is the sum of any interrupt-disabled critical sections in progress at the moment of assertion, the hardware's own interrupt-recognition/vectoring delay, and the context-save overhead before the ISR body runs; a real-time system's schedulability analysis must add this latency on top of a task's nominal computation time, exactly as done for Task 2's preemption of Task 1 in Question 5 below.

Part (6) — Rate Monotonic (RM) scheduling. A fixed-priority policy for periodic tasks in which priority is assigned inversely to period — the shortest-period task gets the highest fixed priority, permanently. RM is the optimal fixed-priority assignment when each task's deadline equals its period: no other static assignment can schedule a task set RM cannot. Liu & Layland's classical sufficient utilisation bound for n tasks is Σ(C_i/T_i) ≤ n(2^{1/n}-1) → ln2 ≈ 0.693 as n→∞.

Part (7) — Earliest Deadline First (EDF) scheduling. A dynamic-priority policy: at every instant, run the ready task whose absolute deadline is soonest, preempting whenever a task with an earlier deadline becomes ready. EDF is provably optimal among all uniprocessor scheduling algorithms — if any algorithm can meet all deadlines for a task set, EDF can too — and its exact schedulability test allows up to 100% CPU utilisation for periodic tasks with deadline = period, well beyond RM's conservative bound. Questions 4 and 5 below both exercise this algorithm directly.

Part (8) — Embedded system. A special-purpose computer system, combining hardware and software, that is built into a larger device to perform one or a small number of dedicated functions — as opposed to a general-purpose computer that runs arbitrary user-selected applications. Embedded systems are frequently (though not always) real-time, resource-constrained (limited memory, power, cost), and designed for a fixed, known workload rather than an open-ended one; the level-crossing controller of Question 1 and the object-detection/braking system of Question 6 are both examples of safety-critical embedded real-time systems.