What “Real Time” Means When Three People Say It
The phrase survives in specifications because everyone believes they understand it. Three people around a table can mean three different things by it, and the system gets built to the vaguest one.
In a requirements workshop the control engineer, the IT architect and the plant manager all agree the system must be real time. The meeting moves on. Nobody has noticed that one of them means a guaranteed 10 millisecond loop, one means sub-second page refresh, and one means "I don't want to wait until tomorrow's report."
That gap is expensive, and it usually surfaces at the worst moment, during acceptance testing, when the only thing left to do about it is argue.
The control engineer's version is the strict one and it has a precise meaning: the system must respond within a bounded time, every time, and a late answer is a wrong answer. What matters is not the average — it's the worst case. A loop that completes in 2 milliseconds on a good day and 40 on a bad one is not a 2 millisecond system. Determinism is the requirement, and it is the reason this layer runs on a PLC or a motion controller rather than on general-purpose computing, and the reason people get uneasy when you propose putting a network or a virtual machine in the middle of it.
The IT architect's version is about human perception. An operator clicking something expects the screen to respond fast enough that it feels connected to their action — a few hundred milliseconds is the usual threshold, and a second is noticeably slow. An occasional slow page is irritating rather than dangerous. That is a completely different engineering problem with completely different acceptable failure modes.
The plant manager's version is about decision cadence. A shift supervisor who currently learns about yesterday's losses at ten this morning would consider a fifteen-minute-old number transformative. Against that baseline, "real time" means fresh enough to act on within the rhythm of the shift. Minutes are fine. Hours are not.
The fix is to stop using the phrase in documents. Replace it with three numbers per data path: how old the data may be when it is used, how long the path may take end to end, and how often the path is allowed to miss that target. "Alarm from field device to operator screen: 1 second at the 99th percentile, 3 second hard maximum" is a specification you can build to, test, and argue about with evidence. "Real time" is not.
Once the numbers are on paper the architecture usually writes itself, because the layers separate naturally. Deterministic control stays local and close to the machine, on hardware built for it. Supervisory data moves on a normal network with a monitoring tool watching for latency. Analytics and reporting run on whatever cadence the business actually needs, and the fact that they lag by minutes stops being a defect.
There's also a cost argument hiding in this, and it is the one that usually ends the discussion productively. Every order of magnitude of latency reduction costs real money — in hardware, in network design, in testing, in the engineering hours spent proving it. Asking which decisions actually change if the number arrives in one second instead of thirty is a fair question, and the honest answer is often "none of them." Knowing that before the architecture is fixed is worth more than any amount of agreement in a workshop.