From redundancy to reliability: the rise of safety PLCs in industrial automation

In a recent design meeting, it was brought up that a vendor has made its regular programmable logic controllers (PLCs) and safety PLCs the same price. The “safety PLC” is no longer more expensive for the hardware. Availability still may be an issue at times, and the programming costs may go up, but the safety chassis is becoming a mainstay. Let’s look at the advantages of a safety PLC.

Safety is a design requirement for modern machines. Many customers must meet IEC 61508 or ISO 13849-1 standards or best practices. However, many machine builders have started defaulting to safety PLCs as a standard due to streamlining software and hardware requirements. It’s easier to plan controls based on safety architecture, as opposed to not.

In simple terms, the safety PLC can take care of general automation tasks of motion, sequencing, communications and inputs and outputs, as well as emergency stops, light curtains, safety doors, two-hand control and other functions. The safety PLC also allows a dual-channel architecture and validates I/O using safety protocols.

A dual-channel architecture allows for redundancy and fail-safe controls. This can be as a dual processor, independent safety circuits, watchdog timers and self-diagnostics, and certified safety outputs like force guided relays. A key factor in safety PLCs is understanding how they are communicating. One communication option is CIP Safety. CIP stands for common industrial protocol. Remember a protocol is a set of rules.

CIP has specific communications checks in the CIP Safety packet. The packet has an originator, a validator client, a validator server and a safety target. There is a data link between the client and the server, and that link carries the message when there is a connection. If the connection times out, then a fault can be thrown. Another way of thinking about it is safety producer, producer, consumer, safety consumer. This allows CIP applications to send safety messages on their own alongside regular operations messages.

Normal activity for a producer and a consumer goes as follows:

1. Establish a connection.
2. Producer sends a ping, which is a network utility command.
3. Consumer responds to ping.
4. Transmission time is calculated.
5. If less than max time, then use the data.
6. If more than max time, then discard the data.
7. If too many packets, then fail safe.

What can you monitor in a CIP safety network?

• Message repetition based on repeats due to timing or cyclic redundancy checks (CRC).
• Message loss for when a message does not reach its target.
• Message insertion errors may be related to timing, identification or CRC checks.
• There could also be delays or corruption.
• Data in a bridge on the network, might age out, as well.

All of these are added communications checks that can be applied in CIP Safety. This also allows an architecture to recognize devices.

Recognizing a device on a safety network is accomplished by understanding the safety signatures on the network and knowing when a signature might change or has been changed. For instance, a controller safety signature may include layers of data including firmware revisions, controller identity and the safety application signature.

Get your subscription to Control Design’s daily newsletter.

Under the safety application, there would be controller safety tags, safety add-on instructions or functions, safety inputs and outputs, safety attributes, safety tag mapping, safety tasks and safety programs. Drilling down into the program, would show safety program tags and safety routines.

Why do controls engineers need to understand this? If the safety routine changes, then the signature in the controller changes. If a safety tag is added, the signature changes. If there is a firmware revision, the signature changes. The controller validates the signature report when the controller is compiled or turned on or adjusted. Thus, changing hardware is regulated, and changing the program is regulated.

The same kind of reporting happens with EtherCAT and functional safety over EtherCAT (FSoE) protocol. EtherCAT uses a safety communications layer with a safety logic connection and a black channel. Again, though, the protocol maps the application, data link and the physical layer between a producer and a consumer, or a client and a server. EtherCAT bases its functional safety communication model on IEC 61784-3.

FSoE acts a little differently than CIP, in that it has a state machine handoff between devices and the controller. Those states are reset, session, connection, parameter, and data. When the reset is OK, the session is OK and the connection is OK, then the parameter is sent and then the parameter is acknowledged as OK, and then the connection has been successful.

Like CIP the safety data is encapsulated in the EtherCAT frame. EtherCAT rides on Ethernet as does the CIP. Like CIP, there is a sequence number, an identifier, a watchdog and a CRC calculation. This means that the safety network may handle the errors: repetition, loss, insertion, incorrect sequence, corruption, delay, masquerade and incorrect forwarding. This should sound familiar as the results of CIP are similar.

Both CIP and FSoE meet IEC 61508 standards for safety integrity level (SIL) 3. FSoE also checks for integrity of the safety configuration, like CIP uses signatures, and thus the errors on compilation when the safety circuit changes or the software changes without updating the configuration in the controller.

Is CIP better than FSoE or vice versa? It depends on whom you ask and what you are familiar with. As a controls engineer or machine builder, it’s best to understand how they work, so that troubleshooting a configuration problem is easier when the downtime call occurs.