Edge AI for Elevators & Escalators 2026 — Predictive Maintenance, In-Car Vision & Code-Compliant Hardware

Vertical transportation is one of the largest installed bases of electromechanical machinery in the built environment. Roughly 20 million elevators and escalators are in service worldwide, more than a million new units ship each year, and almost every one of them carries a service contract. The economics of that industry are decided by callbacks: a nuisance stop or a stuck door costs a truck roll, and most of those faults announce themselves in vibration, motor current and door-cycle timing weeks before a passenger notices anything.

That is why inference hardware is moving into the hoistway. But a lift is not a factory cell with a cabinet and a conditioned room. This guide maps the workloads, the compute tiers and the compliance envelope for anyone specifying edge hardware for vertical transportation — and it states plainly where inference must never be allowed to sit.

Why the Shaft Is a Hostile Place for a Computer

The decisive constraint is architectural. The machine-room-less (MRL) design that has dominated new construction since the 2000s moved the traction machine into the shaft and deleted the room. There is no cabinet, no conditioned air, no three-phase feed and no maintenance bench. Whatever computes must fit a hoistway-mounted box or the car top, tolerate the shaft’s thermal swing, and outlast a machine that starts and stops tens of thousands of times a year.

The electrical environment is harder than the mechanical one. A VVVF (variable-voltage, variable-frequency) drive switches at kilohertz rates on the same steel structure that carries your sensor wiring; regenerative braking pushes energy back onto the line; the door operator runs its own PWM stage a metre from the camera. Lift EMC is assessed under its own product-family standards, which is the clearest signal that treating the box as an ordinary industrial PC misses the point.

One boundary matters more than any component choice: the safety chain. Overspeed governor, safety gear, door interlocks and final limits are hardware-certified devices, and where the safety functions themselves are implemented electronically they must reach a functional-safety integrity level. Inferential maintenance and occupancy analytics are advisory. Put an AI node inside the safety chain and you have neither a certified lift nor a useful model.

The Workload Map

Seven workloads account for almost everything sold into this vertical. They differ enormously in sample rate, model size and where the result has to travel, which is why a single do-everything box is usually the wrong purchase.

A busy lift completes 300–600 door cycles a day, which is 150,000 to 250,000 a year. Counting them is trivial; the value is in the timing signature, where a slow close or an early reversal appears long before the door actually fails. Motor current signature analysis is a different problem: stator currents have to be sampled in the kilohertz range to expose bearing and rotor faults, so the transform belongs on the node, not in a quarterly cloud upload. Traffic optimisation is the opposite shape again — it is a whole-building allocation problem whose inputs are hall calls, so it belongs at the head-end where every car is visible, not in any individual cabin.

Sizing the Node

Sizing follows the workload map rather than a TOPS target. The common mistake is buying one Jetson-class box per car when a door counter, an IMU and a single camera are all the car needs — or, in the other direction, asking an ARM gateway to fuse four camera streams and a motor diagnostic at the same time.

Power is the binding constraint inside the car. The traveling cable that links car to controller has a fixed conductor count and a finite flex life, so PoE on spare pairs or a dedicated low-voltage supply fed from the car’s own single-phase feed are the two realistic options — and the second is often cheaper once the cable specification is on the table. Budget the node, the camera heaters and the cellular modem together; a wide-temperature enclosure with a heater can draw more than the processor it protects.

The Compliance Envelope

Vertical transportation is regulated as a machine rather than as automation, and the standards a buyer must name in the specification are specific to it.

The practical consequence is that the AI node should be a monitored add-on with its own documentation trail, not a component the lift’s conformity assessment depends on. Demand a written support period, a bill of materials for the wireless or cellular module, and a vulnerability-reporting commitment from the supplier. Those are the same Cyber Resilience Act obligations that now attach to every connected edge device, and they will be asked for again at the next modernisation tender.

Seven Buying Rules

• Keep inference out of the safety chain. Derive advisory signals only, and document where the boundary sits.
• Size on sample rate, not model size. Kilohertz diagnostics need a local transform; occupancy needs a camera and a small model.
• Specify the shaft environment explicitly: wide temperature, conducted cooling, isolation from the VVVF structure, and EMC behaviour demonstrated with the drive running.
• Treat the traveling cable as a design input rather than a detail. Conductor count and flex life decide the in-car power budget.
• Buy one node per function where duty cycles differ; a shared box couples a door counter’s uptime to a video pipeline’s thermal load.
• Require vendor-neutral interfaces such as Modbus, CAN or OPC UA, because the lift controller bus is proprietary and you will not be given a driver.
• Plan retention and the evidence chain before the first camera ships, because code-mandated records and video evidence follow different clocks.

QSCompute supplies the hardware half of that specification: fanless and wide-temperature industrial PCs, ARM gateways and Jetson-based edge systems sized from single-car nodes up to building head-ends, with the environmental documentation to match.