“Real-time” is one of the most misused words in connected systems. In marketing it means fast. In engineering it means something precise and much harder: the system must produce a correct result within a guaranteed time, every time, and a late answer counts as a wrong answer.
The distinction matters because architectures that deliver “usually fast” and architectures that deliver “always within 10 ms” are built differently, cost differently, and fail differently. Teams that conflate them discover the gap during commissioning.
This guide covers what real-time actually requires, where latency comes from in an IoT system, and how to combine real-time guarantees with AI — which is inherently variable.
Hard, Firm and Soft Real-Time
| Type | What a missed deadline means | Example |
|---|---|---|
| Hard | System failure, possibly dangerous | Motor control loop, safety interlock, airbag |
| Firm | The result is worthless, but nothing breaks | Rejecting a defective item before it leaves the conveyor |
| Soft | Value degrades gradually | Live dashboard, video stream, status alert |
Most IoT systems described as real-time are soft, and that is fine — the mistake is building soft infrastructure and then depending on it for a firm or hard requirement. The honest test is to ask what actually happens if a response arrives one second late. If the answer is “nothing much”, you do not need real-time engineering, and claiming you do makes the system more expensive for no benefit.
Real-time is about the worst case, not the average. A system with a 5 ms average and a 400 ms worst case is a 400 ms system.
Where the Latency Actually Comes From
End-to-end latency is the sum of stages, and the dominant one is rarely the one teams try to optimise.
- Sensing. Sampling interval plus the sensor’s own settling time. A sensor read every 100 ms cannot support a 10 ms reaction, regardless of everything downstream.
- Processing on device. Usually small and, importantly, predictable — which is what makes it suitable for hard deadlines.
- Network transmission. The large and variable term. Radio retries, congestion and gateway queuing introduce a long tail that averages conceal.
- Platform processing. Queueing, ingestion, rule evaluation. Fine on average, unbounded under load.
- Action delivery. Getting the command back to the actuator, often over the same unreliable path.
Because the network is both the largest and the least predictable term, any genuine real-time requirement forces the decision loop onto the device or an edge node. That is not an optimisation; it is the only way to bound the worst case.
Why AI and Real-Time Pull in Opposite Directions
Machine learning optimises for accuracy on average. Real-time systems require bounded behaviour in the worst case. These are different objectives, and resolving the tension is the core design problem in real-time AIoT.
The practical resolution is layering: a fast deterministic layer handles safety and immediate control, while a slower intelligent layer supervises, tunes and predicts. The model proposes; fixed rules dispose.
Designing a Real-Time AIoT System
These constraints shape the whole architecture, and they are a large part of why intelligence belongs close to the sensor — the reasoning set out in cloud vs edge vs fog computing.
Frequently Asked Questions
Conclusion
Real-time in IoT is a guarantee about the worst case, not a description of speed. Deciding honestly which parts of a system genuinely need that guarantee is the most valuable step, because real-time engineering is expensive and most requirements turn out to be soft.
Where the guarantee is real, keep the loop off the network, separate a deterministic safety layer from any learned component, bound inference time with a measured worst case, and define explicitly what happens when a deadline is missed. That combination lets AI improve a system without undermining the guarantees it depends on.