Addressing an operation

A temperature reading with no address is a number. The same reading with a stable address is a fact about a specific probe, on a specific machine, on a specific line, at a specific plant, and it can be compared to itself a year from now. Everything else in an operational data layer sits on top of that.

The hierarchy used here is ISA-95, and it runs Enterprise, Site, Area, Line, Work Cell, Asset, Tag.

The levels

Read downwards, it narrows from a company to a single value. Read upwards, it is the reason a plant manager can ask about a line and a corporate reader can ask about a site and both questions resolve against the same underlying readings, without anybody maintaining a second rollup by hand.

What a tag carries

Every tag is typed, with engineering units and an update frequency attached to it.

Those three attributes do more work than they look like they do. The type is what stops a boolean being averaged. The engineering unit is what stops a Fahrenheit probe being charted against a Celsius one on the same axis, which is the kind of error that survives review because both lines look plausible. The update frequency sets the expectation for how often a value should arrive, which is the only way anyone can distinguish a signal that is stable from one that has stopped changing without anyone noticing.

The address as an MQTT topic

Site data is published outbound over MQTT, and the topic structure follows ISA-95 Part 1 across six levels:

Enterprise Name / Site Name / Area Name / Line Name / Asset Name / Metrics

Sensors add a seventh segment for the sensor itself. Written out with neutral segment names, one probe on one oven looks like this:

Enterprise/Site1/Production/Line1/Oven01/TempProbe1/temperature

Nothing clever is happening in that string, and that is the point. The address is the hierarchy, spelled out, in order. A reader who understands the seven levels can look at any topic on the plant and say exactly what it is pointing at without opening a mapping document.

Capitalization and spelling must match exactly

The segments in a topic have to match the configured names character for character. Line1, line1 and Line 01 are three different addresses.

Nothing corrects that for you, and nothing should. A system that guesses at near-matches is a system that will eventually merge two machines that happened to be named similarly, and no operator will ever find out why the numbers went strange.

What breaks when naming drifts

Naming drift rarely arrives as an error. It arrives as absence, which is much harder to notice.

A tag that goes nowhere

A value published under a segment that does not match the configured address is not the address anything is looking for. The reading exists, it is simply not the reading anyone asked for.

A record with nothing in it

A digital process record channel is configured with an MQTT tag path that has to be an exact match to the topic carrying the reading. Rename the topic, and the channel points at an address that no longer publishes.

History that splits

Rename an asset after months of readings have accumulated and the history does not follow the rename. One machine now reads as two, each with half a story.

A rollup that understates without saying so

An asset addressed under the wrong line still reports, and its line still reports. The numbers simply belong to the wrong parent, and both look reasonable.

The cost of getting this right is a naming convention settled before the first machine is connected. The cost of getting it wrong is paid every time somebody asks a question the addresses cannot answer.

Why UDTs are strongly recommended

Only tags under the configured tag provider publish, and those tags may be OPC tags, reference tags or expression tags. User-defined types are strongly recommended for consistent instantiation across assets.

The reasoning is the same rule stated one level up. A type defines the shape of a machine once, and every asset instantiated from it carries the same tag names in the same positions. Naming discipline stops being something a person has to remember for the fortieth machine, which is where discipline usually fails.

What the address does not settle

Worth being straight about, because a reader with a controls background will ask. Payload format, quality of service level, retained-message policy, expected publish frequency, reconnect behaviour and store-and-forward are not specified in the platform documentation. The on-site client is expected to handle transmission failures gracefully, with retries or error logging, and that is a requirement placed on the site, not a documented platform behaviour.

No timestamp convention is specified either. Converting timestamps to a standard UTC format is mentioned once as an example of work the on-site client does, and that is the whole of the guidance that exists.

These are the questions to put on the table during the connectivity assessment rather than to assume answers for.

Keep reading