### 6 Information Models

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.

### 6.1 Object and ObjectType Definitions

This method is mandatory for the profile SafetyProviderServerMapper and optional for the profile SafetyProviderPubSubMapper (see 13.2.2.1). 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 8.1.3.2 and 8.1.3.4).

Signature

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

Argument Description
InSafetyConsumerID “Safety Consumer Identifier”, see SafetyConsumerID in Table 24.
InMonitoringNumber “Monitoring Number of the RequestSPDU”, see Clause 8.1.1.2 and MonitoringNumber in Table 24.
InFlags “Byte with non-safety-related flags from SafetyConsumer”, see Clause 6.2.1.
OutSafetyData “Safety Data”, see Clause 8.1.1.4.
OutFlags “Byte with safety-related flags from SafetyProvider”, see Clause 6.2.2.
OutSPDU_ID_1 “Safety PDU Identifier Part1”, see Clause  8.1.3.2.
OutSPDU_ID_2 “Safety PDU Identifier Part2”, see Clause  8.1.3.2.
OutSPDU_ID_3 “Safety PDU Identifier Part3”, see Clause  8.1.3.2.
OutSafetyConsumerID “Safety Consumer Identifier”, see SafetyConsumerID in Table 24 and Table 27.
OutMonitoringNumber    Monitoring Number of the ResponseSPDU, see Clause 8.1.1.8, Clause  8.1.3.1, and Figure 14.
OutCRC CRC-checksum over the ResponseSPDU, see Clause 8.1.3.5.
OutNonSafetyData “Non-safe data” see Clause 8.1.1.10.