This annex gives an informative overview of all the requirements (safety and non-safety) which are described in this document. Both the requirement description and the corresponding page number are given. Note that to fully understand a requirement and its context, it is necessary to consult its original definition. This annex serves merely as a tool for quick navigation.
For the conventions used for numbering requirements, see Clause 3.4.2.
[RQ2.1] A safety device with OPC UA Safety shall fulfill the requirements of the relevant safety standards, such as IEC 61508 (according the SIL-level as described) when used in live operation. 3
-[RQ3.1] Any CRC signature calculation shall start with a preset value of “1”. 8
-[RQ3.2] Any CRC signature calculation resulting in a “0” value, shall use the value “1” instead. 8
-[RQ3.3] SPDUs with all values (incl. CRC signature) being zero shall be ignored by the receiver (SafetyConsumer and SafetyProvider). 8
f)[RQ4.1] The OPC UA Safety stack is intended for implementation in safety devices exclusively. Exceptions (e.g. for debugging, simulation, testing, and commissioning) shall be discussed with a notified body. 9
[RQ4.2] All technical measures for error detection of OPC UA Safety shall be implemented within the SCL in devices designed in accordance with IEC 61508 and shall meet the target SIL. 11
[RQ4.3] For the realization of OPC UA Safety, the following measures shall be implemented: 12
[RQ4.4] The safety measures shall be processed and monitored within the SCL. 12
[RQ5.1] However, whenever qualifier bits are used, the values shown in Table 5 shall be used, i.e., 0x1 for a valid value (“good”), and 0x0 for an invalid value (“bad”). 14
[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. 15
[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. 15
[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. 16
[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. 16
[RQ6.4] For diagnostic purposes, the SPDUs received and sent shall be accessible by calling the method ReadSafetyDiagnostics. 16
[RQ6.5] To reduce the number of variations and to alleviate validation testing, the following restrictions apply to instances of SafetyProviderType and SafetyConsumerType (or instances of types derived from SafetyProviderType or SafetyConsumerType): 18
[RQ6.7] Instances of SafetyProviderType shall use non-abstract DataTypes for the arguments OutSafetyData and OutNonSafetyData. 21
[RQ6.12] To define the concrete data type for the ResponseSPDU (which specifies the concrete data types for SafetyData and NonSafetyData, respectively), proceed as follows: (1) Derive a concrete data type from the abstract ResponseSPDUDataType. (2) In doing so, add the following fields to the structure in the given order: (a) First, field OutSafetyData with the concrete structure data type for the SafetyData (which has to be a concrete structure data type, see clause 8.2.1.4). (b) Second, field NonSafetyData with the concrete structure data type for the NonSafetyData (or a placeholder data type, see requirement RQ6.8). 27
[RQ6.8] To avoid possible problems with empty structures, the dummy structure NonSafetyDataPlaceholder shall be used as DataType for OutNonSafetyData when no non-safety data is used. The datatype-node defining this structure has a fixed node-ID and contains a single Boolean. 28
[RQ6.9] Only scalar data types shall be used. Arrays are currently not supported by this part. 28
[RQ6.10] For controller-like devices, the supported data types and the maximum length of the SafetyData shall be listed in the user manual. 28
[RQ6.11] For the data type Boolean, the value 0x01 shall be used for ‘true’ and the value 0x00 shall be used for ‘false’. 28
[RQ7.1] The SAPI of the SafetyProvider represents the safety communication layer services of the SafetyProvider. Table 24 lists all inputs and outputs of the SAPI of the SafetyProvider. Each SafetyProvider shall implement the SAPI as shown in Table 24, however, the details are vendor-specific. 30
[RQ7.2] Each SafetyProvider shall implement the parameters and constants [RQ7.3] as shown in Table 25. The parameters (R/W in column “Access”) can be set via the SPI, whereas the constants (R in column “Access”) are read-only. The mechanisms for setting the parameters are vendor-specific. The attempt of setting a parameter to a value outside its range, or of the setting of a read-only parameter, shall not become effective, and a diagnostic message should be shown when appropriate. The values of the constants depend on the way the SafetyProvider is implemented. They never change and are therefore not writable via any of the interfaces. 31
[RQ7.4] Each SafetyConsumer shall implement the SAPI as shown in Table 26, however, the details are vendor-specific. 35
[RQ7.5] Each SafetyConsumer shall implement the parameters and constants [RQ7.5b] as shown in Table 27. The parameters (R/W in column “Access”) can be set via the SPI, whereas the constants (R in column “Access”) are read-only. The mechanisms for setting these parameters are vendor-specific. The attempt of setting a parameter to a value outside its range, or of the setting of a read-only parameter, shall not become effective, and a diagnostic message should be shown when appropriate. The SPI of the SafetyConsumer represents the parameters of the safety communication layer management of the SafetyConsumer. The values of the constants depend on the way the SafetyConsumer is implemented. They never change and are therefore not writable via any of the interfaces. 37
[RQ8.1] The flags of the Safety Consumer (RequestSPDU.Flags) shall be used as shown in Clause 6.2.1. 41
[RQ8.2] SafetyData shall contain the safety-related application data transmitted from the SafetyProvider to the SafetyConsumer. It may comprise multiple basic OPC UA variables (see Clause 6.4). For the sake of reducing distinctions of cases, SafetyData shall always be a structure, even if it contains a single basic OPC UA variable, only. 41
[RQ8.3] The flags of the SafetyProvider (ResponseSPDU.Flags) shall be used as shown in Clause 6.2.2. 41
[RQ8.4] Flags in the ResponseSPDU.Flags which are reserved for future use shall be set to zero by the SafetyProvider and shall not be evaluated by the SafetyConsumer. 41
[RQ8.5] The SafetyConsumerID in the ResponseSPDU shall be a copy of the SafetyConsumerID received in the corresponding RequestSPDU. See Clause 8.2.3.1. 41
[RQ8.6] The MonitoringNumber in the ResponseSPDU shall be a copy of the MonitoringNumber received in the corresponding RequestSPDU. See Clause 8.2.3.1. 41
[RQ8.7] This CRC-checksum shall be used to detect data corruption. See Clause 8.2.3.5 on how it is calculated in the SafetyProvider and how it is checked in the SafetyConsumer. 41
[RQ8.8] This structure shall be used to transmit non-safety data values (e.g., diagnostic information) together with safe data consistently. Non-safety data is not CRC-protected and may stem from an unsafe source. 41
[RQ8.9] When presented to the safety application (e.g., at an output of the SafetyConsumer), non-safety values shall clearly be indicated as “non-safety”, by an appropriate vendor-specific mechanism (e.g. by using a different color). 41
[RQ8.23] In the case of Client/Server communication, a SafetyConsumer’s OPC UA mapper may call a SafetyProvider (either the state machine implementation itself or the SafetyProvider’s OPC UA mapper) with an identical RequestSPDU multiple times in a row. In that case, the SafetyProvider (state machine or OPC UA mapper) shall answer all requests. 42
[RQ8.24] For each SafetyProvider, the implemented choice of behavior according to RQ8.23 (i.e., whether currently available process values or initially returned values will be used) shall be documented in the corresponding safety manual. 42
[RQ8.10] Figure 18 shows a simplified representation of the state diagram of the SafetyProvider. The exact behavior is described in Table 29, Table 30, and Table 31. The SafetyProvider shall implement that behavior. It is not required to literally follow the entries given in the tables, if the externally observable behavior does not change. 43
[RQ8.11] Figure 19 shows a simplified representation of the state diagram of the SafetyConsumer. The exact behavior is described in Table 32, Table 33, and Table 34. The SafetyConsumer shall implement this behavior. It is not required to literally follow the entries given in the tables, if the externally observable behavior does not change. 46
[RQ8.12] The ResponseSPDU shall be built by the SafetyProvider by copying RequestSPDU.MonitoringNumber and RequestSPDU.SafetyConsumerID into the ResponseSPDU. After this, SPDU_ID, Flags, the SafetyData and the NonSafetyData shall be updated. Finally, ResponseSPDU.CRC shall be calculated and appended. 56
[RQ8.13] SPDU_ID_1, SPDU_ID_2 and SPDU_ID_3 shall be calculated according to 57
[RQ8.14] Exactly one of the values provided in Table 36 shall be used as constant code value for SafetyProviderLevel_ID. They were chosen in such a way that the hamming distance becomes maximal (hamming distance of 21). 58
[RQ8.15] Measures shall be taken to avoid that a SafetyProvider is erroneously using a code-value belonging to a SIL that is higher than the SIL it is capable of. For instance, a SafetyProvider capable of SIL1-3 should not be able to accidently use the value 0xAB47F33B used for SIL4. One way to achieve this is to avoid that this constant appears in the source code of the SafetyProvider at all. 58
[RQ8.16] SafetyStructureSignature shall be calculated as CRC32-signature (polynomial: 0xF4ACFB13, see Annex B.1) over SafetyStructureIdentifier (encoding: UTF-8), SafetyStructureSignatureVersion and the sequence of the DataType IDs. After each datatype ID, a 16-bit zero-value (0x0000) shall be inserted. All integers shall be encoded using little endian byte ordering. Data shall be processed in reverse order, see Annex B.1. The value “0” shall not be used as signature. Instead, the value “1” shall be used in this case. 59
[RQ8.17] SafetyStructureIdentifier may be visible in the OPC UA information model for diagnostic purposes but shall not be evaluated by the SafetyConsumer during runtime. 59
[RQ8.18] For all releases up to Release 2.0 of the specification, the value for SafetyStructureSignatureVersion shall be 0x0001. 59
[RQ8.19] The generator polynomial 0xF4ACFB13 shall be used for the 32-Bit CRC signature. 60
[RQ8.20] If SafetyData is longer than one byte (e.g., if it is of data type UInt16, Int16 or Float32), it shall be decoded and encoded using little endian order in which the least significant byte appears first in the incremental memory address stream. 60
[RQ8.21] The calculation sequence shall begin with the highest memory address (n) of the STrailer counting back to the lowest memory address (0) and then include also the SafetyData beginning with the highest memory address. 60
[RQ8.22] On the SafetyConsumer, CRC_calc shall be calculated using data received in the ResponseSPDU, and not from expected values. 62
[RQ9.1] Every time the macro <Set Diag(SD_IDerrOA, isPermanent)> is executed within the SafetyConsumer, the textual representation shown in Table 37 shall be presented. The details and location of this representation (display, logfile, etc.) are vendor-specific. 63
[RQ10.1] To support the calculation of SafetyConsumerTimeOut the SafetyProvider shall provide the SafetyProviderDelay as an attribute in the OPC UA information model, see Table 13. 68
[RQ11.1] The parameters SafetyBaseID and SafetyProviderID shall be stored in a non-volatile, i.e., persistent, way. 69
Option 1: [RQ11.2a] Whenever the connection is terminated, the current value of the MNR shall be safely stored within non-volatile memory of the SafetyConsumer. After restart, the previously stored MNR is used for initialization of the MNR (i.e., in state S12 of the SafetyConsumer state machine). 70
Option 2: [RQ11.2b] Whenever the SafetyConsumer is restarted (i.e., in state S12 of the SafetyConsumer state machine), the MNR is initialized with a 32-bit random number. 70
Either [RQ11.2a] or [RQ11.2b], or an equivalent solution shall be fulfilled. 70
[RQ11.3] According to IEC 61508-2, the suppliers of equipment implementing OPC UA Safety shall provide a safety manual. The instructions, information and parameters of Table 40 shall be included in that safety manual unless they are not relevant for a specific device. 72
[RQ11.4] The device a SafetyConsumer is running on shall be able to indicate if SAPI.OperatorAckRequested is enabled. This can be done for example by an indicator LED or by using an HMI. 73
[RQ11.5] If an LED is used for indication, it shall blink in green color with frequency of 0.5 Hz whenever the output SAPI.OperatorAckRequested is true of at least one of the SafetyConsumers running on the device. 73
[RQ13.1] Table 50 provides a list of mandatory and optional namespaces used in a Safety OPC UA Server. 81
____________