Developers
How an operation gets addressed and modelled before anything on it can report, and why the naming agreed in that work outlives every module built on top of it.
An asset in the Singularity is reached by its position in a hierarchy, and that position is an address. A module asking for the state of a machine asks for it at a path. The path resolves to exactly one asset, or it resolves to nothing.
This is the first work an implementation does and the last work anyone wants to redo. Nothing reports until the operation has been described this way, and every module that arrives afterward reads the description agreed here. A module does not know what a machine is. It knows that a path exists, that a tag underneath it carries a type and an engineering unit, and that values arrive at some frequency.
Assets are addressed down a path that runs from the organization to a single named value.
The MQTT topic a site publishes on carries its own six-level form of this path, and the two are not identical. Connecting a site has the topic structure and the Ignition setup that produces it.
Every module reads the same addresses. The OEE Engine reads counters at a path. The Historian keeps the timestamped record against that path. A chart recorder channel binds to an exact tag path and records nothing if the path it was given is not the path the control system publishes. None of those modules holds its own private map of the plant, which is what lets a value captured once be read by everything.
That shared map is also the thing that cannot change without everything downstream feeling it. An address is not a display name, and it is not a label anyone is free to tidy up later.
Capitalization and spelling must match exactly. A segment spelled two ways is two assets as far as the platform is concerned, and drift shows up in ways that read as data problems rather than naming problems.
Settle the naming for the enterprise, its sites, its areas and its lines once, before the first transmitter goes live. It is cheap to agree at the start of an implementation and expensive at any point after.
The addressing scheme is not assumed to exist. It gets built, in the data backbone work that runs when the readiness gate finds gaps, as the UNS architecture workstream.
What that work produces is one agreed namespace the whole estate publishes into: which levels exist, what each is called, and where a given plant, area and line sit within it. A site that already publishes into a namespace of its own brings it to that conversation rather than starting from nothing. A site that has never had one is doing this work for the first time, and it is worth budgeting as its own task rather than as a step inside a connection.
Alongside the namespace, asset modelling settles what each asset is, where it hangs, and what it reports. This is where a machine stops being a device on a floor and becomes something the platform can address.
There is no catalogue of ready-made models per machine type. The taxonomy is fixed and every model is built from it, but the model for a given machine type is agreed during implementation for the machine types in that phase. Expect to sit in that conversation rather than to receive a document.
UDTs are strongly recommended. A user-defined type instantiated across every asset of a kind is what keeps tag naming identical from the tenth machine to the hundredth, and tag naming is what the model binds to. Doing this by hand, per asset, is how drift gets in.
Every tag is typed, carries an engineering unit, and has an update frequency. That taxonomy is the vocabulary every module downstream reads, which has one consequence worth stating plainly: a tag is not added for one module. It is added to the model, and everything that reads the model can then see it.
In Counts, Out Counts, Reject Counts and State are the only tags documented as mandatory anywhere in the specification. Everything else is optional by omission, which is not the same as documented as optional. If a tag matters to a module being bought, confirm it during implementation rather than reading its absence as permission to skip it.
The full taxonomy, with types and engineering units, is in Data models.
Addressing and modelling belong to the data backbone phase, which runs only where the readiness gate finds gaps to close before configuration starts. Where a site already has a working namespace and a consistent asset model, that phase is short. Where it does not, this is the phase.
How implementation works has the full phase sequence and where the data backbone sits inside it. Site readiness covers what gets assessed before it. Connecting a site covers what happens once the model exists and a transmitter has something to publish.
We use cookies to understand how the site is used and to connect form submissions to earlier visits. No analytics or marketing cookies are set until you choose. Privacy Policy