IM Engineer Study Notes
← Back to list
Networking
#OPC UA#IEC 62541#산업 IoT#OT·IT 통합#정보모델#PubSub#산업 보안
Last updated · 2026-09-30

OPC UA (IEC 62541) for Industrial Data Interoperability

1. Overview

A. Definition

OPC UA (Open Platform Communications Unified Architecture) is a platform-independent industrial communication and information-modeling standard for securely exchanging data and expressing its structure and meaning.

Industrial sites combine PLCs, CNC machines, sensors, SCADA, MES, and ERP from different generations and vendors. They differ in transport, tag names, units, status codes, and equipment hierarchies. Connectivity alone therefore does not guarantee that two systems interpret a value in the same way. OPC UA combines communication specifications with information models to move from signal transfer toward semantic interoperability.

Classic OPC depended heavily on Windows COM/DCOM. This constrained heterogeneous operating systems, firewall traversal, and Internet-scale deployments. OPC UA addresses these limits with operating-system and language-neutral architecture. The same foundation can span embedded devices, plant servers, and cloud systems. Its core is not a single transport protocol. It is an architecture of information models, services, message structures, transport mappings, security, and conformance rules.

B. Background and need

Smart manufacturing must combine equipment, production, quality, and energy data across systems. Custom drivers and point-to-point mappings multiply integration costs during equipment replacement and site expansion. They also increase dependency on individual vendors. OPC UA address spaces and standard services reduce bespoke connection logic and improve data reuse.

Industrial data needs more than a numeric value. It may require an engineering unit, quality state, timestamp, and equipment hierarchy. For example, Temp=72 does not say whether the value is Celsius or Fahrenheit. It also does not identify the sensor or whether the measurement is valid. OPC UA models variables, types, references, and metadata so consumers can discover meaning.

Wider OT connectivity also increases safety and availability risks. Application identity, encryption, signatures, user authorization, and audit functions must align with network design and operating policy. OPC UA adoption is therefore an OT/IT data-architecture and security-governance decision, not just a protocol choice.

2. Standard structure and information model

A. Layered architecture

OPC UA can be understood through its information model, services, message model, transport mappings, security, and conformance framework. This separation allows an information model to remain stable while deployments select a suitable transport. The IEC 62541 series divides the specification into parts for concepts, security, address space, services, information models, mappings, and profiles.

flowchart TB
  A[Enterprise apps: MES·analytics·cloud] --> B[OPC UA Client / Server]
  B --> C[Services: Browse·Read·Write·Subscribe]
  C --> D[AddressSpace: Objects·Variables·Methods·Types]
  D --> E[Information Model·Companion Specification]
  B --> F[SecureChannel·Session·certificates·authorization]
  F --> G[Mappings: UA TCP·HTTPS·PubSub]
  G --> H[PLC·robot·sensor·field gateway]

Applications call standard services to browse the address space, read or change values, and subscribe to notifications. The address space is a graph of nodes and references representing equipment, processes, variables, methods, and types. Transport mappings define how messages travel over a network. This keeps information meaning separate from transport technology.

B. Address space and semantic models

A Node is an information unit in OPC UA. Node classes include Objects, Variables, Methods, and type definitions. A Variable can expose not only its current value but also type, access level, engineering unit, description, quality, and timestamp. Objects and references model plant, line, equipment, and component hierarchies. Consumers can browse this hierarchy rather than depend on a fixed tag list.

A NodeId identifies a node in an address space. A Namespace URI helps prevent model identifiers from different vendors from colliding. A QualifiedName combines a name with its namespace. Reference types express relationships such as composition, typing, and state. Without these identifiers and relationships, applications must guess whether two vendors' Pressure variables mean the same thing.

The base information model supplies general building blocks. A Companion Specification standardizes shared meanings for an industry. Models for machinery, robotics, and process industries can help applications discover and use equipment consistently across vendors. However, implementing a companion model does not automatically align every site. Teams still need to test versions, optional fields, units, and implementation differences. They must govern mappings to the enterprise data dictionary.

C. Model-based information versus tag-based interfaces

Traditional tag interfaces require applications to know tag names and addresses in advance. An equipment-model change may then require application code changes. An information-model consumer can browse node types and references to discover equipment properties and relationships. Integration shifts from point-to-point tag conversion toward applications that interpret standard semantics.

Dimension Tag-centric integration OPC UA information-model integration
Representation Address, tag name, value Types, relationships, metadata
Discovery Separate list and manual mapping Browse and type discovery
Change impact Code changes after address changes Govern model and namespace changes
Semantic consistency Project-specific naming rules Common models and companion specs
Trade-off Simple start, rising integration cost Modeling effort, more reuse

The difference is not merely richer data encoding. It reflects whether an enterprise governs process knowledge as a data contract or depends on equipment-specific details. For a small fixed installation, simple tags may be economical. For multi-site analytics and multi-vendor plants, model-based reuse can be more valuable.

3. Communication models and data flow

A. Client-Server services

In the Client-Server model, a server exposes an address space and services. A client uses services such as Browse, Read, Write, Call, and Subscribe. Browse explores nodes and references. Read retrieves values and metadata. Write and Call request permitted changes or actions. Subscriptions and MonitoredItems notify clients of changes and events. They reduce the need to poll every value repeatedly at short intervals.

A connection typically proceeds through endpoint discovery, security-policy selection, SecureChannel setup, user authentication, session creation, and service requests. The client validates the server certificate. The server also checks whether the client application is trusted. A session provides user and authorization context. A channel protects message confidentiality and integrity.

Client-Server suits configuration, on-demand queries, and bidirectional control. For large-scale one-to-many distribution, direct connections from every consumer to every device can create many sessions and operational overhead. The deployment should choose between Client-Server and PubSub based on latency, delivery guarantees, connection count, and operational controls.

B. PubSub communication

Publish-Subscribe (PubSub) lets a Publisher send data while Subscribers consume datasets of interest. The endpoints need not exchange direct request-response messages. Brokered middleware or brokerless delivery can distribute information to many devices. The OPC UA PubSub message model includes datasets, network messages, publisher identifiers, and security settings.

sequenceDiagram
  participant D as PLC·equipment Publisher
  participant C as OPC UA Client
  participant B as MQTT broker or UDP network
  participant S as analytics Subscriber
  C->>D: Establish secure channel and browse model
  D-->>C: Provide address space and configuration
  D->>B: Publish PubSub NetworkMessage
  B->>S: Deliver according to subscription
  S->>S: Decode, validate, and store dataset

Client-Server and PubSub complement each other. Configuration and model discovery can use Client-Server. High-frequency one-to-many distribution can use PubSub. Industrial networks can lose, delay, or duplicate messages. Consumers should validate sequence, timestamp, quality state, and receive time.

C. Transport and profile selection

OPC UA supports industrial binary transport and web- or message-oriented mappings. Selection depends on device capacity, firewall policy, broker availability, network latency, interoperability tests, and security operations. Broker integration such as OPC UA over MQTT or AMQP can support asynchronous delivery toward enterprise and cloud systems. Small embedded devices may face CPU, memory, and certificate-management constraints.

Multiple profiles and transport options add flexibility. They can also create incompatibilities when products support different combinations. Procurement should specify client/server roles, companion models, security policies, transport profiles, and diagnostics. Conformance testing and actual device-to-device interoperability testing are both necessary.

4. Security and operating design

OPC UA security is not just encryption. It includes application identity, user authorization, certificate lifecycle, network segmentation, and audit trails. Client-Server SecureChannels can sign and encrypt messages. User authentication may use accounts, certificates, or tokens according to deployment policy. Disabling security modes or broadly trusting certificates weakens protection even when the standard supports strong controls.

Certificates require lifecycle management for enrollment, renewal, expiration, revocation, backup, and trust-store updates. Manual distribution becomes error-prone when a plant operates thousands of devices. Automated provisioning and centralized visibility help prevent expiration outages and inappropriate trust. Rotation can disrupt production, so teams should plan overlap, rollback, and expiration alerts.

Authorization follows least privilege and asset criticality. Separate read-only collection identities from configuration and control identities. Place risky Method calls behind operator approval or safety interlocks. Do not grant write access to a system that only collects data. Eliminate shared accounts and default passwords.

For PubSub, design message signing and encryption, security groups, key distribution, and subscriber validation. Broker TLS and message-level protection can address different trust boundaries. Requirements should state which protection is needed at each boundary. Rate limits and resource isolation can mitigate denial of service, malformed messages, replay, and excessive subscriptions.

OT security must account for devices with limited patch windows. Separate plant networks from enterprise networks and control flows through an industrial DMZ gateway. Open only approved paths and destinations. Separate collection data flows from control-command flows. Exercise incident response with logging, time synchronization, backup, and recovery procedures.

5. Comparison and application cases

A. OPC UA, MQTT, and Modbus

Modbus offers simple register reads and writes and broad legacy support. Complex equipment semantics, authentication, and encryption generally require additional controls. MQTT excels at lightweight publish-subscribe delivery and broker ecosystems. Topic and payload meaning still require application contracts. OPC UA combines information modeling and security, but entails more modeling and certificate operations.

Dimension OPC UA MQTT Modbus
Main strength Model, services, security Lightweight asynchronous messaging Simple legacy register integration
Data meaning Types, references, information model Depends on topic and payload contract Address meaning documented separately
Pattern Client-Server and PubSub PubSub Mainly request-response
Main consideration Model, certificates, profile compatibility Broker, topic, schema governance Security controls and address documentation

Plants may combine technologies instead of forcing a single protocol. A Modbus gateway can connect legacy equipment. MQTT can carry enterprise events. OPC UA can expose equipment services and semantic models. Gateways become concentrated points for transformation and security. Their design should cover fault isolation, source preservation, and quality metadata.

B. Hypothetical smart-manufacturing case

Assume a hypothetical plant has 120 CNC and assembly machines. Each machine publishes ten status values per second. With separate tags, names, units, and status codes must be mapped plant by plant. New equipment can require changes to analytics applications. An OPC UA server can model equipment types, variables, units, and quality states. A common equipment model lets MES and analytics subscribers reuse those definitions.

The collection consumer receives read-only permission. A control application uses separate credentials and calls only a restricted Method after operator approval. Rather than send every raw sample to the cloud, an edge gateway can summarize anomalies locally. It can retain raw signals only for intervals needed for quality analysis. This example illustrates a design approach, not a normative throughput target. Actual latency and capacity targets require equipment specifications and process-risk analysis.

C. Energy and building operations

Building systems combine boilers, air handlers, meters, and environmental sensors. These devices may use different protocols and data models. Facility operators can model floors, zones, equipment relationships, and units in an OPC UA address space. Energy analytics can browse the model and aggregate loads. Consistent models and naming across buildings support comparable energy-intensity analysis and equipment anomaly detection.

6. Advanced topic: role in an OT/IT data fabric

OPC UA can extend beyond PLC-to-MES translation. It can act as an edge data contract that carries equipment models into enterprise data platforms. A field gateway may browse address spaces, normalize quality, synchronize time, buffer messages, and enforce access policy. Upper-layer analytics can discover equipment from the model and calculate metrics from shared attributes.

Simply combining industry models does not resolve every semantic conflict. For example, State may mean production, stopped, faulted, or waiting at different sites. Enterprises should connect companion models to a data catalog, unit standards, and asset hierarchy. Business meanings must remain governed.

Large deployments should register model versions and server capability profiles in an asset inventory. Schema changes should pass compatibility tests before reaching production equipment. Running old and new versions in parallel at a gateway can control consumer migration. The cost of duplicate operation, security, and performance must also be assessed.

Performance tests should measure more than average latency. Test collection intervals, concurrent subscriptions, notification bursts, reconnect after network loss, certificate validation, and server restarts. Measure p95/p99 latency and data loss. For control paths, validate worst-case delay and safety interlocks. Do not assume that analytical paths and control paths share the same service level.

Check official catalogues for standard editions at procurement and development time. The IEC catalogue lists IEC 62541-1:2025, Overview and Concepts, as published on 19 December 2025. Other parts can have different editions and revision dates, so verify the current edition and profile for every applicable part.

7. Considerations and implications

A. Govern semantic models

Rich models still fail to interoperate when equipment uses inconsistent properties, units, and quality codes. Define reference models, namespaces, versions, required properties, and data-quality rules as enterprise standards. Include them in supplier contracts.

B. Configure security first

Do not leave defaults in place at a production site. Check certificate trust, user permissions, cryptographic policy, and audit logging before deployment. Separate read-only collection from control. Minimize allowed network paths according to asset criticality.

C. Separate safety and availability

Do not assume ordinary OPC UA communication automatically replaces a functional-safety system or deterministic control. Validate safety functions under their applicable safety standards. Define a safe state and manual operation when communication fails.

D. Test interoperability

A vendor statement of standard support does not guarantee compatibility between actual devices. Include roles, policies, model versions, transport mappings, error handling, and reconnect behavior in procurement and acceptance tests. Use multi-vendor interoperability testing.

E. Operate certificates and keys

Assign clear ownership for device identity and key lifecycle. Automate expiration, revocation, and compromise response. Distinguish individual certificates from plant-wide shared keys. Be able to identify which Publishers and Subscribers are affected by a key compromise.

F. Modernize brownfield sites incrementally

Avoid replacing every PLC and SCADA system at once. Begin with read-oriented gateway connections. Expand only after verifying quality, security, and availability metrics. Record transformation rules, source tags, and possible data loss. Ensure new models do not break existing operating procedures.

G. Professional-engineer roadmap

Step 1: inventory assets, protocols, data flows, and control criticality. Use the findings to define a risk-based scope. Step 2: define models, security profiles, certificate operations, and interoperability tests for priority equipment. Step 3: connect field gateways to enterprise platforms. Validate data quality, operational visibility, and recovery. Step 4: standardize multi-site rollout through model catalogs, change approval, vulnerability management, and certificate lifecycle governance.

A professional engineer should measure outcomes by reusable semantic models, integration-maintenance cost, data trust, and reduced safety and security risk. Connect procurement requirements, architecture, security operations, and test evidence in one traceable governance system.

References

In one line: OPC UA combines secure communication with browseable industrial information models, enabling heterogeneous OT data to interoperate through IEC 62541 Client-Server and PubSub patterns selected for site needs.