Fire alarm integration
Fire Alarm Integration with Building Automation
How fire alarm integration works: the fire panel stays the authority, while BAS monitors alarm, fault and status signals through contacts and supervised inputs.
The boundary: the fire panel remains the authority
A fire alarm system is a life-safety system. The fire panel detects, decides and operates the fire cause-and-effect; building automation does not replace it, override it or sit in its critical path. The integration described here is monitoring and, where the fire strategy allows, status exchange. The BAS receives alarm, fault, disablement and zone information so operators can respond with context. It may also receive a signal that a cause-and-effect has operated. It does not become the fire detection system, the evacuation system or the smoke-control system. That boundary should be written into the scope before any cable is pulled. It should also be explained to the people who will use the screen, because an operator who believes the BAS is the fire system may wait for it during an event. The scope should also state what happens during panel maintenance, when a zone is isolated and the BAS still shows a normal state.
- Fire detection and cause-and-effect stay with the fire panel
- BAS receives status; it does not command life-safety sequences
- The boundary is documented in scope and cause-and-effect
- No BAS component sits in the critical fire path
Interface methods: contacts, supervised inputs and protocols
The most common interface is a potential-free contact from the fire panel to a supervised input on the controller. The contact is volt-free, the input is supervised for open and short circuit, and the mapping is documented point by point. The interface is one-way for monitoring; the BAS does not command the fire panel. Serial or network interfaces, such as Modbus or BACnet, are used only where the panel manufacturer supports them, the protocol exposes the required states, and the project's fire consultant accepts the arrangement. A protocol link does not remove the need for a hard-wired signal for critical states. Where both exist, the hard-wired signal is the one that survives a network fault, a firmware change or a misconfigured gateway. The two should be compared during testing, not assumed to agree. Cable screens, segregation from power and consistent terminal numbering are part of the interface, not decoration.
- Potential-free contacts into supervised inputs
- Point-by-point mapping with terminal references
- Protocol links only where the panel supports them
- Hard-wired signals retained for critical states
What the BAS may monitor and display
Typical monitored states are fire alarm, fault, disablement, test mode, power supply fault and zone or device alarm. The platform can present these on a floor plan, route them to the right operator, cross-reference CCTV and record acknowledgement. It can also show which HVAC or access events followed, so the operator can confirm that the cause-and-effect ran. Display is not control. Any action that affects smoke movement, door release, lift homing or evacuation must be defined by the fire strategy and implemented by the fire system or by dedicated hard-wired circuits, not by a BAS sequence. The screen should say plainly when a state is unknown, rather than showing a stale green indicator. An operator needs to distinguish between normal, alarm, fault and no data at a glance; four states, four treatments.
- Alarm, fault, disablement and test states on one view
- Alarm routing and acknowledgement recorded
- CCTV and access events cross-referenced
- No smoke-control or evacuation command from BAS
Alarm handling without adding delay
A fire alarm must never wait for the BAS. The panel owns the alarm; the platform receives a copy. Integration should be designed so that a BAS failure, a network outage or a controller reboot cannot delay the fire signal or mask a fault. On the operator side, fire events need their own priority, colour and acknowledgement rule, separate from comfort or energy alarms. Operators should be trained on what the screen can and cannot tell them, and the escalation path should be tested. If the BAS is offline, the fire system must remain fully functional and the operator must know that monitoring is unavailable. A silent watchdog is not enough; the loss of monitoring should itself raise a visible status. Alarm suppression during maintenance must expire automatically and be logged with a name and a reason.
- Fire events carry a dedicated priority and colour
- BAS failure cannot delay panel alarm or cause-and-effect
- Escalation path tested with operators
- Offline monitoring status is visible
Interlocks, cause-and-effect and the building response
Interlocks are where integration projects become confused. The fire strategy defines what the building must do: stop air handling units, close dampers, release doors, home lifts, start smoke fans. Those actions belong to the fire system and its dedicated circuits. The BAS may provide non-safety services that support the response, such as switching lighting to a safe scene or unlocking a lobby turnstile where the strategy permits, but it must not be the sole actuator for a life-safety function. The cause-and-effect matrix should state, for each action, which system executes it, which system monitors it and what evidence proves it operated. Where the BAS is asked to do more, the request should go back to the fire consultant for a written decision, not be absorbed silently into the sequence. Ambiguity here is discovered at the worst possible moment.
- Fire strategy defines every safety action
- BAS supports but does not execute life-safety functions
- Cause-and-effect names the executing system
- Scope changes go back to the fire consultant
Testing, documentation and handover
Every interface point belongs in a cause-and-effect matrix and a point schedule. Factory acceptance testing should simulate each monitored state and confirm the expected display, alarm routing and logging. Site acceptance testing repeats the checks with the fire panel and the responsible fire authority present where required. Handover documentation should include the contact map, terminal references, protocol settings, alarm texts, test records and the agreed maintenance procedure. Any change to the fire panel configuration or the BAS point mapping should trigger a review of both documents. The record is part of the safety case, not an optional attachment. Test results should be dated, signed and stored where the building team can find them, and a re-test should be scheduled after any panel firmware change. Where a witness test is required, the test script should be issued before the visit so that the sequence is followed in the same order every time.
- Cause-and-effect matrix covers every interface point
- FAT simulates each monitored state
- SAT repeats checks with the fire panel
- Contact map, test records and maintenance procedure handed over
Multi-panel, legacy and phased estates
Many buildings have more than one fire panel, panels from different generations, or a phased refurbishment that leaves part of the building on the old system. Each panel needs its own mapping, point schedule and test record; interface capability differs by brand, model and firmware. A legacy panel with no data port can still provide fire, fault and disablement through volt-free contacts, which is usually enough for monitoring. A phased project should define which panel is authoritative in each zone and how alarms are correlated across the boundary. Time synchronisation across panels matters for event reconstruction. The integration should be documented panel by panel, so that a future extension does not assume a uniformity that does not exist. A single screen can show several panels, but only if the underlying point names and alarm texts are consistent. An estate-wide naming convention is cheaper to impose at the start than to reconcile after several panels have been integrated separately.
- Each panel mapped, named and tested separately
- Legacy panels monitored through volt-free contacts
- Zone authority and alarm correlation defined
- Time synchronisation checked across panels
Fire alarm interface signals
14 rows| Signal | Direction | Typical interface | BAS use and limit | Verification |
|---|---|---|---|---|
| Fire alarm by zone | Panel to BAS | Potential-free contact, supervised input | Display, route and log; no control action | Simulate each zone and confirm the screen |
| Fire panel fault | Panel to BAS | Potential-free contact | Maintenance alarm; must not mask a fire alarm | Open the fault circuit and confirm priority |
| Disablement | Panel to BAS | Contact or supported protocol | Operator context; confirm with the panel log | Disable a device and compare both records |
| Test mode | Panel to BAS | Contact or supported protocol | Suppress routine alarms without hiding the state | Enter test mode and confirm the banner |
| Power supply fault | Panel to BAS | Potential-free contact | Maintenance alarm; the panel remains primary | Remove the supply and confirm the alarm |
| Cause-and-effect operated | Panel to BAS | Contact or protocol status | Confirm the sequence ran; not a field verification | Trigger the matrix and check each feedback |
| Device-level status | Panel to BAS | Modbus or BACnet where supported | Diagnostics; vendor and consultant approval required | Compare sampled devices against panel data |
| Event log export | Panel to BAS | Protocol or file export | Trend and audit; time synchronisation required | Match timestamps across both logs |
| Smoke control status | Panel to BAS | Contact or protocol status | Display only; smoke control keeps its own authority | Confirm status matches the smoke panel |
| Lift homing status | Panel to BAS | Contact or protocol status | Situational awareness; no lift command | Trigger homing and confirm the feedback |
| Door release status | Panel to BAS | Contact or protocol status | Display and log; release remains with access or fire | Release a door under test and check the log |
| Suppression status | Suppression panel to BAS | Contact | Awareness only; suppression stays independent | Verify signal with the suppression vendor |
| Time synchronisation | Panel and BAS | Protocol or network time | Consistent event reconstruction | Compare clocks before and after a forced sync |
| Monitoring link health | BAS | Watchdog or heartbeat | Raise a visible status when monitoring is lost | Disconnect the link and confirm the alarm |
Project images
3 images
Frequently asked
01Does building automation replace the fire alarm panel?
No. The fire panel owns detection, alarm and cause-and-effect. The BAS monitors and displays selected states. It must not replace the panel or sit in the critical path of a life-safety response. Any proposal that puts BAS logic ahead of the panel should be rejected at design review, before it becomes a commissioning argument.
02Dry contact or protocol?
Critical states should be taken from potential-free contacts into supervised inputs. Protocol links suit richer status data where the panel supports them and the fire consultant accepts the arrangement, but they do not replace hard-wired signals. Use the protocol for diagnostics and the contact for the states that must survive a network fault.
03Can the BAS release doors or start smoke fans?
Only within the fire strategy, and only through the fire system or dedicated hard-wired circuits. The BAS may monitor and record the result; it should not be the actuator for smoke control or evacuation. Where a design asks for more, the request needs a written decision from the fire consultant, not an assumption by the integrator.
04What happens if the BAS is offline?
The fire system remains fully functional and alarms locally. What is lost is central monitoring, logging and remote notification. The operating procedure must cover that state and tell staff how to recognise it. A periodic test of the offline condition is worth more than a paragraph in the manual, because it proves the procedure is usable.
05Can one platform monitor several fire panels?
Yes, but each panel needs its own mapping, point schedule and test record. Interface capability differs by brand and model and should be confirmed panel by panel. A shared screen is only useful if the point names, zone labels and alarm texts follow one convention across every panel.
06Do we need the fire panel manufacturer's approval?
Protocol interfaces normally require coordination with the panel manufacturer, including authorisation, register or object documentation and firmware compatibility. The project's fire consultant should also confirm the arrangement. This is a contractual and technical dependency, so it belongs in the programme rather than being discovered during commissioning.
07How is the integration tested?
Point by point against the cause-and-effect matrix at FAT, then again on site with the fire panel and the responsible authority where required. Test records, alarm texts and terminal mappings are part of the handover. Every monitored state should be proved, including the loss of the link and the return to normal.
08Can a legacy panel with no data port be integrated?
Yes, through potential-free contacts for a limited set of states such as fire, fault and disablement. The information is narrower, but the boundary is clear and the maintenance simple. The limitation should be written into the scope so that nobody expects device-level diagnostics from a panel that cannot provide them.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.