Predictive Maintenance for Motors and Cranes: The Data You Need Before Any Model
The maintenance manager's request was short: put artificial intelligence on the cranes, and tell us before they break.
We said yes, and for the first nine months nothing resembling artificial intelligence ran on any crane. What ran instead was a modest set of sensors, a lot of arithmetic about bearings and a growing pile of data, because the model everyone wanted needs something that did not yet exist: examples of the failures it was supposed to predict. This is the story of that project, told in order, with the numbers and the code where they mattered. It is a representative composite, genericised, drawn from several condition-monitoring deployments on cranes and motors, and the figures are illustrative.
The lesson, which runs through every stage, is that predictive maintenance is a data problem long before it is a modelling problem. The teams that succeed spend their first months deciding what to measure, where, when and how to describe what they see. The teams that fail buy the model first.
Week One: A List of What Failed Last Year
The first meeting produced a list, on paper, of everything that had gone wrong with the cranes in the previous year. It was short, and it was more valuable than any dataset.
Most of the stops were bearings: on the hoist motors, on the gearbox shafts and on the wheels of the long-travel drive. A few were couplings. Several were brakes, which wear and fail differently and which vibration sensors barely see. A handful were electrical. And more than half of the lost hours came from two cranes that ran the heaviest duty.
That list set the scope. A condition-monitoring system that tries to predict everything predicts nothing well. We chose the two failure modes that cost the most and that vibration can see, bearings and gearbox faults on the hoist drive, and the two cranes with the heaviest duty. We would add current and temperature measurements for the electrical side, and leave brakes to a periodic manual check.
Start from the failure list, not from the sensor catalogue. A system built to detect three failures well beats one built to detect twenty badly.
Choosing What to Measure
Three kinds of measurement carry most of the information about a rotating machine.
Measurement | What it reveals | Cost and effort | Blind spots |
Vibration, from an accelerometer | Bearing wear, imbalance, misalignment, looseness, gear faults | Moderate, needs good mounting | Slow processes, electrical faults |
Motor current | Load, electrical faults, some mechanical effects | Low, no access to the machine | Weak signal for early bearing faults |
Temperature | Overload, lubrication failure, late-stage damage | Low | Late, because heat rises after damage begins |
We used all three, with vibration as the primary early indicator. A bearing fault announces itself in vibration weeks before it heats the housing, and temperature alone tells you about the failure when it is already expensive. Current showed us the duty: how hard the motor was working and when.
Mounting Is the Measurement
The first surprise was not about data. It was about glue.
An accelerometer measures the motion of whatever it is attached to. If the mounting itself has a resonance in the range of interest, the sensor measures the mount. A magnet on a painted surface rings at a frequency within the band where the early fault signature lives, and a sensor stuck on with a soft adhesive filters the very frequencies you want.
Mounting method | Frequency range it carries well | When to use it |
Stud into a machined seat | Highest | Permanent installations, best quality |
Adhesive on a cleaned, flat pad | Good | Permanent, where studding is not allowed |
Magnet on a flat clean surface | Limited at the top end | Surveys and temporary tests |
Handheld probe | Poorest and least repeatable | Quick checks only |
We studded a mounting pad to each bearing housing and recorded the same machine with the stud mount and a magnet mount to see the difference. Above about two kilohertz the magnet mount's response fell away and added a resonance. Since the bearing fault energy we cared about excites resonances in the one to three kilohertz region, we needed the stud.
Position and direction matter equally. The sensor goes as close to the bearing as possible, on the load zone, in the radial direction where the fault impacts are strongest. Mark the axes, record the orientation and photograph the installation, because six months later nobody will remember which axis was which.
What Overall Vibration Tells You, and When
The usual first measure is the overall level, the root-mean-square value of the vibration signal, which is also what simple alarm limits use. Its limitation shows clearly in a small simulation.
The code below builds a vibration signal from a rotating shaft at 25 hertz, with a second harmonic and noise, and adds the periodic impacts a defective outer race of a bearing would produce, at three severities. It then computes the features that matter. The bearing here has nine rolling elements and a ratio of ball diameter to pitch diameter of 0.21.
import numpy as np, math
from scipy.signal import hilbert, butter, filtfilt
from scipy.stats import kurtosis
rng = np.random.RandomState(7)
fs, fr = 5000, 25.0
t = np.arange(0, 2.0, 1 / fs)
def bpfo(n_balls, d_over_D, fr_hz, phi_deg=0):
return n_balls / 2 * fr_hz * (1 - d_over_D * math.cos(math.radians(phi_deg)))
def healthy():
return np.sin(2 * np.pi * fr * t) + 0.4 * np.sin(2 * np.pi * 2 * fr * t) + 0.25 * rng.randn(len(t))
def faulty(sev):
x = healthy(); f0 = bpfo(9, 0.21, fr); imp = np.zeros_like(t)
for k in range(int(2.0 * f0)):
imp[int(k / f0 * fs)] += sev
ring = np.exp(-np.arange(0, 0.02, 1 / fs) * 900) * np.sin(2 * np.pi * 1800 * np.arange(0, 0.02, 1 / fs))
return x + np.convolve(imp, ring, mode="full")[:len(t)]
def features(x):
rms = float(np.sqrt(np.mean(x ** 2))); crest = float(np.max(np.abs(x)) / rms)
kurt = float(kurtosis(x, fisher=False))
b, a = butter(4, [1200 / (fs / 2), 2400 / (fs / 2)], btype="band")
env = np.abs(hilbert(filtfilt(b, a, x))); env -= env.mean()
spec = np.abs(np.fft.rfft(env * np.hanning(len(env)))); freqs = np.fft.rfftfreq(len(env), 1 / fs)
m = (freqs > 20) & (freqs < 300)
return round(rms, 3), round(crest, 2), round(kurt, 2), round(float(freqs[m][np.argmax(spec[m])]), 1)
print(round(bpfo(9, 0.21, fr), 1)) # 88.9 Hz expected outer-race frequency
print(features(healthy())) # (0.799, 2.44, 2.07, 143.0)
for s in (0.5, 1.5, 4.0):
print(s, features(faulty(s)))
# 0.5 (0.803, 2.89, 2.09, 89.0) 1.5 (0.832, 3.11, 2.24, 89.0) 4.0 (1.006, 4.44, 4.13, 89.0)
Condition | Overall level (RMS) | Crest factor | Kurtosis | Envelope-spectrum peak |
Healthy | 0.799 | 2.44 | 2.07 | 143.0 Hz, noise |
Early fault, severity 0.5 | 0.803 | 2.89 | 2.09 | 89.0 Hz |
Developing fault, severity 1.5 | 0.832 | 3.11 | 2.24 | 89.0 Hz |
Advanced fault, severity 4.0 | 1.006 | 4.44 | 4.13 | 89.0 Hz |
The table is the argument. At the early severity, overall vibration rose by half a percent, from 0.799 to 0.803, which no alarm threshold would ever flag. Kurtosis was flat. Crest factor had begun to move, from 2.44 to 2.89. And the envelope spectrum, which isolates the impacts in the resonance band and looks at their repetition rate, already showed a clear peak at 89.0 hertz, within a tenth of a hertz of the calculated outer-race frequency of 88.9. In the healthy machine the same analysis found only noise.
Overall vibration reacts last. By the time it doubles the damage is advanced. The envelope spectrum reacts first, and it names the fault.
The overall vibration level is the last indicator to notice a bearing fault. The envelope spectrum is among the first, and it points at the part.
Bearing Frequencies: Arithmetic Before Algorithms
Each bearing fault repeats at a frequency fixed by the geometry and the shaft speed. For an outer-race defect, the rate at which rolling elements pass the flaw is half the number of elements times the shaft frequency, times one minus the ratio of element diameter to pitch diameter, multiplied by the cosine of the contact angle. The same bearing at 25 hertz has an outer-race frequency of 88.9 hertz and an inner-race frequency of 136.1.
Fault location | Repetition rate | Reading |
Outer race | About 3.6 times shaft speed for this bearing | Often the first to appear, the load zone is fixed |
Inner race | About 5.4 times shaft speed | Modulated by shaft rotation, so sidebands appear |
Rolling element | About twice the element spin rate | Harder to see |
Cage | A fraction of shaft speed | Usually a symptom of other damage |
The practical consequence is that you must know the shaft speed and the bearing geometry. Obtain the bearing designation from the machine, look up the geometry in the maker's data, and compute the four frequencies for each bearing before deploying. A crane's hoist motor does not run at a single speed, so the frequencies move with speed. Either measure the speed alongside the vibration, or analyse in orders, multiples of shaft speed, which stay fixed as the speed changes.
What Goes Over a Low-Bandwidth Radio
Our sensors sat on steel structures across a large yard, often without mains power nearby, and talked over a low-power wide-area radio with small packets and strict limits on airtime. Raw vibration at five kilohertz is megabytes an hour. It does not travel.
The answer is to compute at the sensor and send features. The node samples for a few seconds under a defined condition, computes the overall level in two or three frequency bands, the crest factor, the kurtosis and the height of the envelope-spectrum peak at each of the bearing's characteristic frequencies, adds the temperature and the operating state, and sends a handful of bytes. A few measurements an hour is enough for slow degradation. On request, or when a feature crosses a warning level, the node uploads a raw burst for the analyst to inspect.
That architecture follows from the radio. As our guide to LoRaWAN gateways showed, airtime and duty cycle limit how many frames a device may send, and every extra byte costs. Design the payload first, and decide what to compute at the edge from it.
A Sensor That Lasts: The Battery Budget
Without mains power, the battery sets the maintenance calendar, and its life comes from arithmetic, not from the datasheet's headline. A sensor node sleeps almost all the time. Each cycle it wakes, samples for a few seconds, computes the features, sends one short radio frame and sleeps again.
def battery_life_days(cap_mah, usable=0.7, sleep_ma=0.010, cycles_per_hour=6,
meas_s=3.0, meas_ma=15.0, comp_s=1.0, comp_ma=8.0, tx_s=0.185, tx_ma=40.0):
per_cycle_mas = meas_s * meas_ma + comp_s * comp_ma + tx_s * tx_ma # milliamp-seconds
per_hour_mah = cycles_per_hour * per_cycle_mas / 3600 + sleep_ma
return round(cap_mah * usable / per_hour_mah / 24), round(per_hour_mah, 4), round(per_cycle_mas, 1)
for c in (1, 6, 12, 60):
print(c, battery_life_days(8000, cycles_per_hour=c))
# 1: 8714 days 6: 2108 days 12: 1104 days 60: 230 days (60.4 mA-seconds per cycle)
Measurements per hour | Estimated battery life | Reading |
1 | About 8,700 days | Battery shelf life will end it first |
6 | About 2,100 days, 5.8 years | A practical default for slow degradation |
12 | About 1,100 days, 3 years | Reasonable for faster-changing machines |
60 | About 230 days | Too frequent for a battery in most cases |
The inputs are illustrative: an 8,000 milliamp-hour cell with 70 percent usable, a 10 microamp sleep current, a three-second measurement at 15 milliamps, one second of computing, and a 185 millisecond radio frame at 40 milliamps. The arithmetic shows two things. The measurement window, not the radio, dominates each cycle, with 45 of the 60.4 milliamp-seconds. And the number of cycles per hour sets the life far more than any other choice, which is a reason to measure in a defined state and not continuously. The figures leave out self-discharge and low temperature, both of which shorten life, so de-rate them.
Duty Cycle Is the Missing Feature
The second surprise was the cranes' behaviour, not the sensors'. A crane is not a pump. It spends much of its time idle, lifts loads of every weight, moves at different speeds and stops and starts all day.
A vibration reading from an idle motor says nothing about its bearings, and a reading from a lift of a heavy load differs from the same lift empty. Our first month of data was a mess: readings from idle, from empty hooks, from full loads and from starts and stops, all averaged into one noisy series with a spread that hid everything.
The fix was to measure in a defined state. The node watched the motor current and recorded only when the hoist ran at steady speed above a set load, discarding starts, stops and idling. Once the data came from comparable conditions, the series tightened by more than half, and trends that had been invisible became obvious. Recording the state beside each reading, even when it is not used, lets you analyse by state later.
Operating state | What to do with the reading |
Idle | Discard for bearing analysis, keep for utilisation |
Starting or stopping | Discard for trending, useful for brake and drive checks |
Steady speed, light load | Keep as a low-load baseline |
Steady speed, heavy load | Keep as the main trend |
One Baseline per Machine
The third surprise was how individual machines are. Two identical cranes, bought together, with identical motors, had overall levels that differed by a third from the first day. Mounting, foundations, alignment and loading all vary.
A single alarm limit for every machine therefore fails twice: it is too loose for the quiet machine, which can degrade a long way before reaching it, and too tight for the noisy one, which alarms from the start. The remedy is a baseline per machine. Record each machine for a few weeks in good condition, in the defined state, and compute its normal level and spread. An alert then means this machine has moved away from its own normal, not that it has exceeded a number from a standard.
Published severity standards for machine vibration give useful guidance on absolute levels by machine class, and they serve as an outer limit. The machine's own baseline is the early warning.
The Arithmetic of False Alarms
Our first alert rule was the obvious one: alarm when the feature exceeds three standard deviations above the baseline. It worked beautifully in the demonstration and badly in the field.
The simulation below shows why. It models 2,000 machine-years of a healthy feature with a stable baseline and noise, and counts how many machines would trigger at least one alert in a year. It then repeats the exercise with a slowly growing fault, a rise of 0.004 per day beginning on day 200, and measures how many days after the start of the fault each rule alerts. One rule alerts on any single reading above the limit. The other requires three consecutive readings above it.
def simulate(n_machines=2000, days=365, thr_sigma=3.0, consecutive=1,
fault_day=None, rise_per_day=0.0, seed=0):
r = np.random.RandomState(seed); false_alarms = 0; detect_days = []
for m in range(n_machines):
base = 1.0 + 0.05 * r.randn(days)
x = base if fault_day is None else base + np.maximum(0, np.arange(days) - fault_day) * rise_per_day
over = x > 1.0 + thr_sigma * 0.05
run, fired = 0, None
for d in range(days):
run = run + 1 if over[d] else 0
if run >= consecutive:
fired = d; break
if fault_day is None and fired is not None: false_alarms += 1
if fault_day is not None and fired is not None and fired >= fault_day: detect_days.append(fired - fault_day)
return false_alarms, detect_days
for k in (1, 3):
print(k, simulate(consecutive=k)[0]) # 763 and 0
print(k, int(np.median(simulate(consecutive=k, fault_day=200, rise_per_day=0.004, seed=3)[1]))) # 23 and 41
Alert rule | Machines with a false alarm per 2,000 machine-years | Median days to alert after the fault begins |
One reading above three standard deviations | 763, about 38 percent | 23 |
Three consecutive readings above three standard deviations | 0 | 41 |
The single-reading rule sounded the alarm on more than a third of healthy machines in a year, and each false alarm costs a visit. The three-in-a-row rule produced none, and it alerted 18 days later on a fault that takes about 37 days to rise to the limit. In a plant where a crane can be stopped for a planned repair with a week's notice, 41 days is plenty. In a plant where a fault can run to failure in a fortnight, it is not, and the choice should reflect that.
The threshold is a choice between missed faults and false alarms. Decide it from the cost of each, and from how fast the fault can progress, and not from the demonstration.
The First False Alarm Costs More Than the First Miss
Our single-reading rule ran for three weeks. In the second week it flagged a hoist motor, a maintenance crew spent half a day inspecting it, found nothing and wrote a short, polite remark in the log. In the third week it flagged another, and the crew did not go.
That is the real cost of false alarms. A miss is invisible until it fails, whereas a false alarm teaches a team to ignore the system. By week four the crew had a habit of checking alerts last, and the one genuine early warning of the project went unread for nine days. The bearing it described was replaced during a planned stop, only because the crane happened to be scheduled for one.
We changed three things. The rule moved to three consecutive readings. Each alert gained a short text with the evidence: which bearing frequency, how far above baseline, for how many readings and under what load. And every alert's outcome, a real fault or a false alarm, went into the log, so that the system could be tuned on facts.
When Machine Learning Finally Helped
By month nine we had something we had lacked at the start: six months of steady-state features from twelve machines, a log of every alert and its outcome and three confirmed bearing faults with the full history leading up to each.
That was enough to use machine learning well, and still not enough for the thing everyone first imagined. Three failures cannot train a classifier that recognises failures. What the data could support was an anomaly model: learn what each machine's feature vector looks like when healthy, in its operating states, and score how unusual a new reading is, combining the band levels, the envelope peaks, the crest factor and the temperature into one number.
The model's real value was narrower and more useful than prediction. It cut false alarms by combining evidence: a single feature drifting up alone, with the others steady, was usually noise, while several rising together was usually real. It handled the dependence on load better than fixed thresholds. And it ranked machines each week by how far they had moved from their own normal, which turned a dashboard into a short list for the crew.
It did not predict the day of failure, and nobody should promise that. What it gave was earlier, better-explained attention, and that is what a maintenance crew can use.
What Vibration Cannot See
A vibration programme catches a large share of rotating-machine faults, and the cranes had failures it could not see. Being honest about them kept the project credible.
Failure | Why vibration misses it | What catches it |
Brake wear and glazing | Brakes act when the machine is nearly stationary | Wear gauges, brake-torque tests, scheduled inspection |
Rope and sheave damage | Slow structural change, no rotating signature | Visual and magnetic rope inspection |
Electrical faults in windings | Show in current, not early in vibration | Motor current analysis, insulation tests |
Overload and abuse | A habit and not a defect | Load monitoring and logging |
Lubrication starvation | Appears first as temperature and noise | Temperature trend, scheduled lubrication |
Structural cracks | Not a rotating-machine problem | Periodic non-destructive testing |
The project's scope statement said plainly which failures the system covered and which it did not, and the maintenance plan listed the manual checks for the rest. That prevented the most damaging misunderstanding in this field: the belief that a monitored crane needs no inspection.
A condition-monitoring system supplements inspection. It does not replace it. Say which failures it covers, and keep the manual checks for the others.
What the Crew Wanted
The last surprise was what the people who would use the system asked for. They did not want a dashboard with spectra. They wanted, for each crane, a one-line status, ordinary and clear: normal, watch or act, with a reason in plain words and a link to the work order.
We built that. Each morning a list went to the shift supervisor with the cranes that had changed state, the bearing involved and the evidence. The spectra and trends were available a click deeper for the analyst. Alerts that mattered created a work order automatically, with the evidence attached, and the crew closed it with what they found, which fed the log.
Adoption followed the usability. A system designed for the analyst was admired and ignored. A system designed for the shift supervisor was used.
Installation Day: A Checklist
Most data quality problems begin on installation day, and a short checklist prevents the commonest.
Confirm the bearing designation and shaft speed range for every monitored bearing, and write them in the installation record.
Prepare the surface: clean, flat, free of paint at the mounting pad, with the stud or bonded pad fixed before the sensor goes on.
Mount the sensor on the bearing housing in the radial direction at the load zone, and record the axis orientation with a photograph.
Record a raw burst under a known operating condition and compare it with the expected bearing frequencies before leaving the site.
Check the radio link from the installed position, and record signal strength and the gateway used.
Log the date, the operating hours of the machine, the state of the bearing if known and any recent maintenance, since this is the start of the baseline.
Agree with the maintenance team who receives the alerts, what each state means and what they should do.
Keep the record with the machine's maintenance file. A sensor with no installation record becomes unexplained data the first time a reading changes after someone moves it.
Results, Counted Honestly
The figures below are illustrative, from the composite deployment, over the first twelve months across twelve machines.
Outcome | Count | Notes |
Real developing faults detected before failure | 3 | All bearings, caught at a planned stop |
Real faults missed | 1 | A brake problem, outside the sensors' scope |
False alarms in the first month, single-reading rule | 9 | The rule that trained the crew to ignore alerts |
False alarms in the last quarter, three-in-a-row plus anomaly score | 1 | Traced to a mounting change |
Unplanned stops caused by monitored faults | 0 | Against a handful in the previous year |
The business case rested on a small number of avoided breakdowns of heavily loaded cranes, each of which would have stopped a production line for a day. Three detections in a year, each turned into a planned repair, paid for the system comfortably. It is not a spectacular count, and it is the honest shape of the benefit: a few expensive events avoided, and a calmer maintenance calendar.
Monitoring Is Not a Safety Function
One clarification belongs in every project of this kind. A condition-monitoring system tells maintenance staff that a machine is changing. It is not a safety device.
Cranes and lifting equipment have their own protective devices: overload limiters, limit switches, emergency stops, brakes and the statutory inspections and tests that apply to lifting machinery. They are designed, tested and certified for the purpose, and they operate in the control chain of the crane. A monitoring system sits outside that chain. It has no authority to stop a lift, and it must not be wired in a way that could interfere with the safety functions.
Three habits keep that line clear. State in the project documents that the system supports maintenance planning and is not part of the safety system. Keep its connections to the crane read-only, with isolation where it taps signals, so that a fault in the monitor cannot affect the crane. And never let its output substitute for a required inspection, since a quiet monitor is not evidence that a crane is safe to lift. Consult the applicable regulations and the crane's competent person before any installation on lifting equipment.
Monitoring reduces surprises, and inspection and safety devices protect people. Keep them separate in the design, the documents and the conversation.
Where the Money Goes
Teams budget for sensors and forget the rest. In a deployment like this, the cost falls into five places, and the proportions surprise people.
Cost area | What it covers | How it behaves |
Sensors and nodes | Accelerometers, mounting pads, the battery node and its enclosure | Falls with volume, a minor share at scale |
Connectivity | Gateways, backhaul and their power and mounting | A fixed cost per site, shared by many nodes |
Installation | Access, shutdowns, mounting preparation and commissioning | Large for the first machines and shrinking with practice |
Analysis and tuning | Baselines, thresholds, alert review and model work | The cost most often underestimated |
Operations | Battery replacement, calibration checks and spares | Small per unit and permanent |
Analysis and tuning is the line most projects omit. The first months of alerts need a person reviewing each one, adjusting thresholds and recording outcomes. A project that budgets for hardware and not for that attention will have a working system that nobody trusts.
Compare the total with the cost of the failures you aim to avoid, using your own breakdown records: the lost production hours, the emergency repair premium and the secondary damage a failed bearing can cause to a shaft or gearbox. The case rests on a few events, so keep the estimate honest and conservative.
Mistakes We Would Not Repeat
Mistake | What it cost | What we do now |
Starting with the model | Months with no usable data | Start with the failure list and the measurement |
Magnet-mounted sensors in permanent sites | Resonances hiding the fault band | Stud or bonded pads |
Averaging across operating states | A noisy series that hid trends | Record only in a defined state, and log the state |
One alarm limit for all machines | Quiet machines ignored, noisy ones alarming | A baseline per machine |
Alerting on a single reading | A third of machines alarming a year | Persistence, plus evidence in every alert |
Designing for the analyst | A dashboard nobody opened | One line per machine for the supervisor |
Promising prediction | Unmet expectations | Promise earlier, explained attention |
A Plan for the First Six Months
Month one: collect the failure list and pick the two or three modes that cost the most and that vibration can see.
Month one: compute bearing frequencies for every machine to be monitored, and note shaft speeds and duty patterns.
Month two: install studded or bonded sensors, record raw bursts under controlled conditions and check the fault bands.
Month three: build state detection from the current, and compute the features at the sensor.
Months three to five: collect baselines per machine, in defined states, and run the three-in-a-row alert rule with evidence text.
Month six: review every alert and its outcome, tune the thresholds, and decide whether there is enough labelled history for an anomaly model.
The Request Revisited
The maintenance manager asked for artificial intelligence on the cranes, and in the end the cranes got something better described as careful measurement with a little learning on top. The sensors were mounted properly. The data was taken in comparable conditions. The baseline belonged to each machine. The alerts explained themselves. And the model arrived when there was something for it to learn.
If you are about to start a project like this, begin with the list of what failed last year. It is the most valuable dataset you have, and it costs a conversation.
Related service: LoRaWAN & IoT Connectivity
Related case study: Edge LoRa Sensor Network for Industrial Crane Motors
Related reading: LoRaWAN Gateway Buyer's Guide for India: Channels, Certification and Capacity and WPC ETA Certificate Step by Step: Getting a LoRa or IoT Device Approved in India.
EurthTech is an engineering-first product design and embedded systems company with a development center in Hyderabad. To discuss a project, write to connect@eurthtech.com or see https://www.eurthtech.com/case-studies.
Comments