Closing the loop on safety system maintenance

“You really have to make safety a closed-loop system." Dan Posten discussed the importance of creating a collaborative platform for planning, executing and validating maintenance of a plant’s safety instrumented functions.

Everyone knows all potential hazards and every possible safety threat can't be eliminated, but they also know we can each get closer to zero incidents—and do it using tools and capabilities that are typically already in place and available.

"Safety systems and their requirements can be very complex, so we want to simplify as much as possible," said safety systems consultant Daniel Poston, P.E., TÜV FS Eng. "Random failures are predictable by understanding the failure modes that need to be tested. Systematic safety issues and failures are real, but they're rarely addressed appropriately because there's no plan or they aren't addressed in initial designs. As a result, we need to develop more robust processes that minimize and eliminate systematic errors before they happen."

Poston presented "Goal Zero Functional Safety: Safety System Lifecycle Execution with Small Company Resources," this week at the EcoStruxure Triconex User Group conference in Galveston, Texas.

Random vs. systematic

To head off hazards, threats and incidents at the pass, Poston explained that end users must start with the right criteria for their applications and facilities, which means they often look to safety standards for guidance. For example, IEC 61511, 2nd edition, has section 3.2.23 on functional safety that advises, "Part of the overall safety relating to the process and the basic process control system (BPCS) depends on the correct functioning of the safety instrumented system (SIS) and other layers, such as mitigation, prevention, control/monitoring and process."

This lays the groundwork for determining, designing in, implementing and achieving safety integrity, which section 3.2.68 defines as the ability of an SIS to perform its safety instrumented function (SIF), according to Poston. "To determine safety integrity, all causes of random hardware and systematic failures that lead to an unsafe state can be included, such as hardware failures, software induced failures and failures due to electrical interference," he stated. "Some of these failures, especially random hardware failures, may be quantified using measures such as average dangerous failure frequency or the probability of failure on demand. However, safety integrity also depends on many systematic factors that can't be accurately quantified, and are often considered qualitatively throughout the lifecycle.

"Random and systematic failures must be considered to achieve required safety integrity. Some can be put into designs, but not all." Poston added that:

• Random hardware failures (section 3.2.58) typically occur at predictable rates but at unpredictable times.
• Systematic failures (section 3.2.81) are related to pre-existing faults, and can only be eliminated by modifying designs, processes, operational procedures or documentation.
• Combined cause failures (section 3.2.6.1) are concurrent failures of different devices that result from one event.

Plan, operate and maintain

Once safety integrity has been designed into a system or application as much as possible, and problematic issues have been removed, Poston reported that safety becomes more of a maintenance issue. This is where the safety planning/operate and maintain (section 5.2.5.3) takes over by advising, "Procedures shall be implemented to evaluate the performance of the SIS against its safety requirements to identify and prevent systematic failures that could jeopardize safety." Meanwhile, section 16.2.2 details maintenance procedures to be followed when faults or failures occur in an SIS, such as fault diagnostics and repair, revalidation, maintenance reporting and tracking.

"If systematic faults still exist, we need to identify and eliminate them," said Poston. "This can be difficult because systematic issues can also creep into designs. The impact of systematic error on safety integrity also depends on the complexity of the process system, number of people involved, and the safety level they're trying to achieve. All of these contribute to where and how much attention needs to be paid to safety."

Functional safety management

To handle all these operational factors but still keep systems running safely, Poston reported that functional safety management (FSM) principles and tools offer the most useful methods and procedures. "FSM depends on the correct functioning of the SIS," he explained. "This includes creating a plan; putting processes in place to execute it; following those processes; validating that those processes were followed; and correcting errors. You really have to make safety a closed-loop system."

For a large process application, facility or organization with hundreds of SIFs including many at SIL 2 or higher, Poston added that designing a safety system can be extremely complicated, and will involve people from all related disciplines. To determine challenges, minimize errors and fill gaps in procedures, he recommended that users employ software tools like Microsoft SharePoint that many already have installed.

"In a typical FSM project, users can transfer their process hazards analysis (PHA) to SharePoint and an Excel spreadsheet; create safety functions and safety requirement specifications (SRS); manage project issues and action items; and coordinate training, competencies, functional safety analysis (FSA), management of change (MOC) and procedures. All of these can be tied into a good FSM process tool. Later, they can compare what they thought would happen to what really happened, find new issues and remove them, too."