The SAPI of the SafetyConsumer represents the safety communication layer services of the SafetyConsumer. Table 25 lists all inputs and outputs of the SAPI of the SafetyConsumer.
[RQ6.14] Each SafetyConsumer shall implement the SAPI as shown in Table 25, however, the details are vendor-specific.
Table 25 – SAPI of the SafetyConsumer
SAPI Term |
Type |
I/O |
Definition |
SafetyData |
Structure |
O |
This output either delivers the process values received from the SafetyProvider in the SPDU field SafetyData, or FSV. |
NonSafetyData |
Structure |
O |
This output delivers the non-safety process values (e.g. diagnostic information) which were sent together with safe data, see 7.2.1.11 |
Enable |
Boolean |
I |
By changing this input to “0” the SafetyConsumer will change each and every Variable of the SafetyData to “0”1 and stop sending requests to the SafetyProvider. When changing Enable to “1” the SafetyConsumer will restart safe communication. The variable can be used to delay the start of the safety communication according to this document, after power on until “OPC UA connection ready” is set.The delay time is not monitored while enable is set to “0”. |
FSV_Activated |
Boolean |
O |
This output indicates via “1” that on the output SafetyData FSV (all binary “0”) are provided1. NOTE A ResponseSPDU which is checked with an error results in FSV_Activated being set to “1”, see T24 in Table 35. There could be other reasons. |
OperatorAckConsumer |
Boolean |
I |
For motivation, see 6.3.4.3. After an indication of OperatorAckRequested this input can be used to signal an operator acknowledgment. By changing this input from “0” to “1” (rising edge) the SafetyConsumer is instructed to switch SafetyData from FSV to PV. OperatorAckConsumer is processed only if this rising edge arrives after OperatorAckRequested was set to “1”, see Figure 19. If a rising edge of OperatorAckConsumer arrives before OperatorAckRequested becomes 1, this rising edge is ignored. |
OperatorAckRequested |
Boolean |
O |
This output indicates the request for operator acknowledgment. The bit is set to “1” by the SafetyConsumer, when three conditions are met: 1)Too many communication errors were detected in the past, so the SafetyConsumer decided to switch to fail-safe substitute values. 2)Currently, no communication errors occur, and hence operator acknowledgment is possible. 3)Operator acknowledgment (rising edge at input OperatorAckConsumer) has not yet occurred. The bit is reset to “0” when a rising edge at OperatorAckConsumer is detected. |
OperatorAckProvider |
Boolean |
O |
This output indicates that an operator acknowledgment has taken place on the SafetyProvider. If operator acknowledgment at the SafetyProvider should be allowed, this output is connected to OperatorAckConsumer, see B.3.4 and B.3.5. NOTE If the ResponseSPDU is checked with error, this output remains at its last value, see T24 in Table 35. |
TestModeActivated |
Boolean |
O |
The safety application program is expected to evaluate this output for determining whether the communication partner is in test mode or not. A value of “1” indicates that the communication partner (source of data) is in test mode, e.g. during commissioning. Data coming from a device in test mode may be used for testing but is not intended to be used to control safety-critical processes. A value of “0” represents the “normal” safety-related mode. The test mode enables the programmer and commissioner to validate the safety application using test data. NOTE If the ResponseSPDU check results in an error and the ErrorIntervalTimer (see 6.3.4.4) is also not expired, TestModeActivated is reset, see state S17_Error in Table 34. |
SafetyProviderID |
UInt32 |
I |
For dynamic systems, this input can be set to a non-zero value. In this case, the SafetyConsumer uses this variable instead of the SPI parameter SafetyProviderIDConfigured. This input is only read in the first cycle, or when a rising edge occurs at the input Enable. See also Table 26. If it is changed to “0”, the value of SPI parameter SafetyProviderIDConfigured will be used (again). For static systems, this input is usually always kept at value “0”. |
SafetyBaseID |
Guid |
I |
For dynamic systems, this input can be set to a non-zero value. In this case, the SafetyConsumer uses this variable instead of the SPI parameter SafetyBaseIDConfigured. This input is only read in the first cycle, or when a rising edge occurs at the input Enable. See also Table 26. If it is changed to “0”, the SPI parameter SafetyBaseIDConfigured will become activated. For static systems, this input is usually always kept at value “0”. |
SafetyConsumerID |
UInt32 |
I |
For dynamic systems, this input can be set to a non-zero value. In this case, the SafetyConsumer uses this variable instead of the SPI parameter SafetyConsumerID. This input is only read in the first cycle, or when a rising edge occurs at the input Enable. See also Table 26. If it is changed to “0”, the SPI parameter SafetyConsumerID will become activated. For static systems, this input is usually always kept at value “0”. |
1 If an application requires different FSV than “all binary 0”, it is expected to use appropriate constants and ignore the output of SafetyData whenever FSV_Activated is set. |