Part 7 of 7 in our Edge to Enterprise in practice series, and the last. In Sense, Decide, Act we described CATIM Nimbus's outbound connection to an industrial cloud platform; this post is about the detail that decides whether its history can be trusted: time.
When the cloud and the plant disagree
Compare a cloud trend with the plant's own records and the two often disagree in a familiar way. Values arrive in bunches. A step change appears late. After a network outage, a stretch of data lands all at once, stamped with the time it finally arrived. Any analysis built on that history - cycle times, correlations, the model meant to predict a failure - inherits the error.
The cause is usually simple: values are dated by when they were sent, not when they happened. Sending in batches, waiting out a link loss and retrying all move the send time. None of them should move the history.
Each value carries the time it changed
In CATIM Nimbus the time travels with the value from the start. When a Tributary flow publishes a value that has changed, the controller marks the moment of the change. That time stays with the value on the Unified Namespace and all the way to the cloud, where each value is stored with the time it changed in the controller, not the time of the request that carried it.
A batch that carries several values lands as several points in history, each at its own time. On a simulated machine, not a customer plant, we checked it where it counts, in the cloud platform's own stored history: each value sat at its own moment, apart from the others in its batch. Whatever the link did in between, the trend lines up with the plant.
Held until the clock is right
A timestamp is only as good as the clock behind it. After a power cut, an edge unit can start before its clock has been set from the network, and a value sent with the wrong time is worse than a late one: it lands in the wrong place in a history that is hard to correct.
So the connection waits. Each value is timed against the controller's own steady clock and given its calendar time only once the clock is confirmed synchronised. Until then values wait on the unit, and the encrypted connection, which needs a correct clock too, is never bypassed to get them out sooner.
Through a link loss, without wearing the unit
When the link to the cloud drops, values wait in the controller's memory, never on its storage, so an outage costs the unit no wear. When the link returns, they go up with their own times. The waiting room has a fixed size: if an outage outlasts it, the oldest values go first and the gap is reported, not hidden.
The site chooses what a long outage sends when the link returns: by default the latest value of each point, so the account is not spent on a backlog in one burst, or every value that waited.
Only what changed, inside the account's limits
Industrial cloud accounts are priced and limited by use. The connection is designed to stay well inside them:
- Only changes. A steady value is not resent, apart from an occasional heartbeat that shows it is alive.
- A deadband and an interval per point. A value that wanders goes up only when it has really moved, and no faster than the engineer allows.
- A cap on requests. At the cap, the connection waits rather than overspends.
- No retry storms. A value the cloud does not recognise is set aside at once, not retried over and over.
- Only real readings. A value that is not a reading is not sent.
The controller's own health travels too: the cloud sees whether it is running, stood down, unreachable or restarted, as an alarm state it can act on. And the connection is made from the plant outwards: nothing on the internet calls in.
What it means for you
- For executives: a cloud history you can use as evidence, and a cloud bill without surprises.
- For project managers: an outage or a slow link stops being a data-cleaning task after the fact.
- For engineers: every point in history carries the time it changed in the controller, and deadbands and intervals are set per point.
Bring us your history problem
If your cloud trends never quite match the plant, we would like to hear about it. 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.