Real time is a deadline, not a speed
A system is real-time if it is guaranteed to respond within a stated deadline. It is not real-time because a dashboard updates without a page refresh, which is what the phrase is usually used to mean.
The useful version of the question is: what is the deadline for this hazard? A gas release in a small enclosed room can go from nothing to a dangerous concentration in tens of seconds. A bearing failing has a runway of weeks. Instrumenting both at the same rate means either wasting most of your budget or missing most of the fast one.
So the honest specification is per-hazard: a sampling interval, a decision latency, and a statement of what happens when either is missed.
Sample fast enough for the thing you are watching
A reading every five minutes cannot describe an event that takes ninety seconds. It can tell you the event happened, afterwards, which is a different product.
This is also why a single fixed rate is the wrong design. Sampling every channel continuously at the rate the fastest hazard demands is expensive in power and in data, and almost all of that expense buys readings of a room where nothing is happening.
The alternative is a state machine. Sample at a slow baseline rate; when any channel starts moving faster than its own noise floor, escalate that node into a fast burst mode for as long as the movement lasts. The fast rate is then paid for only during the minutes it is worth having.
The decision has to survive the network
This is the point where most connected monitoring quietly fails. If readings travel to a server and the server decides whether to alarm, then the alarm has a dependency on the network - and industrial networks drop, congest and get reconfigured by people who were not told what depended on them.
A monitoring system whose alarm stops working during an outage is not a real-time system with an availability caveat. It is a system that is unavailable exactly when a site is least likely to notice.
The structural fix is to put the decision on the device. The node holds its own thresholds and its own signature layer, and sounds its local alarm without asking anything. Connectivity then carries history, cross-node correlation, prediction and notification - all genuinely valuable, none of it load-bearing for the alarm itself.
What the connected half is actually for
Having said what the network must not be responsible for, it is worth being clear about what it earns.
- History. A baseline is a comparison against months of that same sensor in that same room, and only the connected half can hold months.
- Correlation. Two nodes rising together is a different event from one node rising alone, and neither node can see that by itself.
- Prediction. Where a release is heading, and which named assets it reaches first, is computed against a plant model the node does not carry.
- Notification. The alarm on the wall wakes the room. Reaching the person who is not in the room needs the network.
- Forensics. What the readings were doing in the twenty minutes before, kept in a form nobody can revise afterwards.
