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.

If no valid user data is available at the Safety Application, ActivateFSV can be set to “1” by the Safety Application.

NonSafetyData

Structure

I

Used to consistently transmit NonSafetyData 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.

ActivateFSV(Fail-safe substitutevalues)

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 is to 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).

Since 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 MonitoringNumber (MNR). It is updated whenever a new request comes in from the SafetyConsumer.

Since all safety-related checks are executed by an implementation of this document, the safety application is not required to check this MonitoringNumber.

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.2.15, 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.2.14, and 9.1.1.

For static systems, this input is usually always kept at value “0”.

Identifier

Type

Range

Initial value

(before configuration)

Access

Note

SafetyProviderIDConfigured

UInt32

0x0 to 0xFFFFFFFF

0x0

R/W

SafetyProviderID of the SafetyProvider that is normally used, see 3.1.2.15 and 9.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 SafetyProvider’s SAPI. This runtime value can be queried using the SafetyProviderIDActive parameter. See 6.2.2.6 for details on configured and active values.

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 35 and the macro <ParametersOK?> in Table 33.

SafetyBaseIDConfigured

Guid

Any value which can be represented with sixteen octets

All sixteenoctets are 0x00

R/W

SafetyBaseID of the SafetyProvider that is normally used, see 3.1.2.14 and 9.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 6.2.2.6 for details on configured and active values.

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 35 and the macro <ParametersOK?> in Table 33.

See 9.1.1 for more information on GUID.

SafetyProviderLevel

Byte

0x01 to 0x04

n.a.

R

The SIL the SafetyProvider implementation (hardware and software) is capable of, see Figure 9.

NOTE 1 It is independent from the generation of the SafetyData at SAPI.

NOTE 2 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

0x0 to 0xFFFFFFFF

0x0

R/W

Signature of the SafetyData structure, for calculation see 7.2.3.5.

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 35 and the macro <ParametersOK?> in Table 33.

SafetyStructureSignatureVersion

UInt16

0x1

0x1

R/W

Version used to calculate SafetyStructureSignature, see 7.2.3.5

SafetyStructureIdentifier

String

all strings

“” (the empty string)

R/W

Identifier describing the DataType of the SafetyData, see 7.2.3.5.

SafetyProviderDelay

UInt32

0x0 to 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 8.1.

The parameter SafetyProviderDelay has no influence on the functional behaviour of the SafetyProvider. Therefore, it is not necessary for this value to be generated in a safety-related way. 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 behaviour of the SafetyProvider is suitable to fulfill the watchdog delay of the corresponding SafetyConsumer.

SafetyServerImplemented

Boolean

0x0 or 0x1

n.a.

R

This read-only parameter indicates whether the SafetyProvider has implemented the Server part of OPC UA Client/Server communication (see 5.4):

1: Server for OPC UA Client/Server communication is implemented.

0: Server for OPC UA Client/Server communication is not implemented.

The corresponding Facets are SafetyProviderServer and SafetyProviderServerMapper.

SafetyPubSubImplemented

Boolean

0x0 or 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 5.4):

1: OPC UA PubSub communication is implemented.

0: OPC UA PubSub communication is not implemented.

The corresponding Facets are SafetyProviderPubSub and SafetyProviderPubSubMapper.