Safety can be alarming

I just read an interesting article in the September issue of InTech titled "Operators on alert".  It covers the controversial issue around how much safety credit (i.e. risk reduction) can be given to an operator's response to an alarm.  

This article does a nice job of describing how the functional safety standard (ANSI/ISA 84) and the alarm management standard (ANSI/ISA 18.2) can be used in cooperation to help one derive the overal effectiveness an operator can have on his safety performance

You can read the entire article at  www.isa.org/intech/20090901

Why Seperate when you can integrate

I'm taking a stance, and publicly telling you my vision on the issue of separation and integration for safety and control.  When this happens, is still up to debate.

I believe that one day it will only take one control system to automate your critical process.  That's right, there will be day where it is commonly accepted that a single platform can and will provide both control and safety shutdown operations.  The system themselves will be able to provide the logical seperation necessary to comply.

However, before this comes to fruition, it will take much work on system manufactures to provide a hardened platform that is both capable and reliable to take on this responsibility, and even more importantly plant owner/operators to have the diligence to instill complete safety lifecycle procedures at their facilities. 

Some manufactures may argue they're already there.

 

To Integrate or not to integrate Safety and Control

As I began my career in Process Control almost 20 years ago, I remember asking my mentor why our process & instrumentation diagrams (P&ID’s) showed field instruments and final control elements wired up to two different control systems.  His simple explanation was that the distributed control system (DCS) was used to control the process while the programmable logic controller (PLC) was for safety interlocks.  That made no sense to me considering my lack of experience, so I pushed him for a better explanation.  His polite, yet ‘curt’ response on my follow up questioning went something like this “Look kid, the PLC does binary or discrete logic while the DCS does analog or 4-20ma logic”.  Okay, electrically that made sense to me, not sure why, but I left it at that.

Not long after that conversation, hybrid control systems starting hitting the market.  These revolutionary control systems touted the ability to do both analog and discrete control in a single platform.  Technically, we had crossed the bridge of functionality between these disparate systems, but what impact would that have on safety?  A lot as most process industry related standards, text books and guidelines at that time realized the inherent differences and pretty much forbid the integration of control and safety within the same platform.

In the fall of 2004, the ANSI\ISA-84.00.01 Functional safety standard was officially released.  This standard recognized that user/operators could quantify their plants inherent risks and reduce it accordingly with or without separate and independent systems.  Of course with that, came a lot of confusion. 

In October of 2005, I authored and presented a paper at the ISA expo 2005 that identified and describe three simple ways a safety instrumented systems (SIS) could be integrated with basic process control (BPCS).  My goal was to communicate that integration could mean different things to different people and that folks should be aware of such. 

Today, I still see a lot of confusion over this issue on what’s right and what is ‘really’ right.  I recently personally witnessed another vendor use my same 4 year old illustration on SIS integration and bugger it all up to position his system (of course) as the best approach, ugh! 

The answer is not with a vendor whose underline message is “buy mine”, nor from that elderly colleague who’s reluctant to any change, and is convinced his 30 year approach is the ONLY way to go.  Nope, the answer is that it all DEPENDS.  It depends on many factors regarding your process, level of risk needed to be reduced, complexity, management of change issues, budget, communications, security, etc.  Just don’t let someone with a louder voice and stronger opinions convince you otherwise, you do have choices.

When Standards don't comply

A technical standard is an established norm or requirement. It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes and practices, often referred to as ‘good engineering practice’.

There’s usually a lot of good reasons why we try to adopt and follow standards (can you imagine hiring an electrician to wire your new home without following the latest National Electric Standard NEC standards?).  Unfortunately, in our world of process safety understanding how to correctly apply the latest standards isn’t so clear for many.  And in some cases understanding what’s compliant and what’s not is even muddier.
In a recent case that I got personally involved with, there was a requirement that actually complicated the safety solution and resulted in a less than safe design.  How can that be?

Well it can, and often does, when our equipment technology advances ahead of the standard for which it is being specified for.  In this case, the standard hadn’t been updated to recognize some safety equipment offers preconfigured, tested and certified safety techniques that meet the standard’s intended requirement (in this case it was memory corruption).  Unfortunately, the standard was pretty clear on having to add this ‘extra’ external device which only served to complicate the design, increase the nuisance trip rate and overall add more risk.

Planning safety sessions for ISA expo 2009

This past fall I was appointed as the Safety theme chair for ISA expo 2009 (Oct 6-8 2009).  Essentially what this means is that I’m responsible for putting together the entire track of safety sessions. 

At first I was honored and excited about the opportunity to put together a 3 day focus on safety.  But now, with the economy as it is, and travel restrictions for many of us, I’m finding this to be a challenging task.

First I needed to assemble my safety committee, and for this I wanted to gather a team representing end-users, consultants and vendors (yes, even my own competitors).  After a few e-mails and phone calls I’m happy to say that I’ve assembled a good group of individuals that includes; Kevin Klein (Celanese), Sean Cunningham (Kenexis) and Jack Murray (Emerson). 

We had our first face-to-face meeting at ISA’s headquarters in Raleigh, NC this past week.    After a couple days of brainstorming, I'm proud to announce that we have agreed on developing sessions on the following:
Safety System maintenance
Safety Fieldbus implementation
Functional Safety Standards update and panel discussion
Safety system application case study’s
Safety Lifecycle Process - Tutorials
Impact of Instrumentation in SIS applications
Safety Lifecycle tools

This year (as with past) it is expected that our program consist entirely of solicited papers and presenters.  While I like the idea, as it allows for us to be more focused and controlled and solicit on papers and presenters who we know will provide a world class event.  It does, however place the burden on us for creating a top-notch event for ISA.  Feel free to let me know what safety topics you'd especially be interested in learning at ISA expo 2009.

Let’s talk about SIX

Next week (Wednesday, November 5th) I have the honor of delivering a 45 minute presentation at the exiderdome in New York City.  If you haven’t heard, or don’t know what exiderdome is, then check it out at www.sea.siemens.com/exiderdome the short of it, well it’s my companies corporate marketing extravaganza geared for the automation industry.  If that’s not clear, then check out the website.

After securing the coveted, 4:15pm – 5pm timeslot, my next challenge was figuring out what to cover that would keep folks enlightened, entertained and of course awake.  That’s where I came up with the clever them of “Let’s talk about SIX”, meaning of course, answering six of the most commonly misunderstood issues around process safety. 

I invite anyone out there who wants to know the story behind any of these "SIX" important process safety topics to come join me next Wednesday, at exiderdome New York City.

1. What is the Safety Lifecycle?
2. How integrated can my safety and control system be?
3. How much redundancy is required for achieving my safety requirements?
4. How much safety (SIL) do I really needed?
5. Can I safety perform “On line changes” to my safety system?
6. How do I Calculate SIL levels?

And please let me know if you have any other questions you’d like me to answer as well at the next exiderdome.

When 1+1 doesn’t equal two

One would think that simple math would be sufficient when dealing with safety systems?  For the most part this is true, as today, simplified formulas are widely accepted for modeling safety instrumented systems.  The calculations used to help predict the performance of a specific safety design are derived from statistical formulas that most of us learned in our statistics courses we took in college.  Today, there are a number of software based tools to help make all of this as simple as a few mouse clicks. 
While I’ll be the first to agree software tools are great, we mustn’t lose site on the fundamentals.     

As users, we have the ability to impact the system performance in any of the three key variables:
1. Redundancy (1oo1, 1oo2, 2oo2, 2oo3, etc.)
2. Component failure rate (dangerous vs safe)
3. Proof test interval (monthly, yearly, etc.)

I was challenged by a person whose belief was that two SIL 1 components could not, and would not make a SIL 2 design.  This person had some experience plugging in the data, however the software tool that he was using was only yielding SIL 1. 

Bottom line, we discovered his test interval was fixed (yearly) and that his redundancy was built for safety (1oo2), so we turned our focus on his component dangerous failure rate.  Turns out, that the component dangerous failure rate was barely capable of achieving SIL1, with that being the case his statement was accurate, but if his dangerous failure rate dropped from .5 to .15 he would easily achieve SIL 2.    It’s pretty easy to see for yourself, just use the equation for a 1oo2 design:
PFDavg = (λdu)2 *(TI)2/3
Where:
λdu = Dangerous undetected failure rate
TI = Manual test interval

Blow it up and they will come

Process Safety BLOG goes Mainstream

Last week I was notified that my blog was getting picked up by a new website dedicated to Safety.  Stay tuned, as www.Safetybase.com will be going live soon.  It’s exciting to be a part of this new educational-based safety website dedicated to serve the safety needs of the general automation industry. 

I’m honored to join this elite group of experts coming together to provide up-to-date ideas and information on for the changing landscape of process safety.
 
The website’s idea is simple, provide a single access point for obtaining critical safety information for both the process and machine industry.  

Its design is community based, so information will be provided and shared by consultants, end-users and vendors to help you stay current on the latest advancements in safety.  Get the safety information you need and enter into discussions with your peers – to leverage your knowledge base and maximize your productivity.  If it’s about automation and machine safety – you’ll find it at SafetyBase.com.
 
Coming to the cyber world soon, check it out – www.SafetyBase.com and let me know what you think.

Update on the ISA84 Main Committee and Working Group meeting

Last week, about 40 process safety enthusiasts attended the spring 2008 S84 meeting in West Palm Beach, Florida.

The main committee meeting generally consists on brief updates on the individual working groups and the maintenance of the current ANSI/ISA S84.00.01 (IEC 61511 modified).

A couple topics that I thought were pretty interesting were the discussion on ongoing hardware fault tolerance requirements.  I’ve blogged on this before and there’s some obvious concern over products that are reaching the market today claiming to have SIL 3 capabilities with no redundancy.  I still think there is much confusion on this as one well respected end-user noted there dissatisfaction while trying a “new” transmitter claiming to provide high SIL levels, but caused them lot’s of problems with nuisance trips. 
I still get aggravated with the misconception of safety and spurious trip rate.   They are separate and have to be treated as such.

I’ll be the first person to say “yes, my company develops SIL 3 certified, non-redundant products, that will most likely have a higher spurious trip rate than a non-redundant, non-SIL certified device.”  The ONLY way to combat the spurious trips is to add redundancy.

The other topic that puzzled me was the inaccurate statement made regarding the status of safety fieldbus.  Again, it was erroneously stated that there was no safety fieldbus today for the process industries.  Luckily, there were a few “informed” safety experts in the room that noted the existence of PROFISAFE and ASI-safe.  I guess some people are still confused since FF-safety, has yet to be approved or released for safety communications.

I spent the rest of the meetings involved in Fire & Gas working group going over comments on the last draft we issued.

Introducing a non-redundant, redundant SIL 3 solution?

Last month, Siemens Energy and Automation released a new safety I/O card that claims to be the first Hart, Analog input, SIL 3
http://www2.sea.siemens.com/News/Industrial/First-SIL-3-Certified-Hart-Analog-Input-Module.htm

While some may find this as a break thru, it’s what I view as a direction of the industry.  Siemens and other automation suppliers (Emerson, Yokogawa) have introduced and have been offering for several years now, “updated” safety systems, that don’t require redundancy to achieve high levels of safety.  In the past, safety systems required dual, triple or even quadruple redundancy just to achieve high levels of safety.  So what happened?

 

For starters, you need to have a clear understanding on what this means.  These systems are designing safety into their core design.  They no longer “need” additional hardware to internally compare with in order to achieve high safety levels.  They utilized special designs with dedicated internal circuitry that can provided diagnostic coverage levels that had previously been not conceivable.

 

These advanced safety designs provide user benefits by increasing safety while allowing redundant architectures to perform the way they were intended to, prevention against nuisance trips.  An additional benefit is that these systems are immune to system degradation where a conventional “voting” system, needed its redundant partner(s) to help provide high safety.

 

Another common misunderstanding is how these systems address field redundancy (sensors and final control elements).  While I can’t speak for the Emerson or Yokogawa system, I do know for a fact that the new Siemens HART analog input module handles redundant field devices just like any dual, triple or quadruple redundant system would.

Treat your SIS better than Certified pre-owned

Last month we decided it was time to upgrade the old family car.  After searching for several weeks, we decided on a very nice, 3 year-old, certified pre-owned.   While I haven’t purchased a used vehicle in several years, I felt comfortable in this decision as the price was attractive, the warranty was extended, plus I had the assurance that this car had passed the manufactures’ grueling inspection. 

After the first week of owning our new (used) car, I called the dealership to have them install one of those MP 3, auxiliary connections (a result of my purchase negotiations).  While dropping off the car, I happened to mention the brakes were squeaking when lightly applying the brakes.  I figured this was surely the result of new pads wearing in…….  I mean they couldn’t “certify” a car with bad brakes?  I had put less than 200 miles on the car, so it had to be something else, something minor, right? 

The follow up call I got from the service manager answered that question.  “Mr. Fialkowski, we replaced both front and rear brakes for you”.  “No charge, it’s under warranty”.  Boy was I glad to hear that…..

This experience had me wonder how end users in the process industry tackle their own certified Safety Instrumented Systems (SIS) tests.  As most know, when we design an SIS we have to account that they system periodically, MUST BE TESTED.  So how rigorous are we with carrying out these tests, would we allow something as critical as brakes slip under the cracks?  Surely, we have developed exhaustive “punch-lists” that have been reviewed, validated and audited to minimize potential problems? 

I once heard an end user state that when their technician tests their safety valve, it would not be uncommon to bang it with a wrench to “help it along”.  If after this “adjustment” it moves to its “safe” position, he’ll note it as “test-passed”.

Makes me wonder just how my car could have passed this seemingly critical test, or am I just being too sensitive?  I mean it was under warranty….I’m just thankful it wasn’t under critical circumstances.    

Belts and Suspenders?

 

For so many years we have been trained (brainwashed) to believe more redundancy = more safety.  While for some situations it’s true.  Increase your level of redundancy your system will get better safety performance.  However, if you do it WRONG, it’s a proven fact (not just me spouting off) your safety performance will degrade. 

 

This week I ran into a very smart person, who just happened to say the dumbest thing all day.  “We needed safety, so we made the thing redundant”.   

My dad used to say to me “It’s like polishing the brass when the ships sinking”.  If your going to do something, make sure its really worthwhile, otherwise you just wasting your time.

Does past experience equal Prior Use?

So you’re faced with the question of whether that trusty old transmitter you’ve been using as part of your safety shutdown system can meet the “prior use” requirements described in Section 11.5.3 of ANSI/ISA-84.00.01-2004 (IEC 61511-1 Mod). 

Prior use, or Proven-in-use, is defined as a documented assessment showing there is appropriate evidence, based on the previous use of the component, that the component is suitable for use in a safety instrumented system.

Let’s focus on the question “how much operating experience is required to make sure a product has enough safety integrity?”

Lucky for us, IEC 61508 provides specific details on this.

For a given component’s version level IEC 61508 suggests 100,000 unit hours for components targeted for SIL 1 applications and 10 million unit hours for components targeted for SIL 3 applications.  Along with the operating hours, one must also provide documented proof test results for all detected dangerous failures.

Of course there’s a lot more discussion on ISA’s web site in an article written by Bill Goble.  www.isa.org

Not Worth A SFF

In attending last week’s 63rd Annual Texas A&M Instrumentation symposium, I was shocked to hear from a well respected safety expert that SFF (Safe failure fraction) was a failed metric.  No explanation, just that SFF was pretty much useless, followed by a cackle.  I really hate when people make profound statements like this, with no reasoning or justification behind it.  I felt as if the audience was just bullied into this person’s position, and all were just too intimidated to challenge it.  So what’s wrong with SFF?

SFF is defined in ANSI/ISA-84.00.01-2004 Part 1 (IEC 61511-1 Mod), as the fraction of the overall random hardware failure rate of a device that results in either a safe failure or a detected dangerous failure.  It’s sole purpose was to help prevent over optimistic SIL claims by equipment manufactures, and helped to determine the required fault tolerance of your SIS (safety instrumented system). 

While I didn’t get a chance to follow up directly with the individual, I’m pretty sure the argument has something to do with how your system actually responds to a detected dangerous fault.  If your system detects a dangerous fault within itself, does it automatically shutdown your process, or just alarm the operator?  If it’s the latter, than the SFF’s pretty much a failed metric.