Fire alarm cause and effect explained
What cause and effect programming is, how it works on addressable fire alarm panels, what the cause and effect matrix contains, and why it is one of the most important documents in a fire alarm installation.
Cause and effect is the programming logic that tells an addressable fire alarm panel what to do when a specific device activates. It is what transforms a panel from a simple alarm trigger into an intelligent building safety system — controlling door releases, ventilation, lifts, suppression systems, and phased evacuation sequences in response to precisely defined alarm conditions.
What Cause and Effect Means
In fire alarm terminology, cause refers to an input event — a detector activating, a call point being operated, a monitor module receiving a signal. Effect refers to the output response — sounders activating, a door being released, a signal being sent to the ARC, a ventilation system shutting down.
On a simple system, the cause and effect relationship is straightforward: any alarm causes all sounders to activate. On a complex building — a hospital, a multi-tenanted office block, a theatre — the relationships become much more nuanced. Different detectors may trigger different sounder groups. A fire in one zone may require partial evacuation in adjacent zones but not throughout the building. Suppression systems may activate only when multiple detectors in the protected space confirm an alarm simultaneously.
All of these relationships are defined by the cause and effect programme stored in the panel.
The cause and effect matrix
The Cause and Effect Matrix
The cause and effect matrix is a table that defines every input-output relationship programmed into the panel. It is typically presented as a grid with inputs (devices, zones, or groups) on one axis and outputs (sounder groups, relay outputs, panel functions) on the other. Each cell in the grid indicates whether that input activates that output, and under what conditions.
| Input | Sounder Group A (Ground floor) | Sounder Group B (First floor) | Door release — stairwell | ARC signal | Suppression release |
|---|---|---|---|---|---|
| Zone 1 — Ground floor office | ✓ Alarm | ✓ Alert tone | ✓ | ✓ | — |
| Zone 2 — Server room | ✓ Alarm | ✓ Alarm | ✓ | ✓ | ✓ (2nd detector) |
| Zone 3 — First floor | ✓ Alert tone | ✓ Alarm | ✓ | ✓ | — |
Simplified example matrix — real installations are considerably more complex.
Common cause and effect scenarios
Typical Cause and Effect Configurations
Coincidence detection
Two detectors in the same zone or group must both activate before the alarm sounds. Used in areas prone to false alarms — reduces unwanted activations at the cost of slightly slower response to a confirmed fire.
Phased evacuation
An alert tone sounds in adjacent areas while an evacuation tone sounds in the alarm zone — used in high-rise buildings and hospitals where simultaneous full evacuation is impractical. The programme escalates if the alarm is not resolved.
Suppression pre-discharge
A first detector in a suppression-protected area activates an alert but does not release the system. A second detector confirming the alarm triggers a countdown, closes the protected space, and releases the suppression agent.
Ancillary control
Specific alarm zones trigger specific ancillary outputs — a fire in the kitchen triggers ventilation shutdown; a fire anywhere triggers lift recall and door release. Each relationship is explicitly defined in the matrix.
Documentation and review
Why the Matrix Must Be Documented and Maintained
The cause and effect matrix is not an internal document that exists only in the panel’s memory — it is a formal design document that must be produced, reviewed, and approved as part of the design process, and handed over to the building owner as part of the commissioning documentation.
The matrix must reflect the current configuration of the panel at all times. Changes to building layout, occupancy, or the addition of new devices or ancillary systems require the matrix to be reviewed and updated. A matrix that does not match the panel’s programmed configuration — because modifications have been made without updating the document — means the building owner has no accurate record of how their system will respond to an alarm.
During commissioning, every relationship in the matrix must be verified by functional test. A cause and effect matrix that has not been verified is not a commissioning record — it is a design intention that may or may not have been correctly implemented.
Common questions
Frequently Asked Questions
On a simple conventional system where any alarm activates all sounders and there are no ancillary outputs, the cause and effect relationship is implicit — there is little value in a formal matrix. For any addressable system, however, or any system with ancillary outputs, a matrix is essential. As soon as the system has programmed relationships beyond “everything alarms everything”, those relationships need to be documented, verified, and maintained.
The fire alarm system designer produces the matrix as part of the design documentation. For complex buildings — hospitals, high-rise residential, or premises with suppression systems — the matrix should be reviewed and approved by the fire risk assessor, the building owner or their representative, and potentially the fire service where staged evacuation procedures are involved. Changes to the matrix after commissioning should follow the same review process. The building owner should not simply accept a revised matrix from a contractor without understanding and approving the changes.