6 PROFINET OPC UA Information Model

Today OPC UA information models focused on the functional aspects of a dedicated device and the management of parameters in a device parameter set, are typically based on the OPC UA for Devices (DI) base information model (defined in [OPC 10000-100], referenced as OPC UA DI also in this document). In contradiction to this the I4.0 system modelling, including multiple aggregated devices and controllers, requires the representation of several different aspects of the system and therefore will lead to more sophisticated modelling approaches. Such a system model approach using four different independent partial models called “Facets”, linked together by typified references is shown in Figure 16. Here the Asset partial model contains an independent model related to orderable components (assets). The Physical Network partial model contains the independent model of the ethernet network structure. The PROFNET partial model contains all communication related aspects of the PN Controllers and Devices in the system. The Function partial model at least represents the application function aspect of the system. Objects out of the different partial models are connected to each other by typified references expressing semantic information about their relationship.

To be future proof and easily integrable to different base modelling approaches, this Companion Specification defines the PROFINET information model as an independent partial model using the OPC UA Interface and AddIn technology (See [OPC 10001-7]) . This gives the opportunity to connect the same unique PROFINET base information model to the OPC UA DI base model and to use the same PROFNET base model as partial model for the PROFINET communication aspect in the “Facet” modelling approach as shown in Figure 16.

The base information model in chapter 6.3 defines all common types of the PROFINET OPC UA information model.

The Annex B shows how to use the base information model together with OPC UA for Devices.

6.1 Conventions used in the mapping to PROFINET properties

The mentioned values are obtained by the blocks (optionally also subblocks) and fields given in the description. The following syntax is used: “Block | field”.

6.2 General conventions

All variables are read-only unless stated otherwise explicitly.

6.3 Base Information Model

6.3.1 OPC UA Object Types

The first 4 chapters of the base information model include the object types for the internal module/submodule structure of a PROFINET device and controller.

Figure 17 shows a simplified example for a module/submodule object structure. The container folders have been skipped in the figure.

The Device View includes devices in the PROFINET network and their real existing modules and submodules.

The Controller / Application View includes the PROFINET connections (Application Relationships) and the expected modules and submodules which have been configured in the PROFINET controller.

Both views relate to each other by non-hierarchical references.

The chapter 6.3.1.7 includes the object types for the PROFINET network mapping.

The chapter 6.3.1.8 includes the 2 object types for the asset identification within a PROFINET device.

6.3.1.1 Object instances lifetime

All object instances of the base information model represent the online view on the PROFINET network.

All PROFINET objects modeled in this specification are only created in the address space when the OPC UA Server detects their PROFINET counterpart. The objects are removed from the address space when the OPC UA Server detects their absence in the PROFINET network or PROFINET device.

The chapter 6.10 of [PN TAD] describes the possible ways of implementing the PROFINET device discovery. The chapter 11.3 of [PN TAD] describes the detection of the real modules and real submodules of a device and how to get their identification and asset data.

All these ContainerType objects only exist if objects are available in the container.

6.3.1.2 Domain

6.3.1.2.1 IPnDomainType

The Nodes object of the Domain includes all device and controller nodes which belong to the PROFINET domain.

6.3.1.3 Node

6.3.1.3.1 IPnEquipmentType

If the IM component is provided, it must contain the data of the representative submodule for the device in accordance with the I&M0FilterDataDevice block (See [PN TAD] – Identification & Maintenance).

The Assets and IM objects are optional. If the interface is used with the OPC UA facet model, the asset data can be part of another facet (See chapter 6 “PROFINET OPC UA Information Model” and Figure 16 – “Facet” modelling approach for I4.0 System Modelling).

The <Assets> objects are only assets which are directly related to this device. Assets related to the modules or submodules are components of these objects.

The server may provide diagnosis data with the Diagnosis variable or by sending PnDiagnosisAlarmType events. The diagnosis data at the device object includes the diagnosis information of the whole device including the one of all real modules and real submodules. An OPC UA Server might provide instances of the PnDiagnosisAlarmType as objects under the Alarms object.

Mapping to PROFINET properties:

6.3.1.3.1.1 ShowLocation Method

This optional method shall trigger a perceivable signal which allows the identification of the physical device represented by the device object the method is invoked on. This is usually accomplished with a blinking LED.

The method has no parameters (no [in] and no [out] parameters) and no return value.

Signature

	ShowLocation (
		);

6.3.1.3.2 PnEquipmentContainerType

The <PnEquipments> shall have the references and components defined in Table 26 and Table 27.

Mapping to PROFINET properties:

6.3.1.3.3 IPnDeviceType

The BrowseName of a device object instance shall be the content of the NameOfStation variable of the first interface sub module. If the NameOfStation variable is not set, the content of the MAC Address variable of the first interface sub module shall be used. The MAC address string should use the canonical format (separated with -, e.g. AC-FD-CE-EC-03-80).

If the GSDDescription property is provided, it must contain the InfoText with Device Id from the GSD (see mapping table below).

Mapping to PROFINET properties:

6.3.1.3.4 IPnControllerType

6.3.1.4 Application Relationship

6.3.1.4.1 PnApplicationRelationType

The BrowseName of an application relationship object instance shall be the Id in standard GUID string format.

The Modules container object is the root of the configuration hierarchy consisting of the expected modules of the application relationship and their expected submodules (See chapter 6.3 - Base Information Model and Figure 17 – Object Structure).

The State variable has always the value CONNECTED on devices since the object only exists if an AR is established.

An IsPnApplicationRelationControllerInterface reference points to the interface object of the controller used for the AR. If the AR relates to the device an IsPnApplicationRelationDeviceInterface reference points to the interface object of the device. See sections 6.3.2.11 and 6.3.2.12 also.

Mapping to PROFINET properties:

6.3.1.4.2 PnApplicationRelationContainerType

Mapping to PROFINET properties:

6.3.1.5 Module

6.3.1.5.1 IPnModuleType

The properties Slot and IdentNumber must contain the data as described in the mapping table provided for the subtypes IPnRealModuleType and IPnExpectedModuleType.

Mapping to PROFINET properties:

6.3.1.5.2 IPnRealModuleType

The BrowseName of a module object instance shall be the content of the Slot variable in decimal number string format.

If the IM component is provided, it must contain the data of the representative submodule for the module in accordance with the I&M0FilterDataModule block (See [PN TAD] – Identification & Maintenance).

The server may provide diagnosis data with the Diagnosis variable or by sending PnDiagnosisAlarmType events. The diagnosis data at the real module object includes the diagnosis information of the whole module including the one of the real submodules of the module. An OPC UA Server may provide instances of the PnDiagnosisAlarmType as objects under the Alarms object.

Mapping to PROFINET properties:

6.3.1.5.3 PnRealModuleContainerType

The <Modules> shall have the references and components defined in Table 35 and Table 36.

Mapping to PROFINET properties:

6.3.1.5.4 IPnExpectedModuleType

The BrowseName of a module object instance shall be the content of the Slot variable in decimal number string format.

An IsPnRealModule reference points to the real module which is the real realization of the expected module. See section 6.3.2.9 also.

Mapping to PROFINET properties:

6.3.1.5.5 PnExpectedModuleContainerType

The <Modules> shall have the references and subcomponents defined in Table 39 and Table 40.

Mapping to PROFINET properties:

6.3.1.6 Submodule

6.3.1.6.1 IPnSubmoduleType

The properties GSDName and GSDDescription must contain the data from the GSD, as described in the mapping table provided for the subtypes IPnRealSubmoduleType and IPnExpectedSubmoduleType.

6.3.1.6.2 IPnRealSubmoduleType

The BrowseName of a sub module object instance shall be the content of the Subslot variable in hexadecimal number string format (e.g. 0x8001).

If the IM component is provided, it must contain the data in accordance with the I&M0FilterDataSubmodule block (See [PN TAD] – Identification & Maintenance).

The server can provide diagnosis data with the Diagnosis variable or by sending PnDiagnosisAlarmType events. The diagnosis data at the real submodule object includes only the diagnosis information of the real submodule. An OPC UA Server might provide instances of the PnDiagnosisAlarmType as objects under the Alarms object.

An IsPnInterface reference exists if the submodule is an interface submodule. See section 6.3.2.13 also.

An IsPnPort reference exists if the submodule is a port submodule. It points to the PnPortType object. See section 6.3.2.14 also.

Mapping to PROFINET properties:

6.3.1.6.3 PnRealSubmoduleContainerType

The <Submodules> shall have the references defined in Table 44 and Table 45.

Mapping to PROFINET properties:

6.3.1.6.4 IPnExpectedSubmoduleType

An IsPnRealSubmodule reference points to the real submodule which is the real realization of the expected submodule. See section 6.3.2.10 also.

Mapping to PROFINET properties:

6.3.1.6.5 PnExpectedSubmoduleContainerType

The <Submodules> shall have the references and subcomponents defined in Table 48 and Table 49.

Mapping to PROFINET properties:

6.3.1.6.6 PnSubmoduleStateType

Mapping to PROFINET properties:

6.3.1.7 Network

This chapter includes all object types needed to represent the physical network topology of a PROFINET network.

Figure 18 shows an example which illustrates the relations between network objects of a single port PROFINET device and a 4 port Ethernet switch.

The Ethernet interface, ports and cables are represented by objects in the address space. This Ethernet objects relate to each other by CommLinkTo references. This enables the OPC UA Server to represent the physical network topology of the PROFINET network.

6.3.1.7.1 IPnInterfaceType

The BrowseName of an interface object instance shall be the PROFINET interface id with the range 1..16 in decimal number string format.

The NameOfStation variable may be set with the SetNameOfStation method. Nevertheless, the variable itself shall always be read-only.

The CommLinkTo reference points to an EthernetInterfaceType object instance. An object of the IPv4FeatureType must be implemented in this EthernetInterfaceType object instance.

Mapping to PROFINET properties:

6.3.1.7.1.1 SetNameOfStation Method

This optional method writes the NameOfStation remanent to the PROFINET device and sets the NameOfStation variable accordingly.

Signature

	SetNameOfStation (
		[in]	String NameOfStation
		);
	

Method Result Codes

6.3.1.7.2 PnInterfaceContainerType

The <Interfaces> shall have the references defined in Table 53 and Table 54.

6.3.1.7.3 PnPortType

The PnPortType Object Type includes the port specific data of a port submodule.

A PnRealSubmoduleType instance representing a port submodule has an IsPnPort reference to a PnPortType object instance.

Mapping to PROFINET properties:

6.3.1.7.4 PnPortContainerType

6.3.1.7.5 PnPortStatisticType

The port statistic counters can be read from a PROFINET device with the Read PD Port Statistic PROFINET service.

6.3.1.7.6 NetworkComponentType

The NetworkComponentType is the abstract base ObjectType for different types of network components.

The Enabled variable indicates if the network component is activated (Enabled == True) or deactivated (Enabled == False).

6.3.1.7.7 EthernetInterfaceType

The EthernetInterfaceType is used to represent Ethernet network interfaces.

The MacAddress Variable is read only and represents the unique Layer2 source MAC address of the related interface.

Mapping to PROFINET properties:

6.3.1.7.8 EthernetPortType

The EthernetPortType is used to represent Ethernet ports.

The PhysAddress Variable is read only and contains a MAC address representing the Port.

6.3.1.7.9 NetworkComponentFeatureType

The NetworkComponentFeatureType is the abstract base ObjectType for different types of network components.

6.3.1.7.10 IPv4FeatureType

The IPv4FeatureType is used to represent IPv4 settings of a network interface.

Mapping to PROFINET properties:

The IpAddress Variable describes the IPv4 address on the interface.

The SubnetMask Variable describes the IPv4 Subnet mask on the interface.

The DefaultGateway Variable describes the IPv4 address of the default gateway.

The DhcpEnabled Variable specifies whether the DHCPv4 Client functionality for this interface is enabled.

6.3.1.8 Identification

6.3.1.8.1 PnIdentificationType

Mapping to PROFINET properties:

6.3.1.8.1.1 SetTags Method

This optional method writes the I&M1 fields IM_TagFunction and IM_Tag_Location remanent to the PROFINET device and sets the TagFunction and TagLocation variables accordingly.

Signature

	SetTags (
		[in] IMTagSelectorEnumeration Tag_Selector,
		[in] String Tag_Function,
		[in] String Tag_Location
		);
	

Method Result Codes

6.3.1.8.1.2 SetDate Method

This optional method writes the I&M2 field IM_Date remanent to the PROFINET device and sets the Date variable accordingly.

Signature

	SetDate (
		[in] DateTime IM_Date
		);
	

Method Result Codes

6.3.1.8.1.3 SetDescriptor Method

This optional method writes the I&M3 field IM_Descriptor remanent to the PROFINET device and sets the Descriptor variable accordingly.

Signature

	SetDescriptor (
		[in] String Descriptor
		);
	

Method Result Codes

6.3.1.8.2 PnAssetType

The BrowseName of an asset object instance shall be the content of the UniqueIdentifier variable in standard GUID string format.

Mapping to PROFINET properties:

If the AM_Location field is coded using the level tree format, each used level shall be encoded in the Location string with a ‘.’ followed by the value of the level bits encoded as decimal number string. According to [PN TAD] – Figure 38, the HART sensor has the Location string ”.0.4.1.1”.

If the AM_Location field is coded using the slot- and subslotnumber format, the Location string shall be encoded as ‘BeginSlotNumber/BeginSubslotNumber-EndSlotNumber/EndSubslotNumber’. BeginSlotNumber and EndSlotNumber shall be encoded as decimal number strings. BeginSubslotNumber and EndSubslotNumber shall be encoded as hexadecimal number strings (0x…) According to [PN TAD] – Figure 38, the IO-MC 1 asset has the Location string ”2/0x1-4/0x1”.

6.3.1.8.3 PnAssetContainerType

6.3.2 OPC UA Reference Types

6.3.2.1 HasPnApplicationRelation

The HasPnApplicationRelation reference is used to append nodes to the PnApplicationRelationContainerType node.

This reference should always be bidirectional.

The destination of the reference shall be an object of the ObjectType PnApplicationRelationType.

6.3.2.2 HasPnRealModule

The HasPnRealModule reference type is used to append nodes to the PnRealModuleContainerType node.

This reference should always be bidirectional.

The destination of the reference shall be an object implementing the IPnRealModuleType interface.

6.3.2.3 HasPnRealSubmodule

The HasPnRealSubmodule reference type is used to append nodes to the PnRealSubmoduleContainerType node.

This reference should always be bidirectional.

The destination of the reference shall be an object implementing the IPnRealSubmoduleType interface.

6.3.2.4 HasPnExpectedModule

The HasPnExpectedModule reference type is used to append nodes to the PnExpectedModuleContainerType node.

This reference should always be bidirectional.

The destination of the reference shall be an object implementing the IPnExpectedModuleType interface.

6.3.2.5 HasPnExpectedSubmodule

The HasPnExpectedSubmodule reference type is used to append nodes to the PnExpectedSubmoduleContainerType node.

This reference should always be bidirectional.

The destination of the reference shall be an object implementing the IPnExpectedSubmoduleType interface.

6.3.2.6 HasPnAsset

The HasPnAsset reference type is used to append nodes to the PnAssetContainerType node.

This reference should always be bidirectional.

The destination of the reference shall be an object of the ObjectType PnAssetType.

6.3.2.7 HasPnInterface

The HasPnInterface reference type is used to append nodes to the PnInterfaceContainerType node.

This reference should always be bidirectional.

The destination of the reference shall be an object implementing the IPnInterfaceType interface.

6.3.2.8 HasPnPort

The HasPnPort reference type is used to append nodes to the PnPortContainerType node.

This reference should always be bidirectional.

The destination of the reference shall be an object of the ObjectType PnPortType.

6.3.2.9 IsPnRealModule

The IsPnRealModule reference type is used to link ExpectedModule objects to their RealModule counterparts (See Figure 17 – Object Structure).

This reference should always be bidirectional.

The destination of the reference shall be an object implementing the IPnRealModuleType interface.

The source of the reference shall be an object implementing the IPnExpectedModuleType interface.

6.3.2.10 IsPnRealSubmodule

The IsPnRealSubmodule reference type is used to link ExpectedSubmodule objects to their RealSubmodule counterparts (See Figure 17 – Object Structure).

This reference should always be bidirectional.

The destination of the reference shall be an object implementing the IPnRealSubmoduleType interface.

The source of the reference shall be an object implementing the IPnExpectedSubmoduleType interface.

6.3.2.11 IsPnApplicationRelationDeviceInterface

The IsPnApplicationRelationDeviceInterface is used to link PnApplicationRelationType objects to the PN Interface object of the Device object (objects implementing IDeviceType) the application relation connects to (See Figure 17 – Object Structure).

This reference should always be bidirectional.

The destination of the reference shall be an object implementing the IPnInterfaceType interface.

The source of the reference shall be an object of the ObjectType PnApplicationRelationType and shall not use the reference type more than once.

6.3.2.12 IsPnApplicationRelationControllerInterface

The IsPnApplicationRelationControllerInterface is used to link PnApplicationRelationType objects to the PN Interface object of the controller object (objects implementing IControllerType) the application relation belongs to (See Figure 17 – Object Structure).

This reference should always be bidirectional.

The destination of the reference shall be an object implementing the IPnInterfaceType interface.

The source of the reference shall be an object of the ObjectType PnApplicationRelationType and shall not use the reference more than once.

6.3.2.13 IsPnInterface

The IsPnInterface reference type is used to link RealSubmodule objects to PN Interface objects (See Figure 18 – Network Topology).

This reference should always be bidirectional.

The destination of the reference shall be an object implementing the IPnInterfaceType interface.

The source of the reference shall be an object implementing the IPnRealSubmoduleType interface.

6.3.2.14 IsPnPort

The IsPnPort reference type is used to link RealSubmodule objects to PN Port objects (Figure 18 – Network Topology).

This reference should always be bidirectional.

The destination of the reference shall be an object of the ObjectType PnPortType.

The source of the reference shall be an object implementing the IPnRealSubmoduleType interface.

6.3.2.15 CommLinkTo

The CommLinkTo reference type is used between object instances representing network entities like Ethernet interfaces and Ethernet ports to describe their communication as well as their topology dependencies. (See Figure 18 – Network Topology).

This reference should always be bidirectional.

6.3.3 OPC UA Data Types