References

OPC UA enables multiple mesh relationships between Nodes instead of being limited to just a single hierarchy. References are used to relate Nodes to each other. They can be accessed using browsing and querying defined by the services. Like Attributes, they are defined as fundamental components of Nodes.

Reference types are used to create interconnections between Nodes. They are not instantiated, i.e. a NodeClass representing a Reference is not defined. Instead of instantiating the references, they are added to a collection associated with each NodeClass. NodeClass of the Node and its type decide what references are allowed to be added to this collection.

The base of all references is an abstract References type (Figure 1). There is no semantics associated with it.

Figure 1: Standard ReferenceType hierarchy

There are two disjoint sets of standard references:

• HierarchicalReferences

• NonHierarchicalReferences

This distinction reflects two fundamental relationship categories that can be generally distinguished: the association and the dependency. Associations are used to build information architecture – Nodes hierarchy - that can be discovered by the clients using the browsing mechanism. An example of the association is the parent/child relationship. In this case we can say that the target belongs to the source. A dependency from a source element (called the client) to a target element (called the supplier) indicates that the source element uses or depends on the target element. An example of dependency is the Variable/VariableType relationship. In this case we can state that the target describes the source.

HierarchicalReferences do not forbid loops. For example, starting from Node “A” and following HierarchicalReferences may lead to browse to Node “A” again.

HasChild is an abstract type derived from HierarchicalReferences that creates a branch of types, which forbids loops. In this case, starting from Node “A” and only following References, which are subtypes of HasChild, we shall never be able to return to “A”. But it is allowed that there may be more than one path leading to another Node “B”.

The HasChild branch contains HasComponent and HasProperty. Both are derived from the Aggregates type and used to reflect belongs to the relationship. There is also HasSubtype on this branch, but in this case it is used to expose the inheritance hierarchy.

The HasComponent derived from the Aggregates (Figure 1) is defined to build the part-of relationship, i.e. the target Node of HasComponent is a part of the source Node. This type is used to relate Objects, ObjectTypes, Variables and Methods. Table 2 contains the allowed composite Nodes (source) and allowed components as a target of this type of reference. By using this reference, the Variable is defined as a DataVariable.

Figure 2: HasComponent usage scope

The semantics of HasProperty derived from Aggregates (Figure 1) is to identify the properties of a Node. The source Node of this type can be of any NodeClass The target Node shall be a Variable By using the HasProperty, the Variable is de-fined as Property. Since Properties shall not have Properties, a Property shall never be the source Node of a HasProperty reference.

An example of a complex object using the references described above is shown in Figure 3. The ServerType has HasProperty references (double hashed lines) pointing to the ServerArray, NamespaceArray, ServiceLevel and Auditing properties. The ServerStatus is a child variable pointed by a reference of the HasComponent (single hashed line) type. Objects of this type have also components: ServerCapabilities, ServerDiagnostics, VendorServerInfo, ServerRedundancy objects pointed also by a reference of the HasComponent type.

Figure 3: ServerType definition

The HasSubtype is a subtype of the HasChild type. It is worth noting, that inheritance using HasSubtype is represented using the one-to-many (parent/child) relationship. Because new types can be freely derived from the existing ones we cannot enumerate all children in advance - the tree must be built and maintained dynamically during the lifecycle of the Address Space. This means that when a new type is created it is created with a reference to its base (parent), which results in a new subtype being added to the parent.

The Organizes is the next subtype of HierarchicalReferences. The semantics of it is to organize Nodes in the Address Space. It can be used to span multiple hierarchies independent of any hierarchy created with the non-looping Aggregates references. The source Node of references of this type shall be an Object or a View. If it is an Object it should be an Object of the FolderType or one of its subtypes. The target Node of this type can be of any NodeClass.

The types: HasModellingRule, HasModelParent, HasTypeDefinition, HasEncoding, HasDescription, GeneratesEvent belong to the NonHierarchicalReferences branch.