Service Robots and Fire Alarm Integration: Evacuation Behaviour and Life-Safety Interface
At a glance: A service robot that keeps cleaning or delivering while the fire alarm sounds is not a neutral oversight, it is a life-safety fault. This guide defines the alarm interface a robot must accept, the evacuation behaviour it must perform, the lift and lobby coordination that codes expect, and the acceptance test that proves the installation is safe before the first occupant relies on it.
Why the Fire Alarm Interface Is a Procurement Gate
Most service robot projects specify payload, runtime and coverage, and then discover the alarm interface at commissioning, when it is expensive to add. The building's life-safety system does not know the robot exists. If a fire alarm activates and the robot continues its route, it becomes an autonomous obstruction inside a building that people are trying to leave, and it may drive toward the origin of the alarm rather than away from it. In a procurement review this is not a minor gap: an unmanaged robot is an uncontrolled occupant, and building owners increasingly refuse to sign off on a fleet that has no defined emergency mode. The interface has to be designed at the same time as the fleet plan, for the same reason a lift is not installed without a fire recall function.
The complication is that the robot's own safety stack is built for normal traffic, not for emergencies. Its obstacle avoidance will happily navigate around people and keep working; that is exactly what you do not want during an evacuation. The alarm interface overrides the mission layer entirely, and it must do so deterministically rather than by inference. This is the same principle behind incident response and escalation, extended from an operational fault to a building-wide emergency.
What the Robot Must Do When the Alarm Sounds
The behaviour specification is short and non-negotiable. Everything below must be testable, and each line should appear in the acceptance test as a pass or fail.
| Trigger | Required robot action | Time budget |
|---|---|---|
| Fire alarm activates (any zone) | Abort current mission immediately, discard route plan, enter evacuation mode | < 2 s from signal |
| Evacuation mode active | Stop cleaning / delivery duty; stop all fluid, brush and vacuum outputs | < 3 s |
| Robot in a circulation route | Move to the nearest designated parking bay or refuge, clear of the exit path | < 60 s where feasible |
| Robot unable to reach a bay | Stop in place, hold position, engage hazard beacon, remain stationary | Immediate |
| Robot on a lift | Complete egress at the nearest floor, do not accept new calls, do not hold the car | One trip |
| Alarm clears | Remain parked until a human operator releases the fleet, never auto-resume | Manual release |
Two of those rows carry most of the risk. The first is movement toward a refuge: a robot that tries to travel during an evacuation can block a doorway or a stair approach, so the specification must define refuges that are genuinely out of the egress path, not merely convenient. The second is auto-resume. A fleet that restarts the moment the alarm clears will re-enter a building that may still be under investigation, and it removes the human judgement that a real event demands. Manual release is the only acceptable behaviour.
How to Wire the Interface: Three Options and Their Latency
There are three practical ways to connect the fire alarm system to the fleet, and they differ sharply in latency and reliability. Choosing the wrong one is the single most common cause of a failed commissioning.
| Interface | How it works | Typical latency | Reliability |
|---|---|---|---|
| Dry contact from alarm panel | Panel relay closes on alarm; robot or fleet gateway reads a hardwired input | Under 1 s | Highest, independent of network and software stack |
| Building API / BMS event | Alarm event published to the building system, forwarded to the fleet API | 1 to 10 s | High, but depends on network and integration health |
| Acoustic / beacon detection | Robot detects the sounder or visual beacon itself | 3 to 15 s | Lowest, ambient noise and occlusion cause misses |
A dry contact is the reference design and should be the default wherever the alarm panel can provide a spare relay. It does not depend on Wi-Fi, MQTT, a cloud service or a vendor's API staying up, and it fails safe: a broken wire can be arranged to read as alarm, so the fleet parks rather than continues. The API route is acceptable where the building already publishes alarm events reliably and the fleet can subscribe with a monitored heartbeat, but it must be treated as a convenience layer on top of the contact, not a replacement. Acoustic detection should only be a backstop, never the primary path, because a robot that cannot hear the sounder above its own brush motor will not evacuate. Network dependencies deserve the same scrutiny as any other fleet link, which is why the resilience patterns in robot Wi-Fi and network connectivity apply directly here.
Lifts, Lobbies and Multi-Floor Coordination
In a multi-floor building the interface is only half the problem; the lift is the other half. During a fire alarm, lifts are normally recalled to the ground floor and taken out of service for general use, and the robot must not fight that. The correct behaviour is for the fleet to surrender lift control the moment evacuation mode engages, complete any trip already in progress at the nearest landing, and accept no further calls until a human releases it. A robot that holds a lift car open on an upper floor does exactly what the fire recall function exists to prevent.
Lobby and ground-floor behaviour matters just as much, because that is where the egress flow is heaviest. Robots should target parking bays positioned away from primary exit routes, stair approaches and assembly points, and the fleet plan should count those bays as part of the circulation design rather than as an afterthought. The lift and vertical-transport planning covered in multi-floor robot deployment needs a life-safety chapter added to it: for every floor the fleet serves, name the refuge, name the egress path it must not block, and name the muster logic. If a floor has no compliant refuge, the fleet should not be scheduled onto it in the first place.
The Responsibility Matrix Nobody Writes Down
Fires, like most serious incidents, end in a dispute about who was responsible. The robot vendor, the integrator, the fire-safety contractor and the facilities team all touch the system, and if the alarm interface fails the dispute is immediate. Write the matrix into the contract before commissioning.
| Item | Owner |
|---|---|
| Spare relay on alarm panel | Fire alarm contractor, on integrator's request |
| Cabling to fleet gateway | Electrical / integrator |
| Evacuation-mode firmware logic | Robot vendor |
| Fleet release after alarm clear | Facilities / security, named role |
| Periodic interface test | Facilities, with vendor support |
| Documentation of refuge bays | Integrator, signed off by fire-safety contractor |
Two clauses deserve special attention. The periodic test clause should state a frequency and a method, because an interface that was proven at commissioning and never tested again is an assumption, not a control. The release clause should name a role, not a team, so that at 03:00 there is no ambiguity about who authorises the fleet to resume.
Acceptance Test: Proving the Interface Before Occupants Rely on It
The interface is proven by test, not by documentation. Run the following at commissioning and record each as pass or fail with a timestamp, in the same spirit as the wider charging-room fire safety checks that sit alongside it.
- Live alarm test, single zone. Trigger a genuine detector activation and confirm every robot in scope aborts within the stated time budget and reaches a refuge or holds position.
- Signal-loss test. Break the interface link deliberately and confirm the fleet fails safe, treating loss of signal as alarm rather than as normal operation.
- Lift-surrender test. Place a robot in a lift car, raise the alarm, and confirm the robot completes egress and the car is released.
- Refuge-clearance audit. Walk every named refuge with the fire-safety contractor and confirm it is out of the egress path in practice, not just on the plan.
- Release-procedure drill. Have the named release role execute the manual release and confirm the fleet does not auto-resume without it.
- Documentation check. The signed refuge schedule, the interface drawing and the test record all filed together, so the next test does not start from scratch.
A fleet that passes all six is one a building owner can defend. A fleet that passes only the first is a fleet that will be discovered during a real evacuation, which is the worst possible time.
The Takeaway
Treat the fire alarm interface as a design requirement, not a commissioning task. Specify a dry-contact path as the reference, define evacuation behaviour with time budgets and a manual release, coordinate lifts and refuges with the existing life-safety design, write down who owns each link in the chain, and prove the whole thing with a live test before the first occupant depends on it. The robot is an occupant of the building, and it should behave like one when the alarm sounds. Standards framing for the wider safety case is collected in service robot safety standards and compliance.
Tell us your building, alarm system and fleet size, and we will help you scope the interface and the evacuation-behaviour specification. Contact us.
Continue Reading
Get a Quote
Tell us about your space and workload, we reply within 24 hours.