Does using a Safety PLC mean IEC 61511 compliance?
When it comes to deciding on using hard-wired logic or a Programmable Logic Controller (PLC) for a safety instrumented system logic solver design, there are some clear positive and negatives to each approach. So, how do you decide whether a programmable system is advisable or necessary given the possibility for cyber attack* in the internet-of-things era?
Hard-wired logic has been used for decades in safety applications in the process industry sector and beyond. By hard-wired logic, I mean that the logic is built from non-programmable electromechanical components, or electronic components with well-known and predictable failure modes.
This is absolutely still a reasonable choice in applications when safety instrumented functions (SIF) are simple, and when there are very few SIF to be implemented. For such small non-complex systems, the introduction of software in the logic solver may not provide any significant benefits, and may just give a more substantial burden of managing software and cybersecurity issues.
Examples of hard-wired systems include very high integrity applications (e.g. HIPPS - High Integrity Pressure Protection Systems) where the lack of software makes validation much more straightforward. For very high-speed requirements such as turbomachinery over speed protection (e.g. gas turbines), a programmable system may also not be advisable design choice due to the speed of response required.
Simple hard-wired systems, with very few safety instrumented functions, can be implemented with safety relays as the primary logic device. Using safety relays will limit the input signals to digital (on/off) input signals, meaning SIS sensors can only be discrete switches unless some form of analog to digital converter is used.
A significant drawback is the lack of serial communications, meaning any required diagnostic signals back to the Basic Process Control System (BPCS) will also have to be hard-wired via auxiliary relay contacts.
Hard-wired logic pros and cons
Programmable logic - the Safety PLC
When it comes to solving the clear constraints of hard-wired logic, the programmable logic controller (PLC) has been the clear industry choice for more than three decades (writing in 2019).
The term "Safety PLC" is a little more recent, but this term typically means that a PLC has been specifically designed for safety applications, usually on a de-energize-to-trip principle, and assurance for safety integrity has been provided by a third party certifying agency.
Safety PLC's differ from regular ones by employing special internal hardware design principles aimed at reducing or eliminating single points of failure that could occur in regular PLC's. Internal software capability is also simplified to minimise the possibility of software errors leading to a frozen state or endless loop.
Like the regular PLC, the Safety PLC has been almost universally accepted as the path forward for safety-related automation in industry, especially when applications have larger and more complex requirements.
A Safety PLC can be easily configured to send beneficial "live" signal status and extra diagnostic information about the system's health that simply would not be practical with a hard-wired system.
Most modern Safety PLC's can readily accept multiple analog sensor signals, meaning a single instrument can provide alarm and trip points at different levels. Analog signals also enable dynamic display of the process variable and diagnostic alarm information that can give early operator warnings that may help to avoid spurious trips.
A Safety PLC comes into its own when there are multiple safety instrumented functions to manage, and where sequences, time delays or complex logic are a requirement of the process application. A programmable system can efficiently transmit data and alarms to an associated process control system (BPCS) and the operator workstation via serial communications links. If this is implemented carefully, using manufacturer rules, the SIS should not be compromised by sending useful diagnostic information to other systems.
In conclusion, all of the limitations of hard-wired systems are resolved by employing a Safety PLC, BUT, the story does not end there.
In conclusion, all of the limitations of hard-wired systems are resolved by employing a Safety PLC, but the story does not end there.
There are some concerns worth noting. These relate almost one-to-one back to the Pros of hard-wired logic outline above.
Before implementing a safety PLC, consider that:
- Safety PLC's require application program (user software) management.
- Safety PLC's require firmware (embedded manufacturer software) management.
- Safety PLC's require management of external configuration tools.
- Safety PLC's require cyber-security risk assessment.
All the above caveats can be overcome, but this is not feasible just by selecting certified equipment.