Designing OPC UA Information Models

The OPC UA information model is what makes OPC UA far more than a data transport. Where OPC Classic moved flat tag lists, OPC UA describes the structure and meaning of data: objects, their properties, their relationships, and the operations that can be performed on them. A well-designed information model is the difference between a client that must guess what a tag means and a client that can explore, interpret, and automate against the server's data. This article explains the core concepts and a practical design process for building your own UA information model.

Core Building Blocks

Every UA address space is built from nodes connected by references.

References connect nodes and are typed: Organizes (hierarchy), HasComponent (part-of), HasProperty, HasSubtype (type inheritance), and HasEventSource, among others. The address space is a graph, not a tree — the same node can be referenced from several places.

Start from the Standards

Before designing from scratch, check whether a companion specification already covers your domain. Companion specs define standardized information models for industries and applications, and using them gives instant interoperability with existing clients:

• OPC 10000-100 — devices (field devices, general device model)
• OPC UA for PLCopen — mapping IEC 61131-3 data into UA
• OPC UA for ISA-95 / MES — job orders, equipment, materials
• OPC UA for Analytics, Machine Vision, PackML (PackML companion), DI (device integration)
• Industry-specific ones: energy (OPC UA for Energy), robotics (OPC UA for Robotics), CNC (Umati / OPC UA for MachineTools)

If a companion spec fits, adopt it — even partially. If not, design your own model but reuse the standard base types (BaseObjectType, BaseVariableType, AnalogItemType) so that generic UA clients can still browse and interpret your data.

Design Process

1. Define the purpose and audience

Who will consume this model? Operators need status and commands; maintenance needs diagnostics and run hours; MES/ERP needs production counts and state; analytics needs trends and quality. Different audiences may be served by different views over the same underlying nodes.

2. Identify the objects

List the physical and logical entities: machines, process units, lines, tanks, drives, sensors. Choose names that match the plant's own terminology — the model should read like the plant layout, not like a tag dump.

3. Define types, then instantiate

For each object family, create an ObjectType with its variables and methods. For example, a PumpType might contain:

• Variables: Speed (AnalogItemType, RPM), Running (Boolean), Current (AnalogItemType, A), RunHours (AnalogItemType, h)
• Methods: Start(), Stop(), ResetFault()
• Properties: SerialNumber, Model, InstallationDate

Then instantiate objects (Pump_1, Pump_2) as instances of the type. Instances inherit the type's structure, so clients that understand the type can process every instance uniformly.

4. Choose data types carefully

Use the right scalar types (Float vs. Double), and define structures for composite values instead of flattening them into many tags. Add engineering units (via AnalogItemType) so clients can display and convert correctly. For status, prefer structured status variables over cryptic integer codes.

5. Model relationships

Connect objects with meaningful references: a tank FeedsTo a pump; a line Contains machines; alarms BelongTo their source object. This graph is what makes the model browsable and analyzable.

6. Plan for events and alarms

If the system generates alarms, model them as UA events (per OPC UA Part 9 / 18) attached to their source objects, rather than as Boolean tags. Clients can then subscribe to event notifications with filtering, and the alarm history is structured.

7. Version and document

Information models evolve. Keep a version number on the model root, document naming rules, and follow the same change-control discipline as software: a client written against v1 of the model must not break when v2 adds nodes.

Practical Example: a Simple Line Model

Line_1 (Object, LineType)
├── Speed (AnalogItemType, m/min)
├── State (Variable, LineState enum)
├── TotalCount (Variable, UInt32)
├── RejectCount (Variable, UInt32)
├── Machines (Organizes)
│   ├── Filler_1 (FillerType)
│   │   ├── Running (Boolean)
│   │   ├── Level (AnalogItemType, %)
│   │   └── Start() / Stop()
│   └── Capper_1 (CapperType)
│       ├── Torque (AnalogItemType, Nm)
│       └── FaultCode (Variable, UInt16)
└── Alarms (Organizes)
    ├── LineStopped (Event)
    └── RejectRateHigh (Event)

This model lets a generic UA client browse to Line_1, see its machines and their capabilities, invoke Start/Stop, and subscribe to alarms — all without prior knowledge of the vendor's tag naming.

Summary

An OPC UA information model is the contract between your automation layer and every consumer of its data. Reuse companion specs where they exist, define clear types with proper units and structures, connect objects with meaningful references, model alarms as events, and version the model like software. The result is an address space that is self-describing, easier to integrate, and dramatically cheaper to maintain than a flat tag list.

Primary references and further reading

Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.

• OPC Foundation — OPC UA Part 4: Services
• OPC Foundation — OPC UA Part 2: Security Model