Most industrial protocols just move numbers. Register 40001 gives you 42.5 — and that’s it. You need a separate spreadsheet to know it’s a temperature, in Celsius, from Tank 01, with an alarm limit at 80°C.
OPC UA works differently. It doesn’t just carry data — it carries the meaning of that data. The structure, relationships, types, units, and context all travel together. This is the information model, and it’s the reason OPC UA is the foundation of modern industrial interoperability.
This guide explains how the OPC UA information model works, how it’s structured, and how to design and use information models in practice.
Table of Contents
What Is an Information Model?
An information model is a formal description of how data is organized, what it represents, and how different pieces of data relate to each other.
In OPC UA, the information model defines the contents of a server’s address space — the structured collection of all data that the server makes visible to clients. IEC 62541 Part 5 specifies the standard information model that defines the address space of every OPC UA server.
But the information model goes far beyond a simple tag list. As one expert put it, an OPC UA information model defines a comprehensive digital twin: objects, data, services, and how they all relate to one another.
The Three Layers of Information Modeling
OPC UA information modeling works in three layers, each building on the one below.
Layer 1: The meta model (IEC 62541 Part 3)
The meta model defines the building blocks — the rules and structures you use to create any information model. This includes the eight node classes (Object, Variable, Method, View, ObjectType, VariableType, ReferenceType, DataType), the concept of attributes and references, the type system with inheritance, and modeling rules for instantiation.
Think of this as the grammar of the language. It doesn’t describe any specific machine or device. It gives you the tools to describe anything.
Layer 2: The base information model (IEC 62541 Part 5)
The base information model uses the meta model to define standard types and objects that every OPC UA server should provide. This includes the Server Object (exposing server diagnostics, capabilities, and status), base data types (Boolean, Int32, Float, String, DateTime, ByteString, and more), base object types (BaseObjectType, FolderType, etc.), base variable types (BaseVariableType, PropertyType, DataItemType), base reference types (HasComponent, HasProperty, Organizes, HasTypeDefinition), base event types (BaseEventType, SystemEventType, AuditEventType), and standard entry points (Objects folder, Types folder, Views folder).
This is the standard vocabulary. Any OPC UA client connecting to any server will find these types and structures. They form the common ground.
Layer 3: Domain-specific models (Companion Specifications)
On top of the base model, industry groups and vendors build domain-specific information models. These define standard types for specific equipment and industries — robots, packaging machines, CNC controllers, analyzers, weighing systems, and over 60 more.
These models are published as companion specifications with both human-readable documentation and machine-readable nodeset files (XML). They ensure that a packaging machine from Vendor A describes itself the same way as one from Vendor B.
Nodes: The Building Blocks
Everything in the information model is represented as a node. There are eight node classes, divided into instance nodes and type nodes.
Instance nodes (what exists in the server)
| Node Class | Purpose | Example |
|---|---|---|
| Object | Represents a real or abstract thing | Motor_01, Tank_03, ProductionLine_A |
| Variable | Holds a data value | Temperature, Speed, Status |
| Method | A callable function | Start(), Stop(), Calibrate() |
| View | A filtered subset of the address space | MaintenanceView, OperatorView |
Type nodes (blueprints that define structure)
| Node Class | Purpose | Example |
|---|---|---|
| ObjectType | Defines what objects of this type contain | MotorType, TankType |
| VariableType | Defines the structure of variables | AnalogItemType, DataItemType |
| ReferenceType | Defines the meaning of a reference | HasComponent, HasProperty |
| DataType | Defines the structure of data values | Temperature (structure with value + unit) |
The type system supports inheritance. A VariableSpeedMotorType can inherit from MotorType, gaining all of its components while adding new ones specific to variable-speed drives.
References: How Nodes Connect
Nodes don’t exist in isolation. References create the relationships between them. A reference is a named, directed connection from one node (source) to another (target).
The most important standard reference types are:
HasComponent — means “this node is a part of that node.” A Motor has components like Speed, Temperature, and Status variables. HasComponent builds the containment hierarchy.
HasProperty — means “this node describes a characteristic of that node.” EngineeringUnits, AlarmLimits, and SerialNumber are typical properties.
Organizes — means “this node is organized under that node.” Used by folders to group nodes logically without implying ownership.
HasTypeDefinition — means “this node is an instance of that type.” Motor_01 HasTypeDefinition MotorType tells clients exactly what to expect from Motor_01.
HasSubtype — means “this type is derived from that type.” VariableSpeedMotorType HasSubtype of MotorType. This is how inheritance works.
References can be hierarchical (forming browseable trees) or non-hierarchical (creating cross-links). The address space isn’t limited to a single tree — it’s a full graph of interconnected nodes.
Variables vs Properties
This distinction confuses many newcomers, so let’s be clear.
Variables (specifically data variables) represent the actual data values of an object — the things you read, write, and subscribe to during operations. Temperature, Speed, Pressure, RunningState. They’re connected via HasComponent references.
Properties describe characteristics of a node. They provide metadata: EngineeringUnits, AlarmHighLimit, Description, SerialNumber. They’re connected via HasProperty references.
The key difference: variables represent operational data that changes during runtime. Properties represent configuration or descriptive data that changes rarely or never.
The Type System: Design Once, Use Everywhere
The type system is what makes OPC UA information modeling truly powerful.
Defining a type
When you define an ObjectType — say, TemperatureTransmitterType — you specify all the components that every instance of that type will have: a Temperature variable (Float, with EngineeringUnits property), a Status variable (enumeration: Good/Bad/Uncertain), a HighAlarmLimit property, a LowAlarmLimit property, and a Calibrate() method.
This type definition lives in the address space alongside instances. Clients can browse it to understand what any TemperatureTransmitter looks like — without connecting to a specific device.
Creating instances
When a server creates an instance — TemperatureTransmitter_01 based on TemperatureTransmitterType — it gets all the defined components automatically. The HasTypeDefinition reference links the instance to its type, so clients always know the blueprint behind any instance.
Subtyping
Types support inheritance. An AdvancedTemperatureTransmitterType can inherit from TemperatureTransmitterType, adding new components like a DiagnosticsObject or a SelfTest() method. It keeps everything from the parent type and extends it.
This creates a type hierarchy that clients can browse: BaseObjectType → DeviceType → TransmitterType → TemperatureTransmitterType → AdvancedTemperatureTransmitterType.
Why types matter
Types give you three massive advantages. Reusability — define the model once, instantiate it across hundreds of devices. Discoverability — clients understand any instance by looking at its type. Interoperability — if two vendors implement the same type definition, their devices look identical to clients.
Namespaces: Avoiding Collisions
As information models grow — with base types, vendor types, and companion specification types all in the same address space — naming conflicts become possible. Namespaces solve this.
Every node belongs to a namespace identified by a URI. The OPC UA base model uses namespace 0 (http://opcfoundation.org/UA/). A companion specification for robotics uses its own URI. Your company’s custom model uses yours.
Inside a server, namespace URIs are mapped to numeric indexes for efficiency. The server tells clients the mapping. Namespace index 0 is always the base OPC UA model. Index 1 is for server-specific instances. Custom models start at index 2 and above.
A NodeId consists of a namespace index plus an identifier. Two different models can both define a “Status” variable without conflict — they live in different namespaces.
Nodeset Files: Sharing Models
Information models are shared as XML nodeset files (*.NodeSet2.xml). These files contain the complete definition of all types, instances, and references in a model.
Nodeset files serve two purposes. For developers, they can be imported into OPC UA server SDKs to automatically populate the address space with the defined types. For documentation, they provide a machine-readable specification that tools can parse, validate, and visualize.
The OPC Foundation’s UA Cloud Library (uacloudlibrary.opcfoundation.org) hosts a global repository of nodeset files from all published companion specifications. Developers can browse, download, and use these models before ever connecting to a physical device.
How the Standard Information Model Is Organized
IEC 62541 Part 5 defines the structure that every OPC UA server starts with.
The Server Object
Every server exposes a Server object (at a well-known location in the address space) that provides server status and state information, server capabilities (supported profiles, max array lengths, operation limits), server diagnostics (session counts, subscription counts, error counters), vendor-specific information, redundancy configuration, and namespace metadata.
This is the first thing a client typically examines after connecting — it tells you what the server can do and how it’s configured.
The folder structure
The address space is organized under standard root folders. The Objects folder contains all the server’s objects — both standard (like the Server object) and application-specific. The Types folder contains all type definitions organized by category: ObjectTypes, VariableTypes, DataTypes, ReferenceTypes. The Views folder contains any server-defined views.
This consistent structure means every OPC UA server is navigable the same way, regardless of what equipment it represents.
Designing Your Own Information Model
If you’re building an OPC UA server for custom equipment, here are practical design guidelines.
Start from existing types. Don’t reinvent what already exists. Build on the base types from Part 5, the device types from Part 100, and any relevant companion specifications for your industry.
Design types first, instances second. Define your ObjectTypes and VariableTypes before creating instances. This forces you to think about structure and reusability upfront.
Use HasComponent for operational data. Variables that change during runtime — temperatures, speeds, states — connect via HasComponent.
Use HasProperty for metadata. Engineering units, serial numbers, alarm limits, and descriptive information connect via HasProperty.
Keep namespaces clean. Put your custom types in their own namespace with a URI you control. Don’t mix your types into namespace 0 or someone else’s namespace.
Use modeling rules. Mark components as Mandatory (always present in instances), Optional (may be present), or OptionalPlaceholder (clients can add instances of this type). This tells implementers and clients exactly what to expect.
Validate your model. Use the OPC Foundation’s UA Model Compiler or other tools to validate your nodeset file against the OPC UA schema. Catch errors before they reach production.
Document your model. The nodeset file is for machines. Write human-readable documentation for developers and integrators who will implement it.
Real-World Example: Modeling a Pump Station
Here’s how a simple pump station might be modeled in OPC UA.
You’d define a PumpType (ObjectType) with a Discharge Pressure variable (Float, PSI), a Flow Rate variable (Float, GPM), a Running State variable (Boolean), a Motor Speed variable (Float, RPM), a Start() method, a Stop() method, and properties for Manufacturer, Model, and SerialNumber.
A PumpStationType would contain two instances of PumpType (Pump_Primary and Pump_Backup), a TankLevel variable, an AutomaticMode variable, and a SwitchPumps() method.
When the server instantiates PumpStation_01 from PumpStationType, all the components appear automatically. A client browses to PumpStation_01, sees both pumps with all their variables and methods, and knows exactly how to interact with the system — no documentation required.
Conclusion
The OPC UA information model transforms industrial communication from “here’s a number” to “here’s what this number means, where it comes from, what its limits are, and how it relates to everything else.”
The three-layer approach — meta model, base model, domain models — creates a system where any machine can describe itself in a way that any client can understand. Types provide reusability and structure. References create rich relationships. Namespaces prevent conflicts. And nodeset files make models portable and shareable.
For anyone building OPC UA servers, designing industrial data architectures, or integrating equipment from multiple vendors, the information model isn’t a nice-to-have. It’s the core feature that makes OPC UA more than just another protocol. It’s what makes it an interoperability framework.