The following Figure 1 gives an overview of the ReferenceTypes defined in the following subsections.
Figure 1 – Overview of ReferenceTypes
This ReferenceType can be used to expose the relation between a software component and its execution environment. For example, it can be used to expose which firmware (including its version) is available on a field device.
The IsExecutableOn is a concrete ReferenceType and can be used directly. It is a subtype of NonHierarchicalReferences.
The semantic of this ReferenceType is to relate a software component to its execution environment that the software needs to run (e.g. Hardware component, Task or Thread). The relationship shows that the execution environment the reference points to, is able to execute the software component. This does not imply that the software component is currently being executed or running. To show that the software is running in an environment, IsExecutingOn should be used.
The SourceNode of References of this ReferenceType shall be an Object or ObjectType representing a software component.
The TargetNode of References of this ReferenceType shall be an Object or ObjectType representing an execution environment for a software component, which might be a piece of hardware (e.g. Device) or some other environment like a task, thread or software execution framework.
IsExecutableOn is formally defined in Table 1.
Table 1 – IsExecutableOn Definition
|
Attributes |
Value |
||
|
BrowseName |
IsExecutableOn |
||
|
InverseName |
CanExecute |
||
|
Symmetric |
FALSE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of NonHierarchicalReferences defined in OPC 10000-5 |
|||
|
Conformance Units |
|||
|
Base Info IsExecutableOn |
|||
This ReferenceType can be used to expose the relation between a software component and its execution environment it is currently executing on. References of this ReferenceType might be very dynamic and need to disappear as soon, as the software component is not being executed anymore. For example, it can be used to expose that a PLC program is currently running on a specific task of a PLC.
The IsExecutingOn is a concrete ReferenceType and can be used directly. It is a subtype of Utilizes.
The semantic of this ReferenceType is to relate a software component to its execution environment it is currently executing on (e.g. Hardware component, Task or Thread). References of this ReferenceType shall only be used when the software component is currently executed / running.
The SourceNode of References of this ReferenceType shall be an Object or ObjectType representing a software component.
The TargetNode of References of this ReferenceType shall be an Object or ObjectType representing an execution environment for a software component, which might be a piece of hardware (e.g. Device) or some other environment like a task, thread or software execution framework.
IsExecutingOn is formally defined in Table 2.
Table 2 – IsExecutingOn Definition
|
Attributes |
Value |
||
|
BrowseName |
IsExecutingOn |
||
|
InverseName |
Executes |
||
|
Symmetric |
FALSE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of Utilizes defined in 4.5 |
|||
|
Conformance Units |
|||
|
Base Info IsExecutingOn |
|||
This ReferenceType can be used to expose the relation between an object controlling other objects and the controlled objects. For example, it can be used to relate a PLC to the field devices or machine-modules controlled by the PLC or a software component to the hardware components controlled by the software component.
The Controls is a concrete ReferenceType and can be used directly. It is a subtype of HierarchicalReferences.
The semantic of this ReferenceType is to relate the controlling component to the components controlled by the controlling component.
The SourceNode of References of this ReferenceType shall be an Object or ObjectType representing the controlling component, as for example a PLC or a software component.
The TargetNode of References of this ReferenceType shall be an Object representing a component that is controlled by the TargetNode.
Controls is formally defined in Table 3.
|
Attributes |
Value |
||
|
BrowseName |
Controls |
||
|
InverseName |
IsControlledBy |
||
|
Symmetric |
FALSE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of HierarchicalReferences defined in OPC 10000-5 |
|||
|
Conformance Units |
|||
|
Base Info Controls |
|||
This ReferenceType can be used to expose the relation between a component to other components, that the component needs in order to work. In contrast to the Requires ReferenceType, this non-hierarchical ReferenceType allows loops, e.g. both components need each other in order to work. In that case, there would be two References, the first one pointing from one component to the other, and the second one vice versa. For example, a fan in a PC needs the power supply in order to work and the power supply needs the cooling from the fan, that it is not overheating. An example of a non-looping usage is that a robot utilizes a vision system in order to get the position where to grab something.
The Utilizes is a concrete ReferenceType and can be used directly. It is a subtype of NonHierarchicalReferences.
The semantic of this ReferenceType is to relate a component to other components that are needed by the component in order to work.
The SourceNode of References of this ReferenceType shall be an Object or ObjectType representing a component that utilizes the TargetNode in order to work.
The TargetNode of References of this ReferenceType shall be an Object or ObjectType representing the required component.
Requires is formally defined in Table 4.
|
Attributes |
Value |
||
|
BrowseName |
Utilizes |
||
|
InverseName |
IsUtilizedBy |
||
|
Symmetric |
FALSE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of NonHierarchicalReferences defined in OPC 10000-5 |
|||
|
Conformance Units |
|||
|
Base Info Utilizes |
|||
This ReferenceType can be used to expose the relation between a component to other components, that the component requires in order to work. In contrast to the HasComponent ReferenceType, the related components are not considered to be subcomponents of the component. In contrast to the Utilizes ReferenceType, this hierarchical ReferenceType exposes a non-looping hierarchy of dependencies.
For example, it can be used to relate an axis of a motion device to its required powertrains or a software component to other software components required to execute the software component, like for example libraries.
The Requires is a concrete ReferenceType and can be used directly. It is a subtype of HierarchicalReferences.
The semantic of this ReferenceType is to relate a component to other components it requires in order to work.
The SourceNode of References of this ReferenceType shall be an Object or ObjectType representing a component that requires the TargetNode in order to work.
The TargetNode of References of this ReferenceType shall be an Object representing the required component used by the SourceNode.
Requires References shall not lead to loops, that is, starting from Node “A” and only following References of ReferenceType Requires or subtypes it shall never be possible to return to “A”. But it is allowed that following the References there may be more than one path leading to another Node “B”.
Requires is formally defined in Table 5.
|
Attributes |
Value |
||
|
BrowseName |
Requires |
||
|
InverseName |
IsRequiredBy |
||
|
Symmetric |
FALSE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of HierarchicalReferences defined in OPC 10000-5 |
|||
|
Conformance Units |
|||
|
Base Info Requires |
|||
This ReferenceType can be used to expose the relation between two hardware components which are mounted or mechanically linked or connected to each other, without one component being a subcomponent of the other component. If one component is considered to be a subcomponent, the HasAttachedComponent ReferenceType should be used. For example, it can be used to relate a motor to a gear.
The IsPhysicallyConnectedTo is a concrete ReferenceType and can be used directly. It is a subtype of NonHierarchicalReferences. It is a symmetric Reference, that is, it provides the same semantic in both directions.
The semantic of this ReferenceType is to connect two hard components that are physically connected, without one being a subcomponent of the other.
The SourceNode of References of this type shall be an Object or ObjectType representing a piece of hardware.
The TargetNode of this ReferenceType shall be an Object representing a piece of hardware.
IsPhysicallyConnectedTo is formally defined in Table 6.
Table 6 – IsPhysicallyConnectedTo Definition
|
Attributes |
Value |
||
|
BrowseName |
IsPhysicallyConnectedTo |
||
|
InverseName |
- |
||
|
Symmetric |
TRUE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of NonHierarchicalReferences defined in OPC 10000-5 |
|||
|
Conformance Units |
|||
|
Base Info IsPhysicallyConnectedTo |
|||
This ReferenceType can be used to expose that two different Nodes in the AddressSpace representing the same entity in the real world. Both Nodes might represent different aspects of the same entity in the same world, or model the same aspect in different ways, for example defined in different companion specifications. For example, an ethernet port of a network module might be represented as an Object of an ObjectType defined by one companion specification focusing on the PROFINET relevant information for such a port and by another Object providing a more generic Ethernet and IP focused view on the port defined by an ObjectType in another companion specification. Both Objects may have distinguished information, but also provide some common information like the IP address, potentially in different data formats.
If a Server exposes more than two Nodes representing the same entity, it is recommended that all of the Nodes reference each other. A Client should not rely on all Nodes being mutually referenced to each other; i.e., the Client should browse each of the Nodes checking for additional RepresentsSameEntityAs References.
The RepresentsSameEntityAs is a concrete ReferenceType and can be used directly. It is a subtype of NonHierarchicalReferences. It is a symmetric Reference, that is, it provides the same semantic in both directions.
The semantic of this ReferenceType is to relate two Nodes that represent the same entity in the real world.
The SourceNode of References of this ReferenceType can be of any NodeClass.
The TargetNode of References of this ReferenceType can be of any NodeClass.
Both, SourceNode and TargetNode shall represent the same entity in the real world.
RepresentsSameEntityAs is formally defined in Table 7.
Table 7 – RepresentsSameEntityAs Definition
|
Attributes |
Value |
||
|
BrowseName |
RepresentsSameEntityAs |
||
|
InverseName |
- |
||
|
Symmetric |
TRUE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of NonHierarchicalReferences defined in OPC 10000-5 |
|||
|
Conformance Units |
|||
|
Base Info RepresentsSameEntityAs |
|||
This ReferenceType can be used to expose that two different Nodes in the AddressSpace representing the same hardware. It refines the RepresentsSameEntityAs ReferenceType and defines that the same entity in the real world shall be a piece of hardware. For example, it can be used to relate an Object representing a RFID reader based on the AutoID companion specification [1] with an Object representing the same RFID reader based on the IO-Link companion specification [2].
Note: The example given above is special since both specification use OPC UA Part 100 Devices [3] as base. In this case, the preferred modelling approach is provided in an annex of Part 100, where a composition approach is used.
The RepresentsSameHardwareAs is a concrete ReferenceType and can be used directly. It is a subtype of HierarchicalReferences. It is a symmetric Reference, that is, it provides the same semantic in both directions
The semantic of this ReferenceType is to relate two Nodes that represent the same hardware.
The SourceNode of References of this ReferenceType can be of any NodeClass.
The TargetNode of References of this ReferenceType can be of any NodeClass.
Both, SourceNode and TargetNode shall represent the same entity in the real world.
RepresentsSameHardwareAs is formally defined in Table 8.
Table 8 – RepresentsSameHardwareAs Definition
|
Attributes |
Value |
||
|
BrowseName |
RepresentsSameHardwareAs |
||
|
InverseName |
- |
||
|
Symmetric |
TRUE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of RepresentsSameEntityAs defined in 4.8 |
|||
|
Conformance Units |
|||
|
Base Info RepresentsSameHardwareAs |
|||
This ReferenceType can be used to expose that two different Nodes in the AddressSpace representing the same functionality. It refines the RepresentsSameEntityAs ReferenceType and defines that the same entity in the real world shall be a functionality. For example, the functionality to move an axis might be provided by an Object representing a function block of a PLC with that functionality, but also be an Object representing the functionality of a drive. The ReferenceType can be used to related both Objects.
The RepresentsSameFunctionalityAs is a concrete ReferenceType and can be used directly. It is a subtype of HierarchicalReferences. It is a symmetric Reference, that is, it provides the same semantic in both directions.
The semantic of this ReferenceType is to relate two Nodes that represent the same functionality.
The SourceNode of References of this ReferenceType can be of any NodeClass.
The TargetNode of References of this ReferenceType can be of any NodeClass.
Both, SourceNode and TargetNode shall represent the same functionality.
RepresentsSameFunctionalityAs is formally defined in Table 9.
Table 9 – RepresentsSameFunctionalityAs Definition
|
Attributes |
Value |
||
|
BrowseName |
RepresentsSameFunctionalityAs |
||
|
InverseName |
- |
||
|
Symmetric |
TRUE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of RepresentsSameEntityAs defined in 4.8 |
|||
|
Conformance Units |
|||
|
Base Info RepresentsSameFunctionalityAs |
|||
This ReferenceType can be used to expose the relation between an Object representing some functionality and an Object representing some environment (e.g. hard- or software) which is necessary to execute and run the functionality. This implies that a malfunction in a referred environment or a missing related environment results in a non-functional functionality. A functionality Object might relate to several environment Objects, in that case all environment Objects are necessary to execute and run the functionality. An environment Object might be referenced by several functionality Objects.
For example, the functionality to move an axis is hosted by the drive moving the axis. Another example is some analog input functionality, which is related to the IO-module and the related firmware.
The IsHostedBy is a concrete ReferenceType and can be used directly. It is a subtype of Utilizes.
The semantic of this ReferenceType is to relate functionality represented by an OPC UA Node to the hard- and software needed to provide the functionality.
The SourceNode of References of this ReferenceType shall be an Object or ObjectType representing some functionality.
The TargetNode of References of this ReferenceType shall be an Object or ObjectType representing some hard- or software.
IsHostedBy is formally defined in Table 10.
Table 10 – IsHostedBy Definition
|
Attributes |
Value |
||
|
BrowseName |
IsHostedBy |
||
|
InverseName |
Hosts |
||
|
Symmetric |
FALSE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of Utilizes defined in 4.5 |
|||
|
Conformance Units |
|||
|
Base Info IsHostedBy |
|||
This ReferenceType can be used to expose the relation between a hardware component and its subcomponent. An example for this reference is a modular IO-Station which is composed out of a device head and multiple IO-Modules or it can be used to relate a PC to a PCI board plugged inside the PC.
The HasPhysicalComponent is a concrete ReferenceType and can be used directly. It is a subtype of HasComponent.
The semantic of this ReferenceType is to relate a hardware component to its subcomponent, which is also a hardware component.
The SourceNode of References of this ReferenceType shall be an Object or ObjectType representing a piece of hardware.
The TargetNode of References of this ReferenceType shall be an Object representing a piece of hardware that is a component of the SourceNode.
HasPhysicalComponent is formally defined in Table 11.
Table 11 – HasPhysicalComponent Definition
|
Attributes |
Value |
||
|
BrowseName |
HasPhysicalComponent |
||
|
InverseName |
PhysicalComponentOf |
||
|
Symmetric |
FALSE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of HasComponent defined in OPC 10000-5 |
|||
|
Conformance Units |
|||
|
Base Info HasPhysicalComponent |
|||
This ReferenceType can be used to expose the relation between a hardware component and its subcomponent. It indicates that the subcomponent is inside the component. To gain access to the subcomponent typically removing a part of the component (e.g. a hatch) is necessary. For example, it can be used to relate a PC to a PCI board plugged inside the PC. The PCI board is accessible after removing the PC housing. It can also be used to relate a PLC to its CPU, which is hard wired to the PLC, or a network module to its Ethernet PHYs.
The HasContainedComponent is a concrete ReferenceType and can be used directly. It is a subtype of HasPhysicalComponent.
The semantic of this ReferenceType is to relate a hardware component to its subcomponent that is inside the component.
The SourceNode of References of this ReferenceType shall be an Object or ObjectType representing a piece of hardware.
The TargetNode of References of this ReferenceType shall be an Object representing a piece of hardware that is a component of the SourceNode.
HasContainedComponent is formally defined in Table 12.
Table 12 – HasContainedComponent Definition
|
Attributes |
Value |
||
|
BrowseName |
HasContainedComponent |
||
|
InverseName |
ContainedComponentOf |
||
|
Symmetric |
FALSE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of HasPhysicalComponent defined in 4.12 |
|||
|
Conformance Units |
|||
|
Base Info HasContainedComponent |
|||
This ReferenceType can be used to expose the relation between a hardware component and its subcomponent. It indicates that the subcomponent is attached to the component. That implies that the subcomponent is located in direct contact or direct vicinity of the component and is visible from the outside of the component without removing parts of the component (like a hatch). For example, it can be used to relate a drive device or a modular IO-station which is composed out of a device head and multiple IO-modules attached to the head to such an IO-module like a fieldbus interface module. Another example is a laptop having a removable battery attached to it.
The HasAttachedComponent is a concrete ReferenceType and can be used directly. It is a subtype of HasPhysicalComponent.
The semantic of this ReferenceType is to relate a hardware component to its subcomponent that is attached to the component.
The SourceNode of References of this ReferenceType shall be an Object or ObjectType representing a piece of hardware.
The TargetNode of References of this ReferenceType shall be an Object representing a piece of hardware that is a component of the SourceNode.
HasAttachedComponent is formally defined in Table 13.
Table 13 – HasAttachedComponent Definition
|
Attributes |
Value |
||
|
BrowseName |
HasAttachedComponent |
||
|
InverseName |
AttachedComponentOf |
||
|
Symmetric |
FALSE |
||
|
IsAbstract |
FALSE |
||
|
References |
NodeClass |
BrowseName |
Comment |
|
Subtype of HasPhysicalComponent defined in 4.12 |
|||
|
Conformance Units |
|||
|
Base Info HasAttachedComponent |
|||