Clause 5 introduces References, the ProtocolType, and basic TopologyElementTypes needed to create a communication topology. The types for this model are illustrated in Figure 16.
Figure 16 – Device communication model overview
A ProtocolType ObjectType represents a specific communication protocol (e.g. FieldBus) implemented by a certain TopologyElement. Examples are shown in Figure 18.
The ConnectionPointType represents the logical interface of a Device to a Network.
A Network is the logical representation of wired and wireless technologies.
Figure 17 provides an overall example.
Figure 17 – Example of a communication topology
The ProtocolType ObjectType and its subtypes are used to specify a specific communication (e.g. FieldBus) protocol that is supported by a Device (respectively by its ConnectionPoint) or Network. The BrowseName of each instance of a ProtocolType shall define the Communication Profile (see Figure 18).
Figure 18 shows the ProtocolType including some specific types and instances that represent Communication Profiles of that type. It is formally defined in Table 36.
Figure 18 – Example of a ProtocolType hierarchy with instancesthat represent specific communication profiles
Table 36 – ProtocolType definition
Attribute |
Value |
||||
BrowseName |
ProtocolType |
||||
IsAbstract |
False |
||||
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
Subtype of the BaseObjectType defined in OPC 10000-5 |
|||||
|
|
|
|
|
|
Conformance Units |
|||||
DI Network |
|||||
DI Protocol |
A Network is the logical representation of wired and wireless technologies and represents the communication means for Devices that are connected to it. A Network instance is qualified by its Communication Profile components.
Figure 19 shows the type hierarchy and the NetworkType components. It is formally defined in Table 37.
Table 37 – NetworkType definition
Attribute |
Value |
||||
BrowseName |
NetworkType |
||||
IsAbstract |
False |
||||
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
Subtype of the BaseObjectType defined in OPC 10000-5. |
|||||
HasComponent |
Object |
<ProfileIdentifier> |
|
ProtocolType |
MandatoryPlaceholder |
ConnectsTo |
Object |
<CPIdentifier> |
|
ConnectionPointType |
OptionalPlaceholder |
HasComponent |
Object |
Lock |
|
LockingServicesType |
Optional |
Conformance Units |
|||||
DI Network |
The <ProfileIdentifier> specifies the Protocol and Communication Profile that this Network is used for.
<CPIdentifier> (referenced by a ConnectsTo Reference) references the ConnectionPoint(s) that have been configured for this Network. All ConnectionPoints shall adhere to the same Protocol as the Network. See also Figure 22 for a usage example. They represent the protocol-specific access points for the connected Devices.
In addition, Networks may also support LockingServices (defined in 7).
Clients shall use the LockingServices if they need to make a set of changes (for example, several Write operations and Method invocations) and where a consistent state is available only after all of these changes have been performed. The main purpose of locking a Network is avoiding concurrent topology changes.
The lock on a Network applies to the Network, all connected TopologyElements and their components. If any of the connected TopologyElements provides access to a sub-ordinate Network (like a gateway), the sub-ordinate Network and its connected TopologyElements are locked as well.
If InitLock is requested for a Network, it will be rejected if any of the Devices connected to this Network or any sub-ordinate Network including their connected Devices is already locked.
If the Online/Offline model is supported (see 6.3), the lock always applies to both the online and the offline version.
This ObjectType represents the logical interface of a Device to a Network. A specific subtype shall be defined for each protocol. Figure 20 shows the ConnectionPointType including some specific types.
Figure 20 – Example of ConnectionPointType hierarchy
A Device can have more than one such interface to the same or to different Networks. Different interfaces usually exist for different protocols. Figure 21 shows the ConnectionPointType components. It is formally defined in Table 38.
Figure 21 – ConnectionPointType
Table 38 – ConnectionPointType definition
Attribute |
Value |
||||
BrowseName |
ConnectionPointType |
||||
IsAbstract |
True |
||||
References |
NodeClass |
BrowseName |
DataType |
TypeDefinition |
ModellingRule |
Subtype of the TopologyElementType defined in 4.2. |
|||||
HasComponent |
Object |
NetworkAddress |
|
FunctionalGroupType |
Mandatory |
HasComponent |
Object |
<ProfileIdentifier> |
|
ProtocolType |
MandatoryPlaceholder |
ConnectsTo |
Object |
<NetworkIdentifier> |
|
NetworkType |
OptionalPlaceholder |
Conformance Units |
|||||
DI ConnectionPoint |
ConnectionPoints are components of a Device, represented by a subtype of ComponentType. To allow navigation from a Network to the connected Devices, the ConnectionPoints shall have the inverse Reference (ComponentOf) to the Device.
ConnectionPoints have Properties and other components that they inherit from the TopologyElementType.
The NetworkAddress FunctionalGroup includes all Parameters needed to specify the protocol-specific address information of the connected Device. These Parameters may be components of the NetworkAddress FunctionalGroup, of the ParameterSet, or another Object.
<ProfileIdentifier> identifies the Communication Profile that this ConnectionPoint supports. ProtocolType and Communication Profile are defined in 5.2. It implies that this ConnectionPoint can be used to connect Networks and Devices of the same Communication Profile.
ConnectionPoints are between a Network and a Device. The location in the topology is configured by means of the ConnectsTo ReferenceType. Figure 22 illustrates some usage models.
Figure 22 – ConnectionPoint usage
The ConnectsTo ReferenceType is a concrete ReferenceType used to indicate that source and target Node have a topological connection. It is both hierarchical and symmetric, because this is natural for this Reference. The ConnectsTo Reference exists between a Network and the connected Devices (or their ConnectionPoint, respectively). Browsing a Network returns the connected Devices; browsing from a Device, one can follow the ConnectsTo Reference from the Device’s ConnectionPoint to the Network.
The ConnectsToParent ReferenceType is a concrete ReferenceType used to define the parent (i.e. the communication Device) of a Network. It is a subtype of The ConnectsTo ReferenceType.
The two ReferenceTypes are illustrated in Figure 23.
Figure 23 – Type Hierarchy for ConnectsTo and ConnectsToParent References
The representation in the AddressSpace is specified in Table 39 and Table 40.
Table 39 – ConnectsTo ReferenceType
Attributes |
Value |
||
BrowseName |
ConnectsTo |
||
Symmetric |
True |
||
IsAbstract |
False |
||
References |
NodeClass |
BrowseName |
Comment |
Subtype of HierarchicalReferences ReferenceType defined in OPC 10000-5. |
|||
Conformance Units |
|||
DI ConnectsTo |
Table 40 – ConnectsToParent ReferenceType
Attributes |
Value |
||
BrowseName |
ConnectsToParent |
||
Symmetric |
True |
||
IsAbstract |
False |
||
References |
NodeClass |
BrowseName |
Comment |
Subtype of ConnectsTo ReferenceType |
|||
Conformance Units |
|||
DI ConnectsTo |
Figure 24 illustrates how this Reference can be used to express topological relationships and parental relationships. In this example two Devices are connected; the module DPcomm is the communication Device for the Network.
Figure 24 – Example with ConnectsTo and ConnectsToParent References
All Networks shall be components of the NetworkSet Object.
The NetworkSet Node is formally defined in Table 41.
Table 41 – NetworkSet definition
Attribute |
Value |
||
BrowseName |
NetworkSet |
||
References |
NodeClass |
BrowseName |
TypeDefinition |
OrganizedBy by the Objects Folder defined in OPC 10000-5 |
|||
HasTypeDefinition |
ObjectType |
BaseObjectType |
|
Conformance Units |
|||
DI NetworkSet |