We have a SCADA system used to remotely operate a chain of Hydro Power stations. The operators spend a lot of time acknowledging alarms that they can take no further action with. The intention is to develop a formal strategy for alarming inputs to the SCADA can anyone offer suggestions or outline for developing such a strategy.

It is intended that this strategy be implemented as a set of rules for our engineers and designers so new work complies with some standard as to what inputs are required into the system. We will also need to review our existing SCADA database to comply with our strategy.

Regards,
Mark Mullins
Microtech Electronics.

 

I'm not quite sure what you mean or want to do, but in the description of your problem you said the operators (etc.) used a lot of time to acknowledge alarms which they coulden't do anything with. This is a common problem and I have solved it in the following way.

First you have to split alarms in to three groups
A,B and C alarms.

The A alarm you must acknowlegde and it will give an sound(buzzer,pager etc..) to the operator.

The B alarm happens but it will only appear in the alarm lists.

The C alarm is a A or B alarm that is temporarly blocked by a user( because of new biulding, service) and will not appear at all.

using these simple rules the operator can manage alarm handling online in everyday work.

To show all A or B alarms in the same windows or in separate it's up to you. You should have a windows where all alarms are and showing the status and be able to activate C status.

 

Hello Mark

I think, you need to further explain your problem.

How many alarms signlas do you get concurrently.
How many Hydro Power Stations are chain?
What SCADA software are you currently using?
Do you have a classification for your alarms?
Do you have more than one SCADA system?
How many operators do you have?

regards

Cuitlahuac Picasso

 

In response to Mark Mullins' request..

I have always regarded Beville Engineering's Alarm Response Analysis approach as one of the best. (www.beville.com) It is very straight forward. The two rules seem to be: 1) every alarm should be unique 2) each alarm must have a unique operator action.

When do you really need an alarm system to work? - when you have a crisis. This means alarm showers are dangerous. Engineering companies for years have been asking the question "what should I alarm". When they don't get an answer from the operations rep they play it "safe" and alarm everything. This is not the safe approach.

I am always amazed that when you talk to operators and ask what alarms do you really need that there are very few. I think that the critical alarms should be separated from "events" that are journalled. When the operator shows up at a remote site he can look at the event journals. I have never understood why we want a lot of local alarms ringing at remote sites.

Hope this ramble helps.

Rob Bronson
Petro-Canada Upstream

 

Start by making up a priority system for alarms. While top priority may require immediate action, the lower levels may not be programmed to require
acknowledgment and may simply be logged. Then organize the data according to the priorities and move toward implementation.

The problem is that you are sending data to the operators, not information. You must appropriately filter, log, and present the information the operators need, not everything you can send.

Darold Woodward PE
SEL Inc.
[email protected]

 

Hello Mark,

Depending of which SCADA package you use, you will find on the market some packages dedicated to the "intelligent filtering" of alarm. In general those package are based on a expert system (ruels engine). The advantage of those
systems is the capacity to avoid redundant alarm for the same failure.

The "strategy" for alarming is implemented as a set of rules. The startegy itself depend on your HAZOP review. For specific industries these HAZOP must be reviewed by external experts before you can implement it (insurance, ...).

If you need more information, please feel free to contact me.

Regards

Steve Monnet
SMAPI2 Sarl
www.smapi2.com

 

To add to the 'Alarm Handling Strategy':
One can also identify which is 'Parent' alarms. Some SCADA's (FactoryLink) can handle parenting. A parent is something such as a line pressure. If a line pressure drops, then one can have a shower of alarms. If one classifies these shower as a result of the drop in line pressure, then these are the 'children' of the line pressure. By carefully selecting the correct parents, one will only see the real alarms. The 'Children' can be configured to act as 'real' alarms if they appear for example an hour later than the line pressure or when the line pressure restores and the child is not recovered by say an hour.

The A,B and C alarm types is definitely a good idea.

Thanx!

Frik Olivier

 

Dear Mark,

We had a similar situation in a huge captive power plant. What we did was..
1) First branched off the area(s) & ensured that the alarms from a particular area pops up as an alarm to only the concerned operator's console, whereas on the other operator's console the same alarm would be auto acknowledged.
2) We had lot of PLCs communicating with the central DCS. In some cases, when the PLC link gets disconnected (due to any reason - even
say maintenance), lot of alarms use to generate. We avoided that through conditional alarm. i.e., Alarms on those PLC tags use to generate only when say master PLC HEALTH tag status is okay. If PLC communication breaks down, automatically all the alarms are either suppressed or auto acknowledged.
3) Generally the system designer plays it safe by providing alarms on almost all tags. But we sat with the operators & operation engineers and did a major exercise by listing down all available
tags, and identifying the tags on which they want alarms. Listed it down and wrote all values such as high high, high, low, low low, what priority they want (high, medium or normal), whether they want that process value on history trending, real time trending, etc.
Though it was a big exercise, we had to do it atleast once. By this exercise, we could eliminate all duplication exercise & reduce the number tremendously. You would certainly need the help of operations group.
4) You could also think of one more option. If a particular unit (say turbine) is under shutdown condition, you could suppress all alarms on that unit.

I think above points would help you in your exercise.

Best Regards,

K. Venkatachalam

 

i think there are two capabilities an alarm management system should have, beyond the obvious filter by group, filter by priority, and filter
by acknowledgement. for clarity's sake, i should point out that, in the descriptions that follow, i use the term "point" where many people use
"tag"; that is, a configurable element of a runtime database that receives data or events, and performs processing, often including the
generation of alarm events.

1. summary alarms

an arbitrary (i.e. configuration-driven) group of alarms are summarized in a single alarm. (if the system defines alarms only in terms of database points, a point must be allocated to carry the summary alarm.)

a summary alarm should be able to contribute to a higher-level summary alarm.

there should be no constraint on a single alarm contributing to multiple summary alarms.
i.e. a hi temperature alarm could contribute to a summary of the alarms in my environmental control unit, a separate summary of all temperature
alarms, and a summary of all points whose wiring is routed through cable tray A-7)

it may be desirable for a summary alarm to carry its own configured priority, or to reflect the priority of the highest-priority contributing alarm.

it may be desirable for an operator acknowledgement of the summary alarm to auto-ack all the contributing alarms, down to some arbitrary hierachical depth. (typically, the only two generic choices here are "no auto-ack", "ack one level" and "ack all levels". that is, ack-ing a summary alarm either acks nothing, only the immediate contributors, or the entire tree.)

it may be desirable for the summary to reflect the ack state of its contributing alarms. that is, the summary is ack'd if all its contributors are individually ack'd and clear if all its contributing alarms have cleared.


2. alarm inhibition

each point that can generate an alarm (actually, each alarm that can be generated, but most systems
don't define an alarm without a point to carry it) can be configured with an "inhibit" condition.

typically, the inhibit condition is usually implemented as another database point. when a live point receives an update, the value of the
inhibit point is checked against a threshold to determine whether or not to exercise the alarm processing of the point being processed.

there is no real reason why multiple points should not be able to inhibit alarm processing an a given point. i.e. a flow rate value should not alarm if the PLC providing some of its input data has already indicated comm failure, or if the valve it is measuring is flagged Out of Service, or if the level alarm is a cascade event, caused by a stuck valve that has already gone into alarm.

it should be possible to configure a system such that inhibited alarms are reevaluated when the inhibiting condition clears. it is not always
the case that an alarm condition that occurs during an inhibition should forever after be ignored. in some circumstances, an operator doesn't want to see those alarms; in some cases she does. One hybrid strategy is to reevaluate previously inhibited alarms, but auto-ack them when they are created. this way, the alarm shows up in the log, but does not distract the operator, or require operator interaction to deal with it.


my 2 cents.

--
Greg Goodman
Chiron Consulting
[email protected] -- http://www.swbell.net/chironsw -- (713) 869-6876

 

---------- Forwarded message ----------
From: [email protected]
To: [email protected]
Subject: RE: HMI: Making the Browser SCADA Multilingual

As someone answered to the neraly same mail in linuxPLC mailing list, this won't work practically.

1. Translation isn't that easy really.
2. You will end up with a lot of phrases not translated, and what to do then? write the missing phrase in one fixed language - this
will give you a text that is half translated half untranslated
3. The browser will have to have all those texts stored, quite a lot of text if you want to cover a lot of phrases. This will not be implemented in all browsers in a near future. (for example the
browser in a PDA, where there isn't that much memory - yet).
4. What if the browser isn't new enough and don't have the latest phrases you used? Should it just show the number or some "phrase missing" text? Or nothing at all?

Nice idea, but I don't think it will work, in some future you might be able to do good machine translation and in those cases you can just write the page in your favorite language and have it translated on the fly in the clients browser (or in the server). If the browser is unable to translate some words you does at least have the original word to display.


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------