[RQ6.12] The SAPI of the SafetyProvider represents the safety communication layer services of the SafetyProvider. Table 23 lists all inputs and outputs of the SAPI of the SafetyProvider. Each SafetyProvider shall implement the SAPI as shown in Table 23, however, the details are vendor-specific.
Table 23 – SAPI of the SafetyProvider
SAPI Term |
Type |
I/O |
Definition |
SafetyData |
Structure |
I |
This input is used to accept the user data which is then transmitted as SafetyData in the SPDU. NOTE Whenever a new MNR is received from a SafetyConsumer, the state machine of the SafetyProvider will read a new value of the SafetyData from its corresponding Safety Application and use it until the next MNR is received. NOTE If no valid user data is available at the Safety Application, ActivateFSV is expected to be set to “1” by the Safety Application. |
NonSafetyData |
Structure |
I |
Used to consistently transmit non-safety data values (e.g. diagnostic information) together with safe data, see 7.2.1.11 |
EnableTestMode
|
Boolean |
I |
By setting this input to “1” the remote SafetyConsumer is informed (by Bit 2 in ResponseSPDU.Flags, see 6.2.3.2) that the SafetyData are test data, and are not to be used for safety-related decisions. NOTE This document is intended for implementation in safety devices exclusively, see requirement RQ4.1. |
OperatorAckProvider |
Boolean |
I |
This input is used to implement an operator acknowledgment on the SafetyProvider side. The value will be forwarded to the SafetyConsumer, where it can be used to trigger a return from fail-safe substitute values (FSV) to actual process values (PV), see B.3.4. |
OperatorAckRequested |
Boolean |
O |
Indicates that an operator acknowledge is requested by the SafetyConsumer. This flag is received within the RequestSPDU. |
Boolean |
I |
By setting this input to “1” the SafetyConsumer is instructed (via Bit 1 in ResponseSPDU.Flags, see 6.2.3.2) to deliver FSV instead of PV to the safety application program. NOTE If the replacement of process values by FSV should be controllable in a more fine-grained way, this can be realized by using qualifiers within the SafetyData, see 6.3.6. |
|
SafetyConsumerID |
UInt32 |
O |
This output yields the ConsumerID used in the last access to this SafetyProvider by a SafetyConsumer (see 6.2.2.3). NOTE All safety-related checks are executed by an implementation of this document. The safety application is not required to check this SafetyConsumerID. |
MonitoringNumber |
UInt32 |
O |
This output yields the monitoring number (MNR). It is updated whenever a new request comes in from the SafetyConsumer. NOTE All safety-related checks are executed by an implementation of this document. The safety application is not required to check this Monitoring number. |
SafetyProviderID |
UInt32 |
I |
For dynamic systems, this input can be set to a non-zero value. In this case, the SafetyProvider uses this value instead of the value from the SPI parameter SafetyProviderIDConfigured. If the value is changed to “0”, the value of parameter SafetyProviderIDConfigured from the SPI will be used (again).See Figure 8, 3.1, and 9.1.1.
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 SafetyProvider uses this value instead of the value of the SPI parameter SafetyBaseIDConfigured. If the value is changed to “0”, the value of parameter SafetyBaseIDConfigured from the SPI will be used (again).See Figure 8, 3.1, and 9.1.1.
For static systems, this input is usually always kept at value “0”. |