An Escalator Monitoring Pilot That Never Got Built

Overview

Two escalators, one running up and one down, both driven by a motor and gearbox turning a step chain. Both were maintained on a calendar interval by an external contractor. Neither had any condition monitoring at all, and neither produced any data that anyone read.

The proposal was a small, independent, external sensing rig: measure the drive's vibration and current continuously, build a baseline, and detect degradation before the calendar found it.

It was approved in principle. It was designed down to candidate sensor part numbers. It was never built, and the reasons are worth more than the design.

Why escalators

They are an unusually good monitoring candidate on paper. The drive is a constant-speed motor-gearbox-chain train, which is the best-understood failure geometry in the field. They start and stop constantly, so startup-signature analysis is available — unlike a fan that runs at one condition for months. And the consequence of failure is not a production line stopping, it is a public safety incident, which is the category of risk that normally unlocks budget.

They are also an unusually bad monitoring candidate in every way that is not technical. That turned out to be the entire story.

What killed it

Three things, in order of how much they surprised me:

The vendor would not permit drilling. The gearbox belongs to the escalator contractor. Stud mounting — the only method that reaches the frequencies a bearing fault lives at — requires drilling and tapping their equipment. That was refused, which forced epoxy mounting, which caps the usable frequency range before any sensor is chosen. A maintenance-access decision made by someone else set the ceiling on the physics.

Nobody had settled who would own what. Not the hardware — that part is easy. The software and the method, which are the only genuinely valuable and portable parts. Between an employer, a main contractor and a parent company that owns the asset, there were three plausible owners and no written position. Building first and negotiating afterwards would have been the worst possible order.

The return was unproven and the cost was not. Every honest version of the business case rested on an estimate. The cost did not.

The honest verdict

The engineering was the easy part and it was finished. What stopped it was access, ownership and an unprovable return — the three things that stop most condition monitoring deployments, none of which appear in a vendor's technical evaluation.

I would rather publish this than not. A portfolio of things that worked describes a person who has not yet met the parts of this job that are actually hard.

The design

The rig was deliberately lean. Not because lean is virtuous, but because cost is the only variable I controlled — and a small number gets waved through where a large one summons a committee.

What gets measured

One sensor, not four. An earlier version of this design specified two triaxials per motor across two motors — six vibration channels each, for redundancy and coverage. That is a production robustness argument, not a pilot argument. A pilot has to answer "is there signal here at all", and one sensor answers it. Cutting to one also removed a DAQ module from the bill.

If both units genuinely needed covering, the plan was to move the rig rather than buy a second.

The three floors

Everything else was negotiable. These were not — cheap below any of these lines and the data lies to you, which is worse than having none.

Floor 1 — the accelerometer must cover the actual fault frequencies. Set by shaft RPM and bearing geometry, both of which come off the nameplate. An under-ranged sensor does not fail loudly; it returns a confident, clean, empty spectrum, and the pilot concludes "monitoring doesn't work here." Of the candidate sensors priced, one was flagged as likely under-ranged and excluded on exactly this basis despite being the cheapest.

Floor 2 — the DAQ must do true IEPE excitation, simultaneous sampling, and roughly 25 kS/s. Below that, the vibration data is aliased, and aliased data looks like real data.

Floor 3 — raw data must export in an open format. A DAQ that traps its output inside a vendor dashboard fails the entire point of the exercise, which was to run the analysis in my own engine.

The data path

DAQ → Raspberry Pi → local SSD buffer → sync to cloud storage when a connection exists.

Continuous high-rate sampling into a ring buffer, with startup-triggered burst capture so the pre-trigger window is retained — escalators start and stop often, and the moments before inrush are where startup signatures live. Between events, only processed RMS values are published.

The unresolved risk

Connectivity in the pit. A metal-lined pit blocks wireless, and the same no-drilling constraint that governed the sensor also meant no hole for an antenna. The fallback, and honestly the sensible answer, was a local buffer with manual collection — pull the drive on site visits. Slow-drift monitoring does not need live data, it needs eventual data, and a buffer loses nothing.

That option cost nothing and removed a dependency on the building's IT department, a cellular contract and a hole in someone else's structure. It is the decision I am most confident was right.

What was never finished

The costing. Every price in it is still a placeholder, because the whole bill of materials was gated behind one thing: a physical survey to read the motor nameplate. RPM sets the fault frequencies, fault frequencies set Floor 1, and Floor 1 selects the sensor.

The survey never happened, so the spec stops at "the cheapest sensor that clears the floor, pending the nameplate." That is as far as the design can honestly go without a number nobody had.

Access & ownership

Neither of these is an engineering problem. Both of them decide whether the engineering happens.

The mounting refusal

Sensor mounting has a hierarchy, and it is a hierarchy of stiffness: stud reaches roughly 10 kHz and above, epoxy pad somewhat less, magnet around 2–5 kHz, handheld about 1 kHz. Above the mounting resonance the sensor is deaf. Not inaccurate — deaf.

Stud mounting means drilling and tapping the gearbox housing. The gearbox belongs to the escalator contractor, who declined. That is not unreasonable of them: a third party drilling their equipment creates a warranty argument they have no reason to accept and nothing to gain from.

So the design was locked to epoxy, which brings its own requirements — a clean, flat, bare-metal spot close to the bearing, and a genuinely stiff adhesive, because flexible glue is itself a low-pass filter. Epoxy is also semi-permanent, meaning the position has to be right first time, which raised the value of the survey that never happened.

The lesson I would carry into a vendor conversation: lead with external, non-invasive, no drilling. Ask which surfaces are available before specifying anything, because the answer sets your frequency ceiling and therefore which failure modes you can detect at all. Turning up with a sensor selection and discovering the mounting constraint afterwards is the wrong order, and it is the order most people use.

There was also a softer access problem. The maintaining contractor was not forthcoming with their own data or alarm thresholds, which is why the design is deliberately independent external sensing rather than anything that reads their system. Designing around an uncooperative incumbent is a normal condition of this work, not an exception.

The ownership problem

This is the part I got right by accident, in the sense that I recognised it before spending money rather than afterwards.

Three separate things were about to be created, and everyone involved was fuzzily assuming they travelled together:

1. The hardware — DAQ, sensors, the Pi. Commodity. Whoever pays owns it, and it does not matter much, because anyone can buy the same parts.
2. The data — the readings themselves. Negotiable, and it is reasonable for these to belong to whoever owns the asset.
3. The software and the method — the analysis, the baselines, the detection logic. This is the only part that is valuable, portable and replicable. It is worth more than the other two combined and it is the part nobody was talking about.

Paying for the hardware does not buy the software. Naming the three separately is the whole move, because it converts a vague assumption — "whoever funds it owns everything" — into three decisions that have to be made explicitly.

There is a layer beneath that which matters more: if you build it on your employer's time as part of your job, the default may already be work-for-hire. In that case you are not negotiating to own the software, you are negotiating to retain some rights to it. Those are very different conversations, and which one you are in is determined by an employment contract clause, not by the meeting.

Leverage decays, and it decays in the wrong direction

The uncomfortable observation: leverage is highest before you build. While the knowledge is in your head, it is scarce. Once a working system exists, it runs without you, and the scarcity is gone. Being hard to replace protects your job; it does not protect ownership or credit, and those have to be secured separately, on paper.

Which produces the sequencing rule that stopped this project:

1. Read the contract clause. It sets the default before any conversation starts.
2. Specify the sensors — visible expertise, costs nothing.
3. Write a proposal with ownership terms in it, not just a shopping list, so the person approving the money also approves the ownership. Do not let money be approved and ownership quietly deferred.
4. Submit it and let the organisations resolve funding between themselves.
5. Do not build until ownership is agreed.

And the rule underneath all of it: do not self-fund the hardware. Paying personally means unpaid labour plus murky ownership plus an organisation benefiting from both your money and your work with no contract governing either. The only exception is deliberately building your own IP to license — and that is an explicit written arrangement made before spending, not a story told afterwards.

The pilot stalled at step five. Given the alternative was building the valuable part first and discovering who owned it later, stalling was the correct outcome.

Why it did not close

The proposal was accepted as a good idea and never funded. Those are compatible outcomes and it took me a while to understand why.

The asymmetry that kills pilots

The cost is certain and the return is an estimate. However carefully the business case is built, one side of it is a quotation and the other is a projection about failures that have not happened. A committee reads that asymmetry accurately.

Which means the only lever genuinely under my control was the cost. Shrinking the rig was not only an engineering decision — a smaller number clears a lower approval threshold, moves faster, and may avoid a capital process entirely. Lean served the politics as much as the physics.

It still was not enough, because of what the money was being asked to buy.

Protection is invisible when it works

A monitoring pilot that succeeds produces an absence: the failure that did not occur, the callout nobody made. There is no photograph of it. Meanwhile the same budget spent on almost anything else produces something a manager can point at.

This is the structural weakness of every preventive spend, and I do not think it is irrational — it is the correct response to an uncertain return with no visible artefact.

What I would do differently

Instrument the repeat offender, not the category. "Starting condition monitoring" is a programme and needs a programme's approval. "Instrumenting the unit that failed three times last year" is a targeted fix that justifies itself from its own history and asks for far less money. Nobody funds a pilot; people fund stopping a specific recurring problem.

Do the free analysis first. The maintenance records already existed. Counting unplanned versus planned work orders, and the cost of the unplanned ones, produces a number that creates budget appetite instead of requesting budget. That analysis costs nothing but time and I should have led with it rather than with a sensor specification.

Ask who pays before designing what to buy. Vendor-funded pilots are standard practice in this industry precisely because of the asymmetry above. Working out which budget a champion can actually reach — a manager's discretionary spend versus a capital committee — is half the strategy, and I treated it as an afterthought.

Survey before specifying. The whole bill of materials was gated on one nameplate reading. Doing the walkdown first would have either produced a real costing or revealed early that the mounting constraint made the numbers impossible.

What it was worth anyway

The design work stands, and the constraint analysis transferred directly. The same data path and drift logic were later applied to assets that were already instrumented, where no funding decision was required and no ownership question arose — which is how the two electrical case studies on this site exist at all.

That is the real conclusion. The escalator pilot failed because it needed permission, money and hardware. The work that shipped needed none of those, because the sensors were already there and the data was already being logged.

The most fundable monitoring project is the one that does not ask for a sensor. I learned that here, expensively in time and not at all in money.