This chapter contains the basic use case specification for the PROFINET integration to OPC UA. Its purpose is to define the scope and the requirements for the companion standard.

The following figure contains the basic architecture for the integration of PROFINET to OPC UA. It is used to define the scope of the use cases in this document.

Figure 10 – Architecture of PROFINET integration in OPC UA

Aim of the current PROFINET OPC UA companion standard is the mapping of PROFINET concepts and functions to the corresponding concepts of OPC UA. For this mapping, an architecture of devices and instances helps to define the scope, responsibilities and borders.

The upper area of the architecture contains engineering tools or software which acts as OPC UA Client for the devices implementing the OPC UA Servers. It is important to understand, that these engineering tools can be specialized for a certain end customer use-case like asset management and diagnosis. A combination of responsibilities in one tool is possible as well. Moreover, this document does not suggest any implementation of these tools. They can be located as OPC UA Client FB in one PLC, as software parts of an ERP system, developed by an end customer or a vendor of the Edge gateways or PLCs. The requirements of the specialized engineering tools are described in the corresponding use case chapter. Scope of this document is the communication between those OPC UA Clients and OPC UA Servers implementing the defined PROFINET information model.

The interface between the OPC UA Clients and the PROFINET devices is built by components which are OPC UA Servers and implements the role of PROFINET IO controller, IO supervisor or IO device. Each of these components support the whole or parts of the standardized PROFINET OPC UA information model, depending on the information that is available:

• PLC:A PLC may map all configured and connected PROFINET devices to OPC UA. The OPC UA information model in PLCs is built based on the expected configuration downloaded from the PLC specific engineering system to the PLC. It is not necessary to have an online connection to the connected devices. In this case the relevant parts of the information model have an appropriate status variable. The standardized PROFINET specific OPC UA objects may be provided in addition to other OPC UA objects like e.g. PLCopen DA variables.In cascaded Systems as shown above, every automation device with PROFINET IO controller functionality like e.g. robots is able to show the underlying devices as part of their specific information model in the same way as a PLC. An asset management or diagnosis tool may connect to all devices with IO controller functionality to have a complete view to all devices by the perspective of an IO controller.If the underlying devices are not in the same IP network as the IO controller, OPC UA offers a way like aggregation or direct access through firewalls.
• Edge gateway:An Edge gateway may discover the connected PROFINET devices and their configuration and diagnosis with PROFINET services. It does not have information of devices configured in the PLC but not operational in the network. The standardized OPC UA PROFINET objects are provided in addition to other product specific OPC UA objects of the Edge gateway.If the underlying devices are not in the same IP network as the Edge gateway, OPC UA offers a way like aggregation or direct access through firewalls.
• IO device:An IO device may discover the local PROFINET interface, their configuration and diagnosis, the local slot/subslot configuration, direct neighborhood and application relationships (ARs) to all IO controllers in shared device scenarios. It does not have information of other devices in the network. But in addition, an IO device may offer asset and diagnostics information via a local OPC UA Server which cannot be get by a PLC or Edge gateway. This is e.g. the case, if there is no PROFINET connection to an IO controller or the dynamics is higher than the scan cycle of an Edge gateway. A local representation of a PROFINET information model as part of an IO Device must be considered by the mapping of PROFINET to OPC UA.

In each of the above OPC UA Servers, the whole or parts of the standardized PROFINET OPC UA information model are contained. It is important that in all cases the same information is represented in a consistent manner.

A natural language identification of objects in the namespace of the OPC UA Server requires information from the GSDML files involved and/or given by the engineering system of a PLC like module and submodule names, vendor specific diagnosis text messages or user comments to a module or submodule.

The mapping of PROFINET to OPC UA considers those data in the information model independent of the way the OPC UA Server gets it.

Use cases in this document are described in tables to have a unified representation. These tables contain the following rows:

• Goal:The objective of the use case.
• Implements:Relation to the corresponding requirement.
• Preconditions:One or more conditions which must be met as a precondition for the use case.
• OPC UA mapping:This section describes the behavior of the use case by an OPC UA viewpoint.

The following asset management use-cases focus mainly on running applications and plants. During the commissioning phase changes in the assets are normal. The asset management phase begins after the acceptance tests of the commissioning phase.

The following chapters give a brief introduction to relevant PROFINET objects and services, which are used in the scope of the OPC UA integration use cases. A detailed definition of these terms can be found in documents from Chapter 2 or several printed documents which are available at www.profinet.com. Nevertheless, the reader of this document should be able to understand the basic PROFINET concepts without knowledge of all the details.

It is important, that the support of some PROFINET information below is not mandatory. Therefore, an optimal usability and features coverage can be achieved with devices which implement a maximum of optional PROFINET features. The requirement of the PROFINET specification is denoted by the capital (PN-M) for mandatory or (PN-O) for optional.

The following information is general for all PROFINET devices.

• Device Information (PN-M):Information that is related to the device with the PROFINET connection to the network. Examples are VendorID, DeviceID, DCP type identification, DNS Name of Station and IP-Address.
• Physical Topology (PN-M):PROFINET can discover the physical topology of installed devices as all devices exchange neighborhood information with the LLDP protocol.
• Real Configuration (PN-M):The real configuration of a PROFINET device contains slots and subslots with modules and submodules plugged in the device independent from any controller connection. Each module/submodule is identified by a module/submodule identification number which must be unique in the scope of one DeviceID. One defined submodule is the representative of the device; one submodule is the representative of a module. Therefore, the submodule is the carrier of all information. Modules and submodules which are installed in the real configuration of the device can be discovered with a PROFINET service. These modules/submodules are the carrier of the asset information.
• Expected Configuration (PN-M):The expected PROFINET configuration is the result of the PROFINET engineering in the configuration tool of the PLC. It contains the devices, modules, submodules which are configured in the engineering system of the PLC, downloaded to the controller and transferred to the devices during startup.The expected configuration can be read with a defined PROFINET service.
• Module Diff Block (PN-M):The difference between the expected configuration and the real configuration. The reference to the difference is the expected configuration. The module diff block can be read with a defined PROFINET service.

PROFINET defines Identification and Maintenance functions since PROFIBUS. As there is a long history, some restrictions in these data are possible. In general, I&M contain defined properties and values to identify the asset more precise as it is possible with IDs and without knowledge of the GSD file.

• I&M0 – Electronic Faceplate (PN-M for device, PN-O for Modules):Version Information of the submodule like serial number, HW-Version and FW-Version. I&M0 data are read-only.
• I&M1 – function and location (PN-O):A unique function and location of the device/submodule as visible strings. I&M1 data must be written by a PROFINET engineering tool or PLC before they can be used. The mapping to marking systems like IEC 81346 are in the responsibility of the user and not in scope of this document.
• I&M2 – comment (PN-O):A comment to the device as visible string. I&M2 data must be written by a PROFINET engineering tool or PLC before they can be used.
• I&M3 – installation date (PN-O):The installation date of the device. I&M3 data must be written by a PROFINET engineering tool or PLC before they can be used.
• I&M4 – signature (PN-M and defined for Functional Safety):If the submodule is configured by an external safety configuration tool, this tool can write a signature of the parameter set in I&M4 data of the submodule. With its signature it is possible to discover differences between a stored parameter set of the engineering tool and a parameter set in the field. I&M4 is only defined for safety devices.
• I&M5 – additional information (PN-O)Offers additional information about a communication module which is part on an IO device. If the device (e.g. a robot) is made by company A, and the communication module by company B, I&M0 contain information about the robot and company A, I&M5 contain information about the communication module and company B.

In addition to the above I&M data which are only bound to the PROFINET address elements slot/subslot, additional end customer requirements for enhanced asset management capabilities are incorporated in the PROFINET specification. Definition of PROFINET asset management objects sometimes use data types already defined by I&M properties. In addition to them other asset management properties are available. Asset information can be bound to slots and subslots to extend information, which cannot be modelled with I&M properties. Moreover, the PROFINET specification defines a level-tree of assets which objects are independent from the slot/subslot addressing scheme.

The following picture shows a possible example of asset management usage in a modular IO device.

Figure 11 – Asset management example modular IO

The green elements are the modules and submodules of the station carrying I&M information. Additional asset information like version info of the power supply, terminal blocks or connected sensors and actors can be described by means of asset management objects, which are not directly related to the slot/subslot model.

In addition to this example PROFINET AM can be used to manage all components with loadable software, which can be device or module firmware as well as application programs running on PLCs or robots.

The following asset management objects can be accessed via a defined acyclic read service.

• AM_Info:The scope of the asset information, which can be “full information”, “firmware only” or “hardware only”.
• AM_Location:The location of an asset within a device as 16 subsequent octets. The location can be either “slot/subslot” to extend I&M information or “level tree” to form hierarchical structures of assets.
• IM_UniqueIdentifier:A 128-bit globally unique identification of the asset created by the manufacturer e.g. by means of ISO/IEC 9834-8:2014.
• IM_Annotation:A manufacturer-specific identifier of the asset such as the asset’s name as Unicode string8 with the length of 64 octets.
• IM_OrderID:The order ID of the asset as UnicodeString8 with the length of 64 octets.
• AM_SoftwareRevision:The edition of the software of the asset as UnicodeString8 with 64 octets.
• IM_Software_Revision:Software revision in a special I&M coding of VisibleString[9].
• AM_HardwareRevision:The edition of the hardware of the asset as UnicodeString8 with 64 octets.
• IM_Hardware_RevisionThe hardware revision in I&M coding.
• IM_Serial_Number:A unique production number of the asset set by the manufacturer as VisibleString16.
• AM_DeviceIdentification:The unique device identification in the address space of an organization like VendorID & DeviceID for PI. Or OUI for IO-Link.
• AM_TypeIdentification:Used to identify the family of the asset and assigned by the manufacturer like “IO controller”, “IO device”, “IO-Module”. Standard and manufacturer specific values are defined in [3].

The architecture from Chapter 5.2.1 can be specialized for the usage within asset management. An asset management tool as OPC UA Client is connected to an OPC UA Server located in a PLC, Edge gateway or IO device. The PLC acts as IO controller for the underlying PROFINET system. The Edge gateway is scanning the underlying assets by means of DCP and implicit Read Services.

Figure 12 – Architecture of Asset Management

The following end customer requirements are relevant for asset management. A more detailed description of these use cases can be found in [PN TAD].

The requirements are written from the perspective of an asset management tool user.

Table 8 – Asset Management User Requirements

ID	Name	Details
AM1	Unique Identification	The asset must have a unique Identification in the namespace of all installed assets independent whether the asset is installed in a cell or a machine.
AM2	Hardware and Firmware version management	Hardware and Firmware versions of the installed equipment should be discovered or compared with possible white-lists or black-lists.
AM3	Application version management	The application programs running on PLCs, robots or drives are also versioned and part of the asset management. Versioning for these applications shall be visible. This requirement can be solved in a comparable way then firmware version management.
AM4	Asset changed	End users want to know, if an asset is changed.
AM5	Asset installed	A new asset is installed in the cell or machine.
AM6	Asset removed	A new asset is removed from the cell or machine.
AM7	Asset localization changed	The physical location of an asset was changed. E.g. moved from one machine to another.
AM8	Machine part discovery	Usually the assets installed in a machine are in the responsibility of the machine builder. If some of these assets are replaced by the operator of a machine, the asset discovery of integrated assets is required.
AM9	PROFIsafe Device parameters changed	The OEM wants to know, if PROFIsafe Device parameters are changed by an external engineering tool in the device and/or in the engineering system of the IO controller for startup parameters.
AM10	Asset location changed	The asset is moved to a different place in the asset hierarchy.
AM11	I&M Write	The OEM wants to set writeable I&M1...3 parameters via OPC UA independent from the configuration in the engineering system of the IO controller.
AM12	Network parameter check	The end user wants to know, if all installed PROFINET devices follow specific rules for their network parameters given by the OEM. Network parameters are: PROFINET Name of Station IP-Address Subnet mask Default gateway Allowed cycle times Allowed data hold times
AM13	Docking Devices	PROFINET devices which are connected and disconnected to the network at runtime in normal operation.

The following use case describes the discovery of installed PROFINET assets.

Table 9 – Use case - Asset Discovery

Goal	The end user wants to discover all installed assets within a cell. All available information shall be discovered.
Implements	AM1, AM8, AM12
Preconditions	All PROFINET components are configured and connected to the network. Station Names and IP-Addresses of the devices can be set. The Tag-Function and Tag-Location in I&M1 and asset management data are available. The PLC/Edge Gateway is scanning the underlying network continuously with DCP-Identify and PROFINET read services to get all relevant asset information. For details see [1].
OPC UA Mapping	AM tool connects the OPC UA Server in the EGW/PLC/Device. The OPC UA information model in the EGW is built based on the found devices, modules and submodules of the last scan cycle. The required I&M and Asset information are read with the corresponding PROFINET services in the context of an implicit or device access AR. The OPC UA information model in a PLC is built corresponding to the real configuration downloaded from the engineering system of the PLC. The required I&M and Asset information are read with the corresponding PROFINET services in the context of the already established IO-AR. The OPC UA information model in a device is build corresponding to the real configuration plugged by the local device application. The required I&M and Asset information are implemented according the local device application.
Remarks	When there is no station name, the MAC address shall be used as BrowseName. If those devices get a correct name, they are visible as a different entity under their station name as the OPC UA browse name shall be unique.

The following chapter describes criteria to detect changes in the assets. They may be useful to implement corresponding functionalities in the asset management tool.

The user wants to be informed if assets in the plant or machine were changed. The following table describes criteria to detect changes.

Implements AM4.

Table 10 – Criteria for asset information changed

Changed asset	Criteria	PROFINET Service
Device	Software Version changedAKZ/OKZ changed	I&M0:SoftwareVersion I&M1: AKZ/OKZ
ModuleSubmodule	Software Version changedAKZ/OKZ changed	I&M0:SoftwareVersion I&M1: AKZ/OKZ
Asset	Software Version changedAKZ/OKZ changed	Will be part of a next version of the companion specification

The user wants to be informed if assets in the plant or machine were changed. The following table describes criteria to detect changes.

Implements AM4.

Table 11 – Criteria for asset exchange

Changed asset	Criteria	PROFINET Service
Device	Serial number changed	IM_SerialNumber of the DAP
ModuleSubmodule	Serial number changed	IM_SerialNumber of the module/submodule
Asset	Serial number changed	IM_SerialNumber of the asset

The user wants to be informed if assets in the plant or machine were added. The following table describes criteria to detect changes.

Implements AM5.

Table 12 – Criteria for added assets

Added asset	Criteria	PROFINET Service
Device	Device with unknown MAC address in the network	DCP-Identify-All
ModuleSubmodule	Real configuration contains a new module/submodule	RecordRead RealIdentificationData for all API’s
Asset	Asset list contains a new entry	RecordRead AM_Info

The user wants to be informed if assets in the plant or machine were removed. The following table describes criteria to detect changes.

Implements AM6.

Table 13 – Criteria for asset removal

Removed asset	Criteria	PROFINET Service
Device	Device list smaller than previous scan	DCP-Identify-All
ModuleSubmodule	Real configuration contains less modules/submodules	RecordRead RealIdentificationData for all API’s
Asset	Asset list contains less modules/submodules	RecordRead AM_Info

Special cases in PROFINET are devices which are connected and disconnected to the network at runtime, like devices installed on a tool gripped by a robot. It is not guaranteed, that docking devices can be fully discovered by the scan cycle of Edge gateways. An IO controller may show information of docking devices in the local OPC UA Server.

One important use case of asset management is the detection of firmware updates in the plant or machine as well as a version change in a programmable application running on a PLC, robot or drive. The following table describes criteria to detect changes.

Implements AM2, AM3.

Table 14 – Criteria for firmware or application program update

Updated asset	Criteria	PROFINET Service
Device	IM_SoftwareRevision of the submodule representing the device has a changed value.	RecordRead I&M0FilterDataRecordRead I&M0
ModuleSubmodule	IM_SoftwareRevision of module/submodule has a changed value. The modules/submodules with explicit I&M data can be found asking for I&M0FilterData.	RecordRead I&M0FilterDataRecordRead I&M0
Asset	IM_SoftwareRevision or AM_SoftwareRevision of asset has a changed value	RecordRead AM_Info

Sometimes it is important to know, if a safety parameter of a device in the plant or machine, set by an engineering tool, was changed. The following table describes criteria to detect changes.

Implements AM9.

Table 15 – Criteria for safety device parameter change

Changed Parameter	Criteria	PROFINET Service
Device	IM_Signature of DAP has a changed value	RecordRead I&M4
ModuleSubmodule	IM_ Signature of module/submodule has a changed value	RecordRead I&M4
Asset	Not available

As special case for asset management is a change of a device in the physical topology. This is sometimes the case while finding errors in the field by exchange of devices.

Implements AM10.

Table 16 – Criteria for topology change

Topology change	Criteria	PROFINET Service
Device moved	Changed neighborhood information of a device with a known MAC address and/or SerialNumber	DCP_IdentifiyRecordRead PDRealData
Device added	Device with an unknown MAC address in physical topology	DCP_IdentifiyRecordRead PDRealData
Device removed	New physical topology without a device which was there before	DCP_IdentifiyRecordRead PDRealData

PROFINET defines a comprehensive diagnostic model. The main focuses of this model are device diagnosis and network diagnosis. Diagnosis scenarios can appear during startup of a plant as well as during operation.

Details of the PROFINET diagnosis concepts are contained in [PN Diag]. The main ideas are summarized in this chapter:

Figure 13 – Diagnosis base model from [PN Diag]

Each IO device maintains a global list of active diagnosis in a database called Diagnosis ASE.

All diagnosis entries are related to a channel of a submodule. The channel can represent a connected sensor or actor as well as the whole submodule. Submodule related diagnosis is marked with the channel number 0x8000.

If some relevant diagnosis or maintenance appears or disappears on a channel, an entry in the diagnosis ASE is added or removed. In this case, the IO controller is informed with diagnosis alarm to have event driven diagnosis information available in the PLC.

A supervisor like an Edge gateway or diagnosis tool can query the diagnosis ASE with a defined PROFINET record. If the ASE contains entries, the query is answered with a list of diagnosis entries. Otherwise the answer is empty to reduce the network load.

Figure 14 – Severity classification of diagnosis from [PN Diag]

Each channel diagnosis entry contains a severity and a combination of error codes (see Figure 14). Some of these codes are system defined and can be decoded with the help of a general XML file available via PI. Vendor specific and profile specific error codes can be contained in the GSD file of the device.

Figure 15 – Architecture of Diagnosis

In the Diagnosis Use-Case a diagnosis tool is connected to a PLC, Edge gateway or the OPC UA Server of the device itself. The integrated OPC UA Server represents the subordinate PROFINET system or devices and their diagnosis state. There are differences in the available diagnosis information in IO controllers, Edge gateways or devices, which must be considered:

• IO controllerAn IO controller may form an OPC UA object model which is based on the expected configuration given by the engineering system. If there is no PROFINET connection (IOAR) between the controller and the device, the controller knows the reason (e.g. Device not found, duplicated names in the network, etc.). IO controllers are informed from the devices with a diagnosis alarm, if anything in the diagnosis ASE has been changed and may determine a time accurate diagnosis state.
• Edge gateways:An Edge gateway may show IO controllers and IO devices which can be discovered during the scanning process. An Edge gateway may determine the expected configuration of the devices with a normative record. The reason for an e.g. unreachable device can be different from an IO controller. Supervisors like Edge Gateways are not informed with an alarm if something in the diagnosis ASE of the devices has been changed. They can be as time accurate as the scanning time is configured.
• Devices:The IO device represents the diagnosis state of the included modules and submodules. In addition it knows if there is a running AR to the IO controller.

Table 17 – Discover differences

Goal	The end user wants to know if there are any differences between the expected configuration given in the ES of an IO controller and installed devices in the field.
Preconditions	The expected PROFINET configuration is set up in the engineering system of the IO controller, downloaded and activated. The Tag-Function and Tag-Location of I&M1 is configured.
OPC UA Mapping	In a PLC the information model of the OPC UA Server is build according the expected configuration of the PLCs engineering system. Differences between real and expected configuration are marked at the corresponding submodule of the expected configuration. In an EGW the information model of the OPC UA Server is build according to the scanned devices. Differences to the expected configuration are shown based on module diff block information read from the device. In a device the information model of the OPC UA Server is build according the local configuration. Differences to the expected configuration are shown based on module diff block from the controller AR. PLC is named with its station name and IP-Address. Devices are named with their station name, IP-Address and I&M1 information.

Table 18 – Discover reachable configuration

Goal	The end user wants to know which devices and their configuration are installed in the field.
Preconditions	All connected PROFINET systems are configured and running. There can be multiple PLCs in the network visible by an EGW. An EGW or PLC may scan the underlying network continuously with DCP-Identify and PROFINET read services to get all relevant information. For details see [PN TAD].
OPC UA Mapping	The information model of the OPC UA Server is build according the scanned devices and their real slot/subslot configuration. This Use-Case should not be implemented in a Device to avoid network load caused by Identify services.
Remarks	When there is no station name, the MAC address shall be used as BrowseName. If those devices get a correct name, they are visible as a different entity under their station name as the OPC UA browse name shall be unique.

Table 19 – Connection Diagnosis

Goal	The end user wants to know the state of the PROFINET connections related to the expected configuration of the IO controller
Preconditions	The expected PROFINET configuration is set up in the engineering system of the IO controller, downloaded and activated. Some ARs between the IO controller and IO devices are established, others cannot be established by e.g. following reasons: Device with configured NoS not found in the network Duplicate NoS detected Duplicate IP-Address detected AR deactivated in PLC application program
OPC UA Mapping	The connection state of the AR is signaled on the corresponding IO device in the address space of the OPC UA Server. The reason for error is part of the AR.

Table 20 – Submodule state diagnosis

Goal	The end user wants to know differences between the expected and real configuration related to modules/submodules, their identification as well as other reasons for connection problems.
Preconditions	The expected PROFINET slot/subslot configuration is set up in the engineering system of the IO controller, downloaded and activated. An EGW may continuously scan the ExpectedConfiguration and ModuleDiffBlock data records from the reachable devices. Some submodules in real configuration differ from the expected. Details see SubmoduleState. Examples: Wrong Submodule No Submodule Substitute Submodule Application Ready Pending Superordinated Locked Locked by IO controller Locked by IO supervisor
OPC UA Mapping	The difference related to the expected configuration is signaled on the corresponding module/submodule in the address space of the UA Server. The state is shown in a variable with corresponding values of SubmoduleState.

Table 21 – Device diagnosis or maintenance update

Goal	The end user wants to have information about device/module/submodule/channel related diagnosis or maintenance information.
Preconditions	All connected PROFINET systems are configured and running. Channel related diagnosis or maintenance (e.g. short circuit) appears on one channel of a real or PDev submodule. An entry in the diagnosis ASE of the IO device is made. The IO controller is informed with a corresponding diagnosis or maintenance alarm. The EGW may scan the underlying network continuously with DCP-Identify and PROFINET read services to the diagnosis ASE. Channel related diagnosis or maintenance (e.g. short circuit) disappears on one channel of a real or PDev submodule.
OPC UA Mapping	The diagnosis or maintenance is signaled on the corresponding module or submodule in the address space of the OPC UA Server with the following information: ChannelNumber (0x8000 is the whole submodule itself) Severity: fault, maintenance required, maintenance demanded mapped to OPC UA severity classes Error Text from GSDML in current language. Formatted information of ExtChannelAddValue based on GSDML. + Help Text from GSDML.

Table 22 – Network diagnosis or maintenance

Goal	The end user wants to have information about the “health” of the physical PROFINET network in the Diagnosis tool in a topological view.
Preconditions	All connected PROFINET systems are configured and running. PDev related diagnosis or maintenance appear on the network. An EGW or PLC may scan the underlying network continuously with DCP-Identify and PROFINET read services to get all relevant information. The PDev related diagnosis and properties are integrated in the OPC UA address space of the EGW or PLC according to Table 21.
OPC UA Mapping	A diagnosis tool uses the PDev related information from the OPC UA Server to display a topological view with corresponding details. It is not the responsibility of the OPC UA Server.
Remark	Display of physical Topology is possible for PROFINET-Devices and PROFINET-switches, but not possible for devices without topology information.

This use case describes the reading and writing of PROFINET records via objects in the OPC UA Server. This use case is intentionally not provided in this companion specification because access to low level data records is a potential security problem and the access to additional application data via the OPC UA Server shall be done in a high-level object-oriented access.