Mandatory / Optional
In OPC UA, Mandatory and Optional are the two modelling rules that decide whether an instance must carry a declared child node. Mandatory children are guaranteed on every conforming instance; Optional children may simply be absent. A client that assumes an Optional node exists gets BadNodeIdUnknown or BadNoMatch against a perfectly conformant server.
What Mandatory actually guarantees
A Mandatory declaration means the server must create the corresponding node on every instance of the type, with the same BrowseName. That is the whole guarantee. It says nothing about the value being useful: a Mandatory SerialNumber may be an empty string, and a Mandatory state variable may sit at its initial value forever. Mandatory is a structural promise, not a data-quality one.
Optional is the normal case in companion specifications
Most rows in a companion specification's type tables are Optional, because the working group has to cover machines that genuinely differ. In the Machinery building blocks and in MachineTool, large parts of the counters, prognosis and monitoring families are optional, and vendors implement the subset their controller can supply. Two servers can both be fully conformant to the same specification and expose very different node sets.
Handling absence without breaking
The safe pattern is one Browse or one TranslateBrowsePathsToNodeIds pass per instance at startup, recording which optional nodes actually resolved, and building the subscription from that. Translate returns per-path results, so a batch of twenty paths tells you in one round trip which twelve exist. Treat a missing optional node as a disabled feature and log it once; never retry it every publish cycle, and never let it abort the session.
Subtypes may tighten, never loosen
A subtype is allowed to redeclare an inherited Optional child as Mandatory, and vendors do this to promise more than the base model requires. It may not do the reverse. That is why a client should match by type ancestry and then check what is actually present, rather than reasoning from the base specification alone - the instance in front of you may be richer than the standard says.
Example
Probing which optional nodes an instance really has, in one round trip
TranslateBrowsePathsToNodeIds
startingNode = ns=6;s=Line3.MC01
paths:
/4:Identification/4:SerialNumber Mandatory
/4:Identification/4:YearOfConstruction Optional
/4:Production/4:ProductionPlan Optional
/4:Monitoring/4:MachineryItemState Optional
Results
[0] Good -> ns=6;i=41201
[1] Good -> ns=6;i=41207
[2] BadNoMatch -> feature off: no production plan on this machine
[3] Good -> ns=6;i=41310
Build the MonitoredItem list from the Good rows only.Defined in: Part 3 - Address Space Model, modelling rules; Part 7 - Profiles for how conformance units group optional functionality.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.