Start by Admitting What You Can't Predict Yet

The honest answer to “can we do predictive maintenance?” is usually: not yet, and not in the way you mean. What you can almost certainly do is condition monitoring — and in most plants that captures the bulk of the available value at a fraction of the cost. That is not a consolation prize. It is the correct first step, and skipping it is the single best predictor of a project that ends as a dashboard nobody opens.

The confusion is definitional, and it is expensive. “Predictive maintenance” gets used for three different things with wildly different data appetites: knowing a machine is outside its safe operating envelope right now, knowing it is behaving unlike itself, and knowing it will fail in roughly N days. Only the third is prediction. Only the third needs labelled failures. The first needs a sensor and a number. Of the use cases that forecast and flag, this is the hungriest.

The sentence that decides your project. If you cannot name the specific failure mode you are predicting and point to a couple of dozen past instances of it in your data, you are not doing prediction. You are doing condition monitoring or anomaly detection — which is fine, as long as you scope it, price it, and staff it as that.

Three Rungs: Monitoring, Anomalies, Prediction

These get sold as one product. They are three separate engineering problems with three separate data bills, and you climb them in order whether you planned to or not.

Condition monitoring no model at all needs: a threshold “over limit now” Anomaly detection unsupervised ML needs: months of normal “not like usual” Failure prediction supervised ML needs: labelled failures “~3 weeks left” each rung costs more data than the last — and most value sits on the first
Three different problems, routinely sold as one. What separates them is not model sophistication — it is what the data has to contain before you start.

Condition monitoring — the rung most people skip

You measure something that correlates with health — vibration velocity, bearing temperature, motor current, oil particle count — and you alarm when it leaves a band. There is no model. Often there is no machine learning anywhere in it. For rotating equipment, ISO 20816 (which superseded ISO 10816) already hands you broad-band vibration severity zones by machine class; the “algorithm” is a table other people validated over decades. That is a feature, not an embarrassment. It is explainable, it is defensible to an auditor, and it works on day one instead of after a year of data collection.

The reason to start here is not only cost. It is that condition monitoring forces you to solve the problems that would have killed the ML project anyway: getting data off the PLC, timestamping it consistently, deciding who gets called when the alarm fires, and discovering that it fires eleven times a shift because nobody accounted for the machine warming up after the weekend. Solve those with a threshold, and the model — if you still want one — has somewhere to live.

Anomaly detection — useful, and routinely oversold

Anomaly detection needs no labelled failures at all. Feed it a few months of normal operation and an isolation forest or an autoencoder learns the shape of “usual,” then flags departures from it. This is genuinely useful, and it is where most of the honest machine learning value in a plant actually sits.

But be precise about what it tells you: that something changed. Not what changed, not whether it matters, not when it will bite. It will flag the new operator, the new batch of raw material, the recipe change, and the afternoon the hall hit 34 °C — all real anomalies, none of them faults. Without operating context fed in alongside the sensor stream (which product, which load, which shift), you have built an expensive change detector.

The failure mode here is social, not technical. An alarm with no prescribed response gets ignored, then muted, then deleted. Before anyone tunes a threshold, answer this: when it fires, who looks, and what are they authorised to do about it? If the answer is “we'd have a look,” the project is already dead — it just doesn't know yet.

The question that kills more of these projects than any model does. Not “how accurate is it?” but “what changes when it fires?” If the answer is not a specific action by a specific person with the authority to stop a machine, you are building an alarm nobody will answer.

Prediction — what it actually demands

Real prediction — remaining useful life, “this spindle has about three weeks” — is supervised learning. It needs runs-to-failure: sensor history leading up to a failure, labelled with that failure, repeated often enough that the pattern separates from noise. How many is enough depends on how consistent the failure mode is, but one is not a number and three is not either.

And here is the trap that quietly halves everyone's data twice over: it has to be per failure mode. A pump fails from bearing wear, from seal wear, from cavitation, and from impeller erosion. Those look nothing alike in the data and are four separate prediction problems. Twenty pump failures split across four modes is five examples each. Your twenty evaporate the moment you segment them honestly.

Why Labelled Failures Are the Blocker in Predictive Maintenance

Here is the uncomfortable arithmetic. A Zulieferer running 40 CNC machines on a decent maintenance regime might see a handful of unplanned spindle failures a year. Across three years of retained data that is maybe a dozen events, spread over several machine types and several failure modes. No model learns a reliable pattern from that, and no amount of feature engineering rescues it. Which produces the sentence nobody in the sales meeting says out loud: your good maintenance record is exactly what makes prediction statistically impossible. The plants with enough failure data to learn from are the plants that should go fix their maintenance first.

That has a structural consequence worth more than any modelling advice: predictive maintenance is a fleet problem, not a machine problem. If you operate 40 machines you may never accumulate the failures. If you build 800 and they run at customers' sites, you have 800 machines' worth of failure events on one design with one instrumentation package, and the economics invert. This is why the companies for whom this genuinely works are more often machine builders selling it as a service than the plants buying it. If you are a Maschinenbauer weighing whether to instrument your installed base, that is a far better-founded project than the identical effort inside one factory — and if you are the factory, the honest move may be to ask your supplier for it rather than build it.

Even where the failures exist, the labels are worse than you think. They live in your CMMS — SAP PM, Maximo, or a shared spreadsheet — and the timestamp on a work order is when a technician closed the ticket, not when the machine began to degrade. The failure mode is free text: “Lager getauscht.” A usable label set means someone who knows these machines reconstructing, event by event, what actually happened and when. Budget for that person by name. That reconstruction is the project — the same unglamorous work that getting any data ready for AI always turns out to be.

Your Sensor Data Is Thinner Than You Think

Two things go wrong before anyone writes a line of model code, and both are irreversible.

Sampling rate. A rolling-element bearing announces itself at its defect frequencies and their harmonics — hundreds of hertz to several kilohertz. Nyquist says you must sample above twice the highest frequency you care about, and envelope analysis wants considerably more headroom than that. Your PLC logs the drive temperature every five seconds as an average. The signature you need was never sampled. You cannot filter it back in, you cannot interpolate it back in, and no model recovers it. If the answer requires vibration at kHz, the honest reply is “we install accelerometers and come back in a year,” not “let's try it on what we have.”

Retention. Everyone says they have ten years of data. Almost nobody does. Historians and SCADA systems — AVEVA PI, InfluxDB, whatever came with the line — typically keep full resolution for 30 to 90 days, then roll up to hourly or daily aggregates to save disk. Ten years of hourly means is ten years of nothing here: the transient you are hunting is inside the average, gone. Someone should log into the historian and read the retention policy before anyone writes a proposal. It is a fifteen-minute question that has ended more of these projects than any technical review, and better asked now than three weeks into a pilot.

A third, quieter one: the data has to be joinable. Sensor stream in the historian, work orders in SAP, production schedule elsewhere, all on different clocks. Getting from OPC UA on the machine to a table where one row is one machine-hour with the load, the product, and whether a failure followed — that integration is most of the work, and the part that never appears in a demo.

What I Would Not Build

I would not fit a remaining-useful-life model on fewer than a couple of dozen clean examples of one failure mode. Not because it cannot be fit — it can, and it will look magnificent on your training data — but because you would ship a number whose confidence interval you cannot honestly compute, and someone will schedule real downtime against it.

I would not instrument everything. Pick the machine where an hour of downtime costs money someone can name, and where the failure mode is known and recurring. If nobody can tell you what an hour on that line costs, you do not have a business case; you have an interest.

And I would not put a model in the safety loop casually. A maintenance advisory that ranks machines by risk is, in EU AI Act terms, unremarkable. An AI component that autonomously trips a machine as a safety function is a different animal: as a safety component of machinery under the Machinery Regulation (EU) 2023/1230, it can land in the high-risk category, with the conformity assessment that implies. Keep the model advisory and the interlock classical, and the question does not arise. That is not a legal opinion — it is a design choice that saves you needing one.

Where Tippel Fits

The useful first engagement here is not a model. It is a structured pass through your historian, your CMMS, and an hour with the person who actually knows the machines, answering four questions: what is the failure mode, how many labelled instances of it exist, what is retained and at what resolution, and what changes when an alarm fires. That is the AI Readiness Check pointed at a plant floor — fixed price, timeboxed, ending in a go/no-go. Sometimes the verdict is “build the prediction.” More often it is “condition monitoring this year, start sampling properly, revisit prediction in two years when you have something to learn from” — cheaper to hear now than to discover later.

It also tends to end with a design where the data stays where it is. Sensor streams and work orders are production data; the model can run on a box inside your own network, which is usually an easier conversation internally than shipping machine telemetry to someone else's cloud tenant. If you want to find out which rung you are actually standing on, get in touch.