← Back
Home › Systems › Energy, industry and public infrastructure

elevator-control

elevator and escalator group control and safety: destination-dispatch optimisation, drive motion profiles, EN 81 safety chain, remote monitoring

KONE, Otis, Schindler PORT, TK Elevator

Open the elevator-control pageelevator-control Hdr histogramdata-structures: Log-linear bucketed histograms with bounded relative error for latency percentilesDeterministic simulationtestingdistributed: Run the whole system in one thread under a seeded scheduler with simulated network, disk and clock, so every failure replays from its seed.›Primary-backup replicationdistributed: One node orders all writes and ships them to standbys; the acknowledgement rule (none, one, all) sets what a crash loses, and an external arbiter decides who takes over.›Fixed-rate control loopembedded: Run a controller at an exact period using absolute deadlines and a fixed dt, so jitter never accumulates and the math stays valid.›Real time fieldbusembedded: Deterministic cyclic fieldbuses (EtherCAT, PROFINET IRT): on-the-fly frames, distributed clocksRedundancy votingembedded: N-modular redundancy and MooN voting (2oo3, TMR) with discrepancy detectionSafety-critical codingstandardsembedded: Which rule sets (MISRA C, CERT C, JPL Power of Ten, Rust lint subsets) apply when software must not fail, what they forbid, and how to enforce them in CI.›Safety monitor architectureembedded: Independent doer/checker safety monitor that forces a safe state when the main channel misbehavesTime triggered schedulingembedded: Static cyclic schedules where every task and message has a precomputed time slotWatchdog timerembedded: A hardware down-counter that resets the chip unless software proves, in time and in a plausible pattern, that it is still healthy.›Statechartsgraphics: State machines with nesting, parallel regions, history and entry/exit actions, so UI and animation logic stays linear in size instead of exploding.›Assignment problem (Hungarian /Jonker–Volgenant)graphs: Optimal one-to-one matching of rows to columns in O(n³) by growing a matching along shortest augmenting paths over dual potentials.›Process supervisionhardware-os: A parent process starts services, reaps their exits and restarts them under a delay and burst-limit policy, then stops them with SIGTERM before SIGKILL.›Mqtt protocolnetworking: MQTT pub/sub: topics, QoS 0/1/2, retained messages, sessions and keepaliveDiscrete event simulationnumerics: Simulation driven by a time-ordered event queue with deterministic, reproducible replayGenetic algorithmsoptimization: Population search with selection, crossover and mutation for black-box optimizationLocal search 2opt or optoptimization: 2-opt, Or-opt, relocate and swap neighborhoods with fast delta evaluation for routesMixed-integer programming(branch and bound)optimization: Solves LPs with integer variables by solving the LP relaxation, branching on a fractional variable, and pruning subtrees whose LP bound cannot beat the incumbent.›Simulated annealingoptimization: Stochastic local search with a cooling schedule for combinatorial optimizationField oriented controlrobotics: FOC of BLDC/PMSM motors: Clarke/Park transforms, current PI loops, space-vector PWMInput shapingrobotics: Shape motion commands (ZV, MZV, EI) to cancel mechanical resonancesPID controllerrobotics: Drive a measured value to a setpoint with three terms on the error: proportional, integral, derivative. The default feedback loop for motors, heaters, drones and gimbals.›Velocity motion profilesrobotics: Trapezoidal and S-curve (jerk-limited) velocity profiles for point-to-point movesCoverage-guided fuzzingsecurity: Mutate inputs, run an instrumented target, and keep any input that reaches a new code edge; feedback turns blind guessing into incremental search.›Mutual TLSsecurity: TLS where the client also proves a certificate key, so every connection carries a verified, rotatable machine identity.›Signed update metadata (TUF)security: Separate signing roles with thresholds sign small metadata pinning file hashes, versions and expiry, so clients detect rollback, freeze and mix-and-match and recover by rotating the root.›Queueing theorystatistics: Little's law, M/M/c and the universal scalability law for capacity modelsRemaining useful lifeestimationstatistics: Degradation and survival models predicting time to failure from condition dataTime-series anomaly detectionstatistics: Predict the expected value from a seasonal baseline, scale the residual by a robust spread (MAD), threshold at a chosen false-alarm rate, then merge flags into incidents.›Time-series forecasting(baselines, model families, ba…statistics: The end-to-end recipe: fix horizon and uncertainty, beat naive baselines, choose a model family, and validate with rolling-origin backtests and scale-free metrics.›Point-in-time recoverystorage: Periodic base backups plus a continuously archived change log let you rebuild the state as of any instant, then branch from there.›Graceful drainingsystems: On a termination signal, stop taking new work, finish in-flight work until a deadline, tell clients to reconnect elsewhere, then exit; clients resume from a token.›Hierarchical state machinesystems: Nest states so a substate inherits its parent's reactions and only overrides what differs, with ordered entry and exit actions along the path.›Cooperative schedulingconcurrency: Green threads/coroutines yielding at await points on a user-space schedulerFault injectiondistributed: Inject latency, errors, kills and partitions via proxies, netem or hooksRecord replaydistributed: Record every nondeterministic input (time, randomness, I/O, model and tool outputs, per-tick player input) and re-execute deterministically for debugging, replays and state rebuildLeasesdistributed: A lock that expires on its own: bounded-time ownership that survives crashes and partitions, given bounded clock drift and fencing tokens on writes.›Health checkingsystems: Decide per backend whether to route to it using probes and real-traffic errors, with consecutive-count hysteresis, capped ejection and a panic fallback.›Dma transfersembedded: DMA controllers: descriptors, circular buffers, cache coherence for zero-CPU data movementDataflow analysiscompilers: Compute a fact per program point (live variables, reaching definitions, available expressions) by iterating transfer functions over the CFG to a fixed point.›End to end protection e2eembedded: Per-message counter, ID and CRC over a black channel to detect loss, repetition, corruption, delayMemory protection unitembedded: A handful of base/size regions with permissions, checked on every access by the CPU, give microcontroller tasks isolation and stack-overflow traps without an MMU.›PWM generationembedded: A timer's counter, period and compare registers draw the pulse train; preload, dead time and DMA make duty changes glitch-free, shoot-through-free and cheap.›Dijkstra's algorithmgraphs: Single-source shortest paths with non-negative edge weights by settling vertices in order of distance with a priority queue.›d-ary heapdata-structures: Array heap with d children per node (d = 4 typical): half the binary heap's depth, siblings in one cache line, faster priority queues.›+ 33 moreTransparent interceptionnetworking: Redirect traffic to a local proxy (iptables TPROXY/REDIRECT, eBPF) without app changesSyscall interceptionsecurity: Intercept syscalls via ptrace, seccomp user notify or a user-space kernelFencing tokensdistributed: A number that grows with every lock grant and is checked by the protected resource, so a paused ex-holder's late write is rejected.›Control-flow graphcompilers: Split a linear instruction list into basic blocks and connect them by jumps; the graph every optimizer, SSA builder and dataflow pass walks.›Topological sortgraphs: Order the vertices of a DAG so every edge points forward; the core of build systems, schedulers and dependency resolution, with cycle detection for free.›+ 21 moreEbpfhardware-os: Verified in-kernel programs on hooks (kprobes, XDP, tc) with mapsPtrace process controlhardware-os: Ptrace: attach, read and write registers and memory, single-step, intercept signalsSeccomp bpfsecurity: Syscall filtering with seccomp BPF programsBFS and DFSgraphs: The two basic graph traversals; BFS gives hop distances and levels, DFS gives discovery/finish order for cycles, components and topological order.›+ 12 more+ 2 more

How it is built

Architecture overview

An elevator installation is a small real-time system with two very different jobs. The group controller decides which car serves which passenger call, trading waiting time against energy and car loading; a wrong decision only makes people wait. The car and drive controllers move a cabin along a shaft under a motion profile, open doors and stop at a floor within millimetres; a wrong decision here can hurt someone. The design splits these jobs on purpose: an optimiser that may be clever, slow to change and statistically tuned sits above a safety layer that is simple, redundant and certified, and the optimiser can only request what the safety layer allows.

The idea that makes it work is that the safety chain does not trust the controller. Whatever the software asks for, power to the machine and brake is cut when a door is open, a landing lock is not engaged, the car overspeeds or a final limit is crossed. The control software works inside that envelope. Remote monitoring (cloud connection of controllers, vibration and door counters, fault codes) sits outside it and only informs maintenance. Elevators and escalators in Europe are regulated through the EU Lifts Directive 2014/33/EU and the EN 81 standards (for example EN 81-20 for passenger lifts; Wikipedia, Elevator).

Parts:

 hall / destination panels ──► group controller ──car assignment──► car controllers ──► drive (profile, FOC, PWM)
        ▲                       (optimiser, traffic mode)              │  ▲              │
        │                              ▲                              │  │ encoder      ▼
   displays                    traffic forecast                  doors, levelling   motor + brake
                                                                       │
 ┌───────────────────────── safety chain (series contacts) ───────────┴──► cut motor power and drop brake
 │   door/landing locks · governor · final limits · safety monitor (independent channel)
 └─ cannot be overridden by any block above

 car controllers ── MQTT over mutual TLS ──► fleet backend (faults, vibration, door counts) ──► service tickets

How the parts fit together

Group dispatch

Calls arrive as hall calls (up or down at a floor) or, in destination dispatch, as a destination typed on a keypad, a touch screen or read from a card. In destination dispatch, passengers heading to the same floors are grouped into the same cars, which cuts waiting and travel time compared with ordinary up/down buttons (Wikipedia, Destination dispatch). The controller assigns each new call to one car and tells the passenger which car to take, so the assignment is a commitment. That is a different problem from a taxi dispatcher: it must be decided in milliseconds, it cannot be revised cheaply once displayed, and it must handle a car that fails after it was assigned.

The usual structure is: build a candidate list (each car, with its current direction, stops and load), cost each candidate by estimated waiting time, estimated journey time and the effect on calls already assigned, and pick the lowest. The cost model is the policy. It is typically tuned per traffic mode (up-peak, down-peak, lunch, off-peak) from simulation.

Optimisers fit at three levels of effort. A cheap online rule scans cars and picks the minimum with a Top-k selection or small d-ary heap. When several calls arrive at once, or a whole batch is re-planned, the matching of calls to cars is an assignment problem solved exactly in O(n³). When side constraints dominate (zoning, VIP priority, capacity, energy), mixed-integer programming states the full problem; in practice that is too slow for the online path and is used offline to evaluate how far a heuristic is from optimal. Metaheuristics (simulated-annealing, local-search-2opt-or-opt, genetic-algorithms; no pages yet) tune policy parameters or search the stop sequences offline. Reinforcement learning has also been tried: Crites and Barto trained multiple learning agents on a simulated group controller (Machine Learning, 1998). Learned dispatchers are mainly research results; a deployed policy has to be one a service engineer can reason about.

Traffic model and tuning

Buildings have strongly periodic traffic: arrivals in the morning, the lunch exchange, departures in the evening. The controller keeps a running traffic estimate per floor and period and switches mode when the pattern changes. Exponential smoothing is a cheap online estimator with O(1) state; STL decomposition separates the weekly and daily seasonal shape offline. Sparse flows, such as a rarely used basement floor, are intermittent demand (croston-method, no page yet). Time-series cross-validation is the honest test: train on the past weeks, score the next week. Capacity planning at design time uses the up-peak calculation that assumes all passengers come from the ground floor (Wikipedia, Elevator), and queueing-theory (no page yet) gives the first sizing estimate: Little's law links queue length, arrival rate and waiting time. A full design check runs a discrete-event simulation (no page yet) with sampled passenger arrivals (Monte Carlo integration with a seeded PRNG); a seeded run is reproducible, so two dispatch policies can be compared on the identical passenger stream.

Car motion and drive

The group controller says "go to floor 12"; the car controller turns that into a velocity profile: accelerate, cruise, decelerate and stop at the landing, with limited acceleration and limited jerk (the S-curve) because jerk is what a passenger feels (velocity-motion-profiles, no page yet). The profile is a reference, played out at a fixed period by a Fixed-rate control loop that must not drift. A PID controller closes the speed and position loops; inside it the drive runs current control on the motor (field-oriented-control, no page yet) by PWM switching. The encoder or tape signal passes IIR and FIR filters (biquad sections, no page yet) before the loops use it, and a Kalman filter can fuse the encoder with an accelerometer for a smoother speed estimate. Long ropes make the car a spring: input-shaping (no page yet) shapes the command so it does not excite the cabin's resonance. For simulation of the drive and the rope, Explicit Euler is the first integrator; stiff rope models need a smaller step. A Phase-locked loop (digital) appears where the drive tracks an encoder's sinusoidal channels.

Car and floor logic

Doors, buttons, lamps, levelling and operating modes (normal, independent service, fire recall, inspection) are a state machine with many modes that share reactions: a "stop" event means the same in every substate. A Hierarchical state machine and Statecharts keep that logic readable and testable, and they make illegal transitions (moving with doors open) visible in the model. On a networked controller, a Process supervision tree restarts crashed non-safety tasks (display, logging, the remote agent) without touching the drive.

Safety layer

Safety is layered and mostly not software. Traction lifts carry a mechanical overspeed governor that triggers safety gear on the guide rails if the car overspeeds (Wikipedia, Elevator), and the usual electrical safeguard is a chain of series contacts (door and landing locks, final limits) that opens the supply to the machine and brake; the EN 81 series sets the requirements. On top of this, modern controllers add electronic safety functions that are developed to a functional-safety standard. The common pattern is safety-monitor-architecture (no page yet): an independent channel (a doer and a checker) that watches speed, position and door state and forces a safe state on disagreement. Watchdog timer catches a hung processor, redundancy-voting (no page yet) compares two or three channels, a Memory protection unit isolates tasks on the safety microcontroller, and end-to-end-protection-e2e (no page yet) adds counters and checksums (CRC32C checksums or a safety-class CRC) so the receiver detects loss, repetition and corruption over a shared bus. Safety-critical coding standards fix the language subset and review rules, and Code coverage instrumentation provides the evidence that tests reached every branch.

Real-time bus

Between boards the traffic is small but must be deterministic: calls, car states, door commands, drive references. Lift controllers use CAN-based buses such as CANopen (it has a lift community and application profile; Wikipedia, CANopen) and, in motion systems, EtherCAT-style fieldbuses (real-time-fieldbus, no page yet). A time-triggered schedule (time-triggered-scheduling, no page yet) assigns each message a slot so worst-case latency is a design-time number, and dma-transfers (no page yet) move sensor samples without CPU load.

Remote monitoring and updates

The controller reports counters and fault codes to a fleet backend using a publish/subscribe protocol (mqtt-protocol, no page yet) over Mutual TLS, so each controller is an authenticated client. Condition monitoring turns vibration and door-motor current into health signals: vibration-spectral-analysis (no page yet) uses the Fast Fourier transform and the Short-time Fourier transform and spectrogram, with peak-detection (no page yet) for events such as a door-lock impact. A Time-series anomaly detection layer (Robust statistics for the baseline, an Isolation forest for multivariate outliers) flags a car whose door cycle time drifts; remaining-useful-life-estimation (no page yet) turns drift into "replace the belt within N weeks". Latency of door cycles is summarised with an hdr-histogram (no page yet). Firmware reaches the field through Signed update metadata (TUF): roles with thresholds sign small metadata that pins file hashes, so a compromised server alone cannot push firmware, and Digital signatures (Ed25519) plus key-rotation (no page yet) and Secrets management keep the keys safe. Updates never touch the safety channel without a re-certification step; that is a process rule, not a technical one.

Backend and test

The fleet backend stores fault events and counters on a Write-ahead log with Primary-backup replication and Point-in-time recovery; Leases protect single-writer jobs such as alert delivery. The product is tested in simulation: Deterministic simulation testing runs the group controller, car controllers and bus under a seeded scheduler, so a failure found once can be replayed exactly; fault-injection (no page yet) drops bus messages, stalls a car and kills a task. Health checking decides when a controller counts as offline.

The ingest servers that receive fault events from many controllers use Graceful draining on deploy: they stop accepting new connections, finish the events in flight, and tell controllers to reconnect to another server, which controllers do from their local buffer without losing a record. Coverage-guided fuzzing targets what arrives from outside the car: bus frames, remote-monitoring messages and service-tool commands, with the parsers built so that a malformed message cannot reach the safety chain.

Data and control flow

One passenger trip (destination dispatch):

  1. The passenger enters floor 12 at a lobby terminal; the terminal sends the destination and origin to the group controller.
  2. The controller costs each candidate car (position, committed stops, load) and picks one; the terminal shows "car C". Order of milliseconds.
  3. The car controller adds the lobby stop and the floor-12 stop to its plan and re-plans the stop order.
  4. At the lobby the door state machine opens, waits for a clear door sensor, and closes; the safety chain must be closed before the drive may move.
  5. The drive follows the velocity profile; the control loop runs at a fixed period, the safety monitor checks speed against the permitted curve for the remaining distance.
  6. Levelling brings the car to the floor within tolerance; doors open; the plan advances.

One condition-monitoring cycle:

  1. The controller samples door-motor current and car vibration around each run.
  2. It reduces them on the edge: FFT peaks, cycle times, counts.
  3. Summaries are published over MQTT with mutual TLS; the backend appends them to the log.
  4. A scheduled job compares each car to its own robust baseline and to similar cars; outliers become service tickets.

Scaling

  1. Dispatch decision time: a group with many cars and a burst of calls. Levers: incremental costing (only the changed car), a cheap rule online, exact assignment only for batches, precomputed zone tables.
  2. Traffic quality: a bad traffic model gives bad mode switches. Levers: more history per building, seasonal decomposition, a larger simulation set before release.
  3. Motion quality: ride comfort is bounded by the profile and the rope resonance, not by compute. Levers: jerk limits, input shaping, a better position sensor.
  4. Safety certification effort: every change in the safety path costs a re-assessment. Lever: keep the safety function small, independent and rarely changed; put all new features in the non-safety side.
  5. Fleet size: millions of controllers produce a steady stream of small messages. Levers: summarise on the edge, publish deltas, batch per site, shard the backend by site.
  6. Test cost: a physical test needs a shaft. Lever: deterministic simulation with recorded traffic.

Failure modes

FailureSymptomCauseFix
Bunchingtwo cars arrive together, a third nevercost ignores other cars' assignmentscount committed stops in the cost; add a spacing term
Wrong mode in the morninglong queues at the lobby at 8:55traffic mode switch lags the real patternforecast the period ahead, not just the last minutes
Car lost after assignmentpassenger waits at a car that never comescommitment shown but the car went out of servicere-assign on car fault and update the display
Jerky stoppassengers feel a bump at the floorjerk not limited, or loop period jitteringS-curve profile, absolute-deadline control loop
Rope oscillationcabin bobs after stoppingcommand excites a resonanceinput shaping, filter tuned to rope length
Door nuisance tripscar stuck with doors cyclingsensor noise, no debouncefiltering and a retry state in the door machine
Safety channel false tripcar stops between floorsspeed measure noisy near the limit curvefilter with margin, redundant sensors, vote
Missed corrupt messagewrong command accepted over the busno counter or checksum on a safety messageend-to-end protection with counter and CRC
Update bricks the fleetmany controllers offline after a rolloutsingle signer, no staged rolloutthreshold-signed metadata, canary groups, rollback
False maintenance alarmstickets for healthy carsbaseline polluted by outliers or seasonal driftrobust baselines, seasonal decomposition, per-car thresholds

Real implementations

namewhat it isrepolicencenotes
CANopenNodeopen CANopen stack in C for embedded targetsCANopenNode/CANopenNodeApache-2.0CANopen has a lift community and application profile; this is the generic stack
SOEMopen EtherCAT masterOpenEtherCATsociety/SOEM—real-time fieldbus master for motion
Eclipse Mosquittoopen MQTT brokereclipse-mosquitto/mosquitto—remote-monitoring transport

The commercial group controllers (KONE, Otis, Schindler, TK Elevator) are closed. I know of no open-source group controller at industrial level; the open pieces are the buses and brokers. Small research simulators on GitHub are not production systems and are not listed here.

Sources

  • Crites, R. H. and Barto, A. G., Elevator Group Control Using Multiple Reinforcement Learning Agents, Machine Learning 33, 1998. DOI
  • Wikipedia, Elevator: governor and safety gear, EN 81 standards, up-peak calculation, simulation of lift traffic. page
  • Wikipedia, Destination dispatch: origin, grouping of passengers by destination. page
  • EU Directive 2014/33/EU on lifts and safety components for lifts.
  • Trajectory Planning for Automatic Machines and Robots, Springer, 2009: textbook on trajectory profiles. DOI
  • Wikipedia, CANopen: lift community. page
  • OASIS, MQTT Version 5.0. spec
  • EtherCAT Technology Group, technology overview. page

Similar systems

Share the most building blocks with this one.

motor-drive 31 %infusion-pump 30 %traffic-signal-control 30 %airport-operations 29 %solar-inverter 29 %