Industrial protocols are information models with a transport attached

#The mistake I made first

My first integration treated OPC UA as a way to read tag values. Connect, browse for nodes, subscribe, receive numbers. That works, and it throws away most of what the protocol offers.

OPC UA carries an address space where nodes have types, references to other nodes, and semantics attached [1]. A temperature transmitter is not a floating point value at an address. It is an object of a known type, with an engineering unit, a range, a status code and references to the equipment it measures.

Discarding that and keeping the number means rebuilding all of it in your own system, from documentation, by hand, for every site.

#Status codes are the specific example

Every OPC UA value comes with a status. Good, uncertain, bad, with sub-codes explaining why. A sensor reporting a value with an uncertain status is telling you something important, and a client that reads only the value cannot distinguish a live reading from a last known value held after the device stopped responding.

That distinction is exactly the one that determines whether a twin is honest about what it knows. If the protocol gives it to you and you drop it, you have thrown away the information you most need.

#Hierarchy from ISA-95

ISA-95 provides an equipment hierarchy and a vocabulary for the boundary between control and enterprise systems [2]. Adopting it costs a mapping exercise and pays off when the next system arrives already speaking it.

Its limitation is that it is a hierarchy. Real plants are graphs: a header serves units across several areas, a utility crosses the whole site, and a shared spare belongs to two systems. Forcing that into a tree produces either duplicate nodes or a tree that lies about connectivity.

What has worked for me is keeping the ISA-95 hierarchy as one relationship type within a graph rather than as the structure of the data. Knowledge graph representations handle exactly this kind of heterogeneous, multi-relational structure [4], and the hierarchy remains queryable as one edge type among several.

#Getting data out safely

The operational objection to any twin is that it needs data from the control system, and the control system is protected for good reason. NAMUR Open Architecture addresses this directly with a monitoring and optimisation channel that is one way by construction [3].

Designing to that from the start changes the conversation with the operations team, because you are proposing something that cannot write back rather than something that promises not to.

#The practical recommendation

Import the information model, not the values. Map the types once per site rather than the tags once per point. Keep status alongside every value through your whole pipeline, and resist any internal API that returns a bare number, because that API will be the one everything uses.