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