4.3 Communication structure

OPC UA Safety is based on:

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

Safety applications and standard applications are sharing the same standard OPC UA communication systems at the same time. The safe transmission function incorporates measures to detect faults or hazards that originate in standard or black channel elements 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 / 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" (“Black Channel”) does not need any additional functional safety assessment.

The basic communication layers of OPC UA Safety are shown in Figure 2.

image005.png

Figure 2 – Safety layer architecture

Summary of the Safety layer architecture:

Part: Application layer

The Safety application is either directly connected to the SafetyProvider / SafetyConsumer, or it is connected via a Machine-Specific-Interface, which is specified in companion specifications (e.g. sectoral).

The Safety application layer is expected to be designed and implemented according IEC 61508.

The Safety application layer is not in the scope of this part.

Part: OPC UA Safety

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

Safety data is transmitted by point-to-point communication (unidirectional). Each unidirectional connection internally communicates in both directions, using a request/response pattern. This allows for checking the timeliness of messages using a single clock in the SafetyConsumer, thus eliminating the need for synchronized clocks.

When SafetyConsumers connect to SafetyProviders, they have an a priori expectation regarding the pair of SafetyProviderID and SafetyBaseID. 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, a SafetyProvider does not need to know the ID of the SafetyConsumer and will provide its process value to any SafetyConsumer requesting it.

SafetyProviders are not capable of detecting communication errors. All required error detection is performed by the SafetyConsumer.

If a pair of safety applications needs to exchange safety data in both directions, two pairs of SafetyProvider and SafetyConsumer must be established, one pair for each direction.

The OPC UA Mapper implements the parts of the safety layer which are specific for the OPC UA communication service in use, i.e. “pub/sub” or “client/server”. Therefore, the remaining parts of the safety layer can be implemented independent on which OPC UA service is 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.