Part 1 of 7 in our Edge to Enterprise in practice series. In i3X vs MQTT we made the Unified Namespace the data hub of CATIM Nimbus and i3X its typed window; this post shows what the controller puts on that hub about itself, and why maintenance and IT care as much as process engineers do.
A dashboard you can trust starts with the unit
Most plant data projects start with process values: temperatures, pressures, counts. They are why the project exists. But the first question a maintenance planner asks of a dashboard is a different one: is what I am looking at alive? The second comes from IT: what is that unit on my network, what software is it running, and is it healthy?
On many sites those answers live in different places. Process values flow to a historian. Device health sits on a web page you visit one unit at a time. Software versions live in a spreadsheet someone updates after a site visit. Three sources, three ways to drift.
CATIM Nimbus answers all three through one channel: the Unified Namespace, with the i3X API in front of it.
The same value, wherever you read it
Every value a Tributary flow publishes goes onto the Unified Namespace under the plant's address, with its quality and the time it was true. The same value is served through the i3X API. Read it through either door at the same moment and you get the same value, with the same quality.
That matters more than it sounds. When a dashboard subscribes over MQTT and an MES reads through i3X, they are looking at one fact, not two copies that might disagree. A historian that subscribes to the namespace records each value with its quality and its own time, so an engineer looking back at a trend sees not only what the value was, but whether it was a real reading at that moment.
Every topic on the namespace is defined once, with its type and its meaning, and each has one publisher. A published value also keeps its topic when its label changes: the new name travels inside the value, so renaming a signal in a flow never quietly breaks a subscriber.
Every service, one subscription
An edge controller that does real work runs several services side by side: the control runtime, the CATIMi Advisor, the cloud connection, the message broker, the i3X server, the console. Each publishes its own status on the namespace, in the same shape: running, starting, or degraded with a plain-language reason; the data-flow engine publishes the job it runs.
Two details make that status honest. If a service stops without warning, MQTT's last-will message turns its status Bad on its behalf. And each status is refreshed on a steady beat, so one that stops arriving ages rather than lingering as Good. A silent service is never mistaken for a healthy one.
The result: one subscription shows every service on the unit, and whether each one is alive. A maintenance dashboard does not need to know how each service works or poll each one in turn. It subscribes once and sees the whole unit.
The unit's own facts, through the same API
The controller also publishes facts about itself, typed and with their quality, through the same i3X API as the process values:
- the software versions of its services, its control application and that application's libraries
- whether its clock is synchronised, and when it last started
- its temperature, memory and storage, and how much wear the storage has seen
- when its certificate ends
The unit's own status turns degraded, with the reason, when one of these needs attention: a clock that is not synchronised, a certificate close to its end, storage past its wear mark. IT can see what every unit is running without visiting it, and maintenance can plan a replacement before it becomes an outage. Each fact is chosen for what a read-only viewer may see.
One address, set once
All of this sits under one address organised by the ISA-95 hierarchy we described in 4 Surprising Truths About ISA-95: enterprise, site, area and line, then the unit and the value. The site's administrator sets that address once, on the console, in plain lower-case words, and every service on the unit takes it up without a restart.
Below the address, each unit is known by its own fixed name, never typed by hand. Because a renamed level moves every topic below it, the console warns before a level that already has a name is renamed. The best time to set the address is before the first subscriber connects.
What it means for you
- For executives: one view of every unit's health and software, without a site visit or a separate monitoring project.
- For project managers: the health dashboard is a subscription, not a project. A unit on a new line appears under the same address scheme, with the same names and meanings.
- For engineers: every value, every service and every fact about the unit arrives in the same shape, with its quality and time. You can tell a dead service from a quiet one without asking anyone.
See it on one machine
If your maintenance team still learns about a stopped edge service from a frozen dashboard, we would like to show you the alternative on one of your machines. CATIM Nimbus is now in field trials, and we are glad to talk through what your site would see. 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.