Developers
The ISA-95 tag taxonomy the Singularity expects from a site: the hierarchy, the tags, their engineering units, and the four tags that are genuinely mandatory.
A data model is the agreed shape of what a machine reports: which tags exist, what each one means, what type it carries, and what engineering unit it is expressed in. Data arriving from your site has to be in that shape before a module can use it.
There is no catalogue of ready-made models per machine type. The taxonomy below is fixed and it is what every model is built from. The model for a given machine type is agreed during implementation, against this taxonomy, for the machine types in that phase. Expect to sit in that conversation rather than to receive a document.
Every tag is typed, carries an engineering unit, and has an update frequency.
Assets are addressed down a seven-level path.
The MQTT topic a site publishes on carries its own six-level form of this path, which is not identical to the seven levels above. Connecting a site has the topic structure.
Four tags are mandatory. They are the only tags documented as required anywhere in the specification.
The specification tables carry no mandatory-versus-optional column, so every tag below the four above is optional by omission. That is not the same as documented as optional. If a tag matters to a module you are buying, confirm it in implementation rather than reading its absence here as permission to skip it.
What the machine is doing, and the job, product, shift and reason code it is doing it under.
These are the OEE backbone. Three of them carry the mandatory flag.
Physical conditions measured on the process itself, and the electrical draw behind it.
The unit a tag is expressed in is part of the agreement, not a detail settled later. A pressure tag carried in psi where the model expects bar produces a plausible number, and a plausible number survives every check a person makes by eye.
Inspection and sample results measured on the line.
Utilities consumed around the process, plus ambient conditions and the cost and carbon rates applied to them.
Condition and run history for the equipment itself rather than for the product.
These carry an explicit flag in the specification: not required for all assets. It is the only place a tag is marked that way.
These do not come off a PLC. Each one arrives from a system a person operates, and the source system is part of the model.
Scope these early. A downtime reason code that exists only in a supervisor’s head is an operational change on the floor, not a mapping exercise, and it carries the lead time of one.
No timestamp convention is specified. The documentation mentions converting timestamps to a standard UTC format once, as an example of work that happens on the client before publish. That is the whole of the guidance that exists.
Agree the convention in implementation and write it down. A misread timestamp does not fail loudly, and a shift boundary landing an hour off looks exactly like a real production pattern.
Every tag in the agreed model has to be filled from something real on your floor. Deciding which signal on a given machine corresponds to which tag is judgement work that needs plant knowledge, and it is harder than it sounds for reasons that have nothing to do with software.
None of that can be inferred from a tag name, which is why mapping is done per machine type first and then confirmed per machine.
Validate on your side, before publish: tags present, types correct, values inside range, the mandatory four populated. A malformed record caught at the source is one record. The same record caught later is one row inside a stream, and finding it costs more than preventing it did.
Implementation has a hard integration-validation gate, and module configuration does not proceed past it. Configuring a module on top of data that does not yet match the model produces work that has to be redone.
Missing coverage is harder to spot than bad formatting. A site that connects most of its machines and not all of them produces answers that look complete, because nothing on a screen announces which machines are missing. A total reads as a total. Where a machine cannot report yet, know it is out, know why, and have it on the connectivity list.
This is the step implementations stall on, and the platform is rarely the reason.
Mapping needs someone who knows the plant. Type conversion needs someone who knows what a specific machine actually emits. The mandatory four expose instrumentation gaps that have been tolerated for years, because no downstream system ever asked that machine for a reject count before. All of it wants the same small number of people, and those people have day jobs on the floor.
Take one machine type all the way through mapping, conversion, population, and validation before starting the second, so the pattern is proven once instead of debugged five times in parallel. Treat the output of the connectivity assessment as the real schedule, because a machine that cannot report cannot be mapped.
Who owns which half of this work is set out in Division of responsibilities. The module that puts the resulting model to work is the Data Model Engine.
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