5 Use cases ToC Previous Next

5.3 Use Case description ToC Previous Next

5.3.3 PROFINET Diagnosis ToC Previous Next

5.3.3.1 General ToC

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.

5.3.3.2 PROFINET Basics ToC

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

readme_files/image017.png

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.

readme_files/image018.png

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.

5.3.3.3 Architecture ToC

readme_files/image019.png

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 controller An 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.

    5.3.3.4 Use Cases ToC

    5.3.3.4.1 Discover differences between the expected configuration and the field ToC

    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.

5.3.3.4.2 Discover reachable configuration ToC

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.

5.3.3.4.3 Connection Diagnosis ToC

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.

5.3.3.4.4 Submodule state diagnosis ToC

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.

5.3.3.4.5 Device diagnosis or maintenance update ToC

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.

5.3.3.4.6 Network diagnosis or maintenance ToC

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.

Previous Next