How to decode cyclic PROFINET frames?

Introduction

The following document describes the structure of the cyclic Profinet Process Data Exchange Telegrams. These telegrams are exchanged between a Profinet IO Device and Profinet IO Controller to transfer the cyclic process data. These frames can be easily recorded in a proper setup with the common tool Wireshark. A common mistake is to rely on Wiresharks decoding capability of these telegrams, as the Wireshark displays some information from these telegrams. Unfortunately, old versions of Wireshark do not support proper decoding at all and newer version require a proper network recording to show the correct values. The following description shall provide a short introduction on manual decoding of these telegrams.

Profinet Process Data Telegram Structure

The general structure of a cyclic Profinet process data telegram is shown in the following image

The structure is based on a Layer-2 Ethernet Frame using VLAN Priority Tagging. While the VLAN field is sent by every Profinet IO Device and IO Controller it might be removed by intermediate Network Switches. This must be considered when analyzing the telegram. The C_SDU field contains the data to be transfered. As the minimum size of an Ethernet Frame with VLAN is 64 Bytes, the C_SDU field is padded if its length is smaller than 40 bytes. The APDU Status field contains the Cycle Counter and additional status bytes.

The C_SDU is composed of data items of two kinds:

• IO Data Object
• IOCS Object

Each data item is linked to a particular submodule. The IO Data Object consists of the process data and the associated IOPS of the submodule. The IOCS Object contains just the IOCS of the submodule. A C_SDU typically consists of several objects. The actual position of the process data within the C_SDU is parameterized in RPC Connect Request at connection startup. Between two adjacent items additional padding might be inserted. The structure of the data items is illustrated in the following image. The length of the IOPS and IOCS is usually one byte.

Decoding Example

In the following the full process of decoding a process data telegram is described using an example. The decoded frame is an Input IOCR.

Extract Structure Information

The first step is to analyze the RPC Connect Service for the required structure information. This can be done easily with the help of Wireshark. The following image shows the RPC Connect Request and its parts required for decoding an Input IOCR telegram. The Input IOCR description itself is marked in Red. It contains the Frame Id and the offsets of the data items within the C_SDU. The lengths of the associated process data can be extracted from the Expected Submodule Requests marked in Orange.

Decoding Starts by creating a table containing all the offsets of the data items. That information is to be extracted from the IOCR Block Request. In this case we're interested in the Input IOCR. The assigned Frame Id is 0x8000. For Output IOCRs the Frame Id must be extracted from the RPC connect Response Frame, as the Output IOCR FrameId is assigned by the Device. The following image shows the IOCR Block Request of the desired Input IOCR:

From that information we create the following table:

Now all offsets are known. Next step is to extract the sizes of the items. These lengths can be extracted from the submodules which are described in the Expected Submodule Blocks. The first Expected Submodule Block is shown in the following Image:

From that information we can get the lengths of the data items for Api 0 and Slot 0. Import point here is to examine the correct Data Description element. Each submodule can be assigned one Input- and one Output-Data Description. For the Input IOCR the Input Data Descriptions are relevant for IO Data Items and the Output Data Descriptions are relevant for the IOCS items. Vice Versa for Output IOCR. In the example all of the submodules of the first Expected Submodule Block have zero length input data, one byte IOPS and one byte IOCS. (IOPS/IOCS length is usually one byte)

We complete the table using the information from the remaining Expected Submodule Blocks:

The complete table yields:

The table contains several IO Data objects with zero data length. These IO Data objects are the result of the fact that in Profinet a submodule without any process data is regarded as an Input Submodule with zero length process data.

Decoding of Process Data Telegram

The last step is to decode the process data telegram using the table created above. The following image shows a particular telegram of the Input IOCR. For the correct selection not only the Frame Id shall be taken into account but also the Telegram's Source Mac Address, because the same Frame Id might be used by different devices in RT mode. In the following image the frame #106 has been selected for analysis.

The blue marked part is the C SDU (and padding) containing the actual process data. Based on our table the following values can be extracted:

The status value 0x80 indicates that the associated Process Data is valid in case of IO Data Object. For the IOCS object it indicates that the Consumer of the associated Process Data is using the data. (The associated process data is transfered in the opposite direction and thus not part of this IOCR. In other words, in this case Slot 0x1, Subslot 0x1 is an Input Submodule and Slot 0x2, Subslot 0x1 is an Output Submodule)

Remarks

Profinet Process Data Exchange is covered by some additional constraints, which must be obeyed by the device to ensure proper data exchange:

• Some existing IO Controllers (e.g. S7-300, S7-400) do not recognize IOPS changes from "Bad" to "Good" after the RPC Application Ready Request. If that scenario occurs the IO Device must send a Return of Submodule Alarm to the IO Controller.
• The expected behavior of an IO Device is to delay the RPC Application Ready until all Submodule IOPS and IOCS provided by the Device are set to GOOD. Afterwards the RPC Application Ready Request is issued. (PNS Application Ready Service) If the IO Device can not set the IOPS to GOOD for a particular submodule for a specific reason (e.g. Invalid Parameters have been transferred to the IO Device), the device should set the submodule to state 'application ready pending' (PNS Set Submodule State Service), add a diagnosis to the submodule and issue the Application Ready Service. The RPC Application Ready Request will then contain a Module Diff Block indicating a problem with the particular submodule. At some timepoint afterwards it might be desired to set the IOPS of the submodule to GOOD. In that scenario the application shall reset the submodule state (PNS Set Submodule State Service), remove the diagnosis and issue a Return Of Submodule Alarm (PNS Return Of Submodule Service).

Profinet Process Data Model

The Profinet Protocol defines a Consumer - Provider model. The Process Data is generated by the Provider and received by the Consumer. Additionally a Provider Status and a Consumer Status is exchanged. Depending on the view either the IO Controller or the IO Device is the Consumer or Provider. The following table tries to explain this in more detail. As usually, process data transfered from the IO Device to the IO Controller is denoted as Input Data while process data transfered from IO Controller to IO Device is denoted as Output Data. The last column in the table describes the Profinet IO Device V3.x Configuration Packet variables associated with the corresponding Element. The blue rows indicate data which is transfered from the IO Device to the IO Controller while the green rows indicate data which is transfered from the IO Controller to the OP Device.