Smart Elevator, IoT layer
Elevator predictive maintenance, and what makes it work.
A door operator degrades for weeks before it strands anyone. A drive throws intermittent faults nobody watches until it fails on a Friday night. This page covers which signals carry that warning, how detection is built on top of them, and why the quality of the underlying data decides whether any of it is accurate.
The starting problem
Reactive maintenance is expensive and invisible.
The cost of a reactive operation does not appear as a line item. It appears as an emergency callout at an inconvenient hour, a technician driving across a city with the wrong part, a building manager who now escalates everything, and a contract that gets renegotiated downward at renewal.
What makes it frustrating is that most of those failures were not sudden. The component had been degrading for weeks, and the controller had been saying so in a language nobody was listening to. Without measurement, every failure is a surprise, and every surprise is an emergency.
Predictive maintenance is the attempt to hear that earlier. It is measurement and comparison rather than prophecy, and understanding the mechanism is the best defence against the marketing built around it.
Signals that carry warning
Six measures that move before the failure does.
Not every available signal is useful. These are the ones where a change in the number reliably means a change in the machine, which is the only property that makes a signal worth modelling.
The system reads live door timing and flags the upward drift against the unit baseline, weeks before it reaches a close-timeout fault.
What is watched per unit
- Door cycle timing
- Motor current under comparable load
- Run duration and levelling behaviour
- Intermittent self-clearing faults
- Usage intensity per period
- Availability and outage pattern
Door cycle timing
The time an operator takes to open, dwell, and close, measured per cycle. Door mechanisms degrade slowly, and the first symptom is usually a few extra milliseconds that nobody standing in the lobby would ever notice.
What is watched
Drift against the unit baseline, and reopen events climbing without a matching rise in traffic.
Motor current under comparable load
Current drawn on a run between the same floors in the same direction. Comparing like with like matters, because a full car legitimately draws more than an empty one.
What is watched
A steady climb in current for equivalent runs, which usually points to friction, alignment, or brake drag.
Run duration and levelling behaviour
How long a journey between two floors takes and how often the car needs a correction to level at the landing.
What is watched
Longer runs on the same route and rising relevelling counts, both of which precede visible ride quality complaints.
Intermittent faults that clear themselves
Codes raised and released without human involvement. These are invisible in a reactive operation because nothing was reported, yet they are the clearest statement a controller ever makes about a developing problem.
What is watched
Rising frequency of the same self-clearing code, particularly if it clusters at certain times of day.
Usage intensity
Trips, door cycles, and running hours per unit and per period, which vary enormously between a residential block and an office tower with a lunch peak.
What is watched
Units accumulating wear far faster than their service interval assumes.
Availability pattern
How often a unit goes out of service, for how long, and whether it recovers on its own or needs a visit.
What is watched
Short, repeated outages, which are usually a failing component announcing itself before it stops entirely.
How detection is built
Baseline, deviation, cluster, rank.
There is no single model that predicts elevators. There is a sequence of unremarkable steps that, done carefully, produce a short list a planner can act on each morning.
Build a baseline per unit
Averages across every elevator are close to useless here. A twenty-year-old geared machine and a recent gearless unit have different normals, and so do two identical lifts in different buildings. Each unit accumulates its own reference for door timing, run duration, and current.
Detect deviation, not absolute values
The question is never whether a door takes four seconds. It is whether this door now takes longer than it did, consistently, in a way that cannot be explained by traffic. Deviation from a unit baseline is the signal.
Cluster faults into causes
One failing component often triggers several codes in sequence. Grouping codes that repeatedly co-occur turns a wall of alerts into a small number of items that describe a probable cause.
Score by risk and exposure
A slow door on a low-traffic service lift and a levelling fault on a hospital lift under a tight SLA are not the same priority. Scoring combines severity, trend rate, usage, and contractual exposure into an ordered queue.
Decode into plain language
The item a planner reads should state the unit, the observed change, the probable cause, and the recommended check. A raw code with a trend chart is a research task, and nobody has time for a research task on a Friday.
Close the loop with outcomes
What the technician actually found is fed back against the flag. Without that feedback the system cannot learn which patterns are worth acting on, and it will keep making the same wrong call.
Prediction only pays off if the flagged unit turns into scheduled work. That happens in the maintenance module.
Elevator maintenance software →Why data quality decides accuracy
The model is the easy part. The data is not.
Prediction is the detection of small changes. If the measurement error is larger than the change you are hunting, no algorithm recovers the signal. That is why the useful work happens at the panel and in the firmware, long before anything is analysed. Six rules carry most of it.
Measured, not estimated
Door timing derived from the operator contacts is a measurement. Door timing inferred from a vibration sensor is a guess with an error band wider than the drift you are hunting for.
Timestamped at the panel
Server-side timestamps carry network delay. When you are looking for a few hundred milliseconds of drift, that delay is the whole signal, and the analysis becomes a study of the mobile network.
Continuous, with gaps declared
Buffered history means an outage does not silently become a period of apparent good health. Where data is genuinely missing, the record says so rather than interpolating across it.
Comparable conditions
Current on a run from ground to five is only meaningful against other runs from ground to five in the same direction. Normalising for route and direction removes most of the false positives before any model is involved.
Consistent across controller types
If a door cycle means something slightly different on each controller family, comparison across elevators is meaningless. Firmware normalises the definitions so a mixed portfolio of lifts remains analysable.
Honest about unknowns
Unmapped fault codes and ambiguous states are marked as unknown. A model trained on confidently wrong labels produces confidently wrong predictions, and the team stops trusting it within a month.
All six depend on reading the controller directly. How that capture works is covered on elevator remote monitoring, and the decoding behind it on elevator embedded firmware.
Honest limits
What prediction can and cannot see.
Anyone claiming to prevent every failure is selling something. The useful version of this technology is precise about its own boundaries, because that is what lets a maintenance team plan around it.
What prediction handles well
Door operator wear and mechanical binding
Brake drag and increasing friction in the drive train
Levelling degradation and encoder or selector drift
Components announcing themselves through repeated self-clearing faults
Units being worked far harder than their maintenance interval assumes
What it does not handle
Sudden electrical events such as surges or supply faults
Physical damage and vandalism
Failures in parts the controller does not observe at all
Anything on a unit that has been offline and unmonitored
Poor workmanship on a recent repair, until its effects appear in the data
From flag to work order
A prediction nobody schedules is a wasted prediction.
The most common failure of predictive maintenance projects is organisational rather than technical. The detection works, the flags appear on a screen, and nothing changes, because there is no route from a flag to a technician with a part and an access slot.
A flagged unit has to become a scheduled task on the maintenance calendar, with the observed evidence attached, the part identified, and site access arranged. That is what turns an early warning into an avoided callout, and it is why prediction is built inside the operations system rather than beside it.
What a good flag contains
The unit, its site, and the contract it sits under
The measure that moved and by how much against its own baseline
The window over which the change occurred
The fault codes clustered with it and their frequency
A probable cause and the check a technician should make first
Priority derived from risk, usage, and contractual exposure
A one-click route into a scheduled maintenance task
FAQ
Questions about prediction.
It compares how a lift is behaving now against how the same lift behaved when it was healthy. Door cycle timing, motor current under comparable load, run duration between floors, and fault frequency are tracked per unit. When those measures drift away from the unit baseline, or when faults start clustering, the system raises the unit for attention before the failure becomes a callout.
Related
Keep reading.
Prediction starts at the panel.
Tell us what controllers you run and how your maintenance is planned today. We will tell you which failure modes are detectable on your elevators and which are not.