Integration with building automation and mass notification

Eastview's facilities department wants the fire alarm system's status on the building automation system's screens, and its emergency management team wants the mass notification system to use the fire alarm's speakers. Ravi chairs the meeting with the controls contractor, the security manager and Tomasz from IT. 'Everyone wants a piece of the fire alarm,' he says afterwards. 'Our job is to give them what helps, and make sure none of it can stop the fire alarm doing its job.' This lesson covers sharing information with building automation and other systems, how mass notification and fire alarm signals share equipment, and the rules that keep life safety functions protected.

What integration is for

Integrating the fire alarm with other systems can help in several ways:

• Facilities staff see alarms, troubles and supervisory signals on the screens they already watch, with floor plans and equipment details.
• The building automation system can respond to fire alarm events in ways that are useful but not required, such as switching lighting or recording conditions.
• Security staff see door states, camera views near an alarm and the fire alarm's events together.
• Emergency managers can use the fire alarm's speakers and visible signals for other emergencies, such as severe weather or a security threat.

Each of those is a convenience or a separate emergency function. None of them may make the fire alarm's own functions depend on another system, and none may let another system interfere with the fire alarm.

Gateways and protocols

Fire alarm systems share information through gateways, which translate the fire alarm's internal events into the protocols other systems use. In buildings, the common protocols are BACnet and Modbus. A fire alarm point, such as a detector or a zone, is mapped to an object in the other protocol, and its state, alarm, trouble, supervisory or normal, is sent whenever it changes.

The safest gateway is one-way: it sends information out and accepts nothing in. Some gateways accept specific commands, such as acknowledge or silence from a workstation, and these must be listed for that purpose and controlled like any other operating point. A gateway that lets a building automation operator reset the fire alarm from an office would bypass every control on who may operate the system, which is why it isn't allowed without the listing and the owner's and authority's acceptance.

# Map fire alarm points to building automation objects (one-way, illustrative)
points = [("N-L1-014", "smoke north wing level 1 corridor", "alarm"),
          ("N-L2-031", "duct AHU-N2", "supervisory"),
          ("N-PS-01", "RPS-3 battery", "trouble"),
          ("N-L3-007", "pull station level 3 stair B", "normal")]
for k, (addr, desc, state) in enumerate(points, start=101):
    print(f"binary value {k}: {addr:9s} {desc:34s} state={state}")
print("gateway mode: send only; commands from the automation side are refused")

binary value 101: N-L1-014  smoke north wing level 1 corridor  state=alarm
binary value 102: N-L2-031  duct AHU-N2                        state=supervisory
binary value 103: N-PS-01   RPS-3 battery                      state=trouble
binary value 104: N-L3-007  pull station level 3 stair B       state=normal
gateway mode: send only; commands from the automation side are refused

What building automation may and may not do

Building automation systems run fans, pumps, lights and much more, and they are designed for comfort and efficiency, not life safety. They can take part in fire responses, but the rules are strict:

• A life safety function required by the code, such as fan shutdown on smoke or smoke control, is either controlled directly by the fire alarm system or done through a building automation system listed for that service, with its wiring and programming under the same controls.
• Where a fire alarm relay feeds an automation controller that then stops a fan, the whole path is part of the fire alarm function and is tested as one, and the automation programming for that function is documented and protected from change.
• Information sent to the automation system for convenience, such as displaying alarms, is not relied on for any required function.

At Eastview, the facilities team's request is met with a one-way BACnet gateway that sends every fire alarm point's state to the automation screens. Required fan shutdowns stay hard-wired from fire alarm relays at each air handler, as the last lesson described.

Mass notification and the fire alarm

Mass notification systems deliver messages about emergencies other than fire: severe weather, chemical releases, security threats or shelter-in-place instructions. In buildings with a voice evacuation fire alarm, the same speakers, amplifiers and visible signals can often be used, as Voice Evacuation and Mass Notification describes. When two systems share equipment, the question is which message has priority when both want it.

In Canada, mass notification equipment is covered by CAN/ULC-S576, and the priority between mass notification and fire alarm messages is set by the building's design and emergency plan, accepted by the authority. A fire alarm message normally keeps priority unless the plan deliberately gives a particular mass notification message precedence.

# Message priority when systems share speakers (illustrative plan)
priority = ["live voice from fire command", "security threat: shelter in place", "fire evacuation",
            "severe weather: move to shelter areas", "test and general paging"]
def play(requests):
    return min(requests, key=priority.index)
for req in [("fire evacuation", "test and general paging"),
            ("fire evacuation", "security threat: shelter in place"),
            ("severe weather: move to shelter areas", "fire evacuation")]:
    print(f"{' + '.join(req):55s} -> {play(req)}")

fire evacuation + test and general paging               -> fire evacuation
fire evacuation + security threat: shelter in place     -> security threat: shelter in place
severe weather: move to shelter areas + fire evacuation -> fire evacuation

The plan in the example lets a security threat message override fire evacuation and puts live voice from the fire command position above everything. That is the kind of decision the owner, the designer and the authority make together; the technician programs it and tests it.

Security, video and campus monitoring

Security systems often receive fire alarm events so that officers can see camera views near an alarm, check doors and guide responders. The same rules apply: information flows out to the security system, and no security function may stop the fire alarm. Large campuses like Eastview may run their own monitoring station in a security office, receiving all fire alarm events from the network and forwarding fire alarms to the fire department as the authority and the standard require. That station is part of the monitoring arrangement and must meet the requirements for it, including trained, staffed operation at all times.

Supervision of integrations

Even a one-way gateway can fail, and when it does, the people relying on the automation screens stop seeing alarms. Gateways and interfaces should be supervised so that their failure is reported, at least on the receiving system and preferably as a trouble at the fire alarm where the gateway is listed to do so. Interfaces that carry required functions, such as the connection between the fire alarm and a shared mass notification system, must be supervised by the fire alarm system.

# Is the gateway still talking? (heartbeat age check on the automation side, illustrative)
heartbeat_limit_s = 120
last_seen = {"fire alarm gateway": 35, "mass notification interface": 410, "security event feed": 15}
for link, age in last_seen.items():
    print(f"{link:28s} last heard {age:4d} s ago  {'ok' if age <= heartbeat_limit_s else 'LINK LOST - report and investigate'}")

fire alarm gateway           last heard   35 s ago  ok
mass notification interface  last heard  410 s ago  LINK LOST - report and investigate
security event feed          last heard   15 s ago  ok

Documenting and testing integrations

Every integration is documented: the gateway or interface, its listing, its direction, the points it carries, the protocol settings, and who owns each side. Tests confirm that each mapped point arrives correctly on the other system, that commands are refused where the gateway is one-way, that disconnecting the gateway causes the expected trouble and affects no fire alarm function, and, for shared mass notification, that the priorities work as the plan says. After any change on either side, the affected points are tested again.

Graphic workstations and annunciation

Large buildings often have a graphic workstation that shows fire alarm events on floor plans, with the device's location, description and instructions. It is a powerful tool for security staff and firefighters, but it has rules of its own. Where a workstation is used as a required annunciator or as a place where trained staff operate the system, it must be listed for that purpose and supplied from power that lasts as long as the fire alarm's. Where it is only a convenience, the required annunciator at the fire department entrance remains the primary display, and the workstation's failure must not affect it. The floor plans must be kept current: a graphic that shows a detector in a room that was demolished two renovations ago misleads the people who rely on it.

# Check that each device on the graphic floor plan is still in the panel's program (illustrative)
graphic = {"N-L2-014", "N-L2-015", "N-L2-016", "N-L2-019", "N-L2-022"}
panel = {"N-L2-014", "N-L2-015", "N-L2-016", "N-L2-018", "N-L2-019"}
print("on graphic but not in panel:", sorted(graphic - panel))
print("in panel but missing from graphic:", sorted(panel - graphic))

on graphic but not in panel: ['N-L2-022']
in panel but missing from graphic: ['N-L2-018']

Data, records and analysis

Integrated systems produce useful data: which detectors cause unwanted alarms, how often troubles occur and on which circuits, how long supervisory conditions last before someone fixes them. Owners like Eastview increasingly want that data in their maintenance systems. Sharing it is fine when it flows out through the same controlled gateways and doesn't open a path back into the fire alarm. For Bramwell, the data helps target maintenance: the detectors with the most unwanted alarms are cleaned or replaced first, and circuits with repeated ground faults are inspected for damage.

The rule for all integration is the same one that runs through this course. The fire alarm system detects, warns, controls its required functions and reports, on its own, whatever happens to the systems around it. Other systems are welcome to watch and to receive information. They are not allowed to stand between the fire alarm and its job.

Who owns each side

Integration projects involve several companies, and confusion about ownership causes many faults. Bramwell's integration documents include a simple table for each connection: which system sends, which receives, who installed and maintains each end, what is carried, and who must be told about changes. When the controls contractor updates the building automation software, the table tells them that the fire alarm gateway's points must be checked afterwards; when Bramwell changes the fire alarm program, it tells Sasha to send the new point list to the controls contractor and the security manager. A connection that nobody owns is the one that breaks without anyone noticing.

At Eastview, the table has eleven rows: the BAS gateway, the mass notification interface, the security event feed, the monitoring communicator, the elevator interfaces for three groups, the smoke control panel, the kitchen hood monitoring and two special hazard releasing panels. Each row has a named contact on both sides.