Lifts, Fire Doors and WiFi: What Decides Hospital and Hotel Robot Projects

Autonomous service robots rarely fail due to onboard navigation or sensor limitations; they fail because of unresolved physical and digital interfaces within existing building infrastructure. While modern mobile robot hardware is technically mature, commercial facilities like hospitals and hotels were historically designed exclusively for human occupants.

When transitioning from isolated single-room proofs of concept to autonomous multi-floor operations, robotic fleets encounter severe friction at three primary architectural choke points: elevators, fire doors, and wireless network boundaries. Solving these physical bottlenecks requires deep system-level coordination across mechanical, electrical, and digital domains rather than simply adding more sensors to the robot.

• Elevator interfaces: Real-time coordination of cabin dispatch, floor selection, door hold times, and spatial availability.
• Fire door compliance: Managing automated passage without breaching statutory fire compartmentation and self-closing mandates.
• Network infrastructure: Ensuring persistent data links and low-latency access point handovers across shielded shafts and transit corridors.

Addressing these three interfaces requires moving beyond hardware procurement toward holistic system integration. The following sections break down the specific mechanics, protocols, safety clearances, and operational responsibilities required to integrate autonomous mobile robots into enterprise facility workflows.

Autonomous multi-floor navigation requires continuous, bidirectional communication between the mobile robot and the vertical transport dispatch system. A service robot cannot simply wait in front of an elevator shaft like a human passenger; it must programmatically request a car, monitor arrival status, verify available floor space, and command extended door dwell times to ensure safe transit.

The operational sequence follows a strict transactional handshake to prevent deadlocks or safety incidents:

1. Call placement: The robot approaches the elevator lobby, triggers a call for its current floor, and requests a target destination via API or relay control.
2. Car assignment and monitoring: The dispatch controller allocates a specific car, transmitting real-time telemetry including car identifier, current position, travel direction, and arrival state.
3. Payload and space verification: Before boarding, the robot evaluates cabin load status and internal obstacle sensors to confirm sufficient capacity.
4. Door dwell extension and boarding: The robot commands the doors to remain open during entry, navigates into the car, turns to clear the threshold, and releases the door hold.
5. Transit and disembarkation: The elevator travels to the assigned floor, signals arrival, holds the doors open, and confirms complete exit before returning to standard passenger service.

Standard elevator door timers are calibrated for human walking speeds and for a passenger's ability to react to a closing door. Autonomous robots move at controlled, lower velocities across door thresholds to ensure safety, requiring dynamic door-hold overrides. Furthermore, if a cabin arrives with high passenger occupancy, the robot must register the full load condition, reject the car, and wait for a subsequent dispatch without blocking the lobby.

Elevator integration is achieved either through modern cloud-based APIs provided by elevator manufacturers or via hardwired relay retrofits using potential-free contacts. Selecting the correct technical approach depends on the age of the elevator installation, controller architecture, and the manufacturer maintenance contract.

Modern smart elevators increasingly support native digital interfaces for robots. KONE's Service Robot API, for example, uses the WebSocket protocol and lets a robot place automated elevator calls, read real-time status such as car position, direction and door state, and monitor the call as it is allocated, arriving or served^[1]. The concrete protocol and feature set is manufacturer-dependent and must be clarified with the elevator manufacturer or maintenance provider. In contrast, legacy elevators built without digital connectivity require discrete I/O hardware modules installed directly inside the controller cabinet, physically bridging call buttons and door sensor circuits.

Interface Characteristic	Cloud-Based Elevator API	Relay / Hardwired Retrofit
Deployment Complexity	Software-driven integration via standard protocols	Physical hardware installation in machine room
Functional Depth	Full bidirectional telemetry (cabin load, direction, floor)	Basic binary states (door open/close, floor arrived)
Dynamic Dispatching	Group-level dispatch integration supporting multiple robots per elevator group[3][2]	Dedicated single-car assignment only
Hardware Alterations	No physical cabinet modification required	Physical wiring onto elevator controller boards
Manufacturer Approval	Standardized commercial licensing model	Mandatory case-by-case engineering sign-off

Cloud APIs shift the work from heavy hardware installation toward digitally managed connections, and their two-way communication lets robots receive real-time status such as emergency or service modes and adapt their behaviour accordingly^[3][2]. However, legacy relays remain necessary in older building stock. Regardless of the technical route, any interface intervention requires formal clearance from the certified elevator maintenance provider to prevent voiding operational warranties or statutory safety certifications.

Fire doors represent the most stringent regulatory boundary for autonomous robots because their legal purpose is to prevent the spread of smoke and fire through mandatory self-closing mechanisms. Robots cannot physically push open heavy, latching fire doors without compromising structural integrity or breaching building safety codes.

Under German fire safety practice, fire and smoke protection doors must be self-closing, and if they are to be held open, only a hold-open system (Feststellanlage) with building-law approval may be used, granted on the basis of a suitability assessment against the requirements of the Deutsches Institut für Bautechnik (DIBt)^[5][4]. Such a system combines a hold-open device (a magnet with an armature plate or a door closer with hold-open function, optionally with a powered door drive), at least one fire detector such as an optical smoke detector, and a manual release button, so that the door is released and closed at the earliest possible moment in the event of smoke, fire, a fault or a power failure^[4][5].

• Approved hold-open hardware: Hold-open magnets or door closers with hold-open function, fire detectors, and a manual release button must form one approved system regulated under DIN 14677, DIN EN 14637, and the DIBt guidelines^[4][5].
• Fail-safe release: In the event of an alarm or electrical interruption, hold-open mechanisms must release immediately without software delay.
• Monthly functional testing: The operator must keep the hold-open system permanently operable and check its correct function at intervals of no more than one month, plus an annual inspection and maintenance by a qualified specialist^[5][4].
• Expert sign-off: Any modification or automation retrofit on a fire barrier requires formal review and approval by an authorized fire safety expert or building authority.

Robots navigating across fire compartments rely on hold-open systems or synchronized automatic swing door drives that open on approach via secure wireless interlocks. Wedging fire doors open or altering closing tensions manually is illegal and creates severe liability. For hospital cleaning robots and transport units, passage must be designed entirely within certified building automation guidelines.

A continuous, low-latency wireless connection is vital for fleet coordination, real-time elevator handshakes, and door interlocks across complex floor plans. In hotel and hospital environments, physical barriers like reinforced concrete cores, elevator shafts, and fire compartment walls cause severe radio frequency attenuation, resulting in connection dead zones.

Unlike consumer devices that can buffer data or tolerate brief dropouts, autonomous mobile robots require deterministic communication. Without fast roaming support, a client disconnects from its current access point before associating with the next one, leaving a window with no network access that shows up as packet loss or dropped sessions^[6]. Implementing fast roaming standards such as IEEE 802.11k (neighbour information so the client knows where to roam next) and IEEE 802.11r (Fast BSS Transition, so encryption keys are already held by the target access point) reduces the time a handover takes and therefore its impact on operations^[6].

• Dedicated SSID and VLAN: Robot fleet traffic must be isolated from guest and general staff networks to guarantee bandwidth, eliminate broadcast overhead, and protect operational integrity.
• Elevator shaft coverage: In-shaft connectivity or specialized lobby access points are required so robots do not lose connection while inside vertical transit cabins.
• Fail-safe offline behaviors: Robots must execute predefined safe-stop or hold-position routines if a wireless connection drops mid-journey, preventing unauthorized threshold blocking.

Deploying hotel service robots alongside guest networks without network segmentation risks unexpected communication timeouts. A dedicated, professionally surveyed wireless local area network forms the backbone of reliable autonomous operations across multi-zone facilities.

Deployment delays in service robotics projects rarely stem from robot programming; they occur because organizational responsibilities across facility management, external contractors, and IT departments are undefined. Establishing an explicit responsibility assignment matrix at project kickoff prevents scope gaps and ensures compliance milestones are met on schedule.

Project Workstream	Building Operator / Facility Management	Elevator Maintenance Provider	In-House IT Department	Robotics Systems Integrator
Elevator API & Hardware Interface	Commissions service contract and funds upgrade	Provides interface hardware, API keys, and safety sign-off	Configures machine room network connectivity	Integrates dispatch protocols and conducts transit tests
Fire Door Automation & Hold-Open	Secures fire safety expert sign-off and logbooks	Not applicable	Not applicable	Maps trigger zones and verifies sensor safety timings
WLAN Infrastructure & Roaming	Approves access point placement and cable runs	Not applicable	Provisions dedicated VLAN, SSIDs, and fast roaming	Validates signal coverage and handover latency across routes
Fleet Workflow & Application Logic	Defines operational schedules and service routes	Not applicable	Manages host ERP/PMS network firewall permissions	Maps site layout, configures middleware, and trains staff

When evaluating vertical integration across facility services, the robotics systems integrator acts as the central technical coordinator. The integrator aligns the elevator contractor, fire safety inspector, and IT network engineers to ensure each interface complies with statutory requirements before live commissioning begins.

Maintaining dependable fleet availability across elevators, fire barriers, and networks requires centralized operational oversight that tracks building interfaces alongside robotic hardware. When a robot stops in a hallway, operations teams must immediately determine whether the root cause is a dropped wireless signal, a locked fire barrier, an occupied elevator, or an onboard hardware alert.

To manage multi-system environments without manual troubleshooting, modern deployments utilize standardized integration middleware. Pre-built software layers like Connectors translate commands between proprietary robot operating systems and external building controllers, hospital information systems, or hotel property management software. This removes the need to develop custom point-to-point drivers for every door or elevator.

Real-time fleet health is monitored through operational dashboards like Cockpit, which tracks system performance across hardware health, infrastructure availability, and regulatory compliance. The werob Platform coordinates this end-to-end integration architecture, turning isolated robotic units into a reliable, integrated building utility.