7 Safety communication layer services and management ToC Previous Next

7.3 SafetyProvider interfaces ToC Previous Next

7.3.2 SPI of SafetyProvider ToC Previous Next

[RQ7.2] Each SafetyProvider shall implement the parameters and constants [RQ7.3] as shown in Table 25. The parameters (R/W in column “Access”) can be set via the SPI, whereas the constants (R in column “Access”) are read-only. The mechanisms for setting the parameters are vendor-specific. The attempt of setting a parameter to a value outside its range shall not become effective, and a diagnostic message should be shown when appropriate. The values of the constants depend on the way the SafetyProvider is implemented. They never change and are therefore not writable via any of the interfaces.

Table 25 – SPI of the SafetyProvider

Identifier Type Range    Initial Value(before configuration) Access Note
SafetyProviderIDConfigured UInt32 0 - 0xFFFFFFFF 0x0 R/W    Provider-ID of the SafetyProvider that is normally used, see Clause 3.2 and Clause 11.1.1.      For dynamic systems, the safety application program can overwrite this ID by providing a non-zero value at the input SafetyProviderID of the Safety Provider’s SAPI. This runtime value can be queried using the SafetyProviderIDActive parameter. See note on configured and active values at Table 13.   Note: if both the values provided at the SPI and the SAPI are 0x0, this means that the SafetyProvider is not properly configured. SafetyConsumers will never try to communicate with SafetyProviders having a SafetyProviderID of 0x0, see Transitions T13/T27 in Table 30 and the macro <ParametersOK?> in Table 28.
SafetyBaseIDConfigured GUID any value which can be represented with sixteen bytes all sixteenbytes are 0x00 R/W    Base-ID of the SafetyProvider that is normally used, see Clause 3.2. and Clause 11.1.1.   For dynamic systems, the safety application program can overwrite this ID by providing a non-zero value at the input SafetyBaseID of the SafetyProvider’s SAPI. This runtime value can be queried using the SafetyBaseIDActive parameter. See note on configured and active values at Table 13.      Note: if both the values provided at the SPI and the SAPI are 0x0, this means that the SafetyProvider is not properly configured. SafetyConsumers will never try to communicate with SafetyProviders having a SafetyBaseID of 0x0, see Transitions T13/T27 in Table 30 and the macro <ParametersOK?> in Table 28.   See Clause 11.1.1 for more information on GUID.
SafetyProviderLevel    Byte 0x01 - 0x04 n.a. R    The SIL the SafetyProvider implementation (hardware & software) is capable of, see Figure 12.   NOTE: It is independent from the generation of the SafetyData at SAPI.NOTE: the SafetyProviderLevel is used to distinguish devices of a different SIL. As a result, SPDUs coming from a device with a low SIL will never be accepted when a SafetyConsumer is parameterized to implement a safety function with a high SIL.
SafetyStructureSignature UInt32 0 – 0xFFFFFFFF 0x0 R/W    Signature of the SafetyData structure, for calculation see Clause 8.1.3.4 Note: “0” would not be a valid signature and thus indicates a SafetyProvider which is not properly configured. SafetyConsumers will never try to communicate with SafetyProviders having a SafetyStructureSignature of 0x0, see Transitions T13/T27 in Table 30 and the macro <ParametersOK?> in Table 28.
SafetyStructureSignatureVersion UInt16 0x1 0x1 R/W Version used to calculate SafetyStructureSignature, see Clause 8.1.3.4
SafetyStructureIdentifier String all strings “” (the empty string) R/W Identifier describing the data type of the safety data, see Clause 8.1.3.4.
SafetyProviderDelay UInt32 0x0 – 0xFFFFFFFF 0x0 R/W    In microseconds (µs). It can be set during the engineering phase of the SafetyProvider or set during online configuration as well.   SafetyProviderDelay is the maximum time at the SafetyProvider from receiving the RequestSPDU to start the transmission of ResponseSPDU, see Clause 10.1.   The parameter SafetyProviderDelay has no influence on the functional behavior of the SafetyProvider. However, it will be provided in the OPC UA information model of a SafetyProvider to inform about its worst-case delay time. The value can be used during commissioning to check whether the timing behavior of the SafetyProvider is suitable to fulfill the watchdog delay of the corresponding SafetyConsumer.NOTE: This value does not need to be generated in a safety-related way.
SafetyServerImplemented Boolean 0x0 / 0x1 n.a. R    This read-only parameter indicates whether the SafetyProvider has implemented the server part of OPC UA Client/Server communication (see Clause 4.3):   1: Server for OPC UA Client/Server communication is implemented.0: Server for OPC UA Client/Server communication is not implemented.
SafetyPubSubImplemented Boolean 0x0 / 0x1 n.a. R    This read-only parameter indicates whether the SafetyProvider has implemented the necessary publishers and subscribers for OPC UA PubSub communication (see Clause 4.3):   1: OPC UA PubSub communication is implemented.0: OPC UA PubSub communication is not implemented.

readme_files/image016.png Figure 12 – Example combinations of SIL capabilities

The constant SafetyProviderLevel determines the value that is used for SafetyProviderLevel_ID when calculating the SPDU_ID, see Clause 8.1.3.3.

The respective SafetyConsumers (on the PLC and the actuator) need to know the SafetyProviderLevel of their providers for being able to check the SPDU_ID (see Clause 8.1.3.2).

Previous Next