A REAL-TIME SYSTEM is a software system where the correct functioning of the system depends on the RESULTS PRODUCED BY THE SYSTEM AND THE TIME AT WHICH THESE RESULTS ARE PRODUCED. A SOFT REAL-TIME SYSTEM is a system whose operation is DEGRADED if results are not produced according to the specified timing requirements. → a late result is worth less, but the system continues. Video streaming, telemetry collection, a user interface. A HARD REAL-TIME SYSTEM is a system whose operation is INCORRECT if results are not produced according to the timing specification. → a late result is a FAILURE, of the same kind as a wrong result. Braking control, flight control, a pacemaker. (a FIRM real-time system is sometimes distinguished: a late result is useless but not harmful — a missed frame is simply dropped.) THE POINT THAT IS EASY TO MISS: "real-time" does not mean "fast". It means PREDICTABLE. A system that usually responds in 1 ms but occasionally takes 200 ms is worse, for real-time purposes, than one that always takes 20 ms. Average performance is nearly irrelevant; the WORST CASE is the specification. This is why real-time systems avoid garbage collection, dynamic memory allocation, and unbounded loops — not because they are slow, but because their worst case is hard to bound. STIMULUS / RESPONSE SYSTEMS — the standard way to think about real-time design. A real-time system can be considered as a system that responds to external events. To design it, you identify the stimuli and the associated responses. TWO CLASSES OF STIMULI: PERIODIC STIMULI occur at predictable time intervals. Example: the system may examine a sensor every 50 ms and take action depending on the value. APERIODIC STIMULI occur irregularly, and are usually signalled using the computer's INTERRUPT mechanism. Example: an operator pressing an emergency stop. A real-time system is therefore usually a set of concurrent cooperating processes, and the architecture must handle both kinds of stimulus.

A REAL-TIME SYSTEM DESIGN PROCESS — the standard steps: 1. IDENTIFY THE STIMULI to be processed and the required responses to these stimuli. 2. For each stimulus and response, IDENTIFY THE TIMING CONSTRAINTS. 3. AGGREGATE the stimulus and response processing into a number of CONCURRENT PROCESSES. A process may be associated with each class of stimulus and response. 4. For each stimulus and response, DESIGN ALGORITHMS to carry out the required computations. These must be designed before decisions on process timing, because the algorithm's execution time determines whether the deadline is feasible. 5. DESIGN A SCHEDULING SYSTEM which ensures that processes are started in time to meet their deadlines. 6. INTEGRATE the system under the control of a REAL-TIME EXECUTIVE. THE SENSOR/ACTUATOR PROCESS ARCHITECTURE — the canonical structure: ┌──────────┐ ┌───────────┐ ┌────────────┐ │ sensor │──▶│ data │──▶│ actuator │ │ process │ │ processor │ │ control │ └────┬─────┘ └─────┬─────┘ └─────┬──────┘ │ │ │ SENSOR (compute) ACTUATOR · sensors are POLLED periodically or generate interrupts · the data processor carries out the computation and decides on the response · the actuator control process converts the decision into a signal for the physical device THE REAL-TIME EXECUTIVE — a specialised operating system that manages processes and resource allocation in a real-time system. It starts and stops processes, and schedules process execution. Its components: REAL-TIME CLOCK provides information to schedule processes periodically INTERRUPT HANDLER manages aperiodic requests for service SCHEDULER examines the processes that can be executed and chooses one RESOURCE MANAGER allocates memory and processor resources to a scheduled process DISPATCHER starts the execution of a process CONFIGURATION MANAGER (in systems that must keep running) supports dynamic reconfiguration FAULT MANAGER detects and manages faults without stopping the system PROCESS PRIORITY LEVELS — two are normally distinguished: INTERRUPT LEVEL the highest priority, allocated to processes needing a very fast response. One of these is the real-time clock process. CLOCK LEVEL allocated to periodic processes.

THIS IS THE MATHEMATICAL CORE OF REAL-TIME DESIGN: given a set of periodic tasks, CAN the deadlines be met at all? A periodic task i is described by: C_i worst-case execution time (WCET) T_i period (also the deadline, in the simple model) U_i = C_i / T_i its utilisation — the fraction of the processor it needs TOTAL UTILISATION: U = Σ (C_i / T_i) IF U > 1 the task set is INFEASIBLE on one processor, full stop — you are asking for more work than time exists. No scheduler helps. RATE MONOTONIC SCHEDULING (RMS) — fixed priorities, shortest period gets highest priority. The classic Liu & Layland sufficient condition: U ≤ n (2^(1/n) − 1) n = 1 1.000 n = 2 0.828 n = 3 0.780 n = 4 0.757 n = 5 0.743 n = 10 0.718 n → ∞ ln 2 ≈ 0.693 So with many tasks under fixed-priority scheduling, you can only safely count on about 69% of the processor. The rest is the price of guaranteed schedulability. EARLIEST DEADLINE FIRST (EDF) — dynamic priorities; whichever task's deadline is nearest runs next. Its condition is simply: U ≤ 1 EDF can use the whole processor. Its cost: priorities change at run time, so behaviour under overload is harder to predict (a missed deadline can cascade), and it is more complex to implement. WORKED — three tasks in a licence-plate reader controller: task C_i (ms) T_i (ms) U_i ──────────────────────────────────────────── read camera 12 50 0.240 detect plate 28 100 0.280 log + display 8 40 0.200 ──────────────────────────────────────────── U total = 0.720 UNDER EDF: U = 0.720 ≤ 1 → SCHEDULABLE ✓ UNDER RMS: bound for n = 3 is 0.780 0.720 ≤ 0.780 → SCHEDULABLE ✓ NOW SUPPOSE plate detection is improved and takes 34 ms: U = 0.240 + 0.340 + 0.200 = 0.780 EDF: 0.780 ≤ 1 → still schedulable ✓ RMS: 0.780 ≤ 0.780 → exactly at the bound, so the sufficient condition just holds — but with no margin at all ⚠ AND AT 40 ms detection: U = 0.240 + 0.400 + 0.200 = 0.840 EDF: 0.840 ≤ 1 → schedulable ✓ RMS: 0.840 > 0.780 → the RMS test FAILS. Note carefully: the Liu & Layland bound is SUFFICIENT, not necessary — failing it does not prove the set is unschedulable, but you can no longer guarantee it without a full response-time analysis. THE DESIGN LESSON: a 12-millisecond increase in computation that pushed C from 28 to 40 ms changed the system from provably safe to unprovable. In real-time work, MAKING CODE DO MORE IS A SCHEDULABILITY DECISION, and it must be re-analysed, not merely benchmarked. WHY WCET IS THE HARD PART: every number in that table is a WORST case, and worst cases are genuinely difficult to establish on modern hardware. Caches, branch prediction, pipelines, DRAM refresh and speculative execution all make execution time data-dependent and history-dependent. This is why hard real-time systems often use simpler processors deliberately, disable caches, or use static analysis tools to bound WCET rather than measuring it — a measured maximum is not a proven bound. PRIORITY INVERSION — the classic real-time failure, worth knowing by name: a HIGH-priority task waits on a lock held by a LOW-priority task, which is itself preempted by a MEDIUM-priority task. The high-priority task is now effectively blocked by the medium one, inverting the priorities. The famous case is the Mars Pathfinder rover in 1997, which repeatedly reset on the surface of Mars for exactly this reason. The fix is PRIORITY INHERITANCE: the lock holder temporarily inherits the priority of the highest-priority task waiting on it.