OPC UA Information Modeling for Industrial Systems
Transform industrial assets, processes and semantics into structured, interoperable OPC UA information models.
What Is OPC UA Information Modeling?
OPC UA Information Modeling provides a structured way to describe industrial systems beyond the exchange of individual data values.
An OPC UA Information Model represents objects, types, variables, methods, events and the relationships between them within a common semantic structure. It allows applications to understand not only a value, but also what that value represents, where it belongs and how it relates to the rest of the industrial system.
Data connectivity answers:
How can I access this value?
Information modeling answers:
What does this information mean, and how does it relate to the industrial system?
From Tags to Industrial Information
Traditional industrial integration often starts with individual data points: temperatures, pressures, speeds, states or alarms. These values may be accessible through a communication protocol, but their meaning and relationships frequently remain implicit. Applications must know which machine a value belongs to, what it represents and how it relates to other information.
OPC UA Information Modeling changes this approach. Instead of exposing industrial data as an isolated collection of tags, information is organized into objects with defined types, properties, behaviors and relationships.
A motor, for example, is no longer represented only by independent values such as Motor_Status, Speed and Temperature. It can be represented as an industrial object whose variables, methods and events are explicitly associated with that motor and whose relationships to the machine or production line are part of the model.
This transforms raw connectivity into structured industrial information that applications can discover and interpret.
Connectivity provides access to values. Information modeling provides their industrial context and meaning.
The Building Blocks of an OPC UA Information Model
An OPC UA Information Model is built from a set of standardized modeling constructs defined by IEC 62541. Together, they describe the structure, data, behavior and relationships of an industrial system.
Rather than defining every machine or asset independently, OPC UA separates reusable type definitions from their instances. This makes it possible to build consistent models that can be instantiated across machines, production lines and sites.
ObjectTypes and Objects
ObjectTypes define reusable structures, while Objects represent actual instances of those structures within the AddressSpace.
For example, a MotorType can define the information expected for every motor: operating state, speed, temperature, maintenance information, methods and associated events. Individual motors such as Motor_001 and Motor_002 can then be instantiated from that common type.
This separation between type definition and instance is fundamental to OPC UA Information Modeling. It avoids rebuilding the same structure for every asset and provides applications with a consistent way to understand objects of the same type.
An Object can also contain other Objects and Variables, expose Methods and generate Events, allowing a complete industrial asset to be represented as a coherent entity rather than as a collection of unrelated tags.
VariableTypes and Variables
Variables represent data associated with objects in the information model. They can contain process values, states, configuration parameters, measurements or other information required to describe the industrial system.
A Variable is not limited to its current value. OPC UA can associate it with additional characteristics such as its DataType, ValueRank, engineering information, access rights and historical capabilities.
VariableTypes make these definitions reusable. When several objects expose information with the same semantic role, a VariableType can define the expected structure and characteristics once and reuse them consistently throughout the model.
For example, a motor speed is therefore not simply a numerical tag named Speed. Within the model, it can be a Variable belonging to a Motor object, with a defined data type and semantic context inherited from its type definition.
Methods
Methods represent operations that can be invoked on objects.
They allow an OPC UA Information Model to describe not only what an industrial asset is and what data it exposes, but also what operations it can perform.
A motor object could, for example, expose methods such as:Start()Stop()Reset()
A production system could expose more complex operations with typed input and output arguments.
Because Methods belong to objects in the AddressSpace, their meaning is contextual. A client discovering an object can also discover the operations associated with that object instead of relying on a separate proprietary API definition.
This introduces behavior into the information model alongside structure and data.
Events
Events represent information generated when something occurs in the industrial system.
Unlike Variables, which describe a state or value that can be read, Events describe occurrences: a state transition, a process condition, an operator action, a system notification or another significant change.
OPC UA defines an event type system that allows events to carry structured information and to inherit common characteristics from reusable EventTypes.
An industrial model can therefore describe not only assets and their current state, but also the events those assets may produce.
This mechanism also provides the foundation for more specialized OPC UA models such as Alarms & Conditions, where conditions, states, acknowledgements and transitions are represented using standardized event semantics.
References and Relationships
References are one of the most important elements of OPC UA Information Modeling because they define how Nodes are related to each other.
Instead of relying only on a hierarchical folder structure, OPC UA uses typed References to express the semantics of relationships.
Standard References include, for example:
HasComponent— identifies a component belonging to an object;HasProperty— associates descriptive properties with a Node;Organizes— provides an organizational relationship;HasSubtype— expresses type inheritance.
Information Models can also define specialized ReferenceTypes when domain-specific relationships need to be represented.
This allows the AddressSpace to express relationships such as:
a motor is a component of a machine,
a sensor measures a physical quantity,
a machine belongs to a production line,
or a type derives from another industrial type.
The resulting model is therefore not simply a tree of Nodes. It is a typed graph of industrial information that applications can browse and interpret.
Objects provide structure. Variables provide data. Methods provide behavior. Events describe occurrences. References connect everything into a coherent industrial model.
Types, Instances and Reusable Industrial Models
One of the fundamental principles of OPC UA Information Modeling is the separation between reusable type definitions and actual industrial instances.
A type describes the common structure and behavior expected from a category of industrial objects. For example, a PumpType can define the Variables, Methods, Events and relationships that every pump of that type must expose.
The same definition can then be instantiated multiple times:
PumpType
├── Pump_001
├── Pump_002
├── Pump_003
└── Pump_004
Each pump is a distinct Object with its own NodeId, values and runtime state, while all instances share the semantic structure defined by PumpType.
This approach has several consequences for industrial engineering.
First, the model becomes consistent. Applications discovering two instances of the same type know which information and behavior they can expect.
Second, the model becomes scalable. Hundreds or thousands of industrial assets can be instantiated from reusable definitions instead of being modeled individually.
Third, changes can be managed at the model level. The engineering team works with industrial concepts such as pumps, motors, machines or production units rather than maintaining independent collections of tags.
Type inheritance extends this principle further. A specialized industrial type can derive from another type, reuse its existing definition and add domain-specific information.
For example:
BasePumpType
│
├── CentrifugalPumpType
│
└── VacuumPumpType
The result is an industrial type system that can evolve from generic concepts toward increasingly specialized domain models while preserving common semantics.
Namespaces and Model Composition
Real industrial systems rarely rely on a single Information Model.
An OPC UA AddressSpace can combine Nodes originating from the OPC UA base model, standardized Companion Specifications, company models, equipment models and project-specific extensions.
Namespaces provide the mechanism for keeping these models identifiable while allowing them to coexist and reference each other.
A typical industrial model may therefore be composed as follows:
OPC UA Base Model
│
├── Companion Specification
│ │
│ └── Industry-specific types
│
├── Company Information Model
│ │
│ └── Enterprise-specific concepts
│
└── Project / Machine Model
│
└── Runtime instances
Each model can define its own namespace while depending on types and definitions provided by other namespaces.
This is important because interoperability does not require every organization to use one monolithic Information Model. Instead, OPC UA allows models to be composed.
A machine builder can reuse standardized domain types, extend them with proprietary capabilities and instantiate those types for a specific machine. An integrator can then combine that machine model with other equipment models inside a larger production system.
References can cross namespace boundaries, allowing these independently defined models to form a coherent AddressSpace.
The architecture therefore supports both standardization and specialization:
- standardized models provide shared semantics;
- company models capture reusable organization-specific concepts;
- project models describe the actual deployed industrial system.
This composition mechanism is one of the reasons why namespace architecture should be considered during Information Model design rather than treated simply as a technical NodeId configuration detail.
NodeSet: The Portable Representation of an OPC UA Model
An OPC UA Information Model needs a standardized representation that can be exchanged between modeling tools, servers and other engineering environments. OPC UA provides this through the NodeSet XML format.
A NodeSet can describe the Nodes that compose a model, including types, objects, variables, data types and references, together with the namespaces and dependencies required to interpret them.
This makes the Information Model portable independently from a particular server implementation.
A NodeSet can therefore be used to:
- exchange an Information Model between engineering tools;
- import standardized Companion Specifications;
- distribute company or project-specific models;
- load model definitions into an OPC UA implementation;
- provide the basis for creating runtime instances.
However, the distinction between model and NodeSet is important.
A NodeSet is a standardized representation of an OPC UA Information Model. It is not the modeling process itself.
The engineering process starts with understanding the industrial domain: its assets, concepts, relationships and behaviors. The NodeSet is one standardized result of that modeling work.
OPC UA Companion Specifications
OPC UA Companion Specifications define standardized Information Models for specific industries, technologies and application domains. They provide a common vocabulary and structure that different vendors can implement and exchange using OPC UA.
A Companion Specification may define reusable ObjectTypes, VariableTypes, DataTypes, ReferenceTypes, Methods and Events for a particular domain. Applications can therefore recognize not only that a server exposes data, but also that an object represents a standardized machine, device, process element or domain concept.
In real industrial systems, however, a single Companion Specification rarely describes the complete system. An implementation may need to combine:
- the OPC UA base model;
- one or more Companion Specifications;
- company-specific models;
- machine or process-specific models.
OPC UA supports this composition through namespaces and references between models. A project can therefore reuse standardized semantics where they exist while extending them with the information required by the actual industrial system.
Companion Specifications provide standardized semantics. Industrial Information Models compose and extend them to represent the complete system.
From Information Model to Runtime AddressSpace
An Information Model becomes operational when its types and structures are used to create actual industrial instances in an OPC UA AddressSpace.
A model may define, for example, a reusable MotorType. The runtime system then instantiates actual motors such as Motor_001, Motor_002 or Motor_003, each with its own values and state while retaining the structure and semantics defined by the type.
The complete lifecycle can therefore be represented as:
Industrial Domain → Information Model → NodeSet → Instantiation → Runtime AddressSpace
At runtime, these instances must also be connected to the real industrial system. Their Variables need actual values, Methods require implementations, Events must be generated from runtime conditions, and historical or persistence services may need to be associated with the corresponding information.
This is where information modeling and runtime architecture meet.
In OOUAMiddleware, the Information Model is not merely used to generate static source code. Model definitions can be interpreted by the runtime and used as the basis for creating and executing the operational AddressSpace.
Model-Driven Engineering with OpenOpcUa
OpenOpcUa extends Information Modeling into a complete engineering workflow designed to move from industrial knowledge to an operational OPC UA system.
The objective is to keep the industrial model at the center of the engineering process instead of treating OPC UA as a communication layer added after the application has been designed.
The OpenOpcUa workflow separates this process into five phases.
Phase 1 — UML Modeling
The first phase captures the industrial domain independently from runtime implementation details.
Industrial assets, concepts, properties, relationships and behaviors are described using UML. The objective is to create a model that can be reviewed with domain experts before committing it to a particular OPC UA implementation.
This separation is important: the starting point is the industrial semantics, not the server code or the communication protocol.
UML also provides a mature graphical modeling environment for representing inheritance, composition, associations and reusable industrial structures.
Phase 2 — UML to NodeSet
The UML model is transformed into an OPC UA Information Model and represented using the standardized NodeSet format.
During this phase, industrial concepts are mapped to the appropriate OPC UA modeling constructs: ObjectTypes, VariableTypes, DataTypes, References, Methods and other Nodes required by the model.
The resulting NodeSet provides a machine-readable OPC UA representation while preserving the architecture defined during the modeling phase.
This transformation also creates a clear separation between:
domain modeling → OPC UA representation → runtime implementation.
The NodeSet can then be validated, exchanged and reused independently from the runtime environment.
Phase 3 — Instantiation
Defining types is not sufficient to represent an operational industrial system. Actual machines, equipment and process elements must be instantiated from those type definitions.
During the instantiation phase, reusable model types become concrete industrial objects.
For example:
MotorType
├── Motor_001
├── Motor_002
└── Motor_003
Each instance retains the structure and semantics of its type while representing a distinct asset with its own identity, configuration and runtime values.
This allows large industrial AddressSpaces to be constructed consistently from reusable model definitions rather than manually reproducing similar Node structures.
Phase 4 — Configuration
Once the industrial instances exist, they must be connected to the operational environment.
Configuration associates the model with the services required by the deployed system, including, depending on the architecture:
- OPC UA endpoints;
- security and certificates;
- industrial connectivity;
- runtime modules;
- persistence and historical services;
- deployment-specific parameters.
In OOUAMiddleware, these concerns remain separated from the Information Model itself. The same model can therefore be reused while its connectivity, persistence or deployment configuration evolves.
This separation is one of the principles behind the VPI and VFI architecture: industrial connectivity and persistence are attached around the model-driven runtime rather than embedded into the semantic definition of the model.
Phase 5 — Runtime Execution
The final phase turns the engineered model into an operational industrial system.
OOUAMiddleware dynamically interprets and executes the resulting industrial model.
The runtime instantiates and manages the OPC UA AddressSpace, connects industrial values through the configured interfaces, executes services, manages subscriptions and events, and interacts with persistence services when required.
The Information Model therefore does not remain an engineering artifact. It becomes part of the execution architecture.
This leads to the central principle of the OpenOpcUa approach:
Model once. Instantiate consistently. Configure independently. Execute dynamically.
Runtime-Interpreted Information Models in OOUAMiddleware
OOUAMiddleware does not require the industrial Information Model to be hard-coded into the application. Instead, OPC UA model definitions can be loaded, interpreted and instantiated dynamically by the runtime.
This is an important architectural distinction. In a conventional implementation, changes to the Information Model may require modifications to application code, regeneration of software components or recompilation. In OOUAMiddleware, the model is treated as an independent engineering artifact that the runtime can interpret.
The runtime uses the model definitions to construct and manage the OPC UA AddressSpace, create instances and maintain the relationships defined by the Information Model. Runtime services can then connect these modeled objects to actual industrial data, persistence systems and external applications.
This creates a clear separation between three concerns:
- the Information Model, which defines industrial structure and semantics;
- the runtime configuration, which determines how the system is deployed and connected;
- the runtime engine, which executes the resulting industrial system.
The same model can consequently be reused across different deployments without embedding its complete structure into application source code.
This separation also makes the Information Model independent from a single external interface. OOUAMiddleware can expose the same runtime-interpreted industrial model through OPC UA and through additional interfaces such as i3X, while preserving the same underlying semantic structure.
The model defines the industrial system. The runtime interprets it. Interfaces expose it.
See how OOUAMiddleware exposes the same runtime Information Model through the i3X interface.
Why Information Modeling Matters for Industrial Interoperability
Industrial interoperability requires more than establishing a communication channel between two systems.
Two applications may successfully exchange values while still depending on proprietary conventions to understand what those values represent. OPC UA Information Modeling addresses this problem by making industrial structure, types and relationships part of the exchanged information.
Semantic interoperability
Information Modeling enables applications to share meaning, not only values.
A numerical value becomes significantly more useful when an application can discover that it represents the speed of a specific motor, that the motor belongs to a particular machine and that the machine is part of a production line.
This semantic context reduces the amount of external knowledge that each consuming application must maintain.
Reusability
Reusable types allow industrial concepts to be defined once and instantiated consistently across machines, production lines and sites.
Standardized models and Companion Specifications extend this principle beyond a single organization by providing common definitions that multiple vendors and applications can understand.
Information modeling therefore moves integration away from repeated point-to-point mappings toward reusable industrial structures.
Decoupling
When semantics are embedded only in tag names, database schemas or application code, consuming systems become tightly coupled to those implementation choices.
A structured Information Model provides a more stable abstraction.
Industrial applications can navigate objects and relationships through the model instead of depending exclusively on proprietary tag structures or physical data organization.
This does not eliminate integration work, but it moves the integration boundary toward a shared semantic representation.
Long-term architecture
Industrial systems typically outlive individual software products, communication technologies and IT platforms.
A well-designed Information Model can provide a stable semantic layer while the technologies around it evolve.
Connectivity protocols can change. Storage systems can be replaced. New analytics, cloud platforms or application interfaces can be introduced. The industrial concepts represented by the model — machines, assets, processes and their relationships — remain comparatively stable.
This is particularly important for model-driven architectures such as OOUAMiddleware, where connectivity through VPI, persistence through VFI and external interfaces can evolve independently around the runtime Information Model.
Interoperability does not stop when two systems can exchange data. It starts when they can understand the same industrial information.
Explore OPC UA Information Modeling with OpenOpcUa
Continue exploring how OpenOpcUa turns Information Models into operational industrial systems, from model engineering and NodeSet generation to dynamic runtime execution.