Click or drag to resize

ReferenceType Node Class

Home

References are defined as instances of ReferenceType nodes. ReferenceType nodes are visible in the Address Space and are defined using the ReferenceType node class. In contrast, a reference instance is an inherent part of a node and no node class is used to represent references.

This topic contains the following sections:

The OPC Unified Architecture specification defines a set of reference types provided as an inherent part of the OPC Unified ArchitectureAddress Space model. These reference types are defined in Standard Reference Types section and their representation in the Address Space is described in section Services. Servers may also define reference types. In addition, section Services describes NodeManagement services that allow clients to add reference types to the Address Space.

Attributes

The ReferenceType node class inherits the base attributes from the Basenode class. The inherited BrowseName attribute is used to specify the meaning of the ReferenceType as seen from the source node. For example, the ReferenceType with the BrowseName “Contains” is used in references that specify that the source node contains the target node.

The inherited DisplayName attribute contains a translation of the BrowseName.

Note Note

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

The IsAbstract attribute indicates if the ReferenceType is abstract. Abstract ReferenceTypes can not be instantiated and are used only for organizational reasons, e.g. to specify some general semantics or constrains that are inherited to its subtypes.

The Symmetric attribute is used to indicate whether or not the meaning of the reference type is the same for both the source and target nodes.

If a reference type is symmetric, the InverseName attribute shall be omitted. Examples of symmetric reference types are “Connects To” and “Communicates With”. Both imply the same semantic coming from the source node or the target node.

If the ReferenceType is non-symmetric and not abstract, the InverseName attribute shall be set. The optional InverseName attribute of LocalizedText ia a inverse name of the reference, i.e. the meaning of the type as seen from the target node. Examples of non-symmetric reference types include “Contains” and “Contained In”, and “Receives From” and “Sends To”.

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

Figure 1 provides examples of symmetric and non-symmetric references and the use of the BrowseName and the InverseName attributes.

Symmetric and Non-Symmetric References
Figure 1: Symmetric and Non-Symmetric References

It might not always be possible for servers to instantiate both forward and inverse references for non-symmetric reference types as shown in this figure. 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 subscriber knows its publisher, but its publisher does not know its subscribers. The subscriber would have a “Subscribes To” reference to the publisher, without the publisher having the corresponding “Publishes To” inverse references to its subscribers.

The DisplayName and the InverseName attributes are the only standardised places to indicate the semantic of a reference type. There may be more complex semantics associated with a reference type than can be expressed in those attributes (e.g. the semantic of HasSubtype). The OPC Unified Architecture specification does not specify how this semantic should be exposed. However, the Description attribute can be used for this purpose. The OPC Unified Architecture specification does provide a semantic for the reference types specified in Standard Reference Types section.

A reference type 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 shall never be able to return to A, that is, a “No Loop” constraint.

The OPC Unified Architecture specification does not specify how those constraints could or should be made available in the Address Space. Nevertheless, for the standard reference types some constraints are specified in Standard ReferenceTypes section. The OPC Unified Architecture specification 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 relating nodes of some node classes with a defined cardinality is a special constraint of a ReferenceType.

References

This section contains the following subsections:

HasSubtype references and HasProperty references are the only reference types that may be used with ReferenceType nodes as source node. ReferenceType nodes shall not be the source node of other types of references.

HasProperty

HasProperty references are used to identify the properties and shall only refer to nodes of the Variablenode class.

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

Additional properties for reference types may be defined.

HasSubtype

HasSubtype references are used to define subtypes of reference types. 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 attributes for non-symmetric reference types, 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 node classes 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 reference tpe shall have exactly one supertype, except for the References as the root type of the reference types hierarchy. The reference type hierarchy does not support multiple inheritance.

See Also