Part 2 of 7 in our Edge to Enterprise in practice series. In i3X vs MQTT we told how a PLC went down mid-demo and every client saw its values turn Bad instead of freezing; here is what it takes to keep that promise at every step, from the device to the cloud.
A zero that looks like calm
A pump's flow reads 0.0. Has the pump stopped, or has the meter stopped answering? On a trend the two look identical: a flat line. An operator who reads it as calm may wait. A report averages it in. An AI model trained on normal running may decide the process has settled.
The zero is silent because most data paths carry only the number. When a device stops answering, something still fills the slot, and the easiest thing to fill it with is the last value, or an empty one shown as zero.
CATIM Nimbus follows one rule instead: a number never travels alone. Every value carries whether it can be trusted and the time it was true, from the moment it is read to the moment it reaches the cloud.
At the source: never read means invalid
In Tributary, the data-flow engine of CATIM Nimbus, every analogue value in a flow carries a flag that says whether it is a real reading.
- A value that has never been read is invalid, never 0.0. The flow log writes "invalid", the operator panel shows "invalid", and the published value says so.
- A dropout counts as never read. After a device reconnects, its values stay invalid until it answers again. A reconnect alone never turns an empty slot back into a trusted zero.
- Validity travels through the flow by itself. A scaled, filtered or compared value is invalid while an input it depends on is. Nothing has to be wired for it, so existing flows get it as they are.
- When in doubt, it says so. The rules are conservative by design: an analogue value worked out from an input in doubt is marked as untrusted, never presented as good.
On the namespace: four honest words
On the Unified Namespace and through the i3X API, every value arrives as a value, a quality and a timestamp. The quality is one of four words, the same for every consumer:
- Good - a real, current reading.
- GoodNoData - the value exists but has nothing to report, such as a published slot the running job does not use. No value is shown rather than a made-up one.
- Uncertain - the value is older than its publisher promised. A value whose publisher has gone quiet ages to Uncertain, so a reader never keeps trusting a stale Good.
- Bad - not a reading. The value is withheld.
That third word solves a problem most data paths cannot. A steady value from a live publisher is refreshed on a steady beat and stays Good. A value whose publisher has died stops being refreshed and ages. A steady line and a dead source no longer look the same.
When the controller itself stops
The hardest case is when the source of truth goes away entirely. If the control application stops, or its connection to the data layer is lost, every value it publishes turns Bad for every client, then Good again when it returns, with nobody touching a dashboard. If a service on the unit stops without warning, MQTT's last-will message marks it Bad on its behalf.
That is the behaviour of the demonstration in our i3X vs MQTT post, carried through every path on the unit: the namespace, the i3X API, the historian that records each value with its quality, and the cloud.
At the cloud: only real readings leave
The connection to an industrial cloud platform follows the same rule. A value that is not a real reading is not sent: no value and no heartbeat until it is a reading again. The cloud's history therefore shows a gap where the plant had a gap, not a flat line that never happened.
A gap is honest, and every analysis tool knows how to handle one. A fabricated zero is not, and once it sits in a cloud history it is very hard to find and take out.
What it means for you
- For executives: decisions and AI models built on plant data inherit its honesty. Bad data that says it is bad is a manageable problem; bad data that looks good is an expensive one.
- For project managers: fewer "the dashboard was wrong" investigations at commissioning, because a dead device shows as dead from day one.
- For engineers: you can tell a stopped device from a steady process without watching the trend, and anything a flow computes from a dead input is marked invalid too.
The question to ask at every hop
At your data architecture review, ask one question at every hop from the device to the cloud: if the device behind this value stopped answering right now, what would this screen show? If the answer is "the last number" or "zero", the zero is silent. CATIM Nimbus is built so the answer is always "it would say so". If you would like to see that on one of your machines, get in touch.
About CATIM. CATIM - Creating Automation Technology In Motion - empowers people to engineer automation solutions that solve hard technical problems. CATIM Nimbus, the CODESYS edge controller with advisory AI, is the next generation of the Nimbus platform it has built since 2019.