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.
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.
The flip side is that a standard PLC is capable of more complex control functions than a safety PLC.
Dave Collins, machine safety products,
Schneider Electric, www.schneider-electric.us
Five 9s Safe
Safety controllers are designed so in a failure it fails in a safe manner 99.99999% of the time for an SIL-3-rated controller, the most commonly used in machine-control applications.
You can use a single, integrated safety controller for safety and standard functions. While a safety controller is capable of doing simple standard control functions, most lack the ability to segregate the safety from the machine control code. This segregation is important because you cannot use standard signals in a safety loop. Use of a standard input in your machine safety code can nullify the SIL rating of your machine and potentially endanger the machine operator.
Use of an integrated safety controller provides the best of both worlds but is inherently different from a safety-only controller. An integrated safety controller has provisions to keep the safety and standard programs, data tags, inputs and outputs segregated from the standard ones. You will not be able to inadvertently use a standard input in a safety loop because the controller and programming software will prevent you from doing so. However, because the safety and standard controllers are integrated, proper sharing of data between the safety and standard side is allowed—i.e., reading the status of a safety input or safety output from the standard program to coordinate machine operation or for improved diagnostics.
The ability to implement safety control within an architecture that also performs multidisciplined control delivers significant benefits. Hardware, software and support costs are minimized with assets shared by both the standard and safety control systems. Furthermore, the intelligence and diagnostics of the automation system operationally improve equipment productivity and lifespan and reduce downtime.
Jeff Gellendin, product manager, safety controllers,
Rockwell Automation, www.rockwellautomation.com
The safety PLC is invariably more expensive than a standard PLC and has a very limited instruction set, custom-designed with function blocks for emergency-stop functions, safety gates and guard-door switches. The programming is intended to be very specific to the tasks handled by the machine-guarding functionality. The I/O modules of a safety PLC are much more limited in scope with just certain digital inputs and outputs and perhaps no analog at all. A safety PLC monitors voltage of the power supply, the temperature of every safety terminal and the integrity of the wiring connections configured, and it sends special communication signals through the connected digital input and output devices that a standard PLC would not. These are huge technical differences, and this level of complexity is not needed for a general-purpose PLC controller.
The two worlds of safety PLCs and regular PLCs were brought together for better integration, to reduce wiring, and to increase the amount of information sent between the safety system and the general control system, which reduces troubleshooting time when a safety-related issue does occur. But do not confuse these two kinds of PLCs; each has a very different function even though on the outside they may appear to do a similar job.
Kurt Wadowick, I/O systems product specialist,
Beckhoff Automation, www.beckhoff.com
Check and Cross-Check
You can use a safety-certified PLC for safety logic and standard logic. The most practical configuration for a combined system is to use a safety PLC CPU that allows both safety-rated I/O modules and standard I/O modules in its backplane. This eliminates the need to use a separate safety-only-rated PLC system along with a separate standard PLC or the additional expense of using safety-rated I/O, even for devices that are not part of the safety circuitry.
A safety PLC is designed to exceed national consensus standards on what is considered safe design for software/firmware-based safety control (IEC 61508 and others). It offers extra diagnostics, microprocessors, cross-checks, watchdogs and checksums. These are implemented at all hardware and firmware levels, so safety is implemented in a consistent, safe and certified manner, across all the applications developed by all of the various project engineers.
In safety PLCs, checks typically are implemented as automatic module functions without programmer involvement. In other cases, the safety PLC adds things that could not be user-implemented, such multiple microprocessors inside the I/O module that constantly check and cross-check each other for proper function.
So, a safety PLC can be used for standard I/O and safety functions. It is possible to simply add safety I/O to standard PLC functions, but it would require additional cross-checking, logic limitations and other costly and restrictive steps.
Tom Elswick, consulting systems engineer – safety,
Siemens Energy & Automation,