In order to prevent and protect the manufacturers and vendors of products which implement this document from possibly misleading understandings or wrong expectations and gross negligence actions regarding safety-related developments and applications, the following items must be observed and explained in each training, seminar, workshop and consultancy.

A device will not be automatically applicable for safety-related applications just by implementing this document.

In contrast, appropriate development processes according to safety standards must be observed for safety-related products (see IEC 61508, IEC 61511, IEC 602041, IEC 62061, and ISO 13849) and/or an assessment from a notified assessment body is required.

The manufacturer of a safety product is responsible for the correct implementation of this document, as well as the correctness and completeness of the product documentation and information.

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

The test specification for this document describes the test cases which are necessary to test the behavior of a SafetyAutomationComponent as described in this document. These tests – or a set of (automated or manual) tests that has been shown to test the behavior in an equivalent way - must be successfully run at a test laboratory accredited by the OPC Foundation or PI. For details on the testing and certification processes, please consult the OPC Test Lab Specification (OPC 10010, all parts). For a possible architecture of an automated way to perform the test cases, see 10.3. Note that this verification step does not substitute the other methods of assessment that are mentioned in this document.

As a rule, the international safety standards are accepted (ratified) globally. However, since safety technology in automation is relevant to occupational safety and the concomitant insurance risks in a country, recognition of the rules pointed out here is still a sovereign right. The national “Authorities” (notified bodies) decide on the recognition of assessment reports.

NOTE Examples of such “Authorities” are the IFA (Institut für Arbeitsschutz der Deutschen Gesetzlichen Unfallversicherung / Institute for Occupational Safety and Health of the German Social Accident Insurance) in Germany, HSE (Health and Safety Executive) in UK, FM (Factory Mutual / Property Insurance and Risk Management Organization), UL (Underwriters Laboratories Inc. / Product Safety Testing and Certification Organization), or the INRS (Institut National de Recherche et de Sécurité) in France.

For details, see the test specification for this document.

The OPC Foundation will publish an automated test tool, the OPC UA Safety Compliance Test Tool (UASCTT), which implements the test cases that are described in the OPC UA Safety test specification using the test principles described in this Subclause 10.3. The UASCTT will be approved by a Notified Body. It is recommended to use the UASCTT to perform the test cases as described in 10.1, item 5).

An exemplary test principle for this document is presented. The test is a fully automated verification based on test patterns covering all paths of the state machines in this document, with the exception of T29 of the SafetyConsumer state machine.

NOTE The reason for T29 of the SafetyConsumer state machine not being tested by the UASCTT is that this transition cannot be triggered externally by the UASCTT by sending SPDUs or inducing other error conditions. The function of T29 according to this specification is to be proven by the manufacturer and be documented by a manufacturer declaration. Details are found in the test specification.

Different types of possible correct and incorrect SPDUs, parameters, and interactions with the upper interface of the SafetyProvider / SafetyConsumer are taken into account. These test patterns together with the expected responses/stimulations are stored as an XML document and imported into the test tool software. The test tool executes the complete test patterns while connected to the OPC UA Safety layer under test, compares the nominal with the actual reactions and is recording the results that can be printed out for the test report.

Figure 25 shows the structure of the layer tester for the SafetyProvider and SafetyConsumer.

Figure 25 – Automated SafetyProvider / SafetyConsumer test

The SafetyProvider / SafetyConsumer tester acts like an opposite SafetyProvider / SafetyConsumer Layer to stimulate the tested SafetyProvider / SafetyConsumer so that all possible states and transitions in the respective state machine are being exercised. Thus, it must be configured according to the deployed OPC UA communication system. This can be done with the help of an XML file associated with the tester.

A so-called “upper tester” runs on top of the SafetyProvider or SafetyConsumer within the device under test (DUT). It transfers data from the SafetyProvider or SafetyConsumer via its SAPI and makes them visible to the test tool via an OPC UA interface that is specified in the test specification (“Set Data” in Figure 26 and Figure 27). In a similar way, the upper tester enables the test-tool to set inputs of the SAPI (“Get Data” in Figure 26 and Figure 27).

The upper tester is implemented by the vendor of the DUT using standard program languages such as C/C++, IEC 61131-3 or Structured Text and does not need to be executed in a safety-related way.

Detailed requirements for the upper tester are described in the test specification.

Figure 26 – “Upper Tester” within the SafetyProvider

Figure 27 – “Upper Tester” within the SafetyConsumer

Subclause 10.4 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 where the requirement is defined are given. Note that to fully understand a requirement and its context, it is necessary to consult its original definition. This Subclause 10.4 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.

Table 41 – Index of Requirements (informative)

Requirement Number	Requirement Summary	Clause/Subclause
RQ4.1	Implement in devices designed according to IEC 61508 with appropriate SIL	4.2 Implementation aspects
RQ5.1	Implement in safety devices only	5.2 Safety functional requirements
RQ5.2	Implement safety measures (MNR, timeout with receipt, IDs, data integrity check)	5.3 Safety measures
RQ5.3	Process and monitor safety measures in the SCL	5.3 Safety measures
RQ5.4	Start CRC calculation with value “1”	5.5 Requirements for CRC calculation
RQ5.5	Use CRC result “1” instead of “0”	5.5 Requirements for CRC calculation
RQ5.6	Ignore all-zero SPDUs	5.5 Requirements for CRC calculation
RQ6.1	Singleton SafetyACSet folder	6.2.2.1 SafetyACSet Object
RQ6.2	Objects for SafetyProviders and SafetyConsumers	6.2.2.1 SafetyACSet Object
RQ6.3a	Usage of Call Service for Client/Server	6.2.2.1 SafetyACSet Object
RQ6.3b	Usage of SafetyPDUs for PubSub	6.2.2.1 SafetyACSet Object
RQ6.4	Provide SPDUs for diagnostics in method ReadSafetyDiagnostics	6.2.2.1 SafetyACSet Object
RQ6.5	Restrictions on data types	6.2.2.2 Safety ObjectType definitions
RQ6.6	Non-abstract data types for out data	6.2.2.2 Safety ObjectType definitions
RQ6.7	Definition of concrete data types for ResponseSPDU	6.2.3.4 ResponseSPDUDataType
RQ6.8	Usage of NonSafetyDataPlaceHolder	6.2.3.4 ResponseSPDUDataType
RQ6.9	Restriction to scalar types	6.2.5 DataTypes and length of SafetyData
RQ6.10	List supported data types in user manual	6.2.5 DataTypes and length of SafetyData
RQ6.11	Values for Boolean data type	6.2.5 DataTypes and length of SafetyData
RQ6.12	Implementation of SafetyProvider SAPI	6.3.3.2 SAPI of SafetyProvider
RQ6.13a	Implementation of SafetyProvider SPI	6.3.3.3 SPI of SafetyProvider
RQ6.13b	Parameters of SafetyProvider SPI	6.3.3.3 SPI of SafetyProvider
RQ6.14	Implementation of SafetyConsumer SAPI	6.3.4.2 SAPI of SafetyConsumer
RQ6.15a	Implementation of SafetyConsumer SPI	6.3.4.4 SPI of the SafetyConsumer
RQ6.15b	Parameters of SafetyConsumer SPI	6.3.4.4 SPI of the SafetyConsumer
RQ6.16	Values for qualifier bits	6.3.6 Principle for “Application variables with qualifier”
RQ6.17	SafetyConsumer diagnostic message texts	6.4.2 Diagnostics messages of the SafetyConsumer
RQ7.1	RequestSPDU flags	7.2.1.4 RequestSPDU: Flags
RQ7.2	Contents and structure of SafetyData in ResponseSPDU	7.2.1.5 ResponseSPDU: SafetyData
RQ7.3	Usage of ResponseSPDU flags	7.2.1.6 ResponseSPDU: Flags
RQ7.4	Zero out reserved flags	7.2.1.6 ResponseSPDU: Flags
RQ7.5	Copy SafetyConsumerID into ResponseSPDU	7.2.1.8 ResponseSPDU: SafetyConsumerID
RQ7.6	Copy MonitoringNumber into ResponseSPDU	7.2.1.9 ResponseSPDU: MonitoringNumber
RQ7.7	Usage of CRC checksum	7.2.1.10 ResponseSPDU: CRC
RQ7.8	Usage of NonSafetyData	7.2.1.11 ResponseSPDU: NonSafetyData
RQ7.9	Indication of NonSafetyData	7.2.1.11 ResponseSPDU: NonSafetyData
RQ7.10	Answer repeated RequestSPDUs in Client/Server communication	7.2.2.2 SafetyProvider/-Consumer Sequence diagram
RQ7.11	Document behavior chosen in RQ7.10 in safety manual	7.2.2.2 SafetyProvider/-Consumer Sequence diagram
RQ7.12	Monitor ConsumerCycleTime in safety-related way	7.2.2.2 SafetyProvider/-Consumer Sequence diagram
RQ7.13	Implement SafetyProvider behavior	7.2.2.3 SafetyProvider state diagram
RQ7.14	Implement SafetyConsumer behavior	7.2.2.4 SafetyConsumer state diagram
RQ7.15	Rules for building the ResponseSPDU	7.2.3.1 Build ResponseSPDU
RQ7.16	Rules for calculating SPDU_ID fields	7.2.3.2 Calculation of the SPDU_ID_1, SPDU_ID_2, SPDU_ID_3
RQ7.17	Values to indicate SafetyProviderLevel_ID	7.2.3.3 Coding of the SafetyProviderLevel_ID
RQ7.18	Avoid accidental use of higher SIL indicator	7.2.3.3 Coding of the SafetyProviderLevel_ID
RQ7.19	Calculation of SafetyStructureSignature	7.2.3.4 Signature over the Safety Data Structure (SafetyStructureSignature)
RQ7.20	No evaluation of SafetyStructureSignature	7.2.3.4 Signature over the Safety Data Structure (SafetyStructureSignature)
RQ7.21	Value of SafetyStructureSignatureVersion	7.2.3.4 Signature over the Safety Data Structure (SafetyStructureSignature)
RQ7.22	Generator polynomial for CRC signature	7.2.3.5 Calculation of a CRC checksum
RQ7.23	Endianess encoding of SafetyData	7.2.3.5 Calculation of a CRC checksum
RQ7.24	CRC calculation sequence	7.2.3.5 Calculation of a CRC checksum
RQ7.25	Calculate CRC in SafetyConsumer from ResponseSPDU values	7.2.3.5 Calculation of a CRC checksum
RQ8.1	Provision of SafetyProviderDelay	8.2 Safety function response time part of communication
RQ9.1	Storage of SafetyBaseID and SafetyProviderID	9.1.1 SafetyBaseID and SafetyProviderID
RQ9.2a	(Option 1) Use stored MNR after restart	9.2 Initialization of the MNR in the SafetyConsumer
RQ9.2b	(Option 2) Use random MNR after restart	9.2 Initialization of the MNR in the SafetyConsumer
RQ9.3	Provision of and information in safety manual	9.5 Safety manual
RQ9.4	Indication of SAPI.OperatorAckRequested	9.6 Indicators and displays
RQ9.5	Properties of LED indication of SAPI.OperatorAckRequested	9.6 Indicators and displays
RQ12.1	Namespaces	12.2 Handling of OPC UA Namespaces