Architecture Design

Using CPU firmware 3.10 or earlier, the solution architecture is based on:

  • NTP service for time base synchronization.

  • Execution of 2 DFBs (S_WR_ETH_MX and MOVE in the sender PAC and 1 DFB (S_RD_ETH_MX) in the receiver PAC).

  • Scanning via Modbus TCP, for data transportation.

The following figure shows the overview of the process required to perform the safe peer-to-peer communication:

In the figure above, Control Expert automatically creates – and hides from external view – Array 1 and Array 4 in the Global areas of the peer PACs. From a user standpoint, the links are made from Array 0 to Array 2, and from Array 3 to Array 5.

NOTE: On the Ethernet network, you are allowed to mix safety related data and non-safety related data without impact on the integrity level of the safety related data. There is no restriction on the Ethernet network when using the safe peer-to-peer communication.

Peer-to-Peer Data Transfer Configuration Details

The following example shows you how to configure a peer-to-peer transfer of data between two safety PACs with CPU firmware 3.10 or earlier and Control Expert 14.1 or earlier:

Step

Action

1

On the sending PAC, use the Process Data Editor to create an array of 100 integers as an input in the Interface area. In this example, the array name is Array2:

2

On the sending PAC, create another array of 100 integers as an output in the Interface tab of the Safety Data Editor and link it to the input process area array created in step1, above, in the Effective Parameter column. In this example, the array name is Array0:

NOTE: The integer variables from index 0 to 90 of the array contain the safety variable values to exchange with the receiving PAC. The remaining area is reserved for auto-generated diagnostic data, including a CRC and time-stamp. This diagnostic data is used by the receiving PAC to determine if the transferred data is safe.

3

On the sending PAC, configure the DFB S_WR_ETH_MX in a section of the SAFE task. Link the DFB to Array0:

4

In the DTM Browser of the sending PAC, select the CPU (in this example) or an NOC communications module (if any) then click Add... to create a Modbus scanner that can send data via Modbus TCP from the sending PAC to the receiving PAC:

5

Select Modbus Device and click Add DTM to add the Modbus scanner:

6

Open the newly added Modbus device, add a request, and in the Request Setting tab:

  • Set the WR Length column, which is the length of the data to be written, to a value of 100, then

  • Set the WR Address column, which is the address where the table on the receiving PAC will write the data it receives (in this example: 0, which means the sending PAC will write to the table starting to %MW0 in the receiving PAC.

7

Select the Request 001: Items node, then in the Output tab define an array type of INT (that is ≥100 integers). This is the sending PAC table that will be written to the receiving PAC:

8

After saving and building the configuration, the block (BLOCKA_QI0_100 in this example) is automatically created as a process variable:

9

On the sending PAC, in a process code section, use a MOVE DFB to copy the contents of Array2 to the array defined above in the Modbus device structure:

10

On the receiving PAC, use the Safe Data Editor to create a 100 integer array (Array5) as an input in the Interface area:

11

On the receiving PAC, in the Process Data Editor, create an array (Array3) of 100 INT in the <outputs> section of the Interface tab. Link this array to the data area array (Array5, created in step 10) in the Effective Parameter column. The data sent by the sending PAC will be written into this array via the Modbus scanner, provided that this variable is located at the address defined in scanner of the sending PAC (in this example %MW0):

12

On the receiving PAC, use the Safety Data Editor to create a 100 integer array (Array6):

13

On the receiving PAC, in a section of code in the SAFE task, instantiate the S_RD_ETH_MX DFB with the array created in step 10 (Array5) as input parameter and with the array created in step 12 (Array6) as output parameter:

Black Channel Peer-to-Peer

Each peer-to-peer data transmission consists of both User Safety Data, which contains the application-related content being transmitted, and Reserved Data. The Reserved Data is used by the safety PAC to test the reliability of the transmission so that it satisfies the requirements of SIL3. The Reserved Data consists of the following elements:

  • A CRC calculated by the sending PAC from the data to be transmitted. The receiving PAC checks the CRC before using the transmitted data.

  • A communication identifier, which is included in the CRC calculation to help prevent masquerade and insertion attacks on the transmission of safety data.

  • A time stamp, containing the time of the transmission in ms. This stamped time is based on the time value provided by the NTP service and is used to synchronize both the sender PAC and receiver PAC. The data sender PAC adds a time value to the data sent to the receiver PAC. The receiver PAC compares the received time stamp with its own time value, and uses it to:

    • Check the age of the data.

    • Reject duplicate transmissions.

    • Determine the chronological order of received transmissions.

    • Determine the elapsed time between receipt of data transmissions.