August 11, 2026 · Reference

OPC UA Companion Specifications: How UA Models Real Industries

The base OPC UA specification gives you nodes, types, references, and a browseable address space — but no opinion on what a "Machine" or a "Drive" or a "MachineTool" actually is. Two vendors can each ship a perfectly compliant UA server and still describe functionally identical equipment in incompatible ways, forcing every client into per-vendor mapping. That gap is what Companion Specifications close.

Companion Specs are standardized information models negotiated between the OPC Foundation and the industry bodies that actually know each domain — VDMA for machinery, PLCopen for IEC 61131-3, the VDW for machine tools, and the BACnet community for building automation. Implement the spec and your server speaks the same vocabulary as everyone else's in that industry. This guide walks through what companion specs exist, how they layer on top of base UA, and what concretely changes in the address space when a server implements one. For the underlying type system they extend, see the information model explainer.

Why a Generic Model Is Not Enough

Base UA lets you define ObjectTypes, VariableTypes, and DataTypes however you want. That freedom is by design — UA has to model everything from sensors to enterprise MES — but it is also the reason a generic UA server does not, on its own, guarantee interoperability. Vendor A's MotorType exposes Speed and Current; vendor B's DriveType exposes RPM and Amps. Both are valid UA. Neither can be consumed by the same client without a hand-written mapping.

Companion specifications are the missing standardization layer. Each one says, in effect: in this industry, when you expose a Machine, here are the exact object types, the exact child variables, the exact state machine, and the exact units you must use. A client written against the companion spec then works against any conformant server, regardless of vendor.

The Foundation: OPC UA for Devices (DI)

Almost every other companion spec builds on OPC UA for Devices (DI), jointly developed by the OPC Foundation and PLCopen. DI defines the vocabulary for representing physical equipment as UA objects:

• BaseDeviceType — the root type that all device-typed objects inherit from.
• ComponentType — for sub-components of a device (a motor's encoder, a machine's spindle).
• TopologyType — for representing physical layout and parent/child equipment relationships.
• Identification — a standard property set: Manufacturer, Model, HardwareRevision, SoftwareRevision, DeviceClass, and a unique SerialNumber.

Because Machinery, Robotics, Machine Vision, and others all inherit from DI, every companion-spec-compliant device exposes identification the same way. A client that knows how to read DI's Identification object can pull a serial number from a packaging machine, a robot arm, or a vision system using identical code.

PLCopen: IEC 61131-3 Function Blocks as UA

The PLCopen companion specification maps IEC 61131-3 function blocks into the UA address space. A controller that implements it exposes its program structure — function blocks, methods, and variables — as UA objects that a client can browse and, where allowed, call. The practical effect: a supervisory system can invoke a function block on the PLC over UA the same way it would call any UA method, with full type information on parameters and return values, instead of triggering a register bit and hoping.

OPC UA for Machinery

VDMA-driven and one of the most widely adopted companion specs, OPC UA for Machinery defines a uniform way to represent industrial machines regardless of what they make or who built them. Its core objects include:

• MachineIdentification — manufacturer, model, serial, product code (built on DI).
• MachineProduction — production jobs, counts of good/bad parts, current job and program.
• MachineStatus — operational state, detailed machine state, error and warning objects.
• Modes of operation — a standardized mode state machine (automatic, manual, setup, maintenance).

The state machine is PackML/ISA-88-inspired, so a packaging line, a CNC, and an assembly cell can all report "I am in Execute state, production job 1047, 812 good parts, 3 bad" using the same node structure. That is the dream companion specs were designed to deliver.

OPC UA FX (Field eXchange)

FX (Field eXchange) targets controller-to-controller data exchange on the plant floor — the case where two PLCs from different vendors need to share live data without a SCADA broker in the middle. FX defines a standardized way for a controller to publish selected parts of its address space to another controller, typically using OPC UA PubSub underneath. It is the inter-controller lingua franca that propriety protocols (Allied-Telematis, EhterCAT-P, Modbus-TCP-between-PLCs) never managed to become.

OPC UA for Machine Tools (umati)

umati (universal machine technology interface) is the VDW-led companion specification for machine tools — lathes, mills, grinding machines, additive systems. It extends the Machinery model with production metrics specific to metal-cutting and forming: tool management, axis loads, feeds and speeds, and spindle state. The umati initiative also runs a public certification and demo-server program, which makes it one of the easiest specs to test a client against — you can browse a live umati-compliant demo server from macOS without owning a single CNC.

Building Automation: BACnet and OPC UA

Building automation already has BACnet (ISO 16484-5). The OPC Foundation and BACnet community collaborated on a companion spec that maps BACnet objects (analog-input, analog-value, binary-output, schedule, program) into UA's address space, so a single UA client can read both the production floor (Machinery) and the building systems (HVAC, lighting) without learning a second protocol. Combined with BACnet/SC (Secure Connect), this is the path by which a facility-management system converges on one client technology instead of two.

Other Companion Specs Worth Naming

• OPC UA for Robotics — robot identification, axis data, end-effector state (VDMA).
• OPC UA for Machine Vision — vision system identification, image data, results (EMVA).
• OPC UA for Oil & Gas — upstream/downstream equipment models.
• OPC UA for Plastics & Rubber Machinery — injection molding, extrusion.
• OPC UA for Machine Tools (umati, above) and OPC UA for Woodworking Machinery.
• OPC UA for Machinery General Industry Events, and analytical-instrument specs in pharma and lab automation.

How Companion Specs Appear in the Address Space

Companion specs are not a separate protocol or a different port. They are type definitions that the server publishes in its own namespace, alongside the standard UA namespace. Concretely:

• The server registers a new namespace URI (e.g. urn:opcfoundation.org:UA:Machinery) and exposes it via the Server.NamespaceArray attribute.
• Type definitions appear under the Types/ObjectTypes folder — e.g. MachineIdentificationType, MachineStatusType, MachineToolType.
• Instances in the Objects folder inherit from those types: a real machine appears as an Object whose TypeDefinition is MachineIdentificationType.
• Clients browse the typed object and see its standard children (Identification, Production, Status, Modes) without any external documentation.

When you connect a browse client to a Machinery-compliant server from macOS, the address space looks structurally familiar — you do not need a register spreadsheet or a vendor manual to know that the MachineStatus.OperationalState variable exists and is an enumerated value. That is the whole point.

Raw Tags vs Companion-Spec Typed Objects

Why This Matters

• No more per-vendor register maps. A Machinery-compliant machine is self-describing. You stop maintaining spreadsheets that map 40017 to "good parts count, vendor X only".
• Semantic interop, not just byte interop. A client knows the difference between a state enum and a counter, between a temperature and a pressure. Modbus TCP moves bytes; companion specs move meaning.
• Multi-vendor plants become tractable. A line with machines from three vendors can be monitored with one client, one dashboard, one alarm model — if every machine implements the same companion spec.
• Future-proof integrations. When you replace a machine on the line, the new one exposes the same types. Your SCADA keeps working.

Limitations and Gotchas

• Adoption varies. Not every server implements every companion spec. A basic PLC may implement none; a modern machine tool may implement umati plus Machinery. Always browse the namespace array first.
• Partial compliance. Some vendors claim spec compliance but extend the standard types with proprietary children. The standard parts still work; the extensions do not, unless the client knows about them.
• Version drift. Companion specs evolve. A server implementing Machinery 1.0 may not expose nodes added in 2.0. Check the spec version in the namespace URI or the server's documentation.
• Clients must understand the spec too. A generic UA browse client can always read companion-spec nodes; a client built against the spec (typed UI, specific dashboards) is what unlocks the real value.

Browsing a Companion-Spec Server on macOS

MacTools OPC UA Explorer walks companion-spec type definitions natively. Connect to a Machinery- or umati-compliant server, browse Types/ObjectTypes to see the spec's type hierarchy, then drill into Objects to inspect real machines with their standard Identification, Status, and Production children. The companion spec stops being a PDF and becomes a navigable address space — without Windows tooling.

Frequently Asked Questions

What is an OPC UA companion specification?

A companion specification is a standardized OPC UA information model defined jointly by the OPC Foundation and an industry body. It extends base UA with agreed object types, variables, and methods for a specific domain — machines, robotics, machine tools — so equipment from different vendors exposes data the same way and clients interoperate without vendor-specific mapping.

What is OPC UA for Devices (DI)?

OPC UA for Devices (DI) is the foundational companion specification that most others build on. It defines BaseDeviceType, ComponentType, topology objects, and identification properties that represent physical equipment as typed UA objects. Machinery, Robotics, and other companion specs inherit from DI's device model so every domain shares a common equipment vocabulary.

Do all OPC UA servers implement companion specifications?

No. A server can be fully UA-compliant and expose only a vendor-specific information model. Companion spec support is optional and varies — a PLC may implement PLCopen, a CNC machine may implement the Machine Tools spec (umati), and a simple sensor may implement none at all. Browse the server's ObjectTypes namespace to confirm which, if any, companion specs are present.

How do I know which companion specs a server supports?

Browse the server's address space and inspect the namespace URIs and ObjectTypes nodes. Companion specs are published in dedicated namespaces (e.g. urn:opcfoundation.org:UA:Machinery), and their type definitions appear under the Types/ObjectTypes folder. A client like MacTools OPC UA Explorer lists namespaces and lets you walk type definitions to confirm coverage.

Further Reading

• OPC UA Information Model Explained
• How to Browse an OPC UA Server Address Space
• OPC UA vs Modbus TCP
• Industrial Protocol Comparison