Referencesare defined as instances of ReferenceType Nodes. ReferenceType Nodesare visible in the AddressSpaceand are defined using the ReferenceType NodeClassas specified in Table 9. In contrast, a Referenceis an inherent part of a Nodeand no NodeClassis used to represent References.

This standard defines a set of ReferenceTypesprovided as an inherent part of the OPC UAAddress Space Model. These ReferenceTypesare defined in Clause 7and their representation in the AddressSpaceis defined in OPC 10000-5. Serversmay also define ReferenceTypes. In addition, OPC 10000-4defines NodeManagement Servicesthat allow Clientsto add ReferenceTypesto the AddressSpace.

Table 9– ReferenceType NodeClass



Data Type



Base NodeClass Attributes



Inherited from the Base NodeClass. See 5.2.




A boolean Attributewith the following values:

TRUEit is an abstract ReferenceType, i.e. no Referenceof this type shall exist, only of its subtypes.

FALSEit is not an abstract ReferenceType, i.e. Referencesof this type can exist.




A boolean Attributewith the following values:

TRUEthe meaning of the ReferenceTypeis the same as seen from both the SourceNodeand the TargetNode.

FALSEthe meaning of the ReferenceTypeas seen from the TargetNodeis the inverse of that as seen from the SourceNode.




The inverse name of the Reference, which is the meaning of the ReferenceTypeas seen from the TargetNode.




Used to identify the Properties (see



Used to identify subtypes (see

Standard Properties




The NodeVersion Propertyis used to indicate the version of a Node.

The NodeVersion Propertyis updated each time a Referenceis added or deleted to the Nodethe Propertybelongs to. Attributevalue changes do not cause the NodeVersionto change. Clientsmay read the NodeVersion Propertyor subscribe to it to determine when the structure of a Nodehas changed.

The ReferenceType NodeClassinherits the base Attributesfrom the Base NodeClassdefined in 5.2. The inherited BrowseName Attributeis used to specify the meaning of the ReferenceTypeas seen from the SourceNode. For example, the ReferenceTypewith the BrowseName“Contains” is used in Referencesthat specify that the SourceNodecontains the TargetNode. The inherited DisplayName Attributecontains a translation of the BrowseName.

The BrowseNameof a ReferenceTypeshall be unique in a Server. It is not allowed that two different ReferenceTypeshave the same BrowseName.

The IsAbstract Attributeindicates if the ReferenceTypeis abstract. Abstract ReferenceTypescannot be instantiated and are used only for organizational reasons, for example to specify some general semantics or constraints that its subtypes inherit.

The Symmetric Attributeis used to indicate whether or not the meaning of the ReferenceTypeis the same for both the SourceNodeand TargetNode.

If a ReferenceTypeis symmetric, the InverseName Attributeshall be omitted. Examples of symmetric ReferenceTypesare “Connects To” and “Communicates With”. Both imply the same semantic coming from the SourceNodeor the TargetNode. Therefore both directions are considered to be forward References.

If the ReferenceTypeis non-symmetric the InverseName Attributeshall be set. The InverseName Attributespecifies the meaning of the ReferenceTypeas seen from the TargetNode. Examples of non-symmetric ReferenceTypesinclude “Contains” and “Contained In”, and “Receives From” and “Sends To”.

Any subtype, either directly or indirectly of a concreteReferenceType shall not change theSymmetric Attribute definition of its parent type.

Referencesthat use the InverseName, such as “Contained In” References, are referred to as inverse References.

Figure 15provides examples of symmetric and non-symmetric Referencesand the use of the BrowseName and the InverseName.


Figure 15– Symmetric and Non-Symmetric References

It might not always be possible for Serversto instantiate both forward and inverse Referencesfor non-symmetric ReferenceTypesas shown in Figure 15. When they do, the Referencesare referred to as bidirectional. Although not required, it is recommended that all hierarchical Referencesbe instantiated as bidirectional to ensure browse connectivity. A bidirectional Referenceis modelled as two separate References.

As an example of a unidirectional Reference, it is often the case that a signal sink knows its signal source, but this signal source does not know its signal sink. The signal sink would have a “Sourced By” Referenceto the signal source, without the signal source having the corresponding “Sourced To” inverse Referencesto its signal sinks.

The DisplayNameand the InverseNameare the only standardised places to indicate the semantic of a ReferenceType. There may be more complex semantics associated with a ReferenceTypethan can be expressed in those Attributes(e.g. the semantic of HasSubtype). This standard does not specify how this semantic should be exposed. However, the Description Attributecan be used for this purpose. This standard provides a semantic for the ReferenceTypesspecified in Clause 7.

A ReferenceTypecan have constraints restricting its use. For example, it can specify that starting from NodeA and only following Referencesof this ReferenceTypeor one of its subtypes, it shall never be able to return to A, that is, a “No Loop” constraint.

This standard does not specify how those constraints could or should be made available in the AddressSpace. Nevertheless, for the standard ReferenceTypes, some constraints are specified in Clause 7. This standard does not restrict the kind of constraints valid for a ReferenceType. It can, for example, also affect an ObjectType. The restriction that a ReferenceTypecan only be used by relating Nodesof some NodeClasseswith a defined cardinality is a special constraint of a ReferenceType.

HasSubtype Referencesand HasProperty Referencesare the only ReferenceTypesthat may be used with ReferenceType Nodesas SourceNode. ReferenceType Nodesshall not be the SourceNodeof other types of References.

HasProperty Referencesare used to identify the Propertiesof a ReferenceTypeand shall only refer to Nodesof the Variable NodeClass.

The Property NodeVersionis used to indicate the version of the ReferenceType.

There are no additional Propertiesdefined for ReferenceTypesin this standard. Additional parts this series of standards may define additional Propertiesfor ReferenceTypes.

HasSubtype Referencesare used to define subtypes of ReferenceTypes. It is not required to provide the HasSubtype Referencefor the supertype, but it is required that the subtype provides the inverse Referenceto its supertype. The following rules for subtyping apply.

  1. The semantic of a ReferenceType(e.g. “spans a hierarchy”) is inherited to its subtypes and can be refined there (e.g. “spans a special hierarchy”). The DisplayName, and also the InverseNamefor non-symmetric ReferenceTypes, reflect the specialization.
  2. If a ReferenceTypespecifies some constraints (e.g. “allow no loops”) this is inherited and can only be refined (e.g. inheriting “no loops” could be refined as “shall be a tree – only one parent”) but not lowered (e.g. “allow loops”).
  3. The constraints concerning which NodeClassescan be referenced are also inherited and can only be further restricted. That is, if a ReferenceType“A” is not allowed to relate an Objectwith an ObjectType, this is also true for its subtypes.
  4. A ReferenceTypeshall have exactly one supertype, except for the References ReferenceTypedefined in 7.2as the root type of the ReferenceTypehierarchy. The ReferenceTypehierarchy does not support multiple inheritances.