The master alarm database is the permanent record that captures the reasoning behind every alarm in a plant - not just its setpoint, but why it exists, what happens if it is ignored, and exactly what the operator is supposed to do about it. Often called the documentation and rationalization database, or D&R, it is the artifact that rationalization produces and the reference the whole alarm system is maintained against. This page explains what the master alarm database holds, why it is the authoritative record, and how it complements the rationalization process that fills it.
Master Alarm Database in one line: A master alarm database, also called the documentation and rationalization (D&R) database, is the authoritative living record of every alarm in a facility, storing each alarm's setpoint, priority, cause, consequence of inaction, and required operator response, along with supporting attributes. It is the output of alarm rationalization and the reference that configuration, maintenance, and audit all check against, ensuring that what is configured in the control system matches the justification recorded for each alarm.
For each alarm, the master alarm database captures far more than the trip point. It records the setpoint and the priority, but crucially it also documents the cause - the condition that makes the value reach the setpoint - the consequence that follows if the operator does not respond in time, and the specific corrective action the operator is expected to take. It captures the time available to respond, which together with consequence severity justifies the assigned priority, and often the basis or reference that the alarm traces back to, such as a hazard study or a design requirement. Additional attributes typically include the alarm type, any deadband and delay settings, and whether suppression rules apply.
What makes this collection valuable is that it records the reasoning, not just the configuration. A control system holds the setpoint and priority as raw numbers, but it does not explain why the setpoint is where it is or what the operator should do when the alarm fires. The master alarm database is where that human-facing justification lives, which is what allows anyone - a new engineer, an auditor, an operator on a night shift - to understand any alarm without having to reconstruct the original thinking. Because it is meant to stay current as the plant changes, it is described as a living record: when an alarm is added, retuned, or retired, its entry is updated so the database always reflects the alarm system as it actually is.
Rationalization and the master alarm database are two sides of the same coin: rationalization is the activity, and the database is the artifact it produces. During rationalization, a team works through candidate alarms and, for each one, decides whether it is justified and determines its setpoint, priority, cause, consequence, and required action - and every one of those decisions is written into the master alarm database as it is made. The database is therefore the durable result of the rationalization effort, the place where all that analysis is preserved rather than lost once the workshop ends.
Keeping the two distinct clarifies what the database is for after rationalization is over. The rationalization activity happens in bursts - an initial project and then reviews when something changes - but the database is consulted continuously in between. It is the source of truth that control-system configuration is checked against, so that the setpoint running in the PLC or DCS matches the setpoint that was justified. It is what an operator can reference to see the intended response to an alarm they are unsure about. And it is what an audit compares reality against, verifying that the live alarm system still matches the documented, rationalized design. In that sense, rationalization gives the database its content, and the database gives rationalization its lasting value.
In a SCADA or cloud monitoring context, the master alarm database is what keeps the actual configuration honest as the system grows. Every alarm that appears on a dashboard corresponds to a setpoint and priority somewhere in the platform, and the database is the reference those live settings are supposed to match. When a new site or skid is brought online, its alarms ideally come from the database's justified entries rather than being invented at the console, so the deployed alarm set stays consistent with the documented design instead of accumulating unreviewed additions.
For a platform such as Merobix, which spans many remote oil and gas sites, the operator-action field in the database is especially practical, because the person responding may be watching from a distance and may not know the specific site well. Having the intended response recorded - what the alarm means, what to check, and what to do - turns the alarm from a bare notification into actionable guidance, which matters most for the person who is not standing at the equipment. Tying that recorded action to the live alarm is how remote monitoring stays effective rather than just alerting.
The database also underpins management of change across a distributed deployment. Because it is easy to adjust an alarm from a cloud interface, an undocumented change can quietly desync the live system from its justified design. Treating the master alarm database as the record that every change must update - so a retuned setpoint or a new alarm is reflected there - is what prevents the fleet-wide configuration from drifting away from the reasoning that was supposed to govern it.
For each alarm it stores the setpoint, priority, cause, consequence of inaction, and the required operator response, along with the time available to respond and supporting attributes such as alarm type, deadband, delays, and any suppression rules. Crucially it records the reasoning behind each alarm, not just its raw configuration. It is meant to stay current as a living record whenever alarms are added, retuned, or retired.
Rationalization is the activity of deciding whether each alarm is justified and determining its attributes, while the documentation and rationalization (D&R) database is the artifact that stores the results of those decisions. Rationalization happens in bursts, but the database is consulted continuously afterward as the source of truth for configuration, operator reference, and audit. In short, rationalization produces the content and the database preserves it.
Because it is meant to be kept current with the plant, not frozen after the initial rationalization. Whenever an alarm is added, its setpoint changed, or the alarm retired, the corresponding entry is updated so the database always reflects the alarm system as it actually is. If it falls out of date, it stops being a trustworthy reference for configuration checks and audits.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.