OPC UA application engineers should master Parts 1 through 7, with Part 11 added for data access and other specialized parts selected when required; Part 6 is primarily a stack-developer concern [S1][S2].
The IEC 62541 series organizes OPC UA into multiple specification parts, including Parts 1 through 14 and Part 100 for Device Integration.
Core Parts 1–7: Practical Reading Order
Parts 1 through 7 form the working core for OPC UA application architects and integration engineers. Part 1 defines the architecture and vocabulary, Part 2 covers the security model, Part 3 defines the address space, and Part 4 specifies the abstract services that clients and servers exchange [S2][S3].
Part 3 specifies the Address Space Model and the OPC UA meta model, including the building blocks used to expose instance and type information and construct a server address space. Part 6 maps abstract UA Services to concrete wire representations and transport or security mappings, and application architects normally rely on a compliant OPC UA stack rather than implementing these mappings themselves.
Part 7 defines interoperability subsets through Conformance Units and Profiles. A profile must be implemented as a complete set, while each Conformance Unit groups a small, testable set of functions that can be verified with compliance test tools [S2].
Specialized Parts 8–14: Add Them by Function
Parts 8 through 14 and Part 100 address specific capabilities, including automation and control objects, alarms and conditions, programs, access, discovery and global services, aggregates, Pub/Sub, and device integration. The 2015 IEC update added or revised these functional areas alongside the core model and service parts [S4].
Part 8 defines the Automation and Control Objects information model, including automation-device concepts and engineering units. Part 9 defines process alarm and condition-monitoring state machines and event types. Part 10 defines a base state machine for executing, manipulating, and monitoring programs [S2][S4].
Part 14 defines OPC UA Pub/Sub, and the protocol-independent OPC UA architecture supports mappings to communication protocols including TCP/IP, UDP/IP, WebSockets, and AMQP. Choose Pub/Sub when applications need distributed one-to-many distribution, such as high-rate telemetry fan-out, rather than direct request-response interaction.
Client/Server or Pub/Sub: Match the Communication Pattern
OPC UA supports both Client/Server and Publish/Subscribe communication patterns. For an initial connection, the client uses the discovery services to locate the server and its endpoints, then selects an endpoint according to the required security mode.
Client/Server is not the right choice merely because it is the traditional default. Evaluate it when clients need request-response confirmation, targeted queries, or methods, and assess Pub/Sub when the application requires one-to-many distribution without acknowledgements from every recipient.
Security, Discovery, and Identity Requirements
Part 2 defines OPC UA authentication, authorization, confidentiality, and application-level message security, while Part 12 specifies discovery and global services. Assess encryption and discovery separately because confidentiality protects messages, whereas discovery determines how clients locate servers and their available endpoints.
OPC UA provides extensible security profiles covering authentication, authorization, encryption, and checksums, with extensible security key management including X.509 certificates, tokens, and passwords. Security capabilities should be evaluated independently from the discovery configuration that clients use to find available endpoints.
Security scope must be assessed separately from functional interoperability. The IEC 62443 versus IEC 61511 comparison provides a useful boundary because IEC 62541 communication security does not replace functional-safety obligations.
Who Needs Which Part?
Application architects and control integrators need Parts 1 through 5 to understand the architecture, address space, services, and information model. Part 7 specifies Profiles and Conformance Units, while Part 6 specifies mappings for the abstract UA Services.
Stack developers need the full technical depth of Part 6 because it maps abstract services, security mechanisms, and concrete wire transports into binary, XML, and JSON representations. Typical application programmers using a compliant SDK can work through the higher-level API without implementing the specification mapping themselves [S2].
System architects adding distributed telemetry should review Part 14, while administrators evaluating aggregation or device interoperability should check Parts 13 and 100 [S1][S4]. Part 12 is relevant when the design includes discovery and global services.
Procurement and Conformance Checks
A server procurement specification should name the required OPC UA Profiles and companion specifications rather than stating only “OPC UA compliant.” Part 7 specifies Profiles and Conformance Units.
For implementation schedules, EN IEC 62541-1:2026 identifies IEC 62541-1:2025 as its source document and sets a national implementation deadline of 2027-02-28, with conflicting national standards withdrawn by 2029-02-28 [S3].
Constraints and Failure Modes
The largest specification risk is treating OPC UA as a single protocol document. The series has at least 14 numbered parts plus Device Integration in Part 100, so a narrow reading of Parts 1 and 2 leaves the address space, services, profiles, alarms, history, discovery, and Pub/Sub poorly defined [S1][S4].
A second failure mode is requiring Pub/Sub for functions that depend on request-response confirmation, or requiring Client/Server for high-rate fan-out where acknowledgement overhead dominates. A third is specifying security without defining the authentication mode, certificate trust arrangement, transport requirements, and endpoint discovery behavior [S1][S2].
For procurement, trace every functional requirement to a part, profile, or companion specification, then verify the server against the selected Profile set. Also record the transport path, security configuration, data model, and expected client-server or publish-subscribe behavior before commissioning.