Rationalization of a Refinery Unit Alarm Database
Context
A new chemical recovery unit was in detailed design at an operating refinery. Its control and safeguarding scope covered the DCS, SIS and Fire & Gas systems together with package units for product solidification, truck loading, oxygen enrichment, burners and blowers. Before alarm settings froze into the control-system build, the owner and EPC contractor put every proposed alarm through structured rationalization.
Rationalization is mostly for keeping the console reasonable: Every alarm should be necessary, unique and actionable, carry a priority the operator can trust, and direct attention rather than compete for it. Applied at the design stage, it decides what the operators inherit on day one — before the first alarm has ever annunciated.
Approach
Every tag faced the same first question: Does an operator need to act on this signal? Only tags with a defined operator action qualified as alarms; the rest were classified as prompts, alerts, messages or no-signal items and kept off the alarm system. Each qualified alarm then moved through the following steps:
Prepare the review population
An Excel-based alarm master database was built from the project’s P & IDs, cause & effect diagrams, HAZOP and SIL reports, and the I/O and alarm & trip lists.
Read more
Preparatory correspondence addressed package alarm information and clarified what should enter the review.
Evaluate the alarm basis
The shared worksheet recorded purpose, initiating causes, verification and corrective actions, and the consequence of no action.
Read more
The team considered whether operator intervention was needed, from where — panel or field — and whether time was available.
Assign priority consistently
Consequence severity and response-time categories fed the facility priority matrix.
Read more
Typical alarms were assessed, with results extended to spare or similar equipment after considering differences.
Record the handover
Alarm and non-alarm databases, priority summaries and engineering recommendations captured the workshop outcome.
Read more
Same-equipment repeated records received different treatment from alarms transferred to spare equipment.
The report describes a method aligned with the rationalization principles of ANSI/ISA-18.2-2016 and references the facility criteria. Facilitation kept purpose, consequence, response and priority within one decision process; this is not evidence of full lifecycle compliance. Fire & Gas, SIS, diagnostic and function-block alarms took rule-based priorities from the project’s terms of reference — a convention that markedly enlarged the High-priority population, since Fire & Gas detection alarms carry High by default.
This review ran on Excel worksheets and plant-provided documents, and it held up because scope, data structure and facilitation were controlled. At larger scale, software adds rule-based checks, master alarm database integration, version control and continuous performance data collection. It strengthens traceability and lifecycle continuity — not the quality of an individual decision.
Key Design Decisions
Five principles shaped the register — together they determine what the operator will see when the unit starts up.
01 Alarm validity and start-up flooding risk
The issue: The database mixed demand-based signals that require an operator response with status indications, diagnostics and record-only events.
The principle: An alarm exists only where a defined operator action exists — the core test of ISA-18.2 and EEMUA 191.
The outcome: 607 tags validated; 2,229 did not. The alarm load at start-up — and the flooding risk that comes with it — is largely decided at this gate.
02 High priority share above the benchmarks
The issue: Priority needs an anchor, or it drifts toward preference.
The principle: Priority follows the severity of the unmitigated consequence and the time available to respond, read from the facility matrix.
The outcome: 563 alarms assigned as 70 High, 59 Medium and 434 Low. The High share reached 12.43 percent, above the roughly 5 percent that best practice regards as reasonable — driven by the number of Fire & Gas detection alarms and the facility policy of assigning them High. Only two process alarms earned High through the matrix.
03 One condition, one annunciation
The issue: Voted transmitters and spared equipment multiply tags without multiplying information.
The principle: Assess the typical alarm and extend the result to spare or similar equipment; same-equipment repeated tags carry no separate priority.
The outcome: 44 repeated tags recorded without individual priorities — duplicate annunciation addressed on paper before it could reach the console.
04 Rule-based classification for packages and specific systems
The issue: Fire & Gas, SIS, diagnostic and function-block alarms do not fit a cause-and-consequence interview, and case-by-case scoring invites inconsistency across packages.
The principle: Assign these through the default priority table in the project terms of reference, and disclose the effect.
The outcome: Consistent treatment across the unit and its packages, with the resulting rise in the High priority share stated openly in the report.
05 Traceability of decisions
The issue: Workshop conclusions lose their value when the reasoning behind them is not recorded.
The principle: Record purpose, causes, actions, consequence and response class for each alarm in one register.
The outcome: A 21-field database that feeds DCS and SIS configuration, document updates and any future audit — configuration itself assigned to the ICSS vendor under project change control.
Some striking outcomes from the study are set out below.
Recommendations
Tag-level actions live in the register. What follows is the lifecycle work that turns a good register into a good alarm system.
Configure through controlled change
See the details
Approved priorities go into the DCS and SIS through the ICSS vendor; P & IDs, cause & effect diagrams and the alarm & trip list are updated to match. Later deviations go back through Management of Change. Treat the issued register as the seed of the master alarm database — owned, version-controlled and reconciled against the DCS build.
Close the open items before the database freezes
See the details
Five alarms were flagged for review — candidates for deletion or signals serving mainly as compensation inputs. Resolve each with engineering evidence before configuration, and update the register.
Set deadbands, delays and filtering deliberately
See the details
The study records typical deadband values, with tuning deferred to commissioning by agreement. Set final values per measurement type against observed signal behaviour and record them — unset deadbands are where chattering alarms come from.
Baseline alarm performance after start-up
See the details
Collect alarm data over a defined operating period and benchmark rates, floods, standing and chattering alarms and priority distribution against EEMUA 191 and ISA-18.2 metrics. Rationalization set the intent; measurement shows whether operation honours it.
Hold future package alarms to the same evaluation
See the details
New or revised vendor and package alarms should pass the same qualification and prioritization criteria before acceptance. A rationalized database erodes fastest at the interfaces where alarms arrive pre-configured.
How DSIB Brings Value
During design and project delivery
The window for rationalization opens once HAZOP and SIL results and cause & effect logic are mature, and closes when the alarm database and DCS configuration freeze. Worked in that window, as here, it keeps unnecessary alarms out of the control system, surfaces missing technical information while it is cheap to supply, brings package alarms under one set of site criteria, and hands FAT, SAT and commissioning a traceable basis for every alarm. DSIB facilitates this scope for owners, operators and EPC contractors, checking its interfaces with HAZOP, LOPA and SIS decisions.
For operating plants
In an operating unit the trigger is visible on the console: Floods after upsets, standing alarms, chattering points, improper shelving, or an unrationalized alarm database surfacing during a DCS migration, revamp or audit. Independent facilitation separates what looks like a single problem into its parts: Configuration, instrumentation, documentation, operating practice or governance. Each is fixed by a different owner.
Indicators that suggest the plant needs a review
A rationalized database is the precondition for meaningful alarm KPIs. Many alarm-related indicators can be built on it, and plants running an alarm management programme — or an alarm champion campaign — track them continuously. The dashboard below is illustrative: Readings like these, set against the benchmarks of EEMUA 191 and ISA-18.2, are the console saying a review is due.
Rationalize the alarms before the operators inherit them.
Discuss an alarm rationalization, an alarm performance review or a project’s alarm management philosophy — for a unit in design, or a console that has been asking for attention.
Contact DSIB