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.
This method is mandatory for the profile SafetyProviderServerMapper and optional for the profile SafetyProviderPubSubMapper (see 184.108.40.206). 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 may receive invalid responses resulting in a safe reaction which may lead to spurious trips and/or system unavailability.
The method argument OutSafetyData has an application-specific type derived from Structure. This type (including the type identifier) 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 values instead (see state S16 in Table 33 – SafetyConsumer states as well as Clauses 220.127.116.11 and 18.104.22.168).
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) ;
Table 8 – ReadSafetyData Method Arguments
|InSafetyConsumerID||“Safety Consumer Identifier”, see SafetyConsumerID in Table 24.|
|InMonitoringNumber||“Monitoring Number of the RequestSPDU”, see Clause 22.214.171.124 and MonitoringNumber in Table 24.|
|InFlags||“Byte with non-safety-related flags from SafetyConsumer”, see Clause 6.2.1.|
|OutSafetyData||“Safety Data”, see Clause 126.96.36.199.|
|OutFlags||“Byte with safety-related flags from SafetyProvider”, see Clause 6.2.2.|
|OutSPDU_ID_1||“Safety PDU Identifier Part1”, see Clause 188.8.131.52.|
|OutSPDU_ID_2||“Safety PDU Identifier Part2”, see Clause 184.108.40.206.|
|OutSPDU_ID_3||“Safety PDU Identifier Part3”, see Clause 220.127.116.11.|
|OutSafetyConsumerID||“Safety Consumer Identifier”, see SafetyConsumerID in Table 24 and Table 27.|
|OutMonitoringNumber||Monitoring Number of the ResponseSPDU, see Clause 18.104.22.168, Clause 22.214.171.124, and Figure 14.|
|OutCRC||CRC-checksum over the ResponseSPDU, see Clause 126.96.36.199.|
|OutNonSafetyData||“Non-safe data” see Clause 188.8.131.52.|
Table 9 – ReadSafetyData Method AddressSpace definition