5 things to consider when selecting a safety system
Safety is among the top priorities in any manufacturing facility, and given the changes in the industry, technology and even standard, there are a lot of concerns starting with the selection of a safety system.
The performance based safety standards (IEC61508 and IEC61511/ISA84) have changed the way safety system selection should happen. Gone are the days of simply choosing a certified product, or selecting a preferred architecture; today’s system selection is driven by performance requirements.
1: Hazard understanding
Correct, this has nothing to do with the safety system hardware. It is critical in the process to understand the scope of the process hazards and to determine the necessary risk reduction required. This should be done to create the Safety Requirements Specification (SRS) necessary to start a system selection. Even when replacing an existing system, this is critical as the risk profile of the plant may have changed since installation.
2: The more diverse the better
Technology diversity: There has been a long standing requirement that a safety system must be different (or diverse) technology from its process automation counterpart to avoid common cause failures. But most safety systems rely on component redundancy (hardware fault tolerance, or HFT) to meet reliability and availability requirements, introducing a degree of common cause failure directly into the safety system.
Rather than redundancy, leading systems now provide diversity of technologies designed into logic solvers and I/O modules, along with a high degree of diagnostics, to allow a simplex hardware configuration to meet SIL3 requirements.
Product implementation diversity: The standards are imposing diversity on the way manufacturers deliver the product you buy. Even though most safety systems are manufactured by process automation vendors, organizational diversity between the two product teams is only the first level of separation.
Within the safety product team, leading suppliers will also be separating the design group from product development group and then again from product testing group. Ask your potential suppliers how diverse they really are?
3: Systematic safeguards
This addresses how much protection against mistakes is built into the safety system. You should be asking for:
- certified software libraries that offer functions according to the SIL requirements of the application,
- compiler restrictions to enforce implementations according to the SIL requirements,
- user security management to separate approved from non-approved users for overrides, bypass and other key functions,
- and, audit trail capability to record and document changes to aid in compliance with functional safety standards
As mentioned above, previous generations of safety systems met reliability requirements through HFT. This feature helped to provide availability and kept plants running in the event of a component failure with the safety system. Whether you needed it or not, you paid for it. Understand if you need high availability or not as some processes can easily tolerate shutdowns from spurious trips when using simplex configurations that still deliver appropriate SIL coverage.
If you know you need availability, look for a system supporting firmware update or upgrade and maintenance without disrupting the process.
5: Separate, interfaced, or integrated?
Using the SRS and your business requirements, make a clear determination of one of these three requirements. Integrated offers many key benefits, drawing on common capabilities of the process automation system not related to the safety functions directly. But only being interfaced or even kept completely separate are options, and need to be thoroughly considered.
However, achieving the desired risk reduction involves more than just choosing a system. On our next posting we’ll cover implementation, security, operation, and maintenance of a safety system.
Luis Duran is Product Marketing Manager at ABB for the Safety Automation System business.