Introduction

This topic describes CIP Safety device operations, including system error detection and response mechanisms, and device operating state:

  • Power on self check

  • Non-recoverable detected error response

  • Recoverable detected error

  • Target connection health management

  • Run / Idle state of CIP Safety device

Power on Self Check of the CIP Safety Originator and Target

At power on, and each time a new application is loaded, the CIP Safety system performs the following operations:

  • The CPU transfers the configuration parameters to the CIP Safety Stack (CSS) in both the CPU and Copro.

  • The CSS, in both the CPU and Copro, evaluates the CPCRC for each connection.

  • For each connection, the CIP Safety system compares the downloaded CPCRC (calculated by the originator DTM) to the ones calculated by the CPU and Copro.

  • The CSS locks the originator configuration.

  • The application launches Type 2 SafetyOpen requests for a connection to each CIP Safety device.

  • Each CIP Safety device:

    • Calculates its CPCRC and compares it to the CPCRC received from the originator.

    • Compares the received SCID to its internally stored SCID (Note: this check applies only to configurable devices).

I/O exchanges between the originator and target devices start only if all these tests succeed.

NOTE: In addition to the power on self tests described above, the system performs all the run time self tests required by the IEC 61784-3 CIP safety standard.

Non-Recoverable Detected Error Response

If CPU or I/O diagnostics detect a non-recoverable error, the safety system places the affected part of the system into a safe state. The affected part of the system is shut down and de-energized, with safety inputs set to 0. All impacted safety outputs are driven to their configured fallback state.

Recoverable Detected Error Response

Recoverable detected errors typically include events such as a loss of module connection, and so forth. These detected errors are reported in the Health bit of the device DDDT (T_CIP_SAFETY_IO), which contains the logical AND value of the Status_IN and Status_OUT Health bits. In the case of a recoverable error detected for an input, the value of that input is forced into the safe state, and set to 0.

Target Connection Health Management

The health of a connection to the CIP Safety target is reported in the Health bit of the Status_IN and Status_OUT parameters as described in T_CIP_SAFETY_STATUS data type. Target health can be either open and operational, or error detected.

For inputs, the connection state is provided by the server safety validator; for outputs, the connection state is provided by the client safety validator.

Run / Idle

The operating state of the CIP Safety device – run or idle – is reported in the Run_Idle bit of the Status_IN or Status_OUT parameter as described in the T_CIP_SAFETY_STATUS data type.

For an input device:

When a connection with an input module is established, the Run_Idle bit is set to Idle (0) by the producer (input) until the initial time coordination sequence is successfully completed. Thereafter, the value of the bit can be 1 (Run state) or 0 (Idle state). If the Run_Idle bit is set to 0 (Idle state), the input data values are forced to 0 (Safe state).

For an output device:

The Run_Idle bit for outputs is set to 1 by the originator (CPU) when the PAC is in Run state and the initial time coordination sequence is successfully completed. The run/idle state for outputs is set to 0 by originator (CPU) when the PAC is in Stop or Halt state, or when the initial time coordination sequence has not been successfully completed, or when the connection is closed. If the Run_Idle bit is set to 0 (Idle state), the output device is expected to set its outputs to their fallback state.