Cause-and-effect matrices: how fire alarm drives HVAC, access and lifts

A fire alarm system does two things. It detects and announces a fire, and it tells other systems what to do about it. The first part is what most people picture: detectors, a panel, sounders or voice messages. The second part is where buildings are protected or fail, and it is governed by a document that rarely gets the attention it deserves: the cause-and-effect matrix.

The matrix is a table. Down one side are the causes the fire alarm system can report: a smoke detector in a given zone, a manual call point on a given floor, a sprinkler flow switch, an aspirating detector reaching its alert or fire threshold, a confirmed gas release. Across the top are the effects the system can command: shutting down air-handling units, starting smoke extract, closing dampers, releasing held-open doors, unlocking access-controlled doors on escape routes, recalling lifts, starting voice evacuation in specific zones, signalling the BMS and notifying Civil Defence. Each cell says whether that cause triggers that effect, and how: immediately, after a delay, or only on confirmation by a second device.

In the NFPA framework, NFPA 72 (the National Fire Alarm and Signaling Code) governs how emergency control functions are initiated and supervised. It describes the emergency control function interface, the point at which the fire alarm system commands another system: HVAC shutdown and smoke control, elevator recall, door unlocking and door-holder release. These interfaces must be documented and tested, and the fire alarm control unit remains in command: the fire alarm decides, the other systems obey. In the European framework, EN 54 is the standard family for fire detection and alarm systems; voice alarm equipment is specified against EN 54-16 and EN 54-24, which is why voice evacuation in the Gulf is commonly described as EN 54 voice. Saudi projects often draw on both, with the Civil Defence requirements of the Kingdom as the authority baseline and the consultant specification stating which applies where. The matrix is where all of them meet.

Consider a typical alarm in a multi-storey building. A smoke detector on level three goes into alarm and the panel confirms it. The matrix then fires a sequence: voice evacuation starts on level three and adjacent levels, with an alert message elsewhere for a phased evacuation; the air handlers serving level three shut down while stair pressurisation fans start; smoke dampers on the affected zone close; door holders on corridor fire doors release so the doors compartment the fire; access-controlled doors on the escape routes from that level unlock so nobody is trapped behind a card reader; lifts are recalled to the ground floor, or an alternate floor if the alarm is there, and taken out of service; and the BMS receives the alarm so operators see the same picture. Every one of those actions is a row-column intersection in the matrix.

The lifts illustrate why the matrix matters. Lift recall on fire alarm is not simply a switch: a detector in the lift lobby of the recall floor must trigger recall to the alternate floor instead, and detectors in the machine room or hoistway may need to signal shutdown rather than recall. Getting this wrong is a life-safety problem, and the only place a consultant can review the logic before it is programmed is the matrix.

Access control is the second case where the matrix earns its keep. Security teams want doors locked; life-safety teams want doors open. The reconciliation is written into the matrix: which doors unlock on a general alarm, which only on an alarm in their own zone, which stay locked because they are not on an escape route, and whether release is hard-wired from the fire panel or commanded over an integration. NFPA 72 requires the fire alarm system to release these doors regardless of the access-control system's state, which is why a hard-wired interface is common even when a software integration exists.

HVAC brings in the building management system. On some projects the fire panel commands the air handlers directly through relay outputs; on others the BMS applies the approved mechanical responses of the matrix once it receives the alarm, the approach used when the BMS runs on a platform such as Niagara with the fire system integrated. Either way, the matrix must state who acts, and the commissioning test must show that the effect occurred, not merely that the signal was sent.

That leads to documentation. A good matrix is produced during design, revised at shop-drawing stage to reflect the actual devices and zones, and then used as the test script during commissioning: each cell is exercised and the result recorded. The as-built matrix, with its test records, is what Civil Defence and the consultant review and what the facility team will consult years later when a system is modified. In NFPA 72 terms it is the record of completion and of inspection and testing; in practice it is the matrix, signed.

For anyone writing a specification, three points follow. State which framework governs which part of the system. Require the cause-and-effect matrix as a deliverable at design, shop-drawing and as-built stages, not as an afterthought at handover. And require that commissioning demonstrates every effect at the equipment, with the BMS, access and lift contractors present. The matrix is the one document that makes an integrated building behave as designed, and it is far cheaper to get right on paper than on site.