Alarms and Equipment States

How many reports on hazardous incidents have you read about where the alarms presented to the operators were excessive and the resulting confusion contributed to the incident.

I was reminded by this article

Why Is Safety so HARD?

The problem has been known and understood for decades, and now we all know that alarms should be suppressed when they are not relevant, and that when they are they should be prioritised.

But engineering a solution is time consuming and expensive.

The solution has to be specified, reviewed and approved, and maintained as operating experience is gained and the solution is modified, via an approved change process of course.

Typically these are described by text, cause and effect matrices and logic diagrams.  

Mostly the cause and effect matrices describe the responses to potential hazardous events, such as process upsets. The matrices do not often cover the alarms, although some do mention them typically in notes. Some control system actually support Cause and Effect matrix based design, and can translate them into control logic. For example Siemens has one

These are much more constrained than the typical excel version that people produce.

 

Using a state model provides a highly efficient way to define the enabling of alarms. The safety system, as a complete entity is defined in terms of possible states, a method that vastly reduces the number of states that have to be considered.

Then each possible alarm can be considered for it relevance in each state, producing an Alarm State Matrix. 

Hacking Safety Systems

I don't normally comment on this area, but I do track what is going on.
Walt Boyes has written on his 'blog' about a demonstration of compromised Safety System, read it all here
I have resp0nded, not least because many year ago I was delegated the job of checking out alarming reports about Y2K faults that might blow by up refineries. I had a free hand to investigate the truth about such tales, and invariably I found bad science.
The dialog so far follows.

Walt,
When you say things like “blow up a refinery” it suggests that some software fault (eg caused by some hacker) might have the capability of doing that. But as you know the ultimate protection, and a great deal of effort goes into it, is at the lowest physical level possible, relief valves for example. And hard wired logic, high integrity safety systems etc. I had this argument over Y2K many years ago. Don’t you think you may be feeding the trolls? Francis www.controldraw.co.uk
Comment by FrancisL Posted on August 12, 2008 @ 11:26 am

No, I am not feeding trolls. Francis, I saw a live demonstration of a hack against an SIS system last week. It took 26 seconds to cause the valves to fail open. The danger is in fact real.
Comment by waltboyes Posted on August 12, 2008 @ 12:01 pm

More details please Walt. My mind boggles that anyone could engineer an SIS to permit such a hack, and how such an SIS could be even called a safety system. And does the situation not imply that a failure in the SIS (hacked or not) could open the valves? So how can it be called an SIS? Francis
Comment by FrancisL Posted on August 13, 2008 @ 11:47 am

Your guess is as good as mine. Fact remains, this product is being sold as a SIS. I do not know the vendor. Anytime a SIS is connected to the plant network, it becomes open to an attack. Nearly all PLCs, including safety PLCs are vulnerable to DoS attacks unless properly firewalled. I have not much more information, because the demonstrator was unwilling to share too many.