When to integrate or separate safety and standard control?

With the advent of new digital technology it is now feasible to seamlessly integrate standard control and safety control functions within common automation infrastructure. While this can provide productivity and asset management benefits in most cases, if it is not done correctly it can compromise the safety function within the industrial operation. This makes it critically important for users to understand if integration of both functions is the correct solution for them and, if so, where common mistakes or pitfalls are encountered.

The use of programmable logic controllers (PLCs) for safety functions has become more prevalent recently thanks mainly to users becoming more comfortable in using PLCs for safety. In larger systems, especially, there is a trend towards integrating the safety control functions with standard functions when selecting PLC hardware and software. On paper, the case for integration often adds up very quickly with benefits such as:

• Single hardware platform, backbone and infrastructure
• Single software tool and single point of connection
• Single vendor and one point of support and after-sales service
• Ease of integration
• Potential cost savings from the above

Benefits of separated safety and standard control functions

However, having the systems separated has advantages, and should be taken into consideration and compared with the benefits of a single system.

• Using separate, independent and diverse hardware and software will reduce the risk of potentially catastrophic common-cause and systematic design and application errors in the system.
• Separate systems tend to lead to simpler failsafe designs that are more easily implemented and independent of the process control system.

Different vendors offer varied degrees of integration. 'Best of breed' outcomes for both safety and standard can be obtained if safety and standard are separated. Separation also allows the removal of the additional change control and potential revalidation requirements of the safety system when the standard control system is modified post-installation. Combining separated systems is much simpler now compared with 10 years ago, where you needed almost complete separation and a tiny amount of data could be shared between the standard and safety PLCs. Now PLCs can communicate directly with large amounts of information that can be simply shared or even share variables or I/O. Some systems even allow each PLC to write directly to the same output and the two signals are logically ANDed.

The first point listed above in favour a single integrated system was that there is a single hardware platform, backbone and infrastructure. In some integrated systems there is too much data to use within one network so they must be separated in order to get the system to work. Some Ethernet protocols available for safety systems, such as SafetyNET p, can operate on the same infrastructure and network as the standard system.

Finally, once the installation has been commissioned and validated, often an integrated process control and safety system can provide maintenance and testing personnel with a sense of false security, in regard to being armed with a little knowledge about standards PLCs so they apply this to the safety PLC. Without the proper change control and revalidation processes this can potentially lead to very dangerous outcomes that are left in situ after a fault that has been 'patched up' in order to get the system up and running.

Separation in accordance with Safety Standards

When designing a system to IEC 61508 Functional safety of E/E/PE (electrical /electronic /programmable electronic) safety-related systems there is a very important statement that covers the use of safety PLCs and standard PLCs for an application.

Clause 7.4.2.3 Where an E/E/PE safety-related system is to implement both safety and non-safety functions, then all the hardware and software shall be treated as safety-related unless it can be shown that the implementation of the safety and non-safety functions is sufficiently independent (ie that the failure of any non-safety-related functions does not cause a dangerous failure of the safety-related functions).

So, it is possible to use either standalone safety PLCs or use a system that handles both the safety and standard control, provided that there is clear separation and failure of the standard control cannot cause a dangerous failure. A system such as the PSS 4000 from Pilz makes it simple to separate the safety from the standard control within the one programming tool (and on the same hardware platform).

Using safe protocols

The use of Safe protocols is another area where simple mistakes are often made. As the number of safety control equipment vendors continues to grow, so do the number of safe protocols as these vendors continue to strive for connectivity between different hardware components on a safe level. A variety of fieldbus or Ethernet-based systems for standard only, safety only or a combination of standard and safety exist for several industrial applications.

Pilz released the first safe fieldbus, SafetyBUS p, in 1999 for use with the PSS 3000 safety PLC. SafetyBUS p is a CAN bus protocol, as is DeviceNet, CANopen and many more. Now the trend is more towards Ethernet networks and there is a safe version of almost every Ethernet protocol available for industrial applications.

The oldest and most used worldwide Ethernet protocol (for industrial communications, not counting OPC or TCP/IP) is ModbusTCP - which, ironically, does not have a safe version (although safe protocols can run on top it). Other protocols that do have safe versions (or are capable of running safety in conjunction with standard) are EtherNet/IP, Ethercat, Profinet (Profisafe) and Ethernet Powerlink. All were developed as a standard Ethernet network and then had safety added in a later iteration.

Pilz developed the SafetyNET p protocol for safety and standard right from the start, so it really is a combined protocol. SafetyNET p can exist with other protocols in the same network and uses standard industrial Ethernet architectures and devices.

In essence, if you have a distributed network of safety PLCs and you want to use safe remote I/O or safe data from another processor then you need to use a safe protocol. Standard protocols should only ever be used in safety PLCs for interaction of non-safety related signals with the standard PLC, diagnostic information or SCADA/HMI display purposes.

Separate PLC for safety?

Although at first glance the benefits of integrating safety and standard control functions may be attractive, make sure you spend the time analysing exactly your requirements and what you are trying to achieve. For some applications a combined system may be suitable, and for others separate systems might be the better approach. Often the easiest option is not necessarily the best - and remember, someone's safety will depend on it.

To learn more about standard control and safety control, please visit www.pilz.co.uk.