7 Safety communication layer services and management ToC Previous Next

7.3 SafetyProvider interfaces ToC Previous Next

Figure 10 shows an overview of the SafetyProvider interfaces. The SAPI is specified in Clause 7.3.1, the SPI is specified in Clause 7.3.2.

readme_files/image012.png Figure 10 – SafetyProvider interfaces

7.3.1 SAPI of SafetyProvider ToC Previous Next

[RQ7.1] The SAPI of the SafetyProvider represents the Safety communication layer services of the SafetyProvider. Table 13 lists all inputs and outputs of the SAPI of the SafetyProvider. Each SafetyProvider shall implement the SAPI as shown in Table 13, however, the details are vendor specific.

Table 13 – SAPI of the SafetyProvider

SAPI Term Type Definition
SafetyData Structure 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 Used to consistently transmit non-safety data values (e.g. diagnostic information) together with safe data, see Clause 8.1.1.10
EnableTestMode
Boolean By setting this input to “1” the remote SafetyConsumer is informed (by Bit 2 in ResponseSPDU.Flags, see Table 19) that the SafetyData are test data, and is not to be used for safety related decisions. NOTE: The OPC UA Safety stack is intended for implementation in safety devices exclusively, see Clause 4.2.
OperatorAckProvider Boolean This input to is used to implement an operator acknowledgment on the provider side. The value will be forwarded to the consumer, where it can be used to trigger a return from fail-safe substitute values (FSV) to actual process values (PV), see Annex B.2.4.
ActivateFSV (Fail-safe Substitute Values) Boolean By setting this input to “1” the SafetyConsumer is instructed (via Bit 1 in ResponseSPDU.Flags, see Table 19) 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 Clause 5.3.
SafetyConsumerID UInt32 This output yields the ConsumerID used in the last access to this SafetyProvider by a SafetyConsumer see Clause 176.1.1.
NOTE: all safety-related checks are executed by OPC UA Safety. The safety application is not required to check this SafetyConsumerID.
MonitoringNumber UInt32 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 OPC UA Safety. The safety application is not required to check this Monitoring number.
SafetyProviderID UInt32 By changing this input to a non-zero-value, the SafetyProvider uses this variable instead of the SPI-Parameter SafetyProviderID. If it is changed to “0”, the parameter SafetyProviderID will become activated. See Figure 10, Clause 3.2.26, and Clause 11.1.1.
SafetyBaseID GUID By changing this input to a non-zero-value, the SafetyProvider uses this variable instead of the SPI-Parameter SafetyBaseID. If it is changed to “0”, the parameter SafetyBaseID will become activated. See Figure 10, Clause 3.2.25, and Clause 11.1.1.

Previous Next