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
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.