{"data":{"slug":"opc-ua-information-model-design","title":"Designing OPC UA Information Models","summary":"The OPC UA information model is what makes OPC UA far more than a data transport.","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-information-model-design","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-information-model-design.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-information-model-design","published":"2026-08-06T12:26:37+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":965,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-information-model-design-ce767593b5d6.png","html":"

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.

\"A
A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do. View full size
\n\n

Core Building Blocks

\n\n

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

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n
Node classPurposeExample
ObjectRepresents a physical or logical entitya pump, a line, a tank
VariableHolds a value with data type, quality, timestamppump speed, tank level, line status
MethodAn invocable operation with input/output argumentsstart pump, reset alarm
ObjectTypeTemplate defining the structure of objectsPumpType with variables and methods
VariableTypeTemplate for variables (incl. data type and units)AnalogItemType (EU range, engineering units)
DataTypeDefines structured data typesDiagnosticStatus (struct)
ViewA filtered subset of the address space\"Operators\", \"Maintenance\"
\n\n

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.

\n\n

Start from the Standards

\n\n

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:

\n\n\n\n

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.

\n\n

Design Process

\n\n

1. Define the purpose and audience

\n\n

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.

\n\n

2. Identify the objects

\n\n

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.

\n\n

3. Define types, then instantiate

\n\n

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

\n\n\n\n

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.

\n\n

4. Choose data types carefully

\n\n

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.

\n\n

5. Model relationships

\n\n

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.

\n\n

6. Plan for events and alarms

\n\n

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.

\n\n

7. Version and document

\n\n

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.

\n\n

Practical Example: a Simple Line Model

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

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.

\n\n

Summary

\n\n

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.

Apply this to your project

Follow an ASP project guide to connect the fundamentals with implementation and acceptance.

\"Engineering
Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration. View full size

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.

","markdown":"# Designing OPC UA Information Models\n\n> The OPC UA information model is what makes OPC UA far more than a data transport.\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/opc-ua-information-model-design\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: OPC Solutions\n- Published: 2026-08-06 · Updated: 2026-09-13\n- Reading time: 5 min · Language: English\n\nThe **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.\n\n![A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg)\n\n*A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.*\n\n## Core Building Blocks\n\nEvery UA address space is built from **nodes** connected by **references**.\n\n| Node class | Purpose | Example |\n| --- | --- | --- |\n| Object | Represents a physical or logical entity | a pump, a line, a tank |\n| Variable | Holds a value with data type, quality, timestamp | pump speed, tank level, line status |\n| Method | An invocable operation with input/output arguments | start pump, reset alarm |\n| ObjectType | Template defining the structure of objects | PumpType with variables and methods |\n| VariableType | Template for variables (incl. data type and units) | AnalogItemType (EU range, engineering units) |\n| DataType | Defines structured data types | DiagnosticStatus (struct) |\n| View | A filtered subset of the address space | \"Operators\", \"Maintenance\" |\n\nReferences 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.\n\n## Start from the Standards\n\nBefore 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:\n\n- **OPC 10000-100** — devices (field devices, general device model)\n- **OPC UA for PLCopen** — mapping IEC 61131-3 data into UA\n- **OPC UA for ISA-95 / MES** — job orders, equipment, materials\n- **OPC UA for Analytics, Machine Vision, PackML (PackML companion), DI (device integration)**\n- **Industry-specific ones** : energy (OPC UA for Energy), robotics (OPC UA for Robotics), CNC (Umati / OPC UA for MachineTools)\n\nIf 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.\n\n## Design Process\n\n### 1. Define the purpose and audience\n\nWho 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.\n\n### 2. Identify the objects\n\nList 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.\n\n### 3. Define types, then instantiate\n\nFor each object family, create an ObjectType with its variables and methods. For example, a **PumpType** might contain:\n\n- Variables: Speed (AnalogItemType, RPM), Running (Boolean), Current (AnalogItemType, A), RunHours (AnalogItemType, h)\n- Methods: Start(), Stop(), ResetFault()\n- Properties: SerialNumber, Model, InstallationDate\n\nThen 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.\n\n### 4. Choose data types carefully\n\nUse 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.\n\n### 5. Model relationships\n\nConnect 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.\n\n### 6. Plan for events and alarms\n\nIf 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.\n\n### 7. Version and document\n\nInformation 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.\n\n## Practical Example: a Simple Line Model\n\n```\nLine_1 (Object, LineType)\n├── Speed (AnalogItemType, m/min)\n├── State (Variable, LineState enum)\n├── TotalCount (Variable, UInt32)\n├── RejectCount (Variable, UInt32)\n├── Machines (Organizes)\n│ ├── Filler_1 (FillerType)\n│ │ ├── Running (Boolean)\n│ │ ├── Level (AnalogItemType, %)\n│ │ └── Start() / Stop()\n│ └── Capper_1 (CapperType)\n│ ├── Torque (AnalogItemType, Nm)\n│ └── FaultCode (Variable, UInt16)\n└── Alarms (Organizes)\n ├── LineStopped (Event)\n └── RejectRateHigh (Event)\n```\n\nThis 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.\n\n## Summary\n\nAn 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.\n\n## Apply this to your project\n\n- Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.\n- Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.\n- Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n![Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg)\n\n*Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [OPC Foundation — OPC UA Part 4: Services](https://reference.opcfoundation.org/specs/OPC-10000-4/)\n- [OPC Foundation — OPC UA Part 2: Security Model](https://reference.opcfoundation.org/specs/OPC-10000-2/)\n\n---\n\nCite the canonical article: https://wiki.aspotomasyon.com/article/opc-ua-information-model-design (Designing OPC UA Information Models, ASP OTOMASYON, updated 2026-09-13).\n","headings":[{"id":"core-building-blocks","title":"Core Building Blocks"},{"id":"start-from-the-standards","title":"Start from the Standards"},{"id":"design-process","title":"Design Process"},{"id":"practical-example-a-simple-line-model","title":"Practical Example: a Simple Line Model"},{"id":"summary","title":"Summary"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"OPC Foundation — OPC UA Part 4: Services","url":"https://reference.opcfoundation.org/specs/OPC-10000-4/"},{"name":"OPC Foundation — OPC UA Part 2: Security Model","url":"https://reference.opcfoundation.org/specs/OPC-10000-2/"}],"related":[{"slug":"iso-22400-manufacturing-kpis","title":"ISO 22400 Manufacturing KPIs: Definitions, Time Models, and OEE","summary":"Two sites can report the same OEE and mean different things, so a standard vocabulary, formulas, and time model must be fixed before any comparison is made.","category":{"slug":"digital-transformation","name":"Digital Transformation"},"url":"https://wiki.aspotomasyon.com/article/iso-22400-manufacturing-kpis","markdown_url":"https://wiki.aspotomasyon.com/article/iso-22400-manufacturing-kpis.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/iso-22400-manufacturing-kpis","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":9,"word_count":1833,"image":"https://wiki.aspotomasyon.com/assets/social/iso-22400-manufacturing-kpis-db5807fb3c80.png"},{"slug":"io-link-smart-sensor-communication","title":"IO-Link: Smart Sensor Communication","summary":"IO-Link (IEC 61131-9) is the standard for communicating with smart sensors and actuators at the field level.","category":{"slug":"modern-connectivity","name":"Modern Connectivity"},"url":"https://wiki.aspotomasyon.com/article/io-link-smart-sensor-communication","markdown_url":"https://wiki.aspotomasyon.com/article/io-link-smart-sensor-communication.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/io-link-smart-sensor-communication","published":"2026-08-06T12:26:37+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":875,"image":"https://wiki.aspotomasyon.com/assets/social/io-link-smart-sensor-communication-230585d0ebd3.png"},{"slug":"pharmaceutical-automation-gmp-pat","title":"Pharmaceutical Manufacturing Automation and PAT","summary":"Pharmaceutical manufacturing is automation's most demanding domain: the product is invisible, the process is validated, and every batch carries regulatory…","category":{"slug":"process-industries-solutions","name":"Process Industries Solutions"},"url":"https://wiki.aspotomasyon.com/article/pharmaceutical-automation-gmp-pat","markdown_url":"https://wiki.aspotomasyon.com/article/pharmaceutical-automation-gmp-pat.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/pharmaceutical-automation-gmp-pat","published":"2026-08-11T13:05:24+00:00","modified":"2026-09-13T16:44:25+00:00","reading_minutes":4,"word_count":827,"image":"https://wiki.aspotomasyon.com/assets/social/pharmaceutical-automation-gmp-pat-68c28e1295ba.png"},{"slug":"opc-ua-companion-specifications","title":"OPC UA Companion Specifications — Industry-Specific Information Models","summary":"OPC UA Companion Specifications define standardized information models for specific industries and application domains.","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-companion-specifications","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-companion-specifications.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-companion-specifications","published":"2026-05-13T11:58:29+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":1095,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-companion-specifications-40cb237797f5.png"}],"citation":"ASP OTOMASYON. Designing OPC UA Information Models. Updated 2026-09-13. https://wiki.aspotomasyon.com/article/opc-ua-information-model-design"}}