1 Scope

This document describes a safety communication layer (services and a protocol) for the exchange of SafetyData using OPC UA mechanisms. It identifies the principles for functional safety communications defined in IEC 61784‑3 that are relevant for this safety communication layer. This safety communication layer is intended for implementation in safety devices only.

This document defines mechanisms for the transmission of safety-relevant messages among participants within a network using OPC UA technology in accordance with the requirements of the IEC 61508 series and IEC 61784-3 for functional safety. These mechanisms can be used in various industrial applications such as process control, manufacturing, automation, and machinery.

This document provides guidelines for both developers and assessors of compliant devices and systems.

2 Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

IEC 61508 (all parts), Functional safety of electrical/electronic/programmable electronic safety-related systems

IEC 61784‑3:2021, Industrial communication networks – Profiles – Part 3: Functional safety fieldbuses – General rules and profile definitions

IEC 62443 (all parts), Industrial communication networks – Network and system security

OPC 10000-1, OPC Unified Architecture – Part 1: Overview and Concepts

OPC 10000-3, OPC Unified Architecture – Part 3: Address Space Model

OPC 10000-4, OPC Unified Architecture – Part 4: Services

OPC 10000-5, OPC Unified Architecture – Part 5: Information Model

OPC 10000-6, OPC Unified Architecture – Part 6: Mappings

OPC 10000-14, OPC Unified Architecture – Part 14: PubSub

ISO/IEC 9834-8:2014, Information technology – Procedures for the operation of object identifier registration authorities – Part 8: Generation of universally unique identifiers (UUIDs) and their use in object identifiers

3 Terms, definitions, symbols, abbreviated terms and conventions

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000‑4, OPC 10000-6 and the following apply.

ISO and IEC maintain terminology databases for use in standardization at the following addresses:

• IEC Electropedia: available at https://www.electropedia.org/

• ISO Online browsing platform: available at https://www.iso.org/obp

3.1.1 Common terms and definitions

3.1.1.1 Cyclic Redundancy Check

<method> procedure used to calculate the redundant data

3.1.1.2 error

discrepancy between a computed, observed or measured value or condition and the true, specified or theoretically correct value or condition

3.1.1.3 failure

termination of the ability of a functional unit to perform a required function or operation of a functional unit in any way other than as required

3.1.1.4 fault

abnormal condition that may cause a reduction in, or loss of, the capability of a functional unit to perform a required function

3.1.1.5 message

<information theory and communication theory> ordered sequence of characters (usually octets) intended to convey information

3.1.1.6 performance level

discrete level used to specify the ability of safety-related parts of control systems to perform a safety function under foreseeable conditions

3.1.1.7 residual error probability

probability of an error undetected by the SCL safety measures

3.1.1.8 residual error rate

statistical rate at which the SCL safety measures fail to detect errors

3.1.1.9 safety communication layer

communication layer above the OPC UA communication stack that includes all necessary additional measures to ensure safe transmission of data in accordance with the requirements of IEC 61508

3.1.1.10 safety function response time

worst case elapsed time following an actuation of a safety sensor connected to a fieldbus, until the corresponding safe state of its safety actuator(s) is achieved in the presence of errors or failures in the safety function

3.1.1.11 safety integrity level

discrete level (one out of a possible four), corresponding to a range of safety integrity values, where safety integrity level 4 has the highest level of safety integrity and safety integrity level1 has the lowest

3.1.1.12 safety measure

measure to control possible communication errors that is designed and implemented in compliance with the requirements of IEC 61508

3.1.1.13 safety PDU

PDU transferred through the safety communication channel

3.1.2 Additional terms and definitions

3.1.2.1 fail-safe

ability of a system that, by adequate technical or organizational measures, prevents from hazards either deterministically or by reducing the risk to a tolerable measure

3.1.2.2 fail-safe substitute values

values which are issued or delivered instead of process values when the safety function is set to a fail-safe state

3.1.2.3 flag

one-bit value used to indicate a certain status or control information

3.1.2.4 Globally Unique Identifier

128-bit number used to identify information in computer systems

3.1.2.5 MonitoringNumber

means used to ensure the correct order among transmitted safety PDUs and to monitor the communication delay

3.1.2.6 Non-safety-

predicate meaning that the respective object is a “standard” object and has not been designed and implemented to fulfil any requirements with respect to functional safety

3.1.2.7 OPC UA Mapper

non-safety-related part of the implementation of this document which maps the SPDU to the actual OPC UA services

3.1.2.8 process values

input and output data (in a safety PDU) that are required to control an automated process

3.1.2.9 qualifier

attribute (bit or Boolean), indicating whether the corresponding value is valid or not (e.g. being a fail-safe substitute value)

3.1.2.10 SafetyAutomationComponent

communication partner in a unidirectional safety link

3.1.2.11 SafetyConsumer

entity (usually software) that implements the data sink of a unidirectional safety link

3.1.2.12 SafetyData

application data transmitted across a safety network using a safety protocol

3.1.2.13 SafetyProvider

entity (usually software) that implements the data source of a unidirectional safety link

3.1.2.14 SafetyBaseID

randomly generated authenticity ID which is used to safely authenticate SafetyProviders having the same SafetyProviderID

3.1.2.15 SafetyProviderID

user-assigned, locally unique identifier which is used to safely authenticate SafetyProviders within a certain area

3.1.2.16 standard transmission system

part of the transmission system (implemented in hardware and software) that is not implemented according to any safety standards

3.2 Symbols and abbreviated terms

For the purposes of this document, the following symbols and abbreviated terms apply.

3.2.1 Abbreviated terms from IEC 61784-3

3.2.2 Additional symbols and abbreviated terms

3.2.2.1 Abbreviated terms

3.2.2.2 Symbols

3.3 Conventions

3.3.1 General conventions

Italics are used to denote a defined term or definition that appears in 3.1.

Italics are also used to denote the name of a service input or output parameter or the name of a structure or element of a structure that are usually defined in tables.

The italicized terms and names are also often written in camel-case (the practice of writing compound words or phrases in which the elements are joined without spaces, with each element's initial letter capitalized within the compound). For example, the defined term is AddressSpace instead of Address Space. This makes it easier to understand that there is a single definition for AddressSpace, not separate definitions for Address and Space. Terms or names where two capital letters of abbreviations are in sequence or for separation to a suffix are written with underscores in between.

The abbreviation “F” is an indication for safety- related items, technologies, systems, and units (fail-safe, functional safe).

The default data that are used in case of unit failures or errors, are called fail-safe substitute values (FSV) and are set to binary “0”.

Reserved bits (“res”) are set to “0” and ignored by the receiver to avoid problems with future versions of this document.

The notation 0x… represents a hexadecimal value.

3.3.2 Conventions for requirements numbering

Requirements in this document are designated as [RQx.yz], where x denotes the chapter number, y is a counter and z is an optional character to link closely related requirements. The following are examples of valid requirements designations: [RQ8.15] (requirement 15 in chapter 8); [RQ47.11a], [RQ47.11b] (requirements 11a and 11b in chapter 47, which are closely related).

The initial numbering of requirements was chosen such that counters within each chapter are in ascending order. However, the addition of further requirements leads to deviations from this rule since existing requirements shall keep their initial designation.

For an informative index of all the requirements in this document, see 10.3.

3.3.3 Conventions in state machines

See Table 1 for the conventions used in state machines.

4 Overview of OPC UA Safety

4.1 General

This document specifies a safety communication layer (SCL) allowing safety-related devices to use the services of OPC UA for the safe exchange of safety-related data. A safety device that implements OPC UA Safety correctly will be able to exchange safety-related data and hereby fulfill the requirements of the IEC 61508 series and IEC 61784-3. This document uses a MonitoringNumber, a timeout, a set of IDs and a cyclic redundancy check (CRC)code for the detection of all possible communication errors which can happen in the underlying OPC UA standard transmission system. These safety measures have been quantitatively evaluated and offer a probability of dangerous failure per hour (PFH) and a probability of dangerous failure on demand (PFD) sufficing to build safety-related applications with a safety integrity level of up to SIL4.

OPC UA Safety itself is an application-independent, general solution. The length and structure of the data sent is defined by the safety application. However, application-dependent companion specifications (addressing for example electro-sensitive protective equipment, electric drives with safety functions, forming presses, robot safety, and automated guided vehicles) are expected to be defined by application-experts in appropriate OPC UA companion specifications.

4.2 Implementation aspects

[RQ4.1] All technical measures for error detection described in this document shall be implemented within the SCL in devices designed in accordance with the IEC 61508 series and shall meet the target SIL.

4.3 Features

• Runs on top of:

OPC UA Client/Server with the Method Service Set.

OPC UA PubSub.

• From an architectural point of view: easy extensibility for other ways of communication.

• goal: no modification of existing OPC UA framework.

• The state machines of this document are independent from the OPC UA Mapper, allowing for a simplified exchange of the mapper.

• Ready for wireless transmission channels.

• Modest requirements on safety network nodes:

No clock synchronization is necessary (no requirements regarding the accuracy between clocks at different nodes).

Within the SafetyConsumer, a safety-related, local timer is required for implementing the SafetyConsumerTimeout. The accuracy of this timer depends on the timing requirements of the safety application.

• End-to-End Safety: functional SafetyData is transported between two safety endpoint devices across a standard network that is not functionally safety compliant. This includes the lower transport layers such as the OPC UA stack, underlying physical media, and non-safety network elements (e.g. routers and switches).

• “Dynamic” systems:

Safety communication partners can change during runtime,

either an increase or decrease, or both, in the number of safety communication partners can occur.

• Well-defined text-strings are used for diagnostic purposes.

• Safety communication and standard communication are independent. However, standard devices and safety devices can use the same standard transmission system at the same time.

• Functional safety can be achieved without using structurally redundant standard transmission systems i.e. a single channel approach can be used. Redundancy can be used optionally for increased availability.

• For diagnostic purposes, the last SPDU sent and received is accessible in the Information Model of the SafetyProvider.

• Length of user data: 1 octet to 1 500 octets, structures of basic DataTypes, see 6.2.5.

4.4 Security policy

In the final application, an appropriate security environment is necessary to protect both the operational environment and the safety-related systems.

This document does not cover security aspects, nor does it provide any requirements for security.

A threat and risk analysis (TRA) according to the IEC 62443 series shall be carried out on a final application system level.

During compliance tests for this document, security aspects are not part of the scope, as it is assumed that the underlying base mechanisms (i.e. Methods) already provide adequate security.

5 General

5.1 External documents providing specifications for the profile

No other external documents are providing specifications in addition to the Normative references given in Clause 2.

5.2 Safety functional requirements

The following requirements apply for the development of this document:

1. Safety communication suitable for safety integrity level up to SIL4 (see the IEC 61508 series) and PL e (see ISO 13849‑1).

2. Combination of SIL 1 to 4 devices according to this document as well as non-safety devices on one communication network.

3. Implementation of the safety transmission protocol is restricted to the safety layer.

4. The safety-relevant time-out monitoring is implemented in the safety layer.

5. Safety communication meet the requirements of IEC 61784‑3.

6. [RQ5.1] This document is intended for implementation in safety devices exclusively. Exceptions (e.g. for debugging, simulation, testing, and commissioning) shall be discussed with a notified body.

5.3 Safety measures

[RQ5.2] For an implementation of this document, the following safety measures shall be implemented: MonitoringNumber; timeout with receipt in the SafetyConsumer; set of IDs for the SafetyProvider; Data Integrity check.

Together, these safety measures address all possible transmission errors as listed in IEC 61784‑3:2021, 5.5, see Table 2.

[RQ5.3] The safety measures shall be processed and monitored within the SCL.

The SafetyConsumer is specified in such a way that for any communication error according to Table 2, a defined fault reaction will occur.

In all cases, the faulty SPDU will be discarded, and not forwarded to the safety application.

Moreover, if the error rate is too high, the SafetyConsumer is defined in such a way that it will cease to deliver actual process values to the safety application but will deliver fail-safe substitute values instead. In addition, an indication at the Safety Application Program Interface is set which can be queried by the safety application.

In case the error rate is still considered acceptable, the state machine repeats the request, see 9.4.

5.4 Safety communication layer structure

This document is based on:

• the standard transmission system according to OPC UA

• an additional safety transmission protocol on top of this standard transmission system

Safety applications and standard applications share the same standard OPC UA communication systems at the same time. The safe transmission function incorporates safety measures to detect faults or hazards that originate in the standard transmission system which have a potential to compromise the safety subsystems. This includes faults such as:

• Random errors, for example due to electromagnetic interference on the transmission channel;

• Failures or faults of the standard hardware;

• Systematic malfunctions of components within the standard hardware and software.

This principle delimits the assessment effort to the “safe transmission functions”. The standard transmission system does not require any additional functional safety assessment.

The basic communication layers of this document are shown in Figure 2.

Summary of the architecture:

Part: User Layer

The safety applications in the User Layer are either directly connected to the SafetyProvider or SafetyConsumer, or they are connected via a machine-specific or process-specific interface, which is described in companion specifications (e.g. sectoral).

The safety applications are expected to be designed and implemented according to the IEC 61508 series.

The Safety applications in the User Layer are not within the scope of this document.

Part: OPC UA Safety (Safety Communication Layer)

This layer is within the scope of this document. It defines the two services SafetyProvider and SafetyConsumer as basic building blocks. Together, they form the safety communication layer (SCL), implemented in a safety-related way according to the IEC 61508 series.

SafetyData is transmitted using point-to-point communication (unidirectional). Each unidirectional data flow internally communicates in both directions, using a requestand response pattern. This allows for checking the timeliness of messages using a single clock in the SafetyConsumer, thus eliminating the necessity for synchronized clocks.

When SafetyConsumers connect to SafetyProviders, they have prior expectations regarding the pair of SafetyProviderID and SafetyBaseID (e.g. by configuration). If this expectation is not fulfilled by the SafetyProvider, fail-safe substitute values are delivered to the safety application instead of the received process values. In contrast, it is not necessary for a SafetyProvider to know the SafetyConsumerID of the SafetyConsumer and will provide its process values to any SafetyConsumer requesting it.

SafetyProviders can not detect communication errors. All required error detection is performed by the SafetyConsumer.

If it is necessary for a pair of safety applications to exchange SafetyData in both directions, two pairs of SafetyProviders and SafetyConsumers shall be established, one pair for each direction.

The OPC UA Mapper implements the parts of the safety communication layer which are specific for the OPC UA communication Service in use, i.e. PubSub or Client/Server. Therefore, the remaining parts of the safety communication layer can be implemented independent of the OPC UA Service being used.

Part: OPC UA Layer

Client/Server:

• The SafetyProvider is implemented using an OPC UA Server providing a Method.

• The SafetyConsumer is implemented using an OPC UA Client calling the Method provided by the SafetyProvider.

PubSub:

• The SafetyProvider publishes the ResponseSPDU and subscribes to the RequestSPDU.

• The SafetyConsumer publishes the RequestSPDU and subscribes to the ResponseSPDU.

5.5 Requirements for CRC calculation

[RQ5.4] Any CRC signature calculation shall start with a preset value of “1”.

[RQ5.5] Any CRC signature calculation resulting in a “0” value, shall use the value “1” instead.

[RQ5.6] SPDUs with all values (incl. CRC signature) being zero shall be ignored by the receiver (SafetyConsumer and SafetyProvider). For Client/Server communication, this means that a Method Call with all fields making up the RequestSPDU being zero shall be answered with all fields making up the ResponseSPDU being zero. Neither of these SPDUs shall be presented to the respective state machines.

6 Safety communication layer services

6.1 General

Clause 6 describes the integration of this document into the OPC UA Information Models in 6.2 and the resulting Service interfaces in 6.3. Diagnostic services are described in 6.4.

6.2 Information models

6.2.1 General

Subclause 6.2 describes the identifiers, types and structure of the Objects and Methods that are used to implement the OPC UA mappers defined in this document. This implementation serves three purposes:

• support of the safe exchange of SPDUs at runtime

• online browsing, to identify SafetyConsumers and SafetyProviders, and to check their parameters for diagnostic purposes

• offline engineering: the Information Model of one controller can be exported in a standardized file on its engineering system, be imported in another engineering system, and finally deployed on another controller. This allows for a vendor-independent exchange of the communication interfaces of safety applications, e.g. for establishing connections between devices.

Consequently, all type values described in 6.2 are defined as read-only, i.e. they cannot be written by general OPC UA write commands.

6.2.2 Object and ObjectType Definitions

6.2.2.1 SafetyACSet Object

[RQ6.1] Each Server shall have a singleton Folder called SafetyACSet with a fixed NodeID in the Namespace of this document. Because all SafetyProviders and SafetyConsumers on this Server contain a hierarchical Reference from this Object to themselves, it can be used to directly access all SafetyProviders and SafetyConsumers. SafetyACSet is intended for safety-related purposes only. It should not reference non-safety-related items.

See Table 3 for the definition of the SafetyACSet.

[RQ6.2] In addition, a Server shall comprise one OPC UA Object derived from DataType SafetyProviderType for each SafetyProvider it implements, and one OPC UA Object derived from DataType SafetyConsumerType for each SafetyConsumer it implements. The corresponding Information Models shown in Figure 3 and Figure 4 shall be used.

A description of the graphical notation for the different types of Nodes and References (shown in Figure 3, Figure 4, and Figure 6) can be found in OPC UA 10000-3.

Figure 3 describes the SafetyProvider and the SafetyConsumer.

[RQ6.3a] For implementations supporting OPC UA Client/Server, the Call Service of the Method Service Set (see OPC UA 10000-4) shall be used. The Method ReadSafetyData has a set of input arguments that make up the RequestSPDU and a set of output arguments that make up the ResponseSPDU. The SafetyConsumer uses the OPC UA Client with the OPC UA Service Call.

[RQ6.3b] For implementations supporting OPC UA PubSub, the OPC UA Object SafetyPDUs with its Properties RequestSPDU and ResponseSPDU shall be used. RequestSPDU is published by the SafetyConsumer and subscribed by the SafetyProvider. ResponseSPDU is published by the SafetyProvider and subscribed by the SafetyConsumer.

[RQ6.4] For diagnostic purposes, the SPDUs received and sent shall be accessible by calling the Method ReadSafetyDiagnostics.

Figure 4 shows the instances of Server Objects for this document. The ObjectType for the SafetyProviderType contains Methods having outputs of the abstract DataType Structure. Each instance of a SafetyProvider requires its own copy of the Methods which contain the concrete DataTypes for OutSafetyData and OutNonSafetyData.

6.2.2.2 Safety ObjectType definitions

[RQ6.5] To reduce the number of variations and to alleviate validation testing, the following restrictions apply to instances of SafetyProviderType and SafetyConsumerType (or instances of DataTypes derived from SafetyProviderType or SafetyConsumerType):

1. The references shown in Figure 4 originating at SafetyProviderType or SafetyConsumerType and below shall be of ReferenceType HasComponent (and shall not be derived from ReferenceType HasComponent) for Object References or ReferenceType HasProperty (and shall not be derived from ReferenceType HasProperty) for Property References.

2. As BrowseNames (i.e. name and Namespace) are used to find Methods, the names of Objects and Properties shall be locally unique.

3. The DataType of both Properties and MethodArguments shall be used as specified, and no derived DataTypes shall be used (exception: OutSafetyData and OutNonSafetyData).

4. In IEC 62541, the order of Method arguments is relevant.

See Table 4 for the definition of the SafetyObjectsType.

See Table 5 for the definition of the SafetyProviderType.

[RQ6.6] Instances of SafetyProviderType shall use non-abstract DataTypes for the arguments OutSafetyData and OutNonSafetyData.

See Table 6 for the definition of the SafetyConsumerType.

6.2.2.3 Method ReadSafetyData

This Method is mandatory for the Facet SafetyProviderServerMapper. It is used to read SafetyData from the SafetyProvider. It is in the responsibility of the safety application that this Method is not concurrently called by multiple SafetyConsumers. Otherwise, the SafetyConsumer can receive invalid responses resulting in a safe reaction which can lead to either spurious trips or system unavailability, or both.

See Table 7 for Method ReadSafetyData’s arguments and Table 8 for its AdressSpace definition.

The Method argument OutSafetyData has an application-specific DataType derived from Structure. This DateType (including the DataTypeID) is expected to be the same in both the SafetyProvider and the SafetyConsumer. Otherwise, the SafetyConsumer will not accept the transferred data and switch to fail-safe substitute values instead (see state S16 in Table 34 as well as 7.2.3.2 and 7.2.3.5). The Method argument OutNonSafetyData has an application-specific DataType derived from Structure.

Signature

	ReadSafetyData (
		[in]	UInt32	InSafetyConsumerID,
		[in]	UInt32	InMonitoringNumber,
		[in]	InFlagsType	InFlags,
		[out]	Structure	OutSafetyData,
		[out]	OutFlagsType	OutFlags,
		[out]	UInt32	OutSPDU_ID_1,
		[out]	UInt32	OutSPDU_ID_2,
		[out]	UInt32	OutSPDU_ID_3,
		[out]	UInt32	OutSafetyConsumerID,
		[out]	UInt32	OutMonitoringNumber,
		[out]	UInt32	OutCRC,
		[out]	Structure	OutNonSafetyData)
	;

6.2.2.4 Method ReadSafetyDiagnostics

This Method is mandatory for the Facet SafetyProviderServerMapper and optional for the Facet SafetyProviderPubSubMapper. It is provided for each SafetyProvider serving as a Diagnostic Interface, see 6.4.3.

See Table 9 for the arguments of Method ReadSafetyDiagnostics and Table 10 for its AddressSpace definition.

The Method arguments OutSafetyData and OutNonSafetyData are application-specific types derived from Structure.

Signature

	ReadSafetyDiagnostics (
		[out]	UInt32	InSafetyConsumerID,
		[out]	UInt32	InMonitoringNumber,
		[out]	InFlagsType	InFlags,
		[out]	Structure	OutSafetyData,
		[out]	OutFlagsType	OutFlags,
		[out]	UInt32	OutSPDU_ID_1,
		[out]	UInt32	OutSPDU_ID_2,
		[out]	UInt32	OutSPDU_ID_3,
		[out]	UInt32	OutSafetyConsumerID,
		[out]	UInt32	OutMonitoringNumber,
		[out]	UInt32	OutCRC,
		[out]	Structure	OutNonSafetyData)
		;

6.2.2.5 Object SafetyPDUs

This Object is mandatory for the Facet SafetyProviderPubSubMapper and the Facet SafetyConsumerPubSubMapper It is used by the SafetyProvider to subscribe to the RequestSPDU and to publish the ResponseSPDU. The DataType of RequestSPDU is structured in the same way as the input arguments of ReadSafetyData. The DataType of ResponseSPDU is structured in the same way as the output arguments of ReadSafetyData.

See Table 11 for the definition of the SafetyPDUsType.

Both variables in the SafetyPDUsType have a counterpart within the Information Model of the SafetyConsumer. The SafetyConsumer publishes the RequestSPDU and subscribes to the ResponseSPDU.

The Object SafetyPDUs shall contain exactly one Reference to a Variable of DataType RequestSPDUDataType and exactly one Reference to a Variable of a subtype of DataType ResponseSPDUDataType.

For example, Figure 5 shows a distributed safety application with four SafetyAutomationComponents. It is assumed that SafetyAutomationComponent 1 sends a value to the other three SafetyAutomationComponents using three SafetyProviders, each comprising a pair of SPDUs. For each recipient, there is an individual pair of SPDUs.

6.2.2.6 Objects SafetyProviderParameters and SafetyConsumerParameters

Figure 6 shows the safety parameters for the SafetyProvider and the SafetyConsumer.

Table 12 shows the definition for the SafetyProviderParametersType. Refer to 6.3.3.3 for more details on the Safety Parameter Interface (SPI) of the SafetyProvider.

The parameters for SafetyProviderID and SafetyBaseID exist in pairs for “Configured” and “Active” states:

• SafetyProviderIDConfigured and SafetyProviderIDActive,

• SafetyBaseIDConfigured and SafetyBaseIDActive.

The “[...]Configured” parameters shall always deliver the values as configured via the SPI. The “[...]Active” parameters shall deliver:

• the corresponding “[...]Configured” values if the system is still offline;

• the values which have been set during runtime via the SAPI parameters (SafetyProviderID, SafetyBaseID);

• the corresponding “[...]Configured” values if the active values have been set to zero via the SAPI parameters (SafetyProviderID, SafetyBaseID).

The Property SafetyBaseIDConfigured is shared for all SafetyProviders with the same SafetyBaseIDConfigured value. If multiple instances of SafetyObjectsType are running on the same Node, it is a viable optimization that a Property SafetyBaseIDConfigured is referenced by either multiple SafetyProviders or SafetyConsumers, or both.

For releases up to Release 2.0 of the document, the value for the SafetyStructureSignatureVersion shall be 0x0001 (see RQ7.21 in 7.2.3.5).

Table 13 shows the definition of the SafetyConsumerParametersType. The Properties SafetyStructureIdentifier and SafetyStructureSignatureVersion are optional, because SafetyStructureSignature is typically calculated in an offline engineering tool. For small devices, it could be beneficial to only upload the SafetyStructureSignature to the device, but not SafetyStructureIdentifier and SafetyStructureSignatureVersion in order to save either bandwidth or memory, or both. Refer to 6.3.4.4 for more details on the Safety Parameter Interface (SPI) of the SafetyConsumer.

The parameters for SafetyProviderID, SafetyBaseID and SafetyConsumerID exist in pairs for “Configured” and “Active” states: SafetyProviderIDConfigured and SafetyProviderIDActive, SafetyBaseIDConfigured and SafetyBaseIDActive, and SafetyConsumerIDConfigured and SafetyConsumerIDActive.

The “[...]Configured” parameters shall always deliver the values as configured via the SPI. The “[...]Active” parameters shall deliver:

• the corresponding “[...]Configured” values if the system is still offline;

• the values which have been set during runtime via the SAPI parameters (SafetyProviderID, SafetyBaseID, SafetyConsumerID);

• the corresponding “[...]Configured” values if the active values have been set to zero via the SAPI parameters (SafetyProviderID, SafetyBaseID, SafetyConsumerID).

6.2.3 DataType definition

6.2.3.1 InFlagsType

The InFlagsType a subtype of the Byte DataType with the OptionSetValues Property defined. The InFlagsType is formally defined in Table 14.

CommunicationError can be used as a trigger, e.g. for a communication analysis tool. It is not forwarded to the safety application by the SafetyProvider. If CommunicationError is necessary in the safety application, bidirectional communication can be implemented and the value of CommunicationError can be put into the user data.

Bits 3 to 7 are reserved for future use and shall be set to zero by the SafetyConsumer. They shall not be evaluated by the SafetyProvider.

The InFlagsType representation in the AddressSpace is defined in Table 15.

6.2.3.2 OutFlagsType

The OutFlagsType is a subtype of the Byte DataType with the OptionSetValues Property defined. The OutFlagsType is formally defined in Table 16.

Bits 3 to 7 are reserved for future use and shall be set to zero by the SafetyProvider. They shall not be evaluated by the SafetyConsumer.

The OutFlagsType representation in the AddressSpace is defined in Table 17.

6.2.3.3 RequestSPDUDataType

Table 18 shows the definition of the RequestSPDUDataType. The Prefix “In” is interpreted from the SafetyProvider’s point of view and is used in a consistent manner to the parameters of the Method ReadSafetyData (see 6.2.2.3).

The representation in the AddressSpace of the RequestSPDUDataType is defined in Table 19.

6.2.3.4 ResponseSPDUDataType

Table 20 shows the ResponseSPDUDataType Structure. The Prefix “Out” is interpreted from the SafetyProvider’s point of view and is used in a consistent manner to the parameters of the Method ReadSafetyData (see 6.2.2.3).

[RQ6.7] To define the concrete DataType for the ResponseSPDU (which specifies the concrete DataTypes for SafetyData and NonSafetyData, respectively), proceed as follows: (1) Derive a concrete DataType from the abstract ResponseSPDUDataType. (2) In doing so, add the following fields to the Structure in the given order: (a) First, field OutSafetyData with the concrete Structure DataType for the SafetyData (see 7.2.1.5). (b) Second, field NonSafetyData with the concrete Structure DataType for the NonSafetyData (or a placeholder DataType, see requirement RQ6.8).

[RQ6.8] To avoid possible problems with empty Structures, the dummy Structure NonSafetyDataPlaceholder shall be used as DataType for OutNonSafetyData when no NonSafetyData is used. The DataType Node defining this Structure has a fixed NodeID and contains a single Boolean.

The representation in the AddressSpace of the ResponseSPDUDataType is defined in Table  21.

6.2.3.5 NonSafetyDataPlaceholderDataType

Table 22 shows the definition of the NonSafetyDataPlaceholderDataType. The receiver shall not evaluate the value of ‘dummy’.

6.2.4 SafetyProvider version

Future versions may use different identifiers (such as ReadSafetyDataV2 for the Method when using Client/Server communication or RequestSPDUV2DataType and ResponseSPDUV2DataType for the SPDU DataTypes when using PubSub communication), allowing a SafetyProvider to implement multiple versions of this document at the same time. Hence, the same SafetyProvider can be accessed by SafetyConsumers of different versions.

6.2.5 DataTypes and length of SafetyData

This document supports sending of the Built-in and Simple DataTypes specified in OPC UA (see OPC 10000-3 and OPC 10000-6) within SafetyData. The supported DataTypes are vendor-specific.

[RQ6.9] Only scalar DataTypes shall be used. Arrays are currently not supported by this document.

The supported maximum length of the SafetyData is vendor-specific but still limited to 1 500 octets. Typical values for the maximum length include 1 octet, 16 octets, 64 octets, 256 octets, 1 024 octets, and 1 500 octets.

[RQ6.10] For controller-like devices, the supported DataTypes and the maximum length of the SafetyData shall be listed in the user manual.

[RQ6.11] For the DataType Boolean, the value 0x01 shall be used for ‘true’ and the value 0x00 shall be used for ‘false’.

It is recommended to send multiple Booleans in separate variables. However, in small devices, it can be necessary to combine a set of 8 Booleans in one Variable for performance reasons. In this case, the DataType Byte can be used.

6.2.6 Connection establishment

This document uses the OPC UA services for connection establishment, it poses no additional requirement to these services.

This version of the document describes configuration only at engineering time. This means that the parameters defined in the SPI (see 6.3.3.3 and 6.3.4.4) are read-only via the interface described in this document. Changing of parameters is expected to be done in a safety-related way, using the respective tools and interfaces provided by the vendor. Future versions of this document may specify a vendor-independent interface for configuration.

6.3 Service interfaces

6.3.1 Overview

Figure 7 gives an overview of the safety communication layer and its interfaces. It thereby also shows the scope of this document. The main function of the layer services is the state machine which handles the protocol. The state machines interact with the following interfaces:

• The Safety Application Program Interface (SAPI) is accessed by the safety application for exchanging SafetyData during runtime.

• The Safety Parameter Interface (SPI) is accessed during commissioning for setting safety parameters such as IDs or the timeout value in the SafetyConsumer.

• The non-safety related Diagnostic Interface (DI) can be accessed at runtime for troubleshooting the safety communication.

The OPC UA Platform Interface (OPC UA PI) connects the SCL to the non-safe OPC UA stack and is used during runtime.

The interfaces (SAPI, SPI, DI and OPC UA PI) described in 6.3 are abstract and informative. They represent logical data inputs and outputs to this layer that are necessary for the proper operation of the state machine. No normative, concrete mappings are specified. The concrete implementations are vendor-specific and do no necessarily exactly match the abstract interfaces described in this document.

6.3.2 OPC UA Platform interface (OPC UA PI)

The state machines of this document are independent from the actual OPC UA services used for data transmission. This is accomplished by introducing a so-called OPC UA Mapper, serving as an interface between the safety communication layer and the OPC UA stack.

The mapper can either make use of OPC UA Client/Server and remote Method invocation or the publishing of and subscribing to remote Variables as defined in OPC 10000-14. The requirements on the implementation of the mapper are implicitly given in 6.2.

6.3.3 SafetyProvider interfaces

6.3.3.1 General

Figure 8 shows an overview of the SafetyProvider interfaces. The SAPI is specified in 6.3.3.2, the SPI is specified in 6.3.3.3.

6.3.3.2 SAPI of SafetyProvider

[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.

6.3.3.3 SPI of SafetyProvider

[RQ6.13a] Each SafetyProvider shall implement the parameters and constants [RQ6.13b] as shown in Table 24. The parameters (R/W in column “Access”) can be set via the SPI, whereas the constants (R in column “Access”) are read-only. The mechanisms for setting the parameters are vendor-specific. The attempt of setting a parameter to a value outside its range, or of the setting of a read-only parameter, shall not become effective, and a diagnostic message should be shown when appropriate. The values of the constants depend on the way the SafetyProvider is implemented. They never change and are therefore not writable via any of the interfaces.

The constant SafetyProviderLevel determines the value that is used for SafetyProviderLevel_ID when calculating the SPDU_ID, see 7.2.3.4.

It is necessary for the respective SafetyConsumers (on the PLC and the actuator) to know the SafetyProviderLevel of their SafetyProviders in order to check the SPDU_ID (see 7.2.3.2).

6.3.4 SafetyConsumer interfaces

6.3.4.1 General

Figure 10 shows an overview of the SafetyConsumer interfaces. The Safety Application Program Interface (SAPI) is specified in 6.3.4.2, the Safety Parameter Interface (SPI) is specified in 6.3.4.4.

6.3.4.2 SAPI of SafetyConsumer

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.

6.3.4.3 Motivation for SAPI Operator Acknowledge (OperatorAckConsumer)

The safety argumentation assumes that random errors in the underlying OPC UA stack including its communication links are not too frequent, i.e. that its failure rate is lower than a given threshold, depending on the desired SIL (see 9.3.1).

Whenever the SafetyConsumer detects a faulty message, it checks whether the assumption is still valid, and switches to fail-safe substitute values otherwise. Returning to process values then requires an operator acknowledgment.

Operator Acknowledge is expected to be initiated by a human operator who is responsible to check the installation, see Table 40, row “Operator Acknowledge”. For this reason, the parameter OperatorAckRequested is delivered by the SafetyConsumer to the safety application. See Clause B.2 for details on operator acknowledgment scenarios.

Timeout errors do only require an operator acknowledgment if operator acknowledgment is required by the safety function itself. In this case, SafetyOperatorAckNecessary is set to indicate that operator acknowledgments are required. See 6.3.4.5 for details.

6.3.4.4 SPI of the SafetyConsumer

[RQ6.15a] Each SafetyConsumer shall implement the parameters and constants [RQ6.15b] as shown in Table 26. The parameters (R/W in column “Access”) can be set via the SPI, whereas the constants (R in column “Access”) are read-only. The mechanisms for setting these parameters are vendor-specific. The attempt of setting a parameter to a value outside its range, or of the setting of a read-only parameter, shall not become effective, and a diagnostic message should be shown when appropriate. The SPI of the SafetyConsumer represents the parameters of the safety communication layer management of the SafetyConsumer. The values of the constants depend on the way the SafetyConsumer is implemented. They never change and are therefore not writable via any of the interfaces.

6.3.4.5 Motivation for SPI SafetyOperatorAckNecessary

This parameter determines whether automatic restart (i.e. automatically switching back from fail-safe values to process values) is possible for the safety function or not. It is expected to be set to 1 for safety functions where automatic restart is not allowed and restart always requires human interaction.

If automatic restart of the safety function is safe, the parameter can be set to 0.

6.3.5 Cyclic and acyclic safety communication

This document supports cyclic and acyclic safety communication.

For most safety functions it is necessary to react in a timely manner to external events, such as an emergency stop button being pressed or a light curtain being interrupted. In these applications, cyclic safety communication is established. That means the SafetyConsumer is executed cyclically, and the time between two consecutive executions is safely bounded. The maximum time between two executions of the SafetyConsumer will contribute to the safety function response time (SFRT).

Some safety functions, such as the transfer of safe configuration data at startup, do not have to react on external events. In this case, it is not required to execute the SafetyConsumer cyclically.

6.3.6 Principle for “application variables with qualifier”

Qualifiers allow the SafetyProvider to indicate the correctness of values on a fine-grained level. It is good practice to attach qualifiers to each individual value sent within an SPDU. The qualifiers are part of the SafetyData and hence not within the scope of this document.

[RQ6.16] However, whenever qualifiers are used, the values shown in Table 27 shall be used, i.e. 0x1 for a valid value (“good”), and 0x0 for an invalid value (“bad”).

Checking of the qualifiers is done in the safety application.

6.4 Diagnostics

6.4.1 General

Diagnostics according to this document may be implemented in a non-safety-related way. This allows for categorization and localization of safety communication errors.

This document provides two types of diagnostics:

Diagnostics messages generated by the SafetyConsumer and provided in a vendor-specific way.

The Method ReadSafetyDiagnostics, defined in the OPC UA Information Model (see 6.2.2.4 and 6.4.3).

6.4.2 Diagnostics messages of the SafetyConsumer

[RQ6.17] Every time the macro <Set Diag(SD_IDerrOA, isPermanent)> is executed within the SafetyConsumer, the textual representation shown in Table 28 shall be presented. The details and location of this representation (display, logfile, etc.) are vendor-specific.

To avoid a flood of diagnostic messages in case of transmission errors, only up to two messages are shown even if multiple communication errors occur in sequence. This is ensured by the behaviour defined in the SafetyConsumer’s state machine.

Optional features (vendor-specific):

• Extend diagnostic data by expected value and received value, e.g.:
  Mismatch of SafetyProviderID:
  Expected SafetyProviderID: 0x00000005
  Received SafetyProviderID: 0x00000007

• Extend diagnostic data if a parameter of the SafetyConsumer is invalid.
  Example 1:
  The SafetyConsumer has been configured with invalid parameters.
  The value 0x00000000 is an invalid SafetyProviderID.

6.4.3 Method ReadSafetyDiagnostics of the SafetyProvider

This Method (as part of the OPC UA Mapper) serves as a Diagnostic Interface and exists for each SafetyProvider. For time series observation, this interface can be polled, e.g. by a diagnostic device. For details, refer to the OPC UA Information Model described, see 6.2.2.4.

The Diagnostic Interface Method does not take any input parameters and returns both the input and output parameters of the last call of the Method ReadSafetyData.

Additionally, a 2-octet sequence number is added to the Diagnostic Interface, allowing for a detection of missed calls due to polling. The sequence number counts the number of accesses to ReadSafetyData.

A best practice recommendation is to store all input and output parameters if SComErr_diag is <> 0.

7 Safety communication layer protocol

7.1 General

This chapter describes in detail the protocol that is used for the safety communication layer.

7.2 SafetyProvider and SafetyConsumer

7.2.1 SPDU formats

7.2.1.1 General

Figure 11 shows the structure of a RequestSPDU which originates at the SafetyConsumer and contains a SafetyConsumerID, a MonitoringNumber (MNR), and one octet of (non-safety-related) Flags. See 7.2.1.2 to 7.2.1.4 for details. See 6.2.3.3 for details on the RequestSPDUDataType definition.

Figure 12 shows the structure of a ResponseSPDU which originates at the SafetyProvider and contains the SafetyData (1 to 1 500 octets), an additional 25 octet safety code (STrailer) and the NonSafetyData. See 7.2.1.5 to 7.2.1.11 for details. See 6.2.3.4 for details on the ResponseSPDUDataType definition.

7.2.1.2 RequestSPDU: SafetyConsumerID

Identifier of the SafetyConsumer instance, for diagnostic purposes, see 9.1.2.

7.2.1.3 RequestSPDU: MonitoringNumber

The SafetyConsumer uses the MNR to detect SPDUs with timeliness errors, e.g. such SPDUs which are continuously repeated by an erroneous network element which stores data. A different MNR is used in every RequestSPDU of a given SafetyConsumer, and a ResponseSPDU will only be accepted if its MNR matches the MNR of the corresponding RequestSPDU.

The checking for correctness of the MNR is only performed by the SafetyConsumer.

7.2.1.4 RequestSPDU: Flags

[RQ7.1] The flags of the SafetyConsumer (RequestSPDU.Flags) shall be used as shown in 6.2.3.1.

7.2.1.5 ResponseSPDU: SafetyData

[RQ7.2] SafetyData shall contain the safety-related application data transmitted from the SafetyProvider to the SafetyConsumer. It is comprised of a single or multiple basic OPC UA Variables (see 6.2.5). For the sake of reducing distinctions of cases, SafetyData shall always be a Structure, even if it comprised of only a single basic OPC UA Variable.

For the calculation of the CRC signature, the order in which this data is processed by the calculation is important. SafetyProvider and SafetyConsumer shall agree upon the number, type and order of application data transmitted in SafetyData. The sequence of SafetyData is fixed.

SafetyData may contain qualifiers for a fine-grained activation of fail-safe substitute values. For valid process values, the respective qualifiers are set to 1 (good), whereas the value 0 (bad) is used for invalid values. Invalid process values are replaced by fail-safe substitute values in the SafetyConsumer’s safety application. See 6.3.6.

7.2.1.6 ResponseSPDU: Flags

[RQ7.3] The flags of the SafetyProvider (ResponseSPDU.Flags) shall be used as shown in 6.2.3.2.

[RQ7.4] Flags in the ResponseSPDU.Flags which are reserved for future use shall be set to zero by the SafetyProvider and shall not be evaluated by the SafetyConsumer.

7.2.1.7 ResponseSPDU: SPDU_ID

This field is used by the SafetyConsumer to check whether the ResponseSPDU is coming from the correct SafetyProvider. For details, see 7.2.3.1.

7.2.1.8 ResponseSPDU: SafetyConsumerID

[RQ7.5] The SafetyConsumerID in the ResponseSPDU shall be a copy of the SafetyConsumerID received in the corresponding RequestSPDU. See 7.2.3.1.

7.2.1.9 ResponseSPDU: MonitoringNumber

[RQ7.6] The MonitoringNumber in the ResponseSPDU shall be a copy of the MonitoringNumber received in the corresponding RequestSPDU. See 7.2.3.1.

7.2.1.10 ResponseSPDU: CRC

[RQ7.7] The ResponseSPDU CRC shall be used to detect data corruption. See 7.2.3.6 on how it is calculated in the SafetyProvider and how it is checked in the SafetyConsumer.

7.2.1.11 ResponseSPDU: NonSafetyData

[RQ7.8] This structure shall be used to transmit NonSafetyData values (e.g. diagnostic information) together with SafetyData consistently. NonSafetyData is not CRC-protected and can stem from an unsafe source.

[RQ7.9] When presented to the safety application (e.g. at an output of the SafetyConsumer), non-safety values shall clearly be indicated as “non-safety” by an appropriate vendor-specific mechanism (e.g. by using a different colour).

To avoid possible problems with empty structures, the dummy structure NonSafetyDataPlaceholder shall be used when no NonSafetyData is used (see requirement RQ6.8).

7.2.2 Behaviour

7.2.2.1 General

The two SCL services SafetyProvider and SafetyConsumer are specified using state diagrams.

7.2.2.2 SafetyProvider and SafetyConsumer Sequence diagram

Figure 13 and Figure 14 show sequences of requests and responses with SafetyData for this document using OPC UA Client/Server and PubSub communication mechanisms, respectively. The figures show selected scenarios only and are therefore informative.

[RQ7.10] In the case of Client/Server communication, a SafetyConsumer’s OPC UA Mapper may call a SafetyProvider (either the state machine implementation itself or the SafetyProvider’s OPC UA Mapper) with an identical RequestSPDU multiple times in a row. In that case, the SafetyProvider (state machine or OPC UA Mapper) shall answer all requests. The returned ResponseSPDUs may contain different values (e.g. currently available process values) or contain the initially returned values.

[RQ7.11] For each SafetyProvider, the implemented choice of behaviour according to RQ7.10 (i.e. whether currently available process values or initially returned values will be used) shall be documented in the corresponding safety manual.

The SafetyConsumerTimeout is the watchdog time checked in the SafetyConsumer. The watchdog is restarted immediately before a new RequestSPDU is generated (transitions T14 and T28 of the SafetyConsumer in Table 35). If an appropriate ResponseSPDU is received in time, and the checks for data integrity, authenticity, and timeliness are all valid, the timer will not expire before it is restarted.

Otherwise, the watchdog timer expires, and the SafetyConsumer triggers a safe reaction. To duly check its timer, the SafetyConsumer is executed cyclically, with period ConsumerCycleTime. ConsumerCycleTime is expected to be smaller than SafetyConsumerTimeout.

The ConsumerCycleTime is the maximum time for the cyclic update of the SafetyConsumer. It is the timeframe from one execution of the SafetyConsumer to the next execution of the SafetyConsumer. The implementation of the monitoring of the ConsumerCycleTime and the reaction in case of exceeding the ConsumerCycleTime are not part of this document; these are vendor-specific.

[RQ7.12] The ConsumerCycleTime shall be monitored in a safety-related way.

[RQ7.26] A change of the SafetyConsumerTimeout parameter value shall take immediate effect on the ConsumerTimer.

7.2.2.3 Duration of demand

In case it is necessary to ensure that a given SafetyData (e.g. a safety demand or a command value) that originates in the SafetyProvider’s safety application is being received by a SafetyConsumer and forwarded to the SafetyConsumer’s safety application, i.e. if no SafetyData in a series of SafetyData is to be missed, the following two cases shall be considered.

In case A, repeated identical RequestSPDUs are being answered by the SafetyProvider with ResponseSPDUs which contain the initially returned value. This is the case for PubSub communication and is a choice for Client/Server communication, see RQ7.11. In this case, the SafetyProvider’s safety application shall provide the respective SafetyData at the SafetyProvider’s SAPI until at least one change of the MNR is detected.

In case B, repeated identical RequestSPDUs are being answered by the SafetyProvider with the currently available SafetyData. This is a choice for Client/Server communication, see RQ7.11. In this case, the SafetyProvider’s safety application shall provide the respective SafetyData at the SafetyProvider’s SAPI until at least two changes of the MNR have been detected.

Figure 15 and Figure 16 show examples justifying case B by depicting two sequences of ResponseSPDUs as sent by a SafetyProvider. Due to the cycles of SafetyProvider and SafetyConsumer not being synchronized, a SafetyConsumer can evaluate any one of a given number of ResponseSPDUs for a given RequestSPDU.

In the examples, the SafetyData is made up of two components: the “respective safety data”, i.e. a safety demand that is not to be missed (one of the values “A”, “B” or “C”) and non-demand numerical measurement values for which it does not matter whether some are not received by the SafetyConsumer.

The worst-case time to make sure that the respective safety data from the SafetyProvider is made available to the SafetyConsumer is two times the SafetyConsumerTimeout. This worst-case time occurs when the two transmissions of a RequestSPDU and its corresponding ResponseSPDU, which are necessary according to the descriptions above, each take a time of just slightly under one SafetyConsumerTimeout.

If the SafetyConsumer’s SafetyConsumerTimeout is known at the SafetyProvider, the SafetyProvider may alternatively provide the respective safety data for at least two times the SafetyConsumerTimeout to ensure that the respective safety data reaches the SafetyConsumer.

Since NonSafetyData is consistently transmitted with SafetyData, the same considerations apply for NonSafetyData.

7.2.2.4 SafetyProvider state diagram

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

Table 29 shows the symbols used for state machines.

Graphical representation	Type	Description
	Activity state	Within these interruptible activity states the SafetyProvider waits for new input.
	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 can 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.

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

Table 30 shows the internal items of a SafetyProvider instance.

Table 31 shows the states of a SafetyProvider instance. 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 and T27 in Table 35 and the macro <ParametersOK?> in Table 33.

Table 32 shows the transitions of the SafetyProvider.

7.2.2.5 SafetyConsumer state diagram

[RQ7.14] Figure 18 shows a simplified representation of the state diagram of the SafetyConsumer. The exact behaviour is described in Table 33, Table 34, and Table 35. The SafetyConsumer shall implement this behaviour. It is not required to literally follow the entries given in the tables, if the externally observable behaviour does not change.

To avoid unnecessary spurious trips requiring operator acknowledgment, it is recommended that a SafetyConsumer is started after an OPC UA connection to a running SafetyProvider has been established, or that the setting of input SAPI.Enable to “1” is delayed until the SafetyProvider is running.

Table 33 shows the internal items of a SafetyConsumer. A macro is a shorthand representation for operations described in the according definition.

Table 34 shows the states of the SafetyConsumer. The SafetyConsumer parameters are accessed only in state S11. In this state, a copy is made, and in all other states and transitions the copied values are used. This ensures that a change of one of these parameters takes effect only when a new safety connection is established. The only exception from this rule is the parameter SafetyConsumerTimeout. A change of this parameter becomes effective immediately (see RQ7.26). If this is not the desired behaviour, i.e. if parameters should be changeable during runtime, this can be accomplished by establishing a second safety connection according to this document with the new parameters, and then switching between these two safety connections at runtime.

Table 35 shows the transitions of the SafetyConsumer.

7.2.2.6 SafetyConsumer sequence diagram for operator acknowledgment (informative)

Figure 19 shows the sequence after the detection of an error requiring operator acknowledge until communication returns to delivering process values again.

After the error is gone the sequence follows the logic of T22 in Table 35.

7.2.3 Subroutines

7.2.3.1 Build ResponseSPDU

[RQ7.15] The ResponseSPDU shall be built by the SafetyProvider by copying RequestSPDU.MonitoringNumber and RequestSPDU.SafetyConsumerID into the ResponseSPDU. In addition, SPDU_ID, Flags, the SafetyData and the NonSafetyData shall be updated. Finally, ResponseSPDU.CRC shall be calculated and appended.

Figure 20 gives an overview over the task of building the ResponseSPDU.

For the ResponseSPDU.Flags, see 7.2.1.6. For the calculation of the SPDU_ID, see 7.2.3.2. For the calculation of the CRC, see 7.2.3.6.

7.2.3.2 Calculation of the SPDU_ID_1, SPDU_ID_2, SPDU_ID_3

[RQ7.16] SPDU_ID_1, SPDU_ID_2 and SPDU_ID_3 shall be calculated according to Figure 21 and Table 36.

In case of a mismatch between expected SPDU_ID and actual SPDU_ID, the following rules can be used for diagnostic purposes:

• If all of SPDU_ID_1, SPDU_ID_2, and SPDU_ID_3 differ, there probably is a mismatching SafetyBaseID.

• If SPDU_ID_3 differs, but SPDU_ID_1 and SPDU_ID_2 do not, there is a mismatching SafetyProviderID.

• If SPDU_ID_2 differs, but SPDU_ID_1 and SPDU_ID_3 do not, the structure or identifier of the SafetyData do not match.

• If SPDU_ID_1 differs, but SPDU_ID_2 and SPDU_ID_3 do not, the SafetyProviderLevel does not match.

By these rules, there is a very low probability (<10-9) that a mismatching SafetyBaseID will be misinterpreted. From a practical view, this probability can be ignored.

7.2.3.3 Example for the calculation of SPDU_ID_1, SPDU_ID_2 and SPDU_ID_3 (informative)

Figure 22 shows a concrete example of the calculation of SPDU_ID_1, SPDU_ID_2 and SPDU_ID_3. The following input values were chosen for the calculation: SafetyBaseID is the GUID “72962B91-FA75-4AE6-8D28-B404DC7DAF63”, SafetyProviderID has the value 0xE0EA6B40, SafetyStructureSignature has the value 0xDE7329FD and the SafetyProviderLevel_ID is chosen as 0xDEAA9DEE (representing SIL3).

See OPC 10000-6, 5.2.2.6 for details on the encoding of Guids. The octets from the resulting octet stream are used according to Figure 21, i.e. in “reverse order”.

The resulting SPDU_IDs are as follows: SPDU_ID_1 has the value of 0xAC3CB67F, SPDU_ID_2 has the value of 0x9495D388 and SPDU_ID_3 has the value of 0x87F13E11.

7.2.3.4 Coding of the SafetyProviderLevel_ID

The SafetyProviderLevel is the SIL the SafetyProvider implementation (hardware and software) is capable of.

[RQ7.17] Exactly one of the values provided in Table 37 shall be used as constant code value for SafetyProviderLevel_ID. The values were chosen in such a way that the hamming distance between them becomes maximal (hamming distance of 21).

[RQ7.18] Measures shall be taken to avoid that a SafetyProvider is erroneously using a code value belonging to a SIL that is higher than the SIL it is capable of. For instance, a SafetyProvider capable of SIL1 to SIL3 should not be able to accidently use the value 0xAB47F33B used for SIL4. One way to achieve this is to avoid that this constant appears in the source code of the SafetyProvider at all.

The SafetyProviderLevel is independent to the SIL capability of the provided SafetyData, see 3.1.2.12.

7.2.3.5 Signature over the SafetyData Structure (SafetyStructureSignature)

SafetyStructureSignature is used to check the number, DataTypes, and order of application data transmitted in SafetyData. If the SafetyConsumer is expecting anything different than what the SafetyProvider actually provides, SafetyStructureSignature will differ, allowing the SafetyConsumer to enable fail-safe substitute values.

In addition, the identifier of the Structure DataType (SafetyStructureIdentifier) is also taken into account when calculating SafetyStructureSignature. This ensures that the SafetyProvider and the SafetyConsumer are using the same identifier for the Structure DataType, effectively avoiding any confusion.

For instance, if a SafetyProvider defines a Structure with identifier “vec3D_m” comprising three Floats containing a three-dimensional vector in the metric system, this Structure could not be used by a SafetyConsumer expecting a Structure of DataType “vec3D_in” where the vector components are given in inches, or even at a SafetyConsumer expecting a Structure of DataType “orientation”, containing three Floats to define an orientation using Euler angles.

[RQ7.19] SafetyStructureSignature shall be calculated as a 32 bit CRC signature (polynomial: 0xF4ACFB13, see Clause B.1) over SafetyStructureIdentifier (encoding: UTF-8), SafetyStructureSignatureVersion and the sequence of the DataTypeEncodingIDs. After each DataTypeEncodingID, a 16-bit zero-value (0x0000) shall be inserted. All integers shall be encoded using little endian octet ordering. Data shall be processed in reverse order, see Clause B.1. The value “0” shall not be used as a signature. Instead, the value “1” shall be used in this case.

The terminating zero of SafetyStructureIdentifier shall not be considered when calculating the CRC.

[RQ7.20] SafetyStructureIdentifier may be visible in the OPC UA Information Model for diagnostic purposes but shall not be evaluated by the SafetyConsumer during runtime.

[RQ7.21] For all releases up to Release 2.0 of the specification, the value for SafetyStructureSignatureVersion shall be 0x0001.

Example:

SafetyStructureIdentifier,
e.g. “Motörhead” = 0x4d 0x6f 0x74 0xc3 0xb6 0x72 0x68 0x65 0x61 0x64

SafetyStructureSignatureVersion:= 0x0001

2. DataType Boolean: (DataTypeEncodingId = 0x0001),

3. DataType Float: (DataTypeEncodingId =0x000a)

SafetyStructureSignature =

= CRC32_Backward(0x4d, 0x6f, 0x74, 0xc3, 0xb6, 0x72, 0x68, 0x65, 0x61, 0x64,

= CRC32_Forward(

= 0xe2e86173

OPC 10000-3, 5.8.2 defines different categories of DataTypes. Regarding the DataTypeEncodingID which is to be used within the SafetyStructureSignature, the following holds:

• For Built-in DataTypes, the ID from Table 1 of OPC 10000-6 is used as DataTypeEncodingID.

• For Simple DataTypes, the DataTypeEncodingID of the Built-in DataType from which they are derived is used.

• As of now, Structured DataTypes (including OptionSets) shall not be used within SafetyData. Arrays are not supported. Instead, multiple variables of the same type are used.

• Enumeration DataTypes are encoded on the wire as Int32 and therefore shall use the DataTypeEncodingID of the Int32 Built-in DataType.

7.2.3.6 Calculation of a CRC signature

The SafetyProvider calculates the CRC signature (ResponseSPDU.CRC) and sends it to the SafetyConsumer as part of the ResponseSPDU. This enables the SafetyConsumer to check the cor­rect­ness of the ResponseSPDU including the SafetyData, flags, MNR, SafetyConsumerID and SPDU_ID by recalculating the CRC signature (CRC_calc).

[RQ7.22] The generator polynomial 0xF4ACFB13 shall be used for the 32-Bit CRC signature.

[RQ7.23] If SafetyData is longer than one octet (e.g. if it is of DataType UInt16, Int16 or Float), it shall be decoded and encoded using little endian order in which the least significant octet appears first in the incremental memory address stream.

[RQ7.24] The calculation sequence shall begin with the highest memory address (n) of the STrailer counting back to the lowest memory address (0) and then include also the SafetyData beginning with the highest memory address.

Figure 23 shows the calculation sequence of a ResponseSPDU CRC on a little-endian machine, using an example SafetyData with the following fields:

• Int32 var1

• UInt32 var2

• UInt16 var3

• Int16 var4

• Boolean var5

For the example given above, the STrailer (without CRC) and SafetyData have a combined length of 34 octets (16 octets STrailer without CRC, 12 octets of SafetyData). The calculation of ResponseSPDU.CRC (SafetyProvider) or CRC_calc (SafetyConsumer) is done in reverse order, from bottom to top. In the example shown in Figure 23, CRC calculation starts at octet index 33 (most significant octet of the MNR) and ends at octet index 0.

An alternative way to calculate the CRC (particularly useful on big-endian machines) is shown in Figure 24. Here, the individual elements of the ResponseSPDU are already arranged in memory in reversed order, and CRC calculation is executed from octet 0 to octet 33.

[RQ7.25] On the SafetyConsumer, CRC_calc shall be calculated using data received in the ResponseSPDU, and not from expected values.

8 Safety communication layer management

8.1 General

This chapter gives details about the management of the safety communication layer.

8.2 Safety function response time part of communication

For cyclic communication, the part of the safety function response time attributable to a safety communication according to this document (SFRTOPCSafety) is specified in Formula (1).

Calculation of safety function response time part of OPC UA safety

• where

• SFRTOPCSafety: Part of the safety function response time attributable to the safety communication according to this document.

• SafetyConsumerTimeout: Watchdog timer running in the SafetyConsumer. It is started immediately before a new RequestSPDU is sent (T14 or T28). If the timer runs out a timeout error is triggered (T18 or T29).

• ConsumerCycleTime: The maximum time for the cyclic execution of the SafetyConsumer, see 7.2.2.2.

If multiple safety connections according to this document are used within a safety function in series, their respective attributions to the SFRT shall be summed up.

Formula (1) is justified by Figure 25 and the following explanation:

1. The SafetyConsumer sends a RequestSPDU. At about the same time, a dangerous event occurs at the SafetyProvider, demanding the safety function to trigger.

2. However, in the worst case, the RequestSPDU is processed at the SafetyProvider just before the dangerous event becomes known.

3. Hence, the ResponseSPDU does not yet contain any information about the dangerous event.

4. In the worst case, the ResponseSPDU is processed in the SafetyConsumer just before the SafetyConsumerTimeout expires.

5. An error leads to a loss or unacceptable delay of either the RequestSPDU or the ResponseSPDU.

6. Hence, the SafetyConsumerTimeout expires.

7. In the worst case, the timer expires immediately after it was checked. Hence, it takes another cycle of the SafetyConsumer to detect the error.

SafetyConsumerTimeout is a parameter of the SafetyConsumer. ConsumerCycleTime depends on the maximum sample time of the SafetyConsumer application. At commissioning, the integrator should be advised to design it shorter than a quarter of the target SFRTOPCSafety. If the watchdog time SafetyConsumerTimeout is too small, spurious trips can occur. To avoid this, SafetyConsumerTimeout should be chosen as shown in Formula (2).

Selection of the watchdog parameter SafetyConsumerTimeout

• where

• T_CD_RequestSPDU: The worst-case communication delay for the RequestSPDU.

• T_CD_ResponseSPDU: The worst-case communication delay for the ResponseSPDU.

• SafetyProviderDelay: The worst-case SafetyProvider delay.
  Typically, one scan time period of the SafetyProvider.

• SafetyConsumerDelay: The worst-case SafetyConsumer delay.
  Typically, one scan time period of the SafetyConsumer.

[RQ8.1] To support the calculation of SafetyConsumerTimeout the SafetyProvider shall provide the SafetyProviderDelay as a Variable in the OPC UA Information Model, see Table 12.

Vendors may provide their individual adapted calculation method if necessary.

9 System requirements (SafetyProvider and SafetyConsumer)

9.1 Constraints on the SPDU parameters

9.1.1 SafetyBaseID and SafetyProviderID

The pair of SafetyProviderID and SafetyBaseID is used by the SafetyConsumer to check the authenticity of the ResponseSPDU. SafetyProviderID and SafetyBaseID are usually assigned during engineering or during commissioning. It is in the responsibility of the end user or OEM to assign unique SafetyProviderID to individual SafetyProviders whenever this is reasonable possible. For instance, a machine builder should assign unique SafetyProviderIDs within a single machine containing multiple devices which run implementations of this document.

As the effort for the administration of unique SafetyProviderIDs will reach its limits when the system becomes large, this document uses the SafetyBaseID for cases where guaranteeing unique SafetyProviderIDs is not possible.

A SafetyBaseID is a universal unique identifier version4 (UUIDv4, also called globally unique identifier (GUID)), as described in ISO/IEC 9834-8:2014, Clause 15.It is a 128-bit number where at least 96 bits were chosen randomly. The probability that two randomly generated UUIDs are identical is extremely low (2-96 < 10-28), and can therefore be neglected, even when considering applications with a safety integrity level of 4.

It is not necessary to generate an individual SafetyBaseIDs for all SafetyProviders. If two SafetyProviders can be discriminated by their SafetyProviderIDs, they may share the same SafetyBaseID. For instance, a machine builder could generate a unique SafetyBaseID for each instance of a machine, which is reused for all SafetyProviders within a machine.

When implementing or using a generator for the UUIDs, it shall be ensured that each possible value is generated with equal probability (discrete uniform distribution), and that any two values are independent from each other. When a pseudo random number generator (PNRG) is used, it is ‘seeded’ with a random source having enough collision entropy (e.g. seeds of at least 128 bits that are uniformly distributed, too; and all seeds being pairwise independent from each other).

Most commercial systems offer random number generators for applications within a cryptographic context. These applications pose even harder requirements on the quality of random numbers than the ones mentioned above. Hence, cryptographically strong random number generators are applicable to this document as well. See References [2] to [5], as well as OPC 10000-2, for detailed information.

Table 38 shows implementations of cryptographically strong random number-generators that can be used to calculate the random part of the UUIDv4:

While being evaluated from a security point of view, probably none of these implementations has been validated with safety in mind. Therefore, there is a remaining risk that these implementations are subject to systematic implementation errors which could decrease the effectiveness of these random numbers. To overcome this problem, the output of the random number generator is not used directly, but a SHA256-hash is calculated over (1) the generator’s output, (2) a timestamp (wall-clock-time or persistent logical clock) and (3) a unique domain name. Any bits of the SHA256-hash can then be used to construct the random parts of the UUIDv4.

[RQ9.1] The parameters SafetyBaseID and SafetyProviderID shall be stored in a non-volatile, i.e. persistent, way.

9.1.2 SafetyConsumerID

The SafetyConsumerID allows for discrimination between RequestSPDUs and ResponseSPDUs belonging to different SafetyConsumers. It is mainly used for diagnostic purposes, such as detecting unintentional concurrent access of a single SafetyProvider by multiple SafetyConsumers. Safety-related communication errors which are detected by checking the SafetyConsumerID would also be detected by other mechanisms, including the MNR, the SafetyProviderID, and the SafetyConsumerTimeout.

From a safety point of view, there are no qualitative requirements regarding the generation or administration of the SafetyConsumerID. It may be assigned during engineering, commissioning, at startup, and may even change during runtime. It is not required to check for uniqueness of SafetyConsumerIDs.

However, assigning identical SafetyConsumerIDs to multiple consumers is not recommended because fault localization can become more difficult.

9.2 Initialization of the MNR in the SafetyConsumer

The MNR is used to discriminate messages stemming from the same SafetyProvider and is therefore used to detect timeliness errors such as outdated messages, messages received out-of-order, or streams of messages erroneously repeated by a network storing element (e.g. a router).

To be effective, the set of used MNR values shall not be restricted to a small set. This could happen for connections which are restarted frequently, and which start counting from the same MNR value each time.

There are at least two ways to address this potential problem:

Option 1: [RQ9.2a] Whenever the connection is terminated, the current value of the MNR shall be safely stored within non-volatile memory of the SafetyConsumer. After restart, the previously stored MNR is used for initialization of the MNR (i.e. in state S12 of the SafetyConsumer state machine).

Option 2: [RQ9.2b] Whenever the SafetyConsumer is restarted (i.e. in state S12 of the SafetyConsumer state machine), the MNR is initialized with a 32-bit random number.

Either requirement RQ9.2a or requirement RQ9.2b, or an equivalent solution shall be fulfilled.

9.3 Constraints on the calculation of system characteristics

9.3.1 Probabilistic considerations (informative)

Following IEC 61784-3, this document detects all communication errors which can possibly occur in the underlying standard transmission system, including the OPC UA stack. If an error is detected, the erroneous data is discarded. Moreover, this document is designed in such a way that a safety function becomes practically unusable if the failure rate in the underlying, standard transmission system is higher than one error per safety error interval limit (6, 60, or 600 minutes), depending on the desired SIL of the safety function (see Table 26 and Table 39).

Thus, for operational safety functions a failure rate of 0,1 h-1, 1 h-1, or 10 h-1 can be assumed for communication errors occurring in the OPC UA stack. In order to obtain the communication’s contribution to the PFH value of the safety function, this value has to be multiplied by the so-called conditional residual error probability Pre,cond. For the CRC mechanism used in this document, it holds:

Pre,cond ≤ 4,0 × 10-10

This leads to the PFH and PFD values shown in Table 39.

The value 4,0 × 10-10 was justified by extensive numerical evaluation of the 32-bit CRC generator polynomial in use (0xF4ACFB13). The results of this evaluation, executed for all relevant data lengths and all relevant values for the bit error probability p up to p = 0,5, is shown in Figure 26. As can be seen, Pre,cond never exceeds the value 4,0 × 10-10.

An explanation that it is indeed necessary to calculate Pre,cond for all data lengths and all relevant values of p can be found in Figure 27. For the data lengths shown in this figure, Pre,cond exceeds the desired value by several orders of magnitudes. The maximum value of Pre,cond is not obtained when p becomes maximal.

9.3.2 Safety related assumptions (informative)

The boundary conditions and assumptions for safety assessments and calculations of residual error rates are listed here.

Generally:

• Number of retries in the underlying standard transmission system :
  No restrictions

• CRC polynomials used inside the underlying standard transmission system(e.g. Ethernet, TCP, …):
  No restrictions

• Message storing elements:
  No restrictions; any number of message storing elements is permitted

• Size of SafetyData within one ResponseSPDU:
  ≤ 1 500 octets

Even for safety functions that do not require manual operator acknowledgment for restart, manual operator acknowledgment is mandatory whenever the SafetyConsumer has detected certain types of errors and indicates this using OperatorAckRequested. Hence, operator acknowledgment is expected to be implemented by the safety application whenever OPC UA Safety is used. For details, see 6.3.4.3 and Clause B.2.

9.4 PFH and PFD values of a logical safety communication link

The PFH value of a logical safety communication link according to this document depends on the parameter of SafetyErrorIntervalLimit (see Table 26) of the link’s SafetyConsumer. Whenever the SafetyConsumer detects a mismatch of the SafetyConsumerID, SPDU_ID, MNR or CRC, it will only continue operating if the last occurrence of such an error happened more than SafetyErrorIntervalLimit time units ago. Otherwise, it will make a transition to fail-safe values, which can only be left by manual operator acknowledgment, see 6.3.4.3.

This directly limits the rate of detected errors, and indirectly limits the rate of undetected (residual) errors.

See Table 39 for numeric PFH and PFD values.

The parameter SafetyErrorIntervalLimit affects either the PFH or the PFD, or both of only the safety communication channel. There is no effect on the PFH and PFD values of the components the SafetyProviders and SafetyConsumers are running on. The requirements for the implementation of these components are specified in the IEC 61508 series.

9.5 Safety manual

[RQ9.3] According to IEC 61508-2, the suppliers of equipment implementing an implementation of this document shall provide a safety manual. The instructions, information and parameters of Table 40 shall be included in that safety manual unless they are not relevant for a specific device.

9.6 Indicators and displays

[RQ9.4] The device a SafetyConsumer is running on shall be able to indicate if SAPI.OperatorAckRequested is enabled. This can be done for example by an indicator LED or by using an HMI.

[RQ9.5] If an LED is used for indication, it shall blink in green colour with frequency of 0,5 Hz whenever the output SAPI.OperatorAckRequested is true of at least one of the SafetyConsumers running on the device.

This LED may also be used for other purposes. For instance, normal operation may be indicated by a non-flashing LED, or erroneous behaviour may be indicated by an LED blinking with a frequency higher than 0,5 Hz. Thus, this document does not contain any requirements for the behaviour of the LED if SAPI.OperatorAckRequested is false.

The message shown on an HMI is application-specific. For instance, the text “machine has stopped for safety reasons. For restart, please check for obstacles and press the green button.” can be shown.

10 Assessment

10.1 Safety policy

Users of this document shall take into account the following constraints to avoid misunderstanding or wrong expectations regarding safety-related developments and applications.

The communication technologies specified in this document shall only be implemented in devices designed in accordance with the requirements of the relevant safety standards.

The use of communication technologies specified in this document in a device does not ensure that all necessary technical, organizational and legal requirements related to safety-related applications of the device have been fulfilled in accordance with the requirements of the relevant safety standards.

For a device based on this document to be suitable for use in safety-related applications, appropriate functional safety management life-cycle processes according to the relevant safety standards shall be observed. This shall be assessed in accordance with the independence and competence requirements of the relevant safety standards. Safety-related applications of the device can be subject to local regulations and legal requirements.

The manufacturer of a device using communication technologies specified in this document is responsible for the correct implementation of the standard, the correctness and completeness of the device documentation and information.

Additional important information including corrigenda and errata published by the OPC Foundation or PI shall be considered for implementation and assessment.

It is strongly recommended that implementers of this document comply with the appropriate conformance tests and validations provided by the related technology-specific organization.

10.2 Obligations

Since safety technology in automation is relevant to occupational safety and the concomitant insurance risks in a country, local regulations and legal requirements can apply. The national authorities (notified bodies) decide on the recognition of assessment reports.

10.3 Index of requirements (informative)

Table 41 gives an informative overview of all the requirements (safety and non-safety) which are described in this document. A summary requirement description and the corresponding clause or subclause where the requirement is defined are given. To fully understand a requirement and its context, it is necessary to consult its original definition. Table 41 serves as a tool for quick navigation and as a checklist for an overview over all requirements.

For the conventions used for numbering requirements, see 3.3.2.

11 Profiles and Conformance Units

Figure 28 shows an informative overview of the Facets and ConformanceUnits pertaining to this document. For normative reference consult the Profile Reporting at https://profiles.opcfoundation.org/.

12 Namespaces

12.1 Namespace metadata

Table 42 defines the Namespace metadata for this document. The Object is used to provide version information for the Namespace and an indication about static Nodes. Static Nodes are identical for all Attributes in all Servers, including the Value Attribute. See OPC 10000-5 for more details.

The information is provided as Object of type NamespaceMetadataType. This Object is a component of the Namespaces Object that is part of the Server Object. The NamespaceMetadataType ObjectType and its Properties are defined in OPC 10000-5.

The version information is also provided as part of the ModelTableEntry in the UANodeSet XML file. The UANodeSet XML schema is defined in OPC 10000-6.

12.2 Handling of OPC UA namespaces

Namespaces are used by OPC UA to create unique identifiers across different naming authorities. The Attributes NodeId and BrowseName are identifiers. A Node in the UA AddressSpace is unambiguously identified using a NodeId. Unlike NodeIds, the BrowseName cannot be used to unambiguously identify a Node. Different Nodes canmay have the same BrowseName. They are used to build a browse path between two Nodes or to define a standard Property.

Servers canmay often choose to use the same Nnamespace for the NodeId and the BrowseName. However, if they want to provide a standard Property, its BrowseName shall have the Nnamespace of the standards body although the Nnamespace of the NodeId reflects something else, for example the EngineeringUnits Property. All NodeIds of Nodes not defined in this document shall not use the standard namespaces.

[RQ12.1] Table 43 provides a list of mandatory and optional Namespaces used in an OPC UA Server according to this document.

Annex A Safety Namespace and mappings (Normative)

This Annex A defines the numeric identifiers for the numeric NodeIds defined in the Namespace of this document. The identifiers are specified in a CSV file with the following syntax:

<SymbolName>, <Identifier>, <NodeClass>

Where the SymbolName is either the BrowseName of a Type Node or the BrowsePath for an Instance Node that appears in the specification and the Identifier is the numeric value for the NodeId.

The NamespaceUri for all NodeIds defined here is http://opcfoundation.org/UA/Safety

The CSV released with this version of the specification can be found here:

http://www.opcfoundation.org/UA/schemas/1.05/Opc.Ua.Safety.NodeIds.csv

The latest CSV that is compatible with this version of the specification can be found here:

http://www.opcfoundation.org/UA/schemas/Opc.Ua.Safety.NodeIds.csv

A computer processible version of the complete Information Model defined in this document is also provided. It follows the XML Information Model schema syntax defined in OPC 10000-6.

The Information Model schema released with this version of the specification can be found here:

http://www.opcfoundation.org/UA/schemas/1.05/Opc.Ua.Safety.NodeSet2.xml

The latest Information Model schema that is compatible with this version of the specification can be found here:

http://www.opcfoundation.org/UA/schemas/Opc.Ua.Safety.NodeSet2.xml

Annex B Additional information (Informative)

B.1 CRC calculation using tables, for the polynomial 0xF4ACFB13

The calculation of a 32-bit CRC signature over an array of N octets with the help of lookup tables, using “C” as programming language, is shown below:

where the lookup-table crctab32 has to be initialized as shown in Table B.1.

where the lookup-table crctab32 has to be initialized as shown in Table B.1.

B.2 Use cases

B.2.1 Unidirectional communication

The most basic type of communication is unidirectional communication, where a safety application on one device (Controller A in Figure B.1) sends data to a safety application on another device (Controller B in Figure B.1).

This is accomplished by placing a SafetyProvider on Controller A and a SafetyConsumer on Controller B. The connection between SafetyProvider and SafetyConsumer can be established and terminated during runtime, allowing different consumers to connect to the same SafetyProvider at different times. Furthermore, the protocol is designed in such a way, that it is necessary for the SafetyConsumer to know the parametrized set of IDs of the SafetyProvider such that it is able to safely check whether the received data is coming from the expected source. On the other hand, as SafetyData flows in one direction only, it is not necessary for the SafetyProvider to check the ID of the SafetyConsumers. Hence, Controller A can – one after another – serve an arbitrarily large number of SafetyConsumers, and new SafetyConsumers can be introduced into the system without having to update Controller A.

B.2.2 Bidirectional communication

Bidirectional communication means the exchange of data in both directions, which is accomplished by placing a SafetyProvider and a SafetyConsumer on each controller. Hence, bidirectional communication is realized using two safety connections according to this document. See Figure B.2 for an example.

B.2.3 Safety Multicast

Multicast is defined as sending the same set of data from one device (Controller A) to several other devices (Controller B1, B2,…,BN) simultaneously.

Safety multicast is accomplished by placing multiple SafetyProviders on Controller A, and one SafetyConsumer on each of the Controllers B1, B2, … BN. Each of the SafetyProviders running on Controller A is connecting to one of the SafetyConsumers running on one of the Controllers B1, B2, … BN. See Figure B.3 for an example.

The safety protocol in this document is designed in such a way that:

• the state machine of the SafetyProvider has a low number of states, and thus very low memory demands,

• all safety-related message-checks are executed on the consumer and thus the computational demand on the SafetyProvider is low.

Therefore, even if many SafetyProviders are instantiated on a device, the performance requirements will still be moderate.

The properties of simple unicast are also valid for safety multicast; different sets of consumers can connect to SafetyProviders at different times, and new SafetyConsumers can be introduced into the system without having to reconfigure the SafetyProvider instances. As all SafetyProvider instances send the same safety application data (the same data source), it is irrelevant from a safety point of view to which SafetyProvider instance a given SafetyConsumer is connected. Thus, all SafetyProvider instances can be parametrized with the same set of IDs for the SafetyProvider.

B.3 Use cases for Operator Acknowledgment

B.3.1 Explanation

This document supports operator acknowledgment both on the SafetyProvider side and on the SafetyConsumer side. For this purpose, both the interface of the SafetyProvider and the SafetyConsumer comprise a Boolean input called OperatorAckProvider and OperatorAckConsumer, respectively. The safety application can get the values of these parameters on the consumer side via the Boolean outputs OperatorAckRequested and OperatorAckProvider on the SafetyConsumer’s SAPI (see 6.3.4.2).

Subclauses B.3.2 to B.3.5 show some examples on how to use these inputs and outputs. Dashed lines indicate that the corresponding input or output is not used in the use case. For details, see 6.3.3 and 6.3.4.

B.3.2 Use case 1: unidirectional communication and OA on the SafetyConsumer side

In the scenario shown in Figure B.4, operator acknowledgment is done on the SafetyConsumer side, operator acknowledgment on the SafetyProvider side is not possible.

B.3.3 Use case 2: bidirectional communication and dual OA

In the scenario shown in Figure B.5, operator acknowledgment is done independently for both directions.

B.3.4 Use case 3: bidirectional communication and single, one-sided OA

In the scenario of Figure B.6, an operator acknowledgment activated at controller A suffices for re-establishing the bidirectional connection. Both sides will cease delivering fail-safe values and continue sending process values. This is accomplished by connecting OperatorAckProvider with OperatorAckConsumer at the SafetyConsumer of controller B. Activating operator acknowledgment at controller B is not possible in this scenario.

B.3.5 Use case 4: bidirectional communication and single, two-sided OA

Figure B.7 shows a scenario where an operator acknowledgment activated at controller A or controller B suffices for re-establishing the bidirectional connection. Both sides will cease delivering fail-safe values and continue sending process values. This is accomplished by the logic circuits shown in the safety applications.

Annex C Information for assessment (Informative)

This document does not make a statement on how to validate conformance. However, testing and validation of compliance can be subject to regulatory requirements.

Corresponding information regarding the testing and compliance with this document can be retrieved from the local National Committees of the IEC or from the relevant technology-specific organization for this document.

Bibliography

Agreement of Use

COPYRIGHT RESTRICTIONS

Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.

OPC Foundation members and non-members are prohibited from copying and redistributing this specification. All copies must be obtained on an individual basis, directly from the OPC Foundation Web site http://www.opcfoundation.org.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OPC specifications may require use of an invention covered by patent rights. OPC shall not be responsible for identifying patents for which a license may be required by any OPC specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OPC specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

WARRANTY AND LIABILITY DISCLAIMERS

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED “AS IS” AND MAY CONTAIN ERRORS OR MISPRINTS. THE OPC FOUDATION MAKES NO WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OPC FOUNDATION BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you.

RESTRICTED RIGHTS LEGEND

This Specification is provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as applicable. Contractor / manufacturer are the OPC Foundation, 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260-1830.

COMPLIANCE

The OPC Foundation shall at all times be the sole entity that may authorize developers, suppliers and sellers of hardware and software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Products developed using this specification may claim compliance or conformance with this specification if and only if the software satisfactorily meets the certification requirements set by the OPC Foundation. Products that do not meet these requirements may claim only that the product was based on this specification and must not claim compliance or conformance with this specification.

Trademarks

Most computer and software brand names have trademarks or registered trademarks. The individual trademarks have not been listed here.

GENERAL PROVISIONS

Should any provision of this Agreement be held to be void, invalid, unenforceable or illegal by a court, the validity and enforceability of the other provisions shall not be affected thereby.

This Agreement shall be governed by and construed under the laws of the State of Minnesota, excluding its choice or law rules.

This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior understanding or agreement (oral or written) relating to, this specification.

ISSUE REPORTING

The OPC Foundation strives to maintain the highest quality standards for its published specifications; hence they undergo constant review and refinement. Readers are encouraged to report any issues and view any existing errata here: http://www.opcfoundation.org/errata.

Revision 1.05.04 Highlights

The following table includes the issues resolved with this revision.

OPC UA Safety extends OPC UA to fulfill the requirements of functional safety as defined in the IEC 61508 series and IEC 61784-3 series of standards.

Figure 1 shows the relationship between this document and the relevant safety and OPC UA standards in an industrial environment. An arrow from Document A to Document B means “Document A is referenced in Document B”. This reference can be either normative or informative. Not all of these standards are applicable or required for a given product.

Implementing this document allows for detecting all types of communication errors encountered in the lower network layers. In case an error is detected, this information is shared with the safety applications in the User Layer which can then act in an appropriate way, e.g. by switching to a safe state.

The document describes the behaviour of the individual endpoints for safe communication, as well as the OPC UA Information Model which is used to access these endpoints.

This document is application-independent and does not pose requirements on the structure and length of the application data. Application-specific requirements are expected to be described in appropriate companion specifications.

This document can be used for applications requiring functional safety up to the safety integrity level (SIL) 4.