Citect calls for alarm management
01 February 2008
Too many alarms can make safety and productivity systems less functional and are liable to ‘overwhelm operators’. Paul Hurst of Citect UK discusses why and suggests a solution.
Too many alarms
The facility for multiple alarms to overwhelm the capacity of plant operators to assimilate and act upon them has been demonstrated in numerous disasters; from Three Mile Island in 1978, to the 2005 explosion at the third-largest oil refinery in the United States, the BP Texas City Refinery, which left 15 people killed and 180 injured.
What is obvious from all of these disasters is that, despite their obvious significance, alarms have become ‘too much of a good thing’; making less functional what was once an effective safety and productivity improvement system. This problem arose when control systems became mainstream; bringing down the cost, and thereby increasing the proliferation of alarms. With this surfeit came reduced visibility of urgent and underlying problems; increased clutter that operators had to deal with; and longer response times to undertaking appropriate corrective action.
Typically, with thousands of alarms per site, a ‘stock take’ of the existing process, alarms and trends is critical before any changes are implemented. But while engineers and designers appreciate the benefits of such an exercise, the task – by virtue of its scale – can be quite daunting.
This is where certain plant Historians (central data repositories that gather, historise, archive and distribute plant data) can simplify the task. For example, CitectSCADA Reports, the plant-wide reporting solution from Citect, is capable of accurately recording all alarm data and tag values at 100,000 changes per second. Such a tool can help engineers and operators gather and organize alarm data from across the entire site. If gathering data from thousands of alarms appears daunting, then analysing such data to derive useful insight can be even more formidable an undertaking.
Some plant Historians provide assistance with this by helping engineers and operators with event analysis, pulling up all alarms that occurred at a given point in time. Further more they can archive alarms and events, analyse alarms and identify nuisance alarms.
The fruits of such an analysis can help plant engineers to cut through the clutter of multiple alarms. According to EEMUA 191, 150 alarms per day (one every ten minutes) presented to an operator is “very likely to be acceptable”; and 300 alarms per day (an alarm every 5 minutes) is considered “manageable”. However, in reality, it is not unusual to record tens of thousands of alarms per operator per day, which makes such a system self-defeating. Identifying nuisance alarms helps to eliminate unnecessary or ineffective alarms, thus bringing the number of alarms per operator to a more manageable ratio.
To do this, clear justification for each alarm is required. An alarm's reason for being should be related to a specific problem or abnormal situation and also to a specific and defined operator response. If there is no problem, or if the alarm is not intended to elicit specific operator action, then its legitimacy should be questioned. A process indicator or alert does not automatically equate to an alarm.
The key with any system of alarms is identifying root or consequential alarms. This helps to ensure that in an alarm flood, prioritisation models have been configured such that the consequential alarm does not get lost or remain unnoticed.
For consequential alarm and event analysis, most historians would compare one set of alarm data with another set of alarm data (depending on the query placed). However, what is even more useful is to be able to compare alarm data with plant/process trend data.
This is significant because alarms – being reactive in function – cannot anticipate by themselves any process drift towards an abnormality which could eventually lead to breakdown or process failure. Co-relating alarm data with trend information can help throw up such insight. It can also help in fine-tuning alarm settings and in linking alarm spikes to specific process conditions (startups, shutdowns, change in process set points such as tank levels, pressure, temperature levels etc), changes in instrumentation or new or changed control system configurations. In addition, it is by analysing operator response to alarms (and not simply focusing only on alarm data) that poor alarm system design is identified.
CitectSCADA Reports offers such an option; since it historises both alarms and plant process trends. In this way, alarm and event data can be co-related to trend data from the plant to throw up anomalies or areas for alarm rationalisation, or even assist in incident reviews.
Tools such as CitectSCADA Reports, that can help to effectively share alarm analytics, and the resulting insights that these bring in a simple, relevant, meaningful and easy-to-understand format, help to ensure that alarm management is fed back the multi-level and multi-disciplinary input it requires to validate it and keep it relevant to the business objectives and the alarm philosophy of the organisation. Moreover, tools that can take alarm KPIs and benchmark them against industry best practice, could take alarm management to the next level and provide the organisation alarm report cards that can directly result in improved productivity, profitability and safety.
Contact Details and Archive...
Most Viewed Articles...