The #1 infrastructure challenge for multi-floor robotics. Every robot vendor solves this alone, poorly, for one elevator brand at a time. We solve it once, for all of them.
Every robot vendor builds their own proprietary elevator integration. None of them talk to each other.
The ThyssenKrupp TAC32T is a real-world traction elevator system deployed in hospitals across the US. Here's what the platform must understand.
The brain. Houses the User Interface Tool (UIT) — a 2-line text display + 4 buttons for all configuration and inspector commands.
I/O Extension. Handles door disconnect switch, safety gear switch bypass, final limit jumpers, and all hoistway device signals.
Fire/Safety wiring interface. Controls governor overspeed bypass, hoistway safety device bypass, and machine room relay connections.
These are the UIT commands that actually move the car. A robot platform must translate high-level requests into these controller-specific calls.
SCCB
Bottom terminal landing car call
SCCT
Top terminal landing car call
SCC2
Floor 2 car call
SCC(n)
Floor (TOP-1) car call (3+ floor buildings)
TFR
Reset faults after test completion
If any of these signals activate, the Safety String opens and the car stops immediately. The platform must monitor and respect every one.
SAFC
Safety circuit
CST
Car safety tripped
SAFGR
Governor switch
FTSD
Final terminal slowdown
SAFCAR
Car safety gear
SAFMR
Machine room relay
SAFSP
Speed protection
NOPROG
No program
This is one controller, from one manufacturer. Otis, KONE, Schindler, and Hyundai each have entirely different card architectures, command sets, and safety protocols. Accelerate absorbs all of this complexity so no robot vendor ever has to.
Keenon's E-Box is a real-world robot-elevator bridge deployed in hotels and hospitals. It's smart, proven — and locked to one vendor.
Low latency, local control
Remote management, monitoring, fleet visibility
The robot confirms which floor the elevator cabin is on using RFID readers mounted at each landing. This is independent of the elevator controller's own position tracking — a critical redundancy for autonomous operation.
The Keenon E-Box is a well-engineered solution. But it only works with Keenon robots. If a hospital also deploys Aethon TUGs and Bear Robotics Servi bots, those vendors must each build their own elevator bridge. Accelerate replaces every vendor-specific bridge with one universal platform.
One API. Every elevator. Every robot.
The single interface every robot vendor calls. requestElevator(), getStatus(), holdDoors(), releaseElevator()
Translates the unified API into each manufacturer's protocol: KONE WebSocket, Otis OID Azure, ThyssenKrupp touchless API, Schindler PORT
For elevators without cloud APIs. LoRa, dry-contact relay, CANopen, RFID floor detection — like the Keenon E-Box, but vendor-agnostic
Physical button-pressing actuator for legacy elevators with no electronic integration path. Last resort, always available.
End-to-end sequence: Keenon delivery robot, ThyssenKrupp TAC32T elevator, Floor 1 to Floor 3.
requestElevator(floor: 1, destination: 3, robotId: "keenon-K7", priority: NORMAL)
TKE Adapter → TAC32T UIT → SCCB (bottom terminal call)
holdDoors(sessionId: "sess-4f2a", duration: 15000)
TKE Adapter → TAC32T UIT → SCC(3) (Floor 3 car call)
releaseElevator(sessionId: "sess-4f2a")
Every elevator ride follows a deterministic state machine. The middleware orchestrates hardware, sensors, and robot commands through 11 states — from idle to complete.
POST /elevator/callEach elevator button is a low-voltage circuit. A relay closes the circuit to simulate a button press — wired in parallel with the physical button so both human and robot control work simultaneously.
An edge device (Raspberry Pi, industrial PLC, or E-Box) receives commands from the robot middleware, controls relays, and processes sensor inputs.
30 robots. 6 elevator banks. One platform managing it all.
Multiple robots going to the same floor? Send them in the same car. Two robots requesting opposing directions? Queue by priority, prevent elevator lock-up.
Average wait time, rides per hour, peak demand patterns, elevator utilization, robot throughput. Data that no single-vendor solution can provide across a mixed fleet.
One integration per elevator brand. Every robot benefits.
Priority queuing, fire recall, infection isolation. Generic platforms can't do this.
Cross-vendor batching, deadlock prevention, capacity management.
Cloud API → hardware relay → mechanical arm. Always a path forward.
The system must fail safely, comply with elevator codes, and handle every edge case — because a stuck robot in an elevator shaft is everyone’s problem.
Step-by-step hardware installation from the Keenon manufacturer's deployment manual. This is what it actually takes to bridge a robot fleet to an elevator.
Mount the E-box Master unit at the top of the elevator shaft, secured to the shaft structure. This is the cloud gateway.
Mount the E-box Slave unit on top of the elevator cabin. This unit receives LoRa commands and controls the cabin panel via IO cables.
Fix one RFID tag on the shaft wall at each floor level. Mount the RFID Reader on top of the cabin.
Both E-box units have LoRa antennas (black stub on top). These must be oriented parallel to each other for reliable signal through the elevator shaft.
Box logic: NO (Normally Open) — the E-box activates relay contacts to simulate button presses on the cabin panel.
The E-box Slave has 32 IO channels across 8 cable harnesses (4 channels per cable), supporting up to 28 floors + door open.
| IO Port | Function | IO Port | Function |
|---|---|---|---|
| 1 | Door Open | 2 | Reserved (0) |
| 3 | Normally Open | 4 | Normally Closed |
| 5 | Floor 1 | 6 | Floor 2 |
| 7 | Floor 3 | 8 | Floor 4 |
| 9 | Floor 5 | 10 | Floor 6 |
| 11 | Floor 7 | 12 | Floor 8 |
| 13–16 | Floors 9–12 | 17–20 | Floors 13–16 |
| 21–24 | Floors 17–20 | 25–28 | Floors 21–24 |
| 29–32 | Floors 25–28 | Max: 28 floors + door | |
Connect IO cables directly to the back of cabin panel buttons. The E-box relay contacts parallel the physical button press — electrically identical to a passenger pressing the button.
Connect IO cables directly to the lift control board's terminal strip. Bypasses the cabin panel entirely and interfaces with the elevator controller PCB.
Building a universal elevator integration platform requires software at every layer — from firmware running inside an elevator shaft to a cloud dashboard showing live ride status. Here’s the full technology map.
The code that runs on the physical devices inside the elevator shaft. Controls relays, reads sensors, communicates via radio.
A small computer in the building that bridges hardware to the cloud. Runs the state machine locally so rides continue even if the internet drops.
The brain of every elevator ride. Tracks the 11-state lifecycle, enforces safety rules, handles retries and timeouts, and coordinates with sensors at each step.
The single API that every robot vendor calls. Handles authentication, rate limiting, fleet coordination, and routes commands to the correct elevator adapter.
A plugin for each elevator manufacturer that translates our universal API into the brand’s specific protocol. This is the key to N+M — add one adapter per brand, and every robot gets access.
Real-time visibility into every elevator, every robot, and every ride. Building managers see queue status. Engineers see LoRa signal strength and relay timing.
The code inside the shaft
The E-Box Master and Slave each run real-time firmware on microcontrollers. Think of it like the software on a smart thermostat — small, fast, and it must never crash.
The brain of every ride
Every elevator ride follows 11 deterministic states. The state machine ensures the robot never enters a moving elevator, never gets stuck between floors, and always has a recovery path.
One API for every robot
Robot vendors integrate once with our API. The fleet engine decides which elevator to send, handles priority queuing, and prevents 30 robots from calling the same car.
requestRide() function.Speak every elevator’s language
Each elevator brand has its own proprietary protocol. Our adapter layer translates our universal commands into the specific format each manufacturer expects.
callElevator(), getStatus(), holdDoors(), release(). Add a new elevator brand by writing one adapter. Every robot vendor benefits instantly.
See everything in real time
Building managers see a simple map of which robots are riding which elevators. Engineers see LoRa signal strength, relay latency, and RFID read rates. Both get alerts when something goes wrong.
Hospital-grade reliability
Elevator control in a hospital is safety-critical infrastructure. The stack is designed for zero-trust security, encrypted communications, and survivability when things fail.
The system uses multiple communication channels with automatic failover. If the primary path goes down, the next one picks up — all the way to a hardwired fallback.
Different types of data need different storage engines. Hot state lives in memory for speed. Ride history goes to a relational database for querying. Time-series telemetry goes to a specialized store for trend analysis.
We don’t need all of this on day one. The stack is designed to start simple and scale. Each phase adds capabilities while the previous phase continues operating.
Explore the full V1 architecture or get in touch to discuss elevator integration partnerships.