How to Build a Master Alarm Database

Back to Blog

Define the Row Key and Identity Fields

Start with what makes each row unique. A single physical measurement can raise several alarms (high, high-high, deviation), so the key is the combination of tag plus alarm type, not the tag alone. Get this wrong and high and high-high on the same transmitter collide into one row and you lose the ability to rationalize them separately.

Add identity context around the key: the unit or area, the service description in plain language, and a stable alarm identifier that survives control-system reconfiguration. These are the fields an operator scans to find the right row under pressure, so they have to read in operator language, not just tag syntax.

Add the Configuration Fields

Capture the settings that actually live in the control system: the setpoint, the priority, the deadband, any on-delay or off-delay, and the enabled or suppressed state. This is the block the database compares against reality during an audit, so it must mirror the controller's real parameters, including units.

Treat these as the controlled configuration of the alarm. When a setpoint or priority changes, it changes here first through the change process, then in the controller, so the database never lags the plant. The related tuning fields such as deadband and delay are where you later stop a chattering alarm, so keep them explicit rather than buried in a notes column.

Add the Rationalized Knowledge Fields

The database earns its keep in the fields that rationalization fills. For each alarm record the probable cause, the consequence of taking no action, the corrective operator action, and the time available to act. These four are also the raw material of the alarm response procedure the operator sees at the console, so structure them cleanly enough to publish.

Store the priority justification, not just the priority. A priority with no visible link to its consequence and response-time inputs cannot be defended in an audit and gets re-argued every review. Keeping the justification turns priority from an opinion into a traceable decision.

Link Each Row to Its Sources

An authoritative record points back to its evidence. Link each alarm to the P and ID it appears on, the operating or emergency procedure it supports, and the rationalization session that set its values. These links are what let a reviewer trace an alarm from the console back to the drawing that justifies it.

Add lifecycle metadata: date rationalized, last reviewed, and the change record that last touched it. This is the spine that later lets you find stale records and feed a management-of-change workflow, and it is far cheaper to add now than to retrofit.

Verifying the Structure

Test the structure against the work it has to do. Can you produce a clean priority distribution from it. Can you export a per-alarm response sheet for the operator. Can you list every alarm not reviewed since a given date. If any of these needs a spreadsheet gymnastics, a field is missing or misplaced.

Reconcile a sample of rows against the live controller. Every configuration field in the database should match the plant exactly. A mismatch on day one means the export was stale or a field maps wrong, and both are far easier to fix before the database is declared the master.

Common Mistakes to Avoid

The classic error is one row per tag instead of one row per alarm, which quietly merges distinct alarms and defeats rationalization. Close behind is a free-text priority column with values like important and critical that do not map to the philosophy's discrete levels, so no distribution can be computed.

Two governance mistakes undermine the whole effort. Letting the controller be changed without updating the database makes the master a fiction within weeks. And storing priority without its justification means every audit re-litigates decisions the database was supposed to preserve.

Frequently Asked Questions