computer science//real-time computing

Real-time computing is the branch of computing in which a result is correct only if it is both right and on time, so that the worst-case response, not the average, decides whether a system works, and it is what lets a microcontroller fly a drone, a PLC run a press or a drive close a current loop. A correct answer that arrives late is a wrong answer. Real time does not mean fast: a PLC with a 10 ms cycle that never overruns is a real-time system, while a PC that answers in 1 ms almost always and in 80 ms once an hour is not.

Real-time computing is the branch of computing in which a result is correct only if it is both right and on time, so that the worst-case response, not the average, decides whether a system works, and it is what lets a microcontroller fly a drone, a PLC run a press or a drive close a current loop. A correct answer that arrives late is a wrong answer. Real time does not mean fast: a PLC with a 10 ms cycle that never overruns is a real-time system, while a PC that answers in 1 ms almost always and in 80 ms once an hour is not.

The reason the worst case rules comes from control. Every cycle's actual delay subtracts phase from the loop (loop delay, phase margin), so a loop that loses stability once an hour crashes once an hour. Systems are graded by what a missed deadline costs. In hard real time a miss is a failure (the attitude loop of a drone). In firm real time a late result is useless but an occasional loss is tolerated (a video frame). In soft real time a late result is worth less but still worth something (telemetry).

The vocabulary starts with the periodic task, described by four numbers: period, deadline, worst-case execution time and jitter. The WCET is the hard one to know, and jitter is the one that quietly turns timing error into measurement error.

With several tasks on one processor, real-time scheduling decides who runs, from a fixed table to priorities proven against the deadlines, and a real-time operating system supplies preemption, timers and mutexes that avoid priority inversion.

A desktop stack breaks the guarantees in ordinary ways. A Python loop with time.sleep(0.001) is not a 1 kHz loop: the OS wakes the process when it likes, and a garbage collection pause stops it when the collector decides; on loaded desktop Linux the worst case reaches tens of milliseconds. Python serves prototypes, 1 to 10 Hz supervision and training; fast loops go in C, C++ or Rust, with no memory allocation inside the loop, on an RTOS.

Blocking I/O is the classic production trap: writing to an SD card can block for tens of milliseconds, so logging goes in the lowest-priority task, through a buffer, and never in the control path.

Where the loop runs follows from its deadline: the faster its dynamics, the closer to the metal (embedded system, autopilot for a full budget). Real time is a statement about tails, the theme of tails over means.

Design with the worst case and keep slack. Measure the WCET, check schedulability, use priority inheritance, and treat a utilization near 100 % as a loop already late.