Modelling rule

The rule is a node, not a flag

Modelling rules are ordinary Objects in namespace 0, of type ModellingRuleType, each carrying a NamingRule Property. An instance declaration points at one of them with a HasModellingRule reference (i=37). The two you meet constantly are Mandatory (i=78) and Optional (i=80). Because the rule is a node, a client can read it: browse HasModellingRule from a declaration on an ObjectType and you know, before touching a single instance, whether that child is guaranteed.

The placeholder rules

MandatoryPlaceholder and OptionalPlaceholder describe children whose BrowseNames the server chooses. The declaration itself is written with a placeholder name in angle brackets, for example <MachineryItem> or <ToolName>, and it means at least one instance for MandatoryPlaceholder, zero or more for OptionalPlaceholder. This is how a model says a machine has some number of tools without naming them. A client must browse for the children of the placeholder's parent and match on type definition, because TranslateBrowsePathsToNodeIds against the literal angle-bracket name will never resolve.

ExposesItsArray and the rules you will rarely use

ExposesItsArray marks a declaration on an array Variable whose elements are also exposed as individual child nodes, so a client may read the whole array or one element as a node. It is uncommon outside older Data Access models. A declaration with no HasModellingRule reference at all is not instantiated: it exists only as part of the type definition, which is a legitimate modelling choice and an easy accident.

What this means when you write a client

Modelling rules are the contract a companion specification gives you, and the only part of a type you may rely on is the Mandatory part. Build your NodeId resolution so that a missing Optional node degrades a feature instead of failing a connection, and browse rather than translate fixed paths wherever a placeholder rule appears in the model. This is exactly what the umati dashboard client does when it skips instances that lack mandatory nodes.

Example

Modelling rules on an ObjectType and what each produces on an instance

MachineType                                 (ObjectType)
 +- Identification   HasComponent  Mandatory            -> always present
 +- Monitoring       HasComponent  Optional             -> may be absent
 +- <Component>      HasComponent  OptionalPlaceholder  -> 0..n, server names them
 +- <Tool>           HasComponent  MandatoryPlaceholder -> 1..n, server names them

Instance Mixer_01
 +- Identification            present  (Mandatory)
 +- Drive_A                   present  (matched the <Component> placeholder)
 +- Drive_B                   present
 +- Spindle                   present  (matched the <Tool> placeholder)
    (Monitoring absent - legal, it was Optional)

Browse the declaration to read its rule:
  Browse( nodeId = MachineType.Monitoring,
          direction = Forward,
          referenceType = i=37 )   // HasModellingRule
  -> i=80  Optional

Defined in: Part 3 - Address Space Model defines instance declarations, modelling rules and the standard ModellingRule objects.

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.