Part 1: Overview and Concepts
| Document number | OPC 10000-1 |
|---|---|
| IEC designation | IEC 62541-1 |
| Colloquially | Part 1 |
| Group | Core |
Part 1 is the map of the standard. It sets out what OPC UA is, defines the vocabulary every other part assumes, and shows how client/server and PubSub fit together. Read it to work out which part actually answers your question, not to implement anything.
What it defines
Scope, terms and abbreviations, and the layered picture the rest of the standard is built on: a transport underneath, a secure channel over it, a session on top of that, a set of services acting on an address space, and an information model describing what is in that address space. It also names the two communication models, client/server and publish/subscribe, and explains how companion specifications sit on top of the core. Nothing in Part 1 tells you what bytes to send; that is Part 6.
Three numbering systems for one document
The same core document has three names. OPC 10000-4, IEC 62541-4 and Part 4 are one thing: the Services part. The publisher's number, the IEC dual-logo number and the colloquial name are interchangeable in conversation but not in a search box. Companion specifications are numbered in entirely different series, so the address-space number tells you nothing about which series a document belongs to: Industrial Automation is OPC 40001-1, Robotics is OPC 40010-1, the ISA-95 common model is OPC 10030, and the Asset Administration Shell mapping is OPC 30270.
Release families and errata levels
Core OPC UA is currently at 1.05.07, with the released nodesets published 2026-07-30. The important reading is that 1.05 is a release family and the fourth digit is an errata and amendment level, not a feature release. Errata levels can add conformance units and change the documentation attached to standard NodeIds, so a product that claims to support 1.05 has told you almost nothing about interoperability. Ask which errata level, and which profiles and facets.
How the parts group
The classic taxonomy splits the core parts into three families: Core parts covering the model, the services and the mappings; access-type parts covering data access, alarms, programs, history and aggregates; and utility parts covering discovery, PubSub, safety, state machines, roles and file transfer. Above those sit the 80-series for UA Field eXchange and the 100-and-above parts that carry information models elevated into the core series.
What it defines
| Concept | What it is |
|---|---|
| OPC 10000-N | The publisher's own document number for core part N. This is the form you will see cited inside nodeset documentation and inside other parts. |
| IEC 62541-N | The IEC dual-logo number for the same document. The IEC track has historically lagged the publisher's own releases, so not every part has a current IEC edition. |
| Part N | The colloquial name, and the one everybody actually says. Safe in conversation, useless in a tender document without a version and a profile alongside it. |
| Release family and errata level | 1.05 is the family; .07 is the errata level within it. Core is at 1.05.07. Two products both claiming 1.05 can differ in conformance units. |
| Client/server model | Connection-oriented, session-based request and response, defined by Parts 4 and 6. This is what UaExpert and every SDK client speaks. |
| Publish/subscribe model | Connectionless, broker-optional message distribution defined by Part 14. Same information model, completely different wire behaviour and security machinery. |
| Companion specification | A domain information model published on top of the core, in its own document series. It adds types, never new services or transports. |
| Profiles and conformance | Part 1 introduces the idea that a product implements a named subset, not the whole standard. Part 7 is where that subset machinery is actually defined. |
Do you need to read it?
Everyone new to OPC UA should read this part once, and almost nobody should read it twice. It matters most to whoever writes or answers a specification: a tender clause saying compliant with IEC 62541 is unenforceable, while a clause naming a part, a version, a profile and a facet is testable. Architects also use it to decide client/server versus PubSub before any code is written.
Traps that trace back to this part
- Supports OPC UA 1.05 is not an interoperability statement. The fourth digit is an errata level and conformance units move between them, so two devices at 1.05.04 and 1.05.07 can disagree about what is mandatory. Always pin the errata level and the claimed facets.
- Companion specification numbers are in a different series entirely. Searching for OPC 10000-40001 finds nothing, because Industrial Automation is OPC 40001-1. The 10000-series and the 40000-series are not one sequence.
- Part 1 is normative but reads as orientation, which leads people to treat it as the specification. Any concrete requirement you need to argue about lives in Parts 3, 4, 6, 7 or 12 - cite those, not Part 1.
Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.