How can building alarms automatically generate maintenance work orders?

The quickest way to bury a maintenance team is to connect every building alarm straight to the maintenance system. Done properly, though, automatic work orders are one of the more useful integrations a building can have. An interface between the building management system (BMS) and the computerised maintenance management system (CMMS) takes a qualifying alarm, identifies the asset it belongs to, checks whether a work order already exists for that problem, and either creates one with the right priority or updates the one that is open.

The connection itself is usually the easy part. What decides whether it helps or floods the team is a set of rules: which alarms qualify, how duplicates and cascades are handled, and how a work order is closed. Those rules are best written down as an alarm-to-work-order policy before anyone configures the integration.

Hundreds of alarms, a handful of faults

Buildings can generate far more alarms than anyone acts on. Some are genuine faults. A good share can be nuisance alarms from badly set limits, sensors out of calibration, equipment in maintenance mode, or the knock-on effects of a single upstream failure. Pass all of them to the CMMS and that noise becomes hundreds of work orders. Engineers learn to ignore them, and the real faults disappear in the volume.

Process-industry control rooms faced the same problem. The ISA-18.2 standard on the management of alarm systems, and its technical reports, centre on a documented alarm philosophy and on rationalisation, meaning confirmation that each alarm is necessary, has a defined response and is correctly prioritised. ISA-18.2 is written for process industries, not buildings, but its central idea transfers well: an alarm that does not require a defined action by a defined person should not be an alarm, and should certainly not be a work order.

Deciding which alarms qualify

The policy starts by sorting alarms into three groups:

Each work-order alarm then needs a defined asset, a priority, a responsible trade or contractor and an expected response.

Every alarm needs an address

A work order is only useful if it lands against the correct asset in the CMMS, complete with its location, history and documents. That requires a mapping between the BMS point that raises the alarm and the CMMS asset identifier. On new projects the mapping should be specified in the information requirements, and consistent identifiers across BIM, COBie, BMS and CMMS make it much easier. On existing buildings, expect to build and check it by hand for the alarms in scope.

Rules for the situations that cause floods

Alarm floods come from a handful of predictable situations, and each needs an explicit rule:

• A persistence delay requires an alarm to last for an agreed time before it raises a work order, so momentary excursions do not create tasks.
• A chattering alarm, one that repeatedly sets and clears, should update a single work order and record each repetition there. Persistent chatter is itself a fault, to be investigated like any other.
• If a work order is already open for the same asset and condition, a new occurrence is added to that order; it never becomes a duplicate.
• When one failure triggers many downstream alarms, the symptoms should be linked to a single work order on the likely cause. That needs relationships between equipment, such as which pump serves which zones. A semantic model such as Brick, which describes building assets and the relationships between them, makes these cascade rules far easier to write and maintain.
• When an engineer is working on equipment, its alarms should be suppressed or tagged for a defined period, with the suppression logged and time-limited.

Priority and routing come next. Alarm priority should map to work-order priority and response time using the categories already in your maintenance contract, and work should be routed by trade, location and time of day, with escalation if nobody acknowledges it within the agreed time. Out-of-hours rules deserve particular care, because an automatically generated emergency call-out is expensive when the alarm did not justify it.

When is a fault actually fixed?

A work order should not close just because its alarm has cleared. Alarms clear for many reasons, including someone resetting them. A robust closure rule requires both that the alarm has returned to normal and stayed there for an agreed period, and that the engineer has recorded what was found and done. If the same alarm returns within a defined window, the work order reopens or a linked one is created, and the recurrence is reported.

Those results should feed back into the policy. Alarms that keep creating work orders closed as "no fault found" need their limits or logic reviewed, and that review is how the policy gets better over time.

Choosing where the logic sits

As long ago as 2010, the US Department of Energy's Operations and Maintenance Best Practices Guide noted that many CMMS products could interface with energy management and control systems, so the capability is rarely the obstacle. Common patterns are a direct interface from the BMS supervisory software to the CMMS, a middleware or integration platform that applies the rules, or an independent data layer that receives events from several systems and forwards the qualifying ones. For anything beyond a small building we generally prefer to keep the rules in one visible, documented place. Scattered between BMS logic and CMMS configuration, they become hard to audit.

Whichever pattern you choose, the specification should cover the message content, the asset identifier used, retry behaviour if the CMMS is unavailable, how duplicates are prevented and what the integration logs. Testing should use realistic scenarios: a single fault, a chattering alarm, a cascade, an alarm during maintenance mode and the CMMS going offline.