IEC 62541 · Core

Part 5: Information Model

Document number	OPC 10000-5
IEC designation	IEC 62541-5
Colloquially	Part 5
Group	Core

What it defines

The contents of namespace 0, the namespace whose URI is always http://opcfoundation.org/UA/ and whose index is always 0. That includes the root of every type hierarchy - BaseObjectType, BaseVariableType with BaseDataVariableType and PropertyType beneath it, BaseDataType, and the standard reference types - plus the concrete standard objects a client can rely on finding. The numeric NodeIds in namespace 0 are stable across every server and every version, which is what makes generic tooling possible.

The Server object

Every server exposes a Server object, numeric identifier 2253 in namespace 0. Under it sit NamespaceArray and ServerArray, ServerStatus with the current state and start time, ServerCapabilities including the OperationLimits sub-object and the maximum monitored-item and subscription counts, ServerDiagnostics, and the ServerRedundancy object. A well-written client reads this object first and configures itself from what it finds, instead of hardcoding limits.

Namespaces and metadata

NamespaceArray is the mapping from namespace index to namespace URI, and it is the only correct way to turn a URI into the index you need for a NodeId. Part 5 also defines NamespaceMetadata objects, which carry the model version and publication date of each loaded model - the reliable way to find out that a server is serving version 1.03 of a companion model when your client was written against 1.05.

Standard events and folders

The BaseEventType hierarchy is rooted here, with EventId, EventType, SourceNode, Time, Severity and Message, and with the system, device-failure and audit event subtypes beneath it. The standard folders - Root, Objects, Types, Views, and the type folders under Types - give every server the same skeleton. Each released version of the standard ships namespace 0 as a NodeSet2 XML file alongside a type schema and an identifier CSV.

What it defines

Concept	What it is
Namespace 0	The standard namespace, URI http://opcfoundation.org/UA/, always index 0. Its numeric NodeIds are stable across all servers and all versions.
Server object	Numeric identifier 2253. The self-description entry point: status, capabilities, diagnostics, namespaces, redundancy. Read it before doing anything else.
NamespaceArray	Index-to-URI mapping for the connected server. The only correct source for the namespace index in any NodeId you construct.
ServerCapabilities	Declares maximum browse continuation points, monitored items per subscription, subscriptions per session, and the server profile and capability code arrays.
OperationLimits	Per-service batch caps: MaxNodesPerRead, MaxNodesPerWrite, MaxNodesPerBrowse, MaxMonitoredItemsPerCall and others. Optional, and the reason batching is guesswork on servers that omit them.
ServerStatus	State, current time, start time, build info and a shutdown reason. The state enumeration includes Running, Failed, Suspended and Shutdown, and a client should stop retrying against Shutdown.
ServerDiagnostics	Session, subscription and per-service counters. Disabled by default on most servers because it costs performance and discloses topology.
Base type hierarchy	BaseObjectType, BaseVariableType, BaseDataVariableType, PropertyType, BaseDataType and the standard reference types. Every custom type descends from one of these.
BaseEventType	The root of all events, carrying EventId, EventType, SourceNode, SourceName, Time, ReceiveTime, Severity and Message. Alarm types in Part 9 are subtypes of it.
NamespaceMetadata	Per-namespace model version and publication date. The honest way to answer which version of a companion model a server actually implements.

Do you need to read it?

Client developers, because self-description through the Server object is what separates a client that survives a server upgrade from one that does not. Modellers need the base type hierarchy, since every type they define descends from it. Anyone diagnosing throughput problems should read ServerCapabilities and OperationLimits before touching subscription parameters.

Traps that trace back to this part

• OperationLimits are optional. When a server omits them, a client has no idea whether a batch of five thousand reads is welcome or will come back as BadTooManyOperations, and tools fall back to arbitrary internal defaults that are sometimes wildly wrong. Read the limits, and where they are missing, ramp batch sizes up rather than starting large.
• A missing or zero MaxMonitoredItemsPerSubscription is not the same as unlimited, but clients treat it that way - some default to tens of thousands. On a small embedded server this produces BadTooManyMonitoredItems partway through a create call, leaving a subscription that is half-populated and looks fine.
• NamespaceMetadata is how you learn a server's real model version, and plenty of servers do not populate it. Where it is absent, the model version is unknowable from the wire and has to be confirmed with the vendor rather than inferred from the presence of a type.
• Turning ServerDiagnostics on for a debugging session and forgetting to turn it off leaves a permanent performance cost and an information-disclosure surface exposing session and client details to anyone who can browse.

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.