OPC UA

Related classes: opcua:Concept · opcua:Server · opcua:Node · opcua:Object · opcua:Variable · OPCUA_Device · ExtendedProperty · Point

OPC UA is the protocol most PLCs, industrial gateways and many building-automation servers speak. Like BACnet, it is kept as a source layer: an OPC UA server's address space is stored close to OPC UA's own structure, in its own namespace dtmi:mapped:opcua, and linked to the semantic model rather than merged into it. A Supply_Air_Temperature_Sensor stays a Supply_Air_Temperature_Sensor; the fact that it arrived as the Variable AHU_1.SupplyAirTemp on a gateway is recorded next to it. OPC UA nodes never carry Brick classes.

Every class, property and relationship links to the OPC UA specification (OPC 10000, v1.05) section that defines it.

The classes

Class	OPC UA concept	Properties
opcua:Concept	Abstract: the common superclass of every OPC UA class	–
opcua:Server	The server application at one endpoint, the root of the browse tree. Not the standard `Server` Object (`i=2253`)	`opcua:endpointUrl`, `opcua:applicationUri`, `opcua:manufacturerName`, `opcua:productName`, `opcua:softwareVersion`
opcua:Node	Abstract: the attributes every node shares	`opcua:nodeId` (required), `opcua:browseName`, `opcua:typeDefinition`, `opcua:typeDefinitionId`
opcua:Object	An Object node, including folders: a system, a component or a grouping	Those of `opcua:Node`
opcua:Variable	A data Variable: a node that contains a value	Those of `opcua:Node`, plus `opcua:dataType`, `opcua:valueRank`, `opcua:accessLevel`, `opcua:engineeringUnits`, `opcua:euRange`, `opcua:trueState`, `opcua:falseState`, `opcua:enumStrings`, `opcua:enumValues`

opcua:Concept extends Entity. opcua:Server and opcua:Node extend opcua:Concept, and opcua:Object and opcua:Variable extend opcua:Node. A node's DisplayName and Description are stored as name and description.

NodeIds. opcua:nodeId is the deduplication key, in the OPC UA string form with the namespace URI rather than the index: nsu=urn:bms-gw-01:site;s=AHU_1. Namespace 0, the base specification, is the bare identifier (i=58).
Types by name. opcua:typeDefinition and opcua:dataType name the type (AnalogItemType, Double); there are no type vertices. opcua:typeDefinitionId is the type's NodeId, and its nsu= says which companion specification or vendor defines it.
Access. opcua:accessLevel is a list of the AccessLevel bits that are set: CurrentRead, CurrentWrite, HistoryRead, HistoryWrite, SemanticChange, StatusWrite and TimestampWrite.
JSON values. opcua:engineeringUnits is {namespaceUri, unitId, displayName, description, uneceCode}, where uneceCode is the UNECE common code decoded from unitId (CEL). opcua:euRange is {low, high}. opcua:enumStrings is an array of texts whose index is the value; opcua:enumValues is an array of {value, displayName, description}.

Properties that are not modelled

OPC UA Properties (the targets of HasProperty references) are not stored as Variables. The standard Data Access Properties above become modelled properties of the Variable. Every other Property, on an Object or a Variable, becomes an ExtendedProperty attached with hasExtendedProperty: the key is its BrowseName (SerialNumber), the value is JSON, and mappingKey is the Property's NodeId. A vendor structure the connector cannot decode is stored as null, keeping the key.

The address-space tree

Two relationships carry OPC UA's hierarchy, each with its inverse:

Relationship	Inverse	From → To	Meaning
`opcua:organizes`	`opcua:organizedBy`	Server, Object → Object, Variable	Folder-style grouping, with no part-of meaning. Organizes references may form loops
`opcua:hasComponent`	`opcua:componentOf`	Object → Object, Variable; Variable → Variable	Part-of. Never loops

The server stands in for the Objects folder: the folder's children hang off opcua:Server through opcua:organizes. Other OPC UA reference types are written as the nearest of these two: subtypes of Aggregates (other than HasProperty) as opcua:hasComponent, other hierarchical references as opcua:organizes. A node reached from several folders is one vertex with several incoming edges, so anything walking opcua:organizes needs a visited set.

How nodes link to Things and Points

External reference. Point has hasExternalReference targeting opcua:Variable. Thing has it targeting opcua:Server, opcua:Object and opcua:Variable. A Point points at its Variable; the equipment points at its Object; the device that runs the server points at the opcua:Server.
The device. Mapped's OPCUA_Device (a Device) is the box discovered on the network, linked with hasExternalReference → opcua:Server. The equipment the server exposes (the AHU, the pump) is a separate Thing.
Structured Variables. A Variable with component Variables is usually a structure, such as a PLC tag with one member per field. The parent is equipment-like and the components are the points, so a Thing may reference the parent Variable. Make Points of one level only, normally the leaves, or the same value is recorded twice.

From Variable to point class

OPC UA describes a value's shape and access better than BACnet does, but not its meaning. The type and access level narrow the Brick point family; the semantics still need the browse path, the names and the units.

OPC UA signal	Start from	Then decide
`AnalogItemType`, no `CurrentWrite`	Sensor	Which quantity, from `opcua:engineeringUnits`: `CEL` is a temperature, such as Supply_Air_Temperature_Sensor
`AnalogItemType` with `CurrentWrite`	Setpoint or Command	A target (`…_Setpoint`) or a driven output such as Damper_Position_Command
`TwoStateDiscreteType`	Status when read only, Command when written	`opcua:trueState` / `opcua:falseState`: Start/Stop suggests Start_Stop_Command or On_Off_Status; Open/Close suggests a damper or valve
`MultiStateDiscreteType`, `MultiStateValueDiscreteType`	Status or Command	Mode_Status or Mode_Command; `opcua:enumStrings` or `opcua:enumValues` give the states
A Variable with component Variables	A Thing, or nothing	The components are the points
`opcua:typeDefinitionId` in a companion-specification namespace	The matching Brick class	A Pumps `PumpType` Object is a Pump

Practical checks: CurrentWrite in opcua:accessLevel is the commandable signal, the counterpart of BACnet's priority array. opcua:euRange catches scale mismatches (0–100 % against 0–1). Many servers expose every Variable as BaseDataVariableType with no Data Access Properties; there the browse path, the names and opcua:accessLevel carry the signal, and opcua:productName hints at the naming convention to expect.

Example

OPCUA_Device "BMS gateway"       hasExternalReference → opcua:Server "Example OPC UA Gateway"

opcua:Server   organizes →
  opcua:Object "AHU_1" (BaseObjectType)                       ← AHU "AHU-1"
    hasExtendedProperty → ExtendedProperty SerialNumber = "A1-00731"
    hasComponent →
      opcua:Variable "SupplyAirTemp"  AnalogItemType, Double, CurrentRead, CEL      ← Supply_Air_Temperature_Sensor
      opcua:Variable "SupplyFanCmd"   TwoStateDiscreteType, Boolean, CurrentWrite   ← Start_Stop_Command
      opcua:Variable "Mode"           MultiStateDiscreteType, Off/Heat/Cool/Auto    ← Mode_Command

AHU "AHU-1"   hasPoint → each of the three points above

← marks the semantic entity whose hasExternalReference points at the node.

What the data does not say

Methods, Views and type nodes are not stored. Types are names, without their supertypes, so a vendor subtype of AnalogItemType shows only its own name.
Variables hold no live values; those are timeseries on the linked Point.
Events and alarms (HasNotifier, HasEventSource) and peer references (AssociatedWith, the Device Integration ConnectsTo) are not stored.
opcua:accessLevel is a list of strings, not an enum.
Only Points and Things can reference OPC UA nodes: a folder that describes a floor cannot yet be linked from a Place.
Text values are in one locale; the locale itself is dropped.

The classes​

Properties that are not modelled​

The address-space tree​

How nodes link to Things and Points​

From Variable to point class​

Example​

What the data does not say​