The concept of industrial safety has evolved since relays were first employed for safety applications in the 1930s. In the 1950s, DuPont developed its first safety standards, and several vendors introduced solid-state safety systems in the 1970s. It could be said the era of high-tech safety began in 1969 when programmable logic controllers (PLCs) emerged on the market and were soon adapted for safety applications, albeit with somewhat checkered results.1 NASA’s research on fault-tolerant critical controls produced triplicated systems in 1980, and the original ISA 84 standard initiative began in 1987, with the standard itself being published in 1996.
Clearly, the road to where industrial process safety is today has been long and storied with many lessons learned, but there remain obstacles to overcome. Current-generation safety technology and standards are more than adequate, but industry knowhow in the area of developing and implementing effective safety programs is, in many cases, lacking.
“It’s clear that many people who are now responsible for designing [safety] systems are not familiar with the standards, what the standards say, or what designers and users need to understand and do in order to follow them,” says Paul Gruhn, P.E., ISA Fellow and Global Process Safety Consultant for Rockwell Automation. “People need to be competent and qualified to do this work, and it’s clear that many are not.”
A Lifecycle Approach
If control systems were perfect, never failed, and it was possible to anticipate every possible hazard scenario in advance, safety systems would be unnecessary. Unfortunately, everything fails, it’s just a matter of when.
Gruhn says an effective safety program is one that meets the required performance at minimal cost. The current industry standard (IEC 61511/ISA 84) documents the overall design lifecycle (from cradle to grave), methodologies for determining the required SIL (Safety Integrity Level) for each SIF (Safety Instrumented Function), and how to determine the optimum design for any system. “Following the standards allows users to optimize the design the first time, rather than over designing (i.e., wasting money), or under designing (i.e., having to do things over again),” says Gruhn.
By employing a lifecycle approach for safety, end-users can more effectively ensure the system includes appropriate analysis, implementation, testing, operations, and decommissioning. “You can’t just buy safety,” says Ian P. Burns, P.E, CFSP, for Applied Control Engineering Inc., a certified member of the Control Systems Integrators Association. “You need to adopt the entire lifecycle. The lifecycle ensures that hazards are identified, safety requirements are developed, systems are designed to meet the requirements, systems are tested to meet the requirements, and ongoing operation and maintenance is performed to make sure the system continues to meet the requirements.”
Standards & Technology
Unlike many standards, the safety practices noted in IEC 61511/ISA 84 are not prescriptive, i.e., they do not define a specific strategy, design or required instrumentation for a hazard, such as the NFPA standards do for fired heaters and boilers. Rather, they provide a framework or methodology for the user to guide the design process. The user must apply the methodology to their process and get the involvement of more than just the safety engineer in the design team. Finally, the user should understand the concept of the safety function. Each safety function consists of a sensor, a logic processor, and a final control element. The combination of the components in the safety function determines how the system will perform.
With the creation of the ISA S84 committee and the release of the ISA 84 standard, the idea of performance-based safety was formalized. The standard covers safety from its inception, through analysis, design, testing, maintenance, and decommissioning. “Safety instrumented systems perform all of the same functions as the original emergency shutdown or interlock systems, but [the standard considers] how much safety do you need and does your system meet your safety needs,” says Burns.
On the technology end, there is a range of solutions that can be employed for safety applications—switches vs. transmitters, relays vs. solid state vs. software for logic solvers, etc. However, the IEC 61511/ISA 84 standard is, at its heart, performance- rather than technology-focused.
“SIS standards were not created to make life more difficult for everyone,” says Gruhn. “They were created based on accidents, lessons learned, and government regulations. They are the combined knowledge of hundreds of organizations from around the world, [that] have learned all this material the hard way.”
Gruhn warns companies against complacency. “Statements such as, ‘We haven’t had an accident in 15 years, therefore we are safe’ are a complete fallacy,” he says. “No doubt managers said that one day before Bhopal, Chernobyl, Flixborough, Pasadena, Texas City, etc. Ignorance is not bliss, it’s just ignorance.”
Pitfalls & Recommendations
According to Burns, one of the most common pitfalls encountered when designing a safety program is that process and safety functions are often combined into a single controller or system. “An effective SIS segregates these functions and puts a clear separation between the two,” says Burns. “A common problem with current designs is that the safety system can be rendered ineffective or inoperable due to a change in the process control system.” By separating the systems, Burns says an operator or engineer is free to make changes to the control system without jeopardizing the safety system. In addition, he says an effective SIS approach requires a management of change process and restricted access to the SIS to avoid inadvertent and potentially damaging changes.
Ultimately, the SIS is only as effective as the people who are designing it are informed. There is a range of training and programs related to industrial process safety available through organizations like TÜV and ISA, as well as certifications through the Certified Functional Safety program (see table).
Both Gruhn and Burns are bullish on safety systems education. “A HAZOP really needs to be led by someone who has led a HAZOP before,” says Burns. “Understanding all of the steps and getting them done right is important.” Experience is also key for the programmers, who Burns says should also be certified against IEC 61511.
Going Forward
In the years to come, the overall design of safety systems probably isn’t going to change much. “You’re still going to have sensors, logic solvers, and final control elements,” says Burns. However, he says the components will get smarter.
“Just as all control-related hardware and software is benefiting from increased computing power, so will the components in an SIS,” says Burns. “We have seen the computerization of field sensors and process control valves. These improvements have provided increased diagnostics. Additional computing power will add more diagnostics to help minimize undetected errors in devices, thereby making them more reliable.” More specifically, he says functions of logic solvers will allow for more online edits, and the addition of more SIFs, etc., will continue. Likewise, he says tools that allow for programming of SIFs with pre-tested algorithms will help prevent mistakes.
In the end, Gruhn says it’s not the technology that is going to make the difference on whether a process is safe or not. “The path to better and safer facilities is having people [who] understand the standards and how to follow them,” he says.
Matt Migliore is the director of content for Flow Control magazine and FlowControlNetwork.com. He can be reached at 610 828-1711 or [email protected]. Follow Matt on Google+. Connect with Matt on LinkedIn.
References
1. “PLCs and Safety PLCs: Lessons from Pucker Events,” InTech, June 2008,
