Predictive maintenance is not about the machine

The starting error in predictive maintenance

The way predictive maintenance is designed, and sold, puts the machine at the centre. Instrument the asset, learn what its sensors look like when healthy, and sound the alarm when they drift. When context appears, it is treated as noise to remove or ‘normalise’. I think that order is wrong. Context comes first; only then can sensor data be read in its light.

A machine does not fail in a vacuum. It fails inside a factory, a production schedule and a history.

Ignoring context costs twice: missed failures and false alarms

Judge a machine without knowing what it is doing and you pay twice.

First, in missed failures. A baseline built without context must contain every product, season and restart. It becomes so broad that a real fault stays inside it until the end. A seal can leak for weeks without leaving the machine-wide band while clearly breaking the band for the product currently in the mould.

Then, in false alarms. If products are few and very different, the minority product remains outside the band forever. Every run creates alerts on a healthy press. The technician learns to ignore them, including the day one is real.

Lower the threshold and multiply false alarms. Raise it and hide failures. A context-free system has no setting that solves both. This is not a calibration problem. It is structural.

The gain does not come from a better AI algorithm

Here is what no brochure will tell you.

When a system stops crying wolf, credit usually goes to a smarter, deeper, more ‘AI’ model. Yet hold the detector still and change only the reference used to judge each reading, and the difference is enormous. Learned models improve too when given context.

The gain is not in the detector. It is in what the detector knows about the machine.

A system monitoring machine health without factory context is using the wrong reference, however sophisticated the algorithm above it.

What context means in predictive maintenance

Context has two levels: who this machine is, and what is happening around it.

• Its DNA. Two machines of the same model fail differently. Each has its own settings, wear, weak points and intervention history.
• What it is producing. Product, mould, compound and cycle time. One signal can be normal for one product and anomalous for another.
• How it is used. Shifts, load, stops and restarts. Stress depends on how much and how it works.
• The environment. Plant temperature and season. Many deviations follow the environment, not the machine.
• The factory around it. Orders, stock, planned maintenance and upstream and downstream operations. These do not decide whether a fault exists, but they decide when a stop costs most and when intervention makes sense.

In almost every factory, all of this already exists in production records. It simply lives in production systems while maintenance looks elsewhere.

Onboarding is not a cost. It is the science.

Most predictive maintenance projects treat onboarding—connecting the plant, understanding data and tuning thresholds—as a service cost to minimise before the ‘real’ model starts.

For Atherya, the opposite is true. Onboarding builds context, and prediction cannot hold without it. That is where the value is.

Atherya onboarding is a method with precise rules.

• Read only. We read customer data and never write into their systems.
• No questionnaires. History answers first. We ask only what data cannot say, and each answer remains recorded as confirmed knowledge with its source.
• Robust statistics throughout. Past failures must not widen the bands used to judge the next one.
• One codebase. The Lab verifies signatures with the same engine that later judges live factory readings. If something is wrong, we see it before the customer does.

The right normal, in order

For every reading, Atherya searches for the most informed available reference in this order:

• If the value is a set parameter, such as curing time, it is not judged as drift. It is checked against legitimate settings.
• If the product is known and season matters, use that product’s normal for that month.
• If the product is known, use its band.
• If the product has never been seen, invent nothing. Use the union of known product bands. A value between two modes, where the machine never operates, is outside even if one broad band calls it healthy.
• Separate seasons only where data shows they truly shift normal behaviour. The algorithm decides case by case and creates no unnecessary split.
• The machine-wide band is the last resort. If the machine has multiple modes, use it for observation, never for alarms.

What a real factory taught us

During onboarding at a real plant, the difficult part was not noticing that a value moved. It was understanding what the movement meant.

• An ERP change altered the meaning of some press fields. Without that fact, every press would have appeared to drift in the same month. The customer confirmed it and the older data was excluded.
• Parameters disguised as sensors. A column that looked like a measurement was actually a temperature setpoint. Treating it as a sensor would have raised alerts at every setting change.
• The same zeros, the opposite conclusion. An early pass called some mixer sensors dead because they read almost zero. In fact, the stopped machine kept recording while waiting. Its signatures are now learned only while it runs. The data did not change; context decided what it meant.
• Impossible values. Curing times too short for any rubber appeared across machines and products. Before building a quality alarm, the Lab checks whether they are aborted cycles recorded as complete. If so, a hundred quality questions become one precise data-acquisition question.
• Normals no generic threshold could contain. A cryogenic deflashing machine operates at temperatures where any standard threshold would declare disaster.

Anomaly detection: honesty as a method

There is one final difference, perhaps the most important.

Predictive maintenance is full of beautiful numbers: every fault caught, far in advance. Up close, many are detector tests on constructed scenarios lasting minutes, on one machine, without products, seasons or a factory. They are useful software checks. They are not failure predictions.

We chose not to use them that way. Before examining a single real fault, we wrote how it would be measured: data, models and metrics. Compare false alarms at the same number of caught failures, because that is where a system survives or dies on the shop floor. A system catching the same failures while crying wolf far less often is a different product.

Predict the factory

The first months of a predictive maintenance project should not be spent tuning thresholds. They should be spent building context.

Read the history. Learn every machine’s DNA. Connect the factory. Ask the customer only what the data cannot say.

That is what Atherya does.

A machine never fails alone. It fails while making a product, on a shift, in a season, after a stop, inside a factory.

Predict the factory, and you will predict the machine.