Annex B Additional information (Informative)

B.1 CRC calculation using tables, for the polynomial 0xF4ACFB13

The calculation of a 32-bit CRC signature over an array of N octets with the help of lookup tables, using “C” as programming language, is shown below:

// VARIANT A: presumably easier to implement on little endian machines

uint32_t crctab32[256]; // lookup table

uint32_t CRC32_Backward(char *array, int16_t N){ // input is array of N octets

// containing the data,
see Figure 23

uint32_t result = 1; // seed value for the calculated CRC

int16_t i; // index

for(i=N-1;i>=0;i--) // process array in reversed order

result = crctab32 [((result >> 24) ^ array[i]) & 0xff] ^ (result << 8);

if (result==0)
return 1;
else
return result;

}

where the lookup-table crctab32 has to be initialized as shown in Table B.1.

// VARIANT B: presumably easier to implement on big endian machines

uint32_t crctab32[256]; // lookup table

uint32_t CRC32_Forward(char *array, int16_t N){ // input is array of N octets

// containing the data in reversed

// order, see e. g. Figure 24

uint32_t result = 1; // seed value for the calculated CRC

int16_t i; // index

for(i=0;i<N;i++) // process array

result = crctab32 [((result >> 24) ^ array[i]) & 0xff] ^ (result << 8);

if (result==0)
return 1;
else
return result;

}

where the lookup-table crctab32 has to be initialized as shown in Table B.1.

Table B.1 – The CRC32 lookup table for 32-bit CRC signature calculations
CRC32 lookup table (0 to 255)
00000000F4ACFB131DF50D35E959F6263BEA1A6ACF46E179261F175FD2B3EC4C
77D434D48378CFC76A2139E19E8DC2F24C3E2EBEB892D5AD51CB238BA567D898
EFA869A81B0492BBF25D649D06F19F8ED44273C220EE88D1C9B77EF73D1B85E4
987C5D7C6CD0A66F858950497125AB5AA3964716573ABC05BE634A234ACFB130
2BFC2843DF50D35036092576C2A5DE6510163229E4BAC93A0DE33F1CF94FC40F
5C281C97A884E78441DD11A2B571EAB167C206FD936EFDEE7A370BC88E9BF0DB
C45441EB30F8BAF8D9A14CDE2D0DB7CDFFBE5B810B12A092E24B56B416E7ADA7
B380753F472C8E2CAE75780A5AD98319886A6F557CC69446959F626061339973
57F85086A354AB954A0D5DB3BEA1A6A06C124AEC98BEB1FF71E747D9854BBCCA
202C6452D4809F413DD96967C97592741BC67E38EF6A852B0633730DF29F881E
B850392E4CFCC23DA5A5341B5109CF0883BA23447716D8579E4F2E716AE3D562
CF840DFA3B28F6E9D27100CF26DDFBDCF46E179000C2EC83E99B1AA51D37E1B6
7C0478C588A883D661F175F0955D8EE347EE62AFB34299BC5A1B6F9AAEB79489
0BD04C11FF7CB70216254124E289BA37303A567BC496AD682DCF5B4ED963A05D
93AC116D6700EA7E8E591C587AF5E74BA8460B075CEAF014B5B30632411FFD21
E47825B910D4DEAAF98D288C0D21D39FDF923FD32B3EC4C0C26732E636CBC9F5
AFF0A10C5B5C5A1FB205AC3946A9572A941ABB6660B6407589EFB6537D434D40
D82495D82C886ECBC5D198ED317D63FEE3CE8FB2176274A1FE3B82870A977994
4058C8A4B4F433B75DADC591A9013E827BB2D2CE8F1E29DD6647DFFB92EB24E8
378CFC70C32007632A79F145DED50A560C66E61AF8CA1D091193EB2FE53F103C
840C894F70A0725C99F9847A6D557F69BFE693254B4A6836A2139E1056BF6503
F3D8BD9B07744688EE2DB0AE1A814BBDC832A7F13C9E5CE2D5C7AAC4216B51D7
6BA4E0E79F081BF47651EDD282FD16C1504EFA8DA4E2019E4DBBF7B8B9170CAB
1C70D433E8DC2F200185D906F5292215279ACE59D336354A3A6FC36CCEC3387F
F808F18A0CA40A99E5FDFCBF115107ACC3E2EBE0374E10F3DE17E6D52ABB1DC6
8FDCC55E7B703E4D9229C86B66853378B436DF34409A2427A9C3D2015D6F2912
17A09822E30C63310A559517FEF96E042C4A8248D8E6795B31BF8F7DC513746E
6074ACF694D857E57D81A1C3892D5AD05B9EB69CAF324D8F466BBBA9B2C740BA
D3F4D9C9275822DACE01D4FC3AAD2FEFE81EC3A31CB238B0F5EBCE9601473585
A420ED1D508C160EB9D5E0284D791B3B9FCAF7776B660C64823FFA4276930151
3C5CB061C8F04B7221A9BD54D505464707B6AA0BF31A51181A43A73EEEEF5C2D
4B8884B5BF247FA6567D8980A2D1729370629EDF84CE65CC6D9793EA993B68F9
This table contains 32-bit values in hexadecimal representation for each value (0 to 255) of the argument a in the function crctab32 [a]. The table should be used line-by-line in ascending order from top left (0) to bottom right (255). For instance, crctab32[10] is highlighted using a darker background and red colour.

B.2 Use cases

B.2.1 Unidirectional communication

The most basic type of communication is unidirectional communication, where a safety application on one device (Controller A in Figure B.1) sends data to a safety application on another device (Controller B in Figure B.1).

Figure B.1 – Unidirectional communication

This is accomplished by placing a SafetyProvider on Controller A and a SafetyConsumer on Controller B. The connection between SafetyProvider and SafetyConsumer can be established and terminated during runtime, allowing different consumers to connect to the same SafetyProvider at different times. Furthermore, the protocol is designed in such a way, that it is necessary for the SafetyConsumer to know the parametrized set of IDs of the SafetyProvider such that it is able to safely check whether the received data is coming from the expected source. On the other hand, as SafetyData flows in one direction only, it is not necessary for the SafetyProvider to check the ID of the SafetyConsumers. Hence, Controller A can – one after another – serve an arbitrarily large number of SafetyConsumers, and new SafetyConsumers can be introduced into the system without having to update Controller A.

B.2.2 Bidirectional communication

Bidirectional communication means the exchange of data in both directions, which is accomplished by placing a SafetyProvider and a SafetyConsumer on each controller. Hence, bidirectional communication is realized using two safety connections according to this document. See Figure B.2 for an example.

Figure B.2 – Bidirectional communication

B.2.3 Safety Multicast

Multicast is defined as sending the same set of data from one device (Controller A) to several other devices (Controller B1, B2,…,BN) simultaneously.

Figure B.3 – Safety multicast

Safety multicast is accomplished by placing multiple SafetyProviders on Controller A, and one SafetyConsumer on each of the Controllers B1, B2, … BN. Each of the SafetyProviders running on Controller A is connecting to one of the SafetyConsumers running on one of the Controllers B1, B2, … BN. See Figure B.3 for an example.

The safety protocol in this document is designed in such a way that:

Therefore, even if many SafetyProviders are instantiated on a device, the performance requirements will still be moderate.

The properties of simple unicast are also valid for safety multicast; different sets of consumers can connect to SafetyProviders at different times, and new SafetyConsumers can be introduced into the system without having to reconfigure the SafetyProvider instances. As all SafetyProvider instances send the same safety application data (the same data source), it is irrelevant from a safety point of view to which SafetyProvider instance a given SafetyConsumer is connected. Thus, all SafetyProvider instances can be parametrized with the same set of IDs for the SafetyProvider.

B.3 Use cases for Operator Acknowledgment

B.3.1 Explanation

This document supports operator acknowledgment both on the SafetyProvider side and on the SafetyConsumer side. For this purpose, both the interface of the SafetyProvider and the SafetyConsumer comprise a Boolean input called OperatorAckProvider and OperatorAckConsumer, respectively. The safety application can get the values of these parameters on the consumer side via the Boolean outputs OperatorAckRequested and OperatorAckProvider on the SafetyConsumer’s SAPI (see 6.3.4.2).

Subclauses B.3.2 to B.3.5 show some examples on how to use these inputs and outputs. Dashed lines indicate that the corresponding input or output is not used in the use case. For details, see 6.3.3 and 6.3.4.

B.3.2 Use case 1: unidirectional communication and OA on the SafetyConsumer side

Figure B.4 – OA in unidirectional safety communication

In the scenario shown in Figure B.4, operator acknowledgment is done on the SafetyConsumer side, operator acknowledgment on the SafetyProvider side is not possible.

B.3.3 Use case 2: bidirectional communication and dual OA

Figure B.5 – Two-sided OA in bidirectional safety communication

In the scenario shown in Figure B.5, operator acknowledgment is done independently for both directions.

B.3.4 Use case 3: bidirectional communication and single, one-sided OA

Figure B.6 – One sided OA in bidirectional safety communication

In the scenario of Figure B.6, an operator acknowledgment activated at controller A suffices for re-establishing the bidirectional connection. Both sides will cease delivering fail-safe values and continue sending process values. This is accomplished by connecting OperatorAckProvider with OperatorAckConsumer at the SafetyConsumer of controller B. Activating operator acknowledgment at controller B is not possible in this scenario.

B.3.5 Use case 4: bidirectional communication and single, two-sided OA

Figure B.7 – One sided OA on each side is possible

Figure B.7 shows a scenario where an operator acknowledgment activated at controller A or controller B suffices for re-establishing the bidirectional connection. Both sides will cease delivering fail-safe values and continue sending process values. This is accomplished by the logic circuits shown in the safety applications.