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.

image018.png

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.