ISA-18.2 says an alarm needs four things. A BMS sends none of them.

It is 03:14 on a Sunday. A supply-air sensor on CRAH-07 crosses its limit, and within ninety seconds the building management system has raised fifty-one events across that unit, the chilled-water loop it shares, and four racks in the affected row. One engineer is on shift, looking at a list.

Alarm management is the discipline that decides which of those fifty-one deserve a human, in what order, and with what response. ANSI/ISA-18.2 is the standard that defines how to do it, and it requires that every alarm document four things: a cause, a consequence, a corrective action, and a time to respond. A BACnet event notification carries thirteen fields, and not one of them is any of those four. That gap is what a cooling plant inherits, and it is why fifty-one alarms arrive with no ranking attached.

• ISA-18.2 requires four attributes per alarm — cause, consequence, corrective action, time to respond.
• A BACnet notification defines thirteen fields, and none of them is one of the four.
• Alarm-to-work-order integrations transport and group alarms, but supply none of the four either.
• In a data hall the fourth attribute is physical: time to respond is thermal margin, and it changes minute to minute.

What is alarm rationalisation?

Alarm rationalisation is the stage of ISA-18.2 where every proposed alarm is reviewed by a group of people and either justified or removed. It is a documentation exercise, done once per alarm, away from the console. The output is a record for each surviving alarm that states why it exists, what happens if it is ignored, what the operator should do, and how long they have to do it.

Two things follow from that definition, and both matter more in a data hall than in the process plant the standard was written for. The first is that rationalisation is static: the record is written once and reviewed on a cycle, so it cannot know what else is already degraded tonight, or how much margin is left before load is at risk. The second is that most building management systems have never been rationalised at all, because the practice arrived through process control rather than through facilities.

The word is worth keeping straight from two neighbours. Rationalisation decides which alarms should exist. Alarm management is the whole lifecycle around them, from philosophy through monitoring and audit, and alarm correlation is a runtime activity that groups related alarms as they fire — which the standard does not require.

What does a BMS alarm actually carry?

A building management system reports an alarm as an event notification, and the most widely published definition of that notification is the BACnet standard, ANSI/ASHRAE 135. Its confirmed event notification is defined with thirteen fields.

• Who and where: a process identifier, the initiating device, and the event object, which is the point or object that changed.
• When: a timestamp.
• How loud: a notification class and a priority from 0 to 255, where a lower number means a higher priority.
• What kind: an event type such as out-of-range or change-of-state, and a notify type of alarm, event or acknowledgement.
• State: the state the object left, the state it entered, and optional event values such as the reading and the limit it crossed.
• Words: an optional message text, and a flag saying whether acknowledgement is required.

Every one of those is a fact about a point. None of them is a fact about the plant: which loop the point sits on, what is downstream, whether redundancy is intact, or how long the hall has before load is affected.

That is not a flaw in the protocol. A notification is designed to be small, unambiguous and fast, and a decision is none of those things.

What does ISA-18.2 say an alarm must have?

The alarm-management standard, ANSI/ISA-18.2-2016, defines an alarm as an audible or visible means of indicating to the operator an equipment malfunction, process deviation or abnormal condition requiring a timely response. The last three words are the test: if no timely operator response exists, the standard says it should not be an alarm.

The standard's rationalisation stage then documents, for each alarm, its cause, its consequence if nobody acts, the operator's corrective action and the time available to respond. Priority is set from a matrix of consequence severity against time to respond, and the results live in a master alarm database.

Cause

What condition produces the alarm, so the responder does not start from the symptom.

Consequence

What happens if nobody acts. The standard limits this to the direct consequence, not a chain of further failures.

Corrective action

The operator response that prevents or mitigates the consequence. Acknowledging the alarm or writing a log entry does not count.

Time to respond

The window before the consequence can no longer be prevented, estimated in ranges such as under five minutes or five to fifteen.

Priority

Derived from consequence severity and time to respond, in no more than three or four levels, with roughly five percent of alarms at the highest.

Notice where those attributes live. They sit in a database that exists only if rationalisation has been done, and not in the notification that leaves the BMS.

The standard also gives the cascade a name: more than ten alarms annunciating in ten minutes is an alarm flood, and its performance targets expect roughly one alarm per ten minutes per operator, not fifty. Naming it matters, because a defined condition can be designed against while a busy shift can only be endured.

ISA-18.2 was written for the process industries and says so in its title. Data-center practice has borrowed its vocabulary: one published critical-facilities scheme uses Critical, Major, Minor and Informational with immediate, fifteen-minute and one-hour response windows, and defines rationalisation as checking that each alarm needs operator action, has the right priority and setpoint, and has a documented response procedure.

The standard says every alarm needs a cause, a consequence, an action and a deadline. The integration moves the reading and assumes the other four.

What do alarm-to-work-order integrations do today?

The tools that connect a BMS to a CMMS are real and useful, and the consensus of their published descriptions is consistent. Most will map an alarm to a work-order template, set a priority and group duplicates inside a time window.

• Map each alarm type to a work-order template with a preset priority, assignment rule and asset link.
• Set priority from alarm severity, equipment criticality and time of day, and route by location, system and on-call rota.
• Group related alarms from one fault so that a cascade produces one work order rather than forty.
• Attach the asset's maintenance history, previous alarms and parts list, and measure response time from the alarm timestamp.
• In some products, hold the alarm for a person to confirm before it reaches the CMMS, or check telemetry before the work order is allowed to close.

Read those again with the standard's attributes in mind. Priority is inherited from the alarm or a template; cause, consequence and time to respond are either absent or were set once, statically, when the template was configured.

The template cannot know that N+1 in this hall was consumed last week, or that the failing unit feeds the row under a customer commitment. Someone still works that out, usually by phone, and the work order records their conclusion without recording their reasoning.

What fields does a decision record add?

A decision record is the ISA-18.2 attributes computed live for this incident, rather than looked up from a spreadsheet written last year. It also carries two the standard never asked for, because a process plant has one control room and a data center has several organisations with different permissions.

The middle column is the important one. If rationalisation has been done, the decision record starts from it; if it has not, the decision record is the first place those attributes exist.

Where the deadline comes from

In a data hall, time to respond is a physical quantity rather than an estimate. ASHRAE's thermal guidelines recommend an inlet dry-bulb of 18 to 27 °C for classes A1 to A4, allow 15 to 32 °C for class A1, and limit the rate of change to 20 °C per hour and no more than 5 °C in any fifteen minutes.

The margin on a decision record is the distance between the observed inlet trend and those lines, expressed as minutes. That number changes as the incident develops, which is why it cannot live in a template.

How to rationalise the alarms on a cooling plant

Rationalisation is a workshop, not a software purchase, and a first pass on one hall takes a competent facilities team about two days. The output is a spreadsheet, and that is fine — the value is in the argument the group has, not the tool that stores it.

Work in this order. Steps one to four are pure ISA-18.2; step five is the part the standard leaves open and a data hall has to answer for itself.

• Export every configured alarm from the BMS with its point, limit, priority and notification class. Expect more than you think — a mid-size hall routinely carries several thousand.
• Cut the ones that cannot be acted on. If no human response exists, it is an event for the historian, not an alarm. This alone typically removes a third of the list.
• For each survivor, write the four attributes in plain language: the cause, the consequence of ignoring it, the corrective action, and the time available to take it. If the group cannot agree the consequence, the alarm is not justified.
• Assign priority from consequence and time together, not from severity alone. ISA-18.2 expects three or four priorities and a deliberately skewed distribution — roughly 80% low, 15% medium, 5% high. A plant where everything is critical has no priorities at all.
• Mark which of the four attributes are static and which are not. In a cooling plant the time to respond is a live quantity, and writing a fixed number in the spreadsheet is the step that quietly makes the record wrong.

Measure the result against the standard's own rate targets rather than against how the room feels. ISA-18.2 gives an operator load of roughly one to two alarms per ten minutes as manageable, and names anything above ten in ten minutes an alarm flood — a distinct condition, not a busy night.

How does one incident read as a decision record?

At 03:14 the supply-air point on CRAH-07 in Hall B crosses 27 °C and holds. Within ninety seconds the BMS raises eleven alarms across the unit, the row sensors downstream and the hall return, each with a priority, a timestamp and a state change, which is an alarm flood by the standard's definition.

An integration would open one grouped work order with the asset history attached, at the priority the template holds for a CRAH high-temperature alarm. The decision record says more, and says it in a form a person can accept or overrule.

Observed

Eleven alarms in ninety seconds on CRAH-07 and the four rack rows it serves; row inlets downstream are climbing at about 0.2 °C per minute.

Inferred

Loss of cooling output from CRAH-07, with a probable chilled-water valve fault. Confidence: moderate, because the valve position point is not trusted.

Consequence

Rows B3 to B6 lose N+1 now and lose cover entirely if CRAH-08 degrades. Two of those rows carry a customer commitment.

Margin

About 24 minutes from the current 27.2 °C inlet to the class A1 allowable limit of 32 °C at the observed trend, and less if the trend steepens.

Response

Dispatch a CRAH-certified technician under the approved MOP for the chilled-water valve and notify the on-call lead. Outside the approved scope: any change to a setpoint.

Approval

Dispatch inside the approved scope proceeds. The on-call lead must approve before the unit is isolated.

Closes when

Supply air on CRAH-07 is back inside 18 to 27 °C and holds for the observation window, and the technician's finding agrees with the inference.

Every line the standard asks for is present and computed for this incident, and every line a person would need in order to disagree is visible. That is the difference between a record and a notification.

What this cannot do

The decision layer reads the plant; it does not drive it. It takes no control authority, cannot change a setpoint, and cannot dispatch anyone outside a scope a person approved in advance.

A human still performs the physical work and signs for anything safety-critical, and the technician's finding at the unit can overrule the inference. That disagreement is recorded, because it is the most useful thing the loop produces.

Answered