In engineering, a fast response is meaningless if it cannot be guaranteed. A system that responds reliably in 50 ms is more deterministic than one that responds in 5 ms only some of the time. The distinction may seem unnecessary until a missed deadline means a robotic arm strikes a worker, or a safety valve fails to close fast enough.
Determinism Is the Actual Requirement
Real-time processing is formally defined as a system’s ability to respond to an input within a bounded, predictable time window regardless of system load, thermal conditions, or concurrent activity. The bound is called the deadline, and whether missing that deadline is acceptable determines the class of real-time system involved.
Hard real-time
Zero tolerance for deadline violations. A missed deadline constitutes a system failure. Examples include flight control systems, airbag deployment, anti-lock braking systems, and surgical robotics. Being 1 ms late is the same as not responding at all.
Soft real-time
Tolerates occasional deadline misses with graceful degradation rather than catastrophic failure. A video codec that drops a frame produces a visible artifact; it does not crash the aircraft. Examples include audio processing, industrial HMI systems, and networked telemetry.
Firm real-time
Late results are useless but not dangerous. Examples include automated trading systems and certain sensor fusion pipelines.
These classifications directly affect engineering decisions. A hard real-time requirement typically eliminates standard Linux as the primary runtime. A soft real-time requirement does not.
Why Standard Operating Systems Fail the Hard Real-Time Test
Linux, Windows, and most general-purpose operating systems are designed to be fair schedulers. They continuously balance resources across processes, handle interrupts, manage memory, and optimize responsiveness on average. The word “average” is a problem.
Under a standard Linux kernel, interrupt latency can vary from a few microseconds to several milliseconds depending on what else the system is doing. For a soft real-time application, this variance is acceptable. For a hard real-time application, such as controlling a power converter output stage at a 100 kHz switching frequency, a 2 ms jitter spike is a hardware fault waiting to happen.
A real-time operating system (RTOS), such as FreeRTOS, Zephyr, or VxWorks, uses a preemptive, priority-based scheduler with deterministic interrupt handling. The worst-case interrupt latency is bounded and measurable. Higher-priority tasks preempt lower-priority tasks immediately, not when the scheduler gets around to it.
Below the RTOS: DSP and FPGA
The RTOS is not where real-time processing started. Before general-purpose processors were fast enough to be trusted with bounded response times, determinism was achieved by dedicating silicon to the task.
Digital signal processors, such as TI’s TMS320 family and Analog Devices’ SHARC and Blackfin processors, were built around a single-cycle multiply-accumulate unit, Harvard memory architecture, zero-overhead loops, and circular addressing for filter delay lines. The practical consequence matters more than the feature list: a DSP filter kernel running bare-metal, with no operating system and no scheduler, executes a fixed number of clock cycles every time. Worst-case execution time is not measured statistically over a long test run; it is calculated from the instruction listing before the board is ever powered.
A field-programmable gate array (FPGA) takes the same idea one step further by removing the instruction stream altogether. There is no scheduler to preempt, no interrupt controller to arbitrate, and no shared bus to contend for. Instead, the algorithm exists as parallel logic, and its timing is a function of clock frequency and propagation delay, verified by static timing analysis during synthesis. Jitter is expressed in clock cycles rather than microseconds. This is what makes an FPGA the only practical option for sample-rate processing at tens or hundreds of megahertz, protocol timing with nanosecond tolerances, or hundreds of channels that must be handled genuinely simultaneously rather than time-sliced.
Seen together, these four options form a scale that trades flexibility for determinism: a GPOS offers the most flexibility and only statistical timing guarantees; an RTOS bounds worst-case latency to microseconds while keeping a familiar software model; a bare-metal DSP delivers cycle-accurate execution at the cost of a much narrower development environment; and an FPGA provides determinism by construction, at the highest engineering effort per function.
Modern designs rarely pick just one. Heterogeneous SoCs place all of them on a single die, which is precisely why the Zynq platform suits the TETRA base station: the programmable logic handles the fastest signal path, one ARM core runs an RTOS for time-critical control, and the second runs Linux for management and connectivity. The decision is not which technology is best, but which deadline belongs at which level.
What Edge Processing Unlocks for Real-Time Systems
Moving processing closer to the sensor eliminates the largest and least predictable source of latency in most IoT architectures: the network.
Cloud round-trip latency (typically 50–200 ms) is not just slow for real-time purposes; it is non-deterministic. A congested network can push that latency into the range of seconds.
Edge processing restores determinism by removing the network from the control loop entirely. Two specific capabilities become available:
Closed-loop feedback at microsecond scale
A sensor can trigger an actuator without any data leaving the local hardware. In motor control, the current measurement, PID calculation, and PWM output adjustment can complete in under 10 µs on a properly configured RTOS — performance that cloud-mediated control cannot match by several orders of magnitude.
Safe operation during connectivity loss
Critical systems can maintain a safe state even when external connectivity is lost. A pressure relief valve that triggers based on local edge logic does not depend on the cloud being reachable. In safety-critical certification (IEC 61508, ISO 26262), this is often a formal requirement: the safety function cannot depend on external communication.
Summary
Real-time data processing is ultimately about guaranteed behavior, not raw speed. Whether that guarantee comes from an RTOS, a bare-metal DSP, or an FPGA follows from the deadline itself, not from a preference for one technology over another. For industrial and safety-critical applications, matching the right level of determinism with edge-local processing is what makes deterministic behavior achievable and certifiable.
