OPC UA Safety diagnostics may be implemented in a non-safety-related way. It allows for categorization and localization of safety communication errors.
OPC UA Safety provides two types of diagnostics:
- OPC UA Safety diagnostics messages generated by the SafetyConsumer and provided in a vendor-specific way.
- The method “ReadSafetyDiagnostics”, defined in the OPC UA Information Model (see Clause 6.1.2 and Clause 9.2).
[RQ9.1] Every time the macro <Set Diag(SD_IDerrOA, permanent)> is executed within the SafetyConsumer, the textual representation shown in Table 29 shall be presented. The details and location of this representation (display, logfile, etc.) are vendor specific.
Table 29 – Safety layer diagnostic messages
|
Internal identifier (as used in the state-machines) |
General Error type(String) |
Extended error type (String) |
Error code(offset) |
Classification *)(optional) |
Mandatory |
|
SD_IDerrIgn |
The SafetyConsumer has discarded a message due to an incorrect ID. |
|
0x01 |
A |
Yes |
|
SD_IDerrOA |
The SafetyConsumer has switched to fail-safe substitute values due to an incorrect ID. Operator acknowledgment is required. |
Mismatch of SafetyBaseID |
0x11 |
B, E |
Yes |
|
SD_IDerrOA |
The SafetyConsumer has switched to fail-safe substitute values due to an incorrect ID. Operator acknowledgment is required. |
Mismatch of SafetyProviderID |
0x12 |
B, E |
Yes |
|
SD_IDerrOA |
The SafetyConsumer has switched to fail-safe substitute values due to an incorrect ID. Operator acknowledgment is required. |
Mismatch of safety data structure or identifier. |
0x13 |
B, E |
Yes |
|
CRCerrIgn |
The SafetyConsumer has discarded a message due to a CRC error (data corruption). |
|
0x04 |
A |
Yes |
|
CRCerrOA |
The SafetyConsumer has switched to fail-safe substitute values due to a CRC error (data corruption). Operator acknowledgment is required. |
|
0x14 |
B, C |
Yes |
|
CoIDerrIgn |
The SafetyConsumer has discarded a message due to an incorrect ConsumerID. |
|
0x05 |
A |
Yes |
|
CoIDerrOA |
The SafetyConsumer has switched to fail-safe substitute values due to an incorrect consumer ID. Operator acknowledgment is required. |
|
0x15 |
B |
Yes |
|
MNRerrIgn |
The SafetyConsumer has discarded a message due to an incorrect monitoring number. |
|
0x06 |
A |
Yes |
|
MNRerrOA |
The SafetyConsumer has switched to fail-safe substitute values due to an incorrect monitoring number. Operator acknowledgment is required. |
|
0x16 |
B, C |
Yes |
|
CommErrTO |
The SafetyConsumer has switched to fail-safe substitute values due to timeout. |
|
0x07 |
B |
Yes |
|
ApplErrTO |
The SafetyConsumer has switched to fail-safe substitute values at the request of the safety application. |
|
0x08 |
D |
No |
|
FSV_Requested |
The SafetyConsumer has switched to fail-safe substitute values at the request of the SafetyProvider. Operator acknowledgment is required. |
|
0x20 |
F |
Yes. |
*) The following classification is specified:A) Transient communication errorB) Permanent communication errorC) Transmission quality seems not to be sufficientD) Application errorE) Parameter errorF) Error does not affect communication itself.
In order to avoid a flood of diagnostic messages in case of transmission errors, only up to two messages are shown even if multiple communication errors occur in sequence. This is ensured by the design of the SafetyConsumer’s state machine.
Optional Feature:Extended diagnostic data by expected value and received value, e.g.Mismatch of safety data ProviderID:Expected ProviderID: 0x00000005Received ProviderID: 0x00000007
This method (as part of the OPC UA Mapper) is provided for each SafetyProvider serving as a diagnostic interface. For time series observation, this interface can be polled, e.g. by the diagnostic device. For details, refer to the OPC UA information model described, see Clause 6.1.2.
The diagnostic interface method does not take any input parameters and returns both the input- and output parameters of the last call of the method ReadSafetyData.
Additionally, a 2-byte sequence number is added to the diagnostic interface, allowing for a detection of missed calls due to polling. The sequence number counts the number of accesses to ReadSafetyData.
A best practice recommendation is to store all input- and output parameters if SComErr_diag is <> 0.