Process operators worldwide place a great emphasis on safety, not only to comply with local and international regulations but also to effectively avoid risks posed in production. However, many people understand safety differently; that affects the actions taken to reduce risk and the performance metrics used. Some sites focus primarily on enhancing occupational safety, such as preventing falls and slips, while other plants or processes face higher process safety risks, such as explosions or fires in production areas. Both aspects of safety deserve adequate attention and implementation of appropriate risk reduction measures.
It shouldn’t be a surprise that the risk reduction strategy is aligned with a corporate safety vision, in other words an explicit statement by senior management of the ethos of the company. Such a statement should link the acceptable risk for the organization (at the plant or corporate level) and guide the risk reduction strategies to follow. Every level of the organization must understand the overarching reasons for the vision and that the organizational structure, management processes, technology and human resources create a supportive framework to “live the vision.” Of course, it’s crucial that the vision and values be communicated and the effectiveness of the communication is verified. (Executives often can improve their efforts, see: “Process Safety Begins in the Board Room.")
An inadequate safety culture normally ranks among the top causes of incidents and accidents in the industry; consequences can range from minor injury to catastrophes getting worldwide news media attention.
We must understand the risk of an operation and openly discuss how to reduce it to an acceptable level. While the complete elimination of risk might not be feasible, cutting it to a level an asset owner and operator can tolerate is a must.
The first step is to understand the scope of the process hazards and determine the risk reduction required, including the role of functional safety, which is the use of equipment and systems to decrease risk. This is crucial for creating the safety requirements specification (SRS) necessary to start the system design.
Some people apparently believe that achieving adequate functional safety simply involves using a technology that has been certified according to some national or international standard and that the responsibility for functional safety rests exclusively with technology suppliers. That is not the case. However, it’s very common to find people having a “false sense of safety” for those reasons.
Functional safety standards apply to product designers, vendors, system integrators and end users. Each will have different responsibilities in the implementation of functional safety or safety systems but all must be ready to demonstrate competence for the activities directly under their charge.
Ultimately, it’s the responsibility of the end user, typically the plant operator, to demonstrate compliance to these standards and to apply recognized and generally accepted good engineering practices.
Today’s standards mandate a functional safety management system (FSMS), which is a series of work processes established on top of the traditional quality management system that addresses functional safety requirements from design through implementation to eventual modification or decommissioning of a process or system. Among other things, the FSMS must document the requirements and the validation testing to demonstrate the intended risk reduction ultimately was achieved. These procedures might require the involvement of two people and the issuance of a permit; this provides an opportunity to check (in some cases by an independent party) that everything necessary has been done and that the target risk reduction has been attained.
Some work processes may involve checklists to reduce the likelihood that standard operating procedures are not followed or steps omitted. Such checklists are useful for catching lapses where operators or engineers intended to perform the activity but were distracted by another task or simply forgot they hadn’t performed it.
When addressing the human aspect of safety, always keep in mind the words of the late Trevor Kletz , a renowned safety guru (see: “Trevor Kletz Bequeaths Better Process Safety"): “We can’t enable people to carry out tasks beyond their physical or mental abilities… [but] we can reduce the opportunities for such slips and lapses of attention by changing designs or methods of working.”
Technology certainly can help reduce risk. However, it must align with the human elements (organizational structure, management processes and human resources) for the safety framework to hold. Unfortunately, in many cases companies implement a variety of different process-safety and risk-reduction mechanisms that are disconnected from the human processes in place and decoupled from each other, thereby losing the ability to effectively assess risk or prevent a serious hazardous event.
To make matters worse, technology selection often isn’t tied to a culture of safety in the organizations making the decisions, leading to additional inconsistencies and gaps — and, therefore, creating more chances for hazards to escalate.
Technology typically centers on safety instrumented systems (SISs). Choosing such systems traditionally involves grappling with a number of questions such as: What is the architecture? Is it redundant? Is it certified? However, before asking those questions, you should go back to the SRS, the document that is the link between the hazards and risk analysis and the SIS design.
The functional safety standards define the SRS. It should provide a clear description of the functions to be carried out by the safety systems, including potential SISs, together with safety integrity level (SIL) requirements (along with mode of operation, continuous or demand) for any safety instrumented function as well as what is needed to ensure that safety is maintained. (The SIL actually necessary should be carefully assessed, see: “Do You Really Need SIL 3?")
Safety Instrumented Systems
Today’s performance-based safety standards have changed the way safety system selection should happen. Gone are the days of simply choosing a certified product or picking a preferred architecture. Now system selection is driven by performance requirements:
Hazard understanding. Properly grasping the scope of the process hazards is essential for determining the risk reduction required. Even when replacing an existing system this is critical because the risk profile of the plant may have changed since installation.
Diversity. This has two elements:
• Technology diversity. There has been a long-standing requirement that a safety system must use different technology than its process automation counterpart to avoid common cause failures. However, most safety systems rely on component redundancy, i.e., hardware fault tolerance (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 a diversity of technologies designed into logic solvers and input/output modules, along with a high degree of diagnostics, to allow a simplex hardware configuration to meet SIL-3 requirements.
• Product implementation diversity. The standards are requiring changes in the way process automation and other vendors develop and deliver the product you buy. The product team for a safety system must be separate from that for the process control system. Within the safety product team, leading suppliers also will be separating the design group from the product development group and both from the product testing group. Check how diverse your potential suppliers really are.
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.
Availability. Previous generations of safety systems met reliability requirements through HFT. This feature helped provide availability and kept plants running in the event of a component failure in the safety system. Whether or not you needed HFT, you paid for it. Some processes demand high availability but others easily can tolerate shutdowns from spurious trips by using simplex configurations that still deliver appropriate SIL coverage. So, understand the availability necessary.
If availability is essential, look for a system supporting firmware updates or upgrades and maintenance without disrupting the process.
Integrated, interfaced or separated? A safety system integrated with the process automation system offers many key benefits, drawing on common capabilities of the process automation system not related directly to the safety functions (Figure 1). However, in some cases, it may make more sense to only interface the two systems or to keep them completely separate. Use the SRS and your business requirements to determine which option is most appropriate.
Layers of Protection
The SIS is only one of multiple layers of protection that include basic process control systems, alarm systems and others that are not technology based such as work processes or plant emergency response.
While these different layers of protection should remain functionally independent from each other, it’s also important to strive for the most efficient management of process safety to improve operators’ ability to head off escalating process conditions before automated intervention is needed. Integrated systems can serve as the enabling technology to support not only making the right decisions under abnormal conditions in the plant but also measuring the right variables to ensure the safety of the facility.
In summary, safety does not happen by accident. It requires continuous and collective effort.
LUIS DURAN is safety business development manager for ABB Inc., Houston. E-mail him at email@example.com