Methods for Testing Safety Critical Loops

A big thanks to Emerson’s Mike Boudreaux for his guest post while I’m out this week.

Jim is on vacation this week. He knows that I always have something to say about process safety and functional safety, and so he’s agreed to let me to fill in for him as a guest author for the Emerson Process Experts blog today. Thanks, Jim!

I was up late the other night, clicking around in the LinkedIn groups for DeltaV, process safety, functional safety, security, and other topics that I find interesting. One of the groups that I frequently visit is named EHSQ Elite. EHSQ Elite is a group of safety, security, risk, regulatory, sustainability, health, environmental and quality professionals working in or for the industry, authorities and service sectors. The group has over 7,400 members, and claims to be the biggest and fastest growing safety oriented group on LinkedIn. EHSQ Elite has a very active discussion group. I saw that EHSQ Elite is sponsoring a process safety seminar series, so the group seems to be growing outside of LinkedIn.

It is definitely the largest group that I’ve seen in LinkedIn. The group is so active that it is really hard to keep up with all of the discussions and news feeds, and if you’re primarily focused on process safety then it can be hard to sort through the noise. Luckily, LinkedIn has recently provided a new feature that enables the creation of subgroups. Pieter-Jan Bots, the manager of the group, has quickly taken advantage of this new feature and created several subgroups related to different safety topics. One of the subgroups that he created is Process Safety Management. I anticipate that this new group will grow quickly under the EHSQ Elite group. It is less than a month old and it already has 80 members.

One of the discussion topics in the group is “Methods for testing safety critical loops?”

What methods are available for testing the different elements in safety critical loops, including initiating element (e.g. pressure or level measurement), the wiring and relays or safety logic, and the final element(s) (e.g. emergency shutoff valve))? Challenge is to test the whole loop, or make sure that all elements are functioning.

I posted the following comment there, but I think it is worth sharing with the readers of the Emerson Process Experts blog. It is so relevant to what we do here at Emerson and we already have a discussion going here about partial stroke testing. Here’s my comment.

The goal of proof testing devices is to uncover dangerous undetected failures – covert failures that prevent the device from acting when needed. Modern electronics-based devices include internal diagnostic tests that can detect dangerous failures, but there are always some dangerous failures that cannot be detected by diagnostics. Devices that are IEC 61508 certified should include a proof test procedure in the safety manual.

Testing of sensors and transmitters is usually very straight-forward. For examples of sensor testing procedures, see the manuals for the Rosemount 3051S and 3144P pressure and temperature transmitters: http://is.gd/1AIxZ (page 21) and http://is.gd/1AIFb (page 111).

For testing logic solvers, you can often separate hardware testing from software testing. Testing of the internal electronics hardware is typically very easy to do with modern logic solvers that can perform automated diagnostics and proof tests to uncover failures. For example, see section 5.3 of the DeltaV SIS safety manual: http://is.gd/1AKre. Functionally testing software (logic) is MUCH more complicated. Everyone has a different philosophy about the best practices for performing functional tests for the whole loop. A segmented approach is generally accepted, but there are many purists who want the entire loop to be tested all at once. This is sometimes impractical, though. The risk of a segmented approach is that there are opportunities for mistakes to be made since this approach relies more heavily on detailed procedures and processes. A segmented approach for functionally testing the logic solver will typically require a screw terminal to screw terminal test, by manipulating the values of input channels and monitoring the response of output channels. When possible, a test from sensor to final element is preferred, but this is not always practical. Offline simulation tools can simplify this activity so that configuration errors are caught offline before testing is performed using physical hardware.

Testing final elements is a pretty deep topic. There are MANY ways to test final elements – some are manual and some are automatic. The goal is to prove that the final element performs according to design specifications. With electronics based devices, partial stroke tests and proof tests can be automated. Here is a link to recent online discussions among functional safety experts about partial stroke testing: http://is.gd/1AK5K.

Feel free to join the EHSQ Elite Process Safety Management group in LinkedIn and join me in the discussion there!

Leave a Reply