[RQ8.10] Figure 18 shows a simplified representation of the state diagram of the SafetyProvider. The exact behavior is described in Table 29, Table 30, and Table 31. The SafetyProvider shall implement that behavior. It is not required to literally follow the entries given in the tables, if the externally observable behavior does not change.

image023.png

Figure 18 – Simplified representation of the state diagram for the SafetyProvider

Table 28 – Symbols used for state machines.

Graphical representation

Type

Description

image024.png

Activity State

Within these interruptible activity states the SafetyProvider waits for new input.

image025.png

Action State

Within these non-interruptible action states events like new requests are deferred until the next activity state is reached, see [1].

The transitions are fired in case of an event. “Event” in this context means either a method call in the case of Client/Server communication or the detection of a changed RequestSPDU by the OPC UA mapper in the case of PubSub communication.

In case of several possible transitions, so-called guard conditions (refer to […] in UML diagrams) define which transition to fire.

The diagram consists of activity and action states. Activity states are surrounded by bold lines, action states are surrounded by thin lines. While activity states may be interruptible by new events, action states are not. External events occurring while the state machine is in an action state, are deferred until the next activity state is reached.

NOTE: The details on how to implement activity states and action states are vendor-specific. Typically, in a real-time system the task performing the SafetyProvider or SafetyConsumer state machine is executed cyclically (see 5.2). Whenever the task is woken up by the scheduler of the operating system while it is in an action state, it executes action states until its time slice is used up, or an activity state is reached. Whenever a task being in an activity state is woken up, it checks for input. If no new input is available, it immediately returns to the sleep state without changing state.

If input is available, it starts executing action states until its time-slice is up or until the next activity state is reached.

Table 29 – SafetyProvider instance internal items

INTERNAL ITEMS

TYPE

DEFINITION

RequestSPDU_i

Variable

Local Memory for RequestSPDU (required to react on changes).

SPDU_ID_1_i

UInt32

Local variable to store SPDU_ID_1

SPDU_ID_2_i

UInt32

Local variable to store SPDU_ID_2

SPDU_ID_3_i

UInt32

Local variable to store SPDU_ID_3

BaseID_i

GUID

Local variable containing the BaseID (taken either from the SPI or SAPI).

ProviderID_i

UInt32

Local variable containing the ProviderID (taken either from the SPI or SAPI).

<Get RequestSPDU>

Macro

Instruction to take the whole RequestSPDU from the OPC UA Mapper.

<Set ResponseSPDU>

Macro

Instruction to transfer the whole ResponseSPDU to the OPC UA Mapper

<Calc SPDU_ID_i>

Macro

const uint32 SafetyProviderLevel_ID := … // see Clause 8.2.3.3

If(SAPI.SafetyBaseID == 0) thenBaseID_i := SPI.SafetyBaseIDConfiguredElse BaseID_i := SAPI.SafetyBaseID

Endif If(SAPI.SafetyProviderID == 0) thenProviderID_i := SPI.SafetyProviderIDConfiguredElse ProviderID_i := SAPI.SafetyProviderID

Endif

SPDU_ID_1_i := BaseID_i (bytes 0…3) XOR SafetyProviderLevel_ID

SPDU_ID_2_i := BaseID_i (bytes 4…7) XOR SPI.SafetyStructureSignature

SPDU_ID_3_i := BaseID_i (bytes 8…11) XOR BaseID_i (bytes 12…15) XOR ProviderID_i

// see Clause 8.2.3.2 for clarification

<build ResponseSPDU>

Macro

Take the MNR and the SafetyConsumerID of the received RequestSPDU. Add the SPDU_ID_1_i, SPDU_ID_2_i, SPDU_ID_3_i, Flags, the SafetyData and the NonSafetyData, as well as the calculated CRC.

See Clause 8.2.3.1

Table 30 – States of SafetyProvider instance

STATE NAME

STATE DESCRIPTION

Initialization

// Initial state

SAPI.SafetyData := 0

SAPI.NonSafetyData := 0SAPI.MonitoringNumber := 0SAPI.SafetyConsumerID := 0

SAPI.OperatorAckRequested := 0

RequestSPDU_i := 0

S1_WaitForRequest

// waiting on next RequestSPDU from SafetyConsumer

<Get RequestSPDU>

S2_PrepareSPDU

ResponseSPDU.Flags.ActivateFSV := SAPI.ActivateFSVResponseSPDU.Flags.OperatorAckProvider := SAPI.OperatorAckProvider ResponseSPDU.Flags.TestModeActivated := SAPI.EnableTestMode

<Calc SPDU_ID_i>

<build ResponseSPDU> // see Clause 8.2.3.1

Table 31 – SafetyProvider transitions

TRAN-SITION

SOURCE STATE

TARGET STATE

GUARD CONDITION

ACTIVITY

T1

Init

S1

T2

S1

S2

// RequestSPDU received

-

// Process Request

RequestSPDU_i := RequestSPDU

SAPI.MonitoringNumber := RequestSPDU.MonitoringNumber

SAPI.SafetyConsumerID := RequestSPDU.SafetyConsumerID

SAPI.OperatorAckRequested := RequestSPDU.Flags.OperatorAckRequested

T3

S2

S1

// SPDU is prepared

-

<Set ResponseSPDU>

NOTE: the SafetyProvider does not check for correct configuration. It will reply to requests even if it is incorrectly configured (e.g., its SafetyProviderID is zero). However, SafetyConsumers will never try to communicate with SafetyProviders having incorrect parameters, see Transitions T13/T27 in Table 34 and the macro <ParametersOK?> in Table 32.