Table of Contents

OPC UA: an Industry 4.0 information framework

OPC UA (IEC 62541) is a platform-independent industrial interoperability framework. Its real subject is how data is described, not merely how it moves: a typed address space, a security model, and companion specifications that give an industry a shared vocabulary for its machines. That description layer, not the transport, is what makes a machine's data usable by an MES, a SCADA system or a third-party integrator. AEI Corporation implements OPC UA servers and clients, designs information models, and integrates OPC UA with the deterministic networks beneath it.

This section covers OPC UA from first principles through quick-start guides, stack comparisons, benchmarking and interoperability results, platform support, and brownfield/greenfield integration methodology (including how it sits alongside legacy fieldbus and newer industrial Ethernet networks).

OPC UA at glimpse

What is the address space, and why is the information model the real work?

An OPC UA server exposes its data as an address space: a mesh of nodes (variables, objects, methods, types) joined by typed references, not a flat list of tags. A client can browse it and discover what a machine is, not only what numbers it emits. Generic tooling depends on exactly that distinction.

The engineering effort actually goes into modelling decisions: what is an object versus a variable, which type a node instantiates, whether NodeIds are deterministic and stable across firmware versions. These outlive the product. Unstable NodeIds are the classic defect: every client configuration breaks on the next firmware release. Models are authored and exchanged as NodeSet2 XML files, and treating that file as a versioned artefact of the product (rather than a tool output) is what keeps a device's interface compatible over its lifetime. See OPC UA information model.

OPC UA address space — ObjectNode with VariableNodes and MethodNodes connected by HasComponent references

Figure 1 — OPC UA address-space structure. An ObjectNode (MyDevice) groups its VariableNodes (Value, Quality, Timestamp) and MethodNodes (Start, Stop) via typed HasComponent references. Clients traverse this graph by NodeId and BrowseName — no schema negotiation required.

Client/server or pub/sub — which one is right?

Client/server (specified in IEC 62541-4) is a session-based, connection- oriented request/response model with browse, read, write, method calls and subscriptions. It is the right choice at the integration boundary: a client discovers the address space, negotiates security, and holds a session with known state: the model MES, SCADA and engineering tools expect.

PubSub (IEC 62541-14) removes the session. Publishers emit datasets to subscribers with no connection state between them, over UDP multicast, over raw Layer 2 Ethernet with the UADP binary encoding, or as JSON over MQTT or AMQP. It suits one-to-many distribution, cyclic machine data at rates a session model handles poorly, and cloud paths where a broker is already present.

They are not alternatives to choose once. Most real systems use both: PubSub for cyclic distribution, client/server for configuration, diagnostics and anything requiring acknowledged interaction.

What does OPC UA over TSN actually add?

OPC UA PubSub over raw Layer 2 Ethernet gives a compact, session-free datagram; TSN gives that datagram a guaranteed transmission slot. Together they make OPC UA usable for traffic that previously had to run on a separate fieldbus, which is the point of the OPC Foundation's field-level communications work. See OPC UA and field level communication.

One caveat: this only removes a network if the whole path supports it. A TSN-scheduled PubSub stream through one non-TSN switch is an ordinary best-effort stream. The migration is a network-wide decision, not a device feature.

What does the security model require that projects under-plan?

OPC UA security is certificate-based, and the part projects under-budget is not the cryptography but the certificate lifecycle. Each application instance holds an X.509 certificate; servers and clients must mutually trust each other's certificates, which means trust lists have to be provisioned, maintained, and updated in the field for the life of the machine.

The engineering decisions to make explicitly: the message security mode (None, Sign, or Sign-and-Encrypt) and the security policy. Per IEC 62541-7 and the OPC Foundation, the current recommended policies for production are Basic256Sha256 (widely adopted baseline), Aes128-Sha256-RsaOaep (standard industrial deployments), and Aes256-Sha256-RsaPss (highest strength). The older Basic128Rsa15 and Basic256 policies are deprecated and must not be used for new work. Then user authentication, which is a separate axis from application trust (anonymous, username/password, or certificate). Then how certificates are distributed and renewed at scale: manual trust-list management does not survive a fleet, which is why the Global Discovery Server and push/pull certificate management exist. Verify the currently recommended policy set against IEC 62541-7 profiles before pinning one in a specification.

What are companion specifications?

A companion specification is an industry-agreed information model built on OPC UA: it fixes what objects, variables and states a class of machine exposes, so that two builders' machines look the same to an MES. PackML (ISA-88) for packaging and EUROMAP 77/79 for injection moulding are the examples we work with most. See OPC UA companion specifications.

Open-Source stacks

Cloud and IIoT platforms

Our solution platforms on OPC UA + TSN

Tools

Test racks

References