References are defined as instances of ReferenceType Nodes. ReferenceType Nodes are visible in the AddressSpace and are defined using the ReferenceType NodeClass as specified in Table 9. In contrast, a Reference is an inherent part of a Node and no NodeClass is used to represent References.

This standard defines a set of ReferenceTypes provided as an inherent part of the OPC UA Address Space Model. These ReferenceTypes are defined in Clause 7 and their representation in the AddressSpace is defined in OPC 10000-5. Servers may also define ReferenceTypes. In addition, OPC 10000-4 defines NodeManagement Services that allow Clients to add ReferenceTypes to the AddressSpace.

Table 9 – ReferenceType NodeClass

Name	Use	Data Type	Description
Attributes
Base NodeClass Attributes	M	--	Inherited from the Base NodeClass. See 5.2.
IsAbstract	M	Boolean	A boolean Attribute with the following values: TRUEit is an abstract ReferenceType, i.e. no Reference of this type shall exist, only of its subtypes. FALSEit is not an abstract ReferenceType, i.e. References of this type can exist.
Symmetric	M	Boolean	A boolean Attribute with the following values: TRUEthe meaning of the ReferenceType is the same as seen from both the SourceNode and the TargetNode. FALSEthe meaning of the ReferenceType as seen from the TargetNode is the inverse of that as seen from the SourceNode.
InverseName	O	LocalizedText	The inverse name of the Reference, which is the meaning of the ReferenceType as seen from the TargetNode.
References
HasProperty	0..*		Used to identify the Properties (see 5.3.3.2).
HasSubtype	0..*		Used to identify subtypes (see 5.3.3.3).
Standard Properties
NodeVersion	O	String	The NodeVersion Property is used to indicate the version of a Node. The NodeVersion Property is updated each time a Reference is added or deleted to the Node the Property belongs to. Attribute value changes do not cause the NodeVersion to change. Clients may read the NodeVersion Property or subscribe to it to determine when the structure of a Node has changed.

The ReferenceType NodeClass inherits the base Attributes from the Base NodeClass defined in 5.2. The inherited BrowseName Attribute is used to specify the meaning of the ReferenceType as seen from the SourceNode. For example, the ReferenceType with the BrowseName “Contains” is used in References that specify that the SourceNode contains the TargetNode. The inherited DisplayName Attribute contains a translation of the BrowseName.

The BrowseName of a ReferenceType shall be unique in a Server. It is not allowed that two different ReferenceTypes have the same BrowseName.

The IsAbstract Attribute indicates if the ReferenceType is abstract. Abstract ReferenceTypes cannot be instantiated and are used only for organizational reasons, for example to specify some general semantics or constraints that its subtypes inherit.

The Symmetric Attribute is used to indicate whether or not the meaning of the ReferenceType is the same for both the SourceNode and TargetNode.

If a ReferenceType is symmetric, the InverseName Attribute shall be omitted. Examples of symmetric ReferenceTypes are “Connects To” and “Communicates With”. Both imply the same semantic coming from the SourceNode or the TargetNode. Therefore both directions are considered to be forward References.

If the ReferenceType is non-symmetric the InverseName Attribute shall be set. The InverseName Attribute specifies the meaning of the ReferenceType as seen from the TargetNode. Examples of non-symmetric ReferenceTypes include “Contains” and “Contained In”, and “Receives From” and “Sends To”.

Any subtype, either directly or indirectly of a concrete ReferenceType s hall not change the Symmetric Attribute definition of its parent type.

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

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

Figure 15 – Symmetric and Non-Symmetric References

It might not always be possible for Servers to instantiate both forward and inverse References for non-symmetric ReferenceTypes as shown in Figure 15. When they do, the References are referred to as bidirectional. Although not required, it is recommended that all hierarchical References be instantiated as bidirectional to ensure browse connectivity. A bidirectional Reference is 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” Reference to the signal source, without the signal source having the corresponding “Sourced To” inverse References to its signal sinks.

The DisplayName and the InverseName are the only standardised places to indicate the semantic of a ReferenceType. There may be more complex semantics associated with a ReferenceType than 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 Attribute can be used for this purpose. This standard provides a semantic for the ReferenceTypes specified in Clause 7.

A ReferenceType can have constraints restricting its use. For example, it can specify that starting from Node A and only following References of this ReferenceType or 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 ReferenceType can only be used by relating Nodes of some NodeClasses with a defined cardinality is a special constraint of a ReferenceType.

HasSubtype References and HasProperty References are the only ReferenceTypes that may be used with ReferenceType Nodes as SourceNode. ReferenceType Nodes shall not be the SourceNode of other types of References.

HasProperty References are used to identify the Properties of a ReferenceType and shall only refer to Nodes of the Variable NodeClass.

The Property NodeVersion is used to indicate the version of the ReferenceType.

There are no additional Properties defined for ReferenceTypes in this standard. Additional parts this series of standards may define additional Properties for ReferenceTypes.

HasSubtype References are used to define subtypes of ReferenceTypes. It is not required to provide the HasSubtype Reference for the supertype, but it is required that the subtype provides the inverse Reference to 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 InverseName for non-symmetric ReferenceTypes, reflect the specialization.
2. If a ReferenceType specifies 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 NodeClasses can be referenced are also inherited and can only be further restricted. That is, if a ReferenceType “A” is not allowed to relate an Object with an ObjectType, this is also true for its subtypes.
4. A ReferenceType shall have exactly one supertype, except for the References ReferenceType defined in 7.2 as the root type of the ReferenceType hierarchy. The ReferenceType hierarchy does not support multiple inheritances.