EEMUA 191 Alarm Management in Adroit |
Over 90% of all SCADA HMI installations have some kind of alarming configured but the vast majority suffer from a common set of problems:
Too many nuisance alarms
A large diamond mine customer of Adroit was known to have over 10 000 alarms configured. This is information overload for operators.
According to EEMUA 191 guidelines, an alarm is an event to which an operator must knowingly react, respond, and acknowledge – not simply
acknowledge and ignore. No plant should have more than 6 such alarm occurrences per hour, i.e. no more than one every ten minutes.
Quick Start Guide
Alarms simply ignored
Nuisance alarms are simply ignored by most users because they are considered inconsequential, as a result of too much information
|
Over the years, there have been numerous catastrophic accidents attributable to these kinds of problems:
- Sevesco, Italy, 1976
- Three Mile Island, 1979
- Chernobyl, 1983
- Union Carbide, India 1984
- Phillips 66, California, 1989
- Westray, Canada, 1992
- Texaco, Milford Haven, 1994
- Olympic Pipeline, Bellingham, 1999
- BP, Grangemouth, 2000
- BP, Texas City, 2005
At the heart of Adroit’s alarm management is a relational database containing both raw alarm data as well as inferred context data
|
|
By appropriately utilizing the generated information, alarm management improves process efficiencies as a result of:
- Enterprise-wide, centralised alarm and event collection into a single relational database
- Elimination of nuisance alarms through conditional alarming and post analysis repair
- Elimination of alarm printers because no-one looks at them anyway
- Fast and thorough incident reviews recording time parameters and application of reasons and custom notes
- Improving existing alarm configuration iteratively
- Identifying process bottlenecks and impact on operator workload and efficiencies
The methodology:
- Incidents are categorized to improve SQL queries based on equipment, process area, physical area, etc.
- Incident records include time of incident occurring, clearing, and being acknowledged
- Incident records can be enabled for alarm reasoning using pre-configured reasons, sub-reasons, and free-format comments
- Incident database is accessible to 3rd party MIS applications for custom reporting and analysis
- Allows for configuration, post-reasoning, and viewing of incidents in tabular or graphic form
Based on SQL Server Reporting Services (SSRS), reports are all web-based, meaning no front-end software is required. You can drill through from summary reports into more detailed reports at the click of a button. All reports are exportable to Excel, Word, PDF, etc., and are also schedulable. Report parameters and settings are defined on an individual user basis depending on their reporting requirements.
The alarm management report pack is therefore optimally structured to enable you to assess, analyse, and iteratively improve your alarm configuration as described above.
The following images show screenshots of some reports from the alarm management pack:
New Click to view Alarm Management reports hosted as an ASP.NET Core web application. These reports display some key metrics on live alarms from the Quick Start training configuration running on our web server