This chapter describes the identifiers, types and structure of the objects and methods that are used to implement the OPC UA mappers defined in this part. 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. IMPORTANT NOTE:
Neither online browsing nor offline engineering currently supports any features to detect errors. Hence, no guarantees with respect to functional safety are made. This means that online browsing can only be used for diagnostic purposes, and not for exchanging safety-relevant data. In the context of offline engineering, the programmer of the safety application is responsible for the verification and validation of the safety application. It must be assumed that errors may occur during the transfer of the information model from one engineering system to another.
As a consequence, all type values described in this clause are defined as read-only, i.e., they can not be written by general OPC UA write commands.
[RQ6.1] Each server shall have a singleton folder called SafetyACSet with a fixed NodeId in the namespace of OPC UA Safety. 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/or SafetyConsumers. SafetyACSet is intended for safety-related purposes only. It should not reference to non-safety-related items.
Table 4 – SafetyACSet definition
OrganizedBy by the Objects Folder defined in OPC 10000-5.
|HasTypeDefinition||ObjectType||FolderType||Entry point for all SafetyProviders and SafetyConsumers|
[RQ6.2] In addition, a server shall comprise one OPC UA object derived from type SafetyProviderType for each SafetyProvider it implements, and one OPC UA object derived from type SafetyConsumerType for each SafetyConsumer it implements. The corresponding information model shown in Figure 6 and Figure 7 shall be used.
Figure 6 describes the SafetyProvider and the SafetyConsumer.
NOTE: OPC UA Safety assumes (atomic) consistent data exchange between OPC mappers of the two endpoints.
[RQ6.3] For implementations supporting OPC UA Client/Server, the Call-Service of the Method Service Set (see OPC 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.3a] 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.
NOTE: The terms “request” and “response” refer to the behavior on the layer of OPC UA Safety. Within the PubSub context, both requests and responses are realized by repeatedly publishing and subscribing datagrams, see Figure 17.
[RQ6.4] For diagnostic purposes, the SPDUs received and sent shall be accessible by calling the method ReadSafetyDiagnostics.
Figure 6 – Server Objects for OPC UA Safety
NOTE: for the input/output arguments of the methods ReadSafetyData and ReadSafetyDiagnostics, see Clause 6.1.3 and 6.1.4. For the parameters of the SafetyProvider and SafetyConsumer, see Figure 9, Table 13, and Table 14. For RequestSPDU and ResponseSPDU, see Table 8, Table 19, Table 21, and Clause 8.1.1.
Figure 7 shows the instances of server objects for OPC UA Safety. The ObjectType for the SafetyProviderType contains methods having outputs of the abstract data type ”Structure”. Each instance of a SafetyProvider needs its own copy of the methods which contain the concrete DataType for “OutSafetyData” and “OutNonSafetyData”.
Figure 7 – Instances of server objects for OPC UA Safety