What Controls Safety?

This probably is more complicated than I think, but what are the critical hardware, firmware and/or software differences between a safety PLC and a "regular" PLC? Can I really use just one for both functions now?

—from June '09 Control Design

ANSWERS

It's All About Error Detection

This question has been on the mind of many users contemplating the use of programmable safety PLCs. The differences between a regular PLC and a safety PLC are all about error-detection. Your regular PLC will do a good job of controlling your machine, but it won't have the necessary functionality to detect errors that occur within its operating system, the application program or the I/O connected to it.

A regular PLC can have some basic detection for application program errors, like infinite loops through a watchdog. If the watchdog doesn't trigger at a set interval, the application could be stuck somewhere and the PLC will no longer process the application.

On the I/O side, regular PLCs typically have no way of detecting wiring errors on I/O such as channel mismatches, short circuits and ground faults. Safety PLC systems accomplish error detection within the operating system and application program, or the software side of the safety system, through redundancy. The safety PLC and every safety module has dual processors executing the safety application. The operating system, firmware and safety application running on each processor is generated by separate compilers, so no individual error could happen twice and go unnoticed.

On the hardware side of the safety system, any potential wiring error can be detected through input and output pulsing. Unique pulsing patterns are generated for every digital input and output signal that can detect if an I/O is properly connected or has a failure due to miswiring or cable fatigue. Also dual, redundant I/Os can further increase the level of error detection, such as a dual-channel e-stop to detect a failure of a single contact no longer opening by doing an equivalent state monitoring right on the safe input module.

All of the extra efforts for error detection come at a price though. Because of the extra efforts for redundancy, cost per I/O point is higher and density per module is lower when compared to regular I/O. So only I/Os handling safety-relevant functions should be using safety I/O, while other non-safety critical I/Os can remain regular I/O points handled by the PLC. Also, to keep the safety application "safe" and transparent, some of the programming flexibility of regular PLCs, such as high-level language programming like structured text, is not available in safety PLCs.

The key for implementing programmable safety systems is to use the best of both a PLC and safety controller integrated into a single system. Communication between both of them should be seamless. Using a single tool and connection point for programming and diagnostics reduces engineering, commissioning and maintenance times. With this approach of integrated but separated architecture, both the regular PLC and the safety PLC handle their own tasks of controlling the machine and functional machine safety respectively, while allowing maximum flexibility.

Robert Muehlfellner, director, automation technology,
B&R Industrial Automation, www.br-automation.com

Execution and Reaction Time

You can use a safety controller to control the rest of the machine, but not vice versa. However, there are many reasons not to do this. As with all safety systems, reaction time is of paramount importance since that will dictate where your detection points—light curtains, for example—need to be placed to ensure a safe stop before injury. The more tasks you give the processor to do, the longer it will take to execute and thus increase the scan time and slow down the response of the safety system. Keeping the two systems separate also increases reliability of the system and ease in troubleshooting. Did the process stop the machine, or did the safety system? But by far the best reason to keep the safety system separate from the process control is purely the cost—both the initial cost of wiring and extra or high-end CPUs to manage the response time and safety I/O and the potential end-user indirect costs of adding troubleshooting time and of the risk in changing the safety program.

The best solution for most machines is a process controller and a safety controller as entirely separate systems linked by a bus. This will provide the most economical and robust solution, allow the systems to interact, including monitoring the process and safety system on a single HMI if desired.

Dominic Caranci, PE, product marketing specialist, safety,
Omron Canada, www.omron.com

Level of Safety

The main differences between a regular PLC and a safety PLC are internal redundancy, self-monitoring and certification. Most safety PLCs are certified to IEC 61508 and assigned a safety integrity level (SIL), with SIL 3 being the highest used for machinery type of applications.

A safety PLC can be used for both standard control and safety-related functions, but a standard PLC cannot be used for safety-related functions. Some suppliers use the same application software to program both, but as a rule, the safety PLC will have a more restrictive library of functions than the standard PLC, even if the same application software package is used.