Use case · Predictive maintenance

Recognising drift before the breakdown.

Vibration, temperature and current draw tell the same story long before a machine stops — but only if someone reads them together and compares them with that machine's own history. Meddle does that, and does it without pretending it works on day one.

Motor M-04 · booster pumplast 6 weeks
Vibration RMS+34% vs baseline
Bearing temperature+7 °C
Average draw+4%
Running hours since last service3,180
StatusDrift confirmed on 3 signals
Which motors are drifting against their own history?
  • 3 signals
    drift is confirmed by crossing, not by one threshold
  • History
    compared against that machine, not a generic model
  • Honest
    prediction arrives when the data supports it, not before
The problem

Why maintenance stays reactive

  • A single threshold arrives late

    A temperature alarm fires when the damage is already underway. The useful signal is not crossing a threshold, it is the slope you climbed to reach it over the preceding weeks.

  • The data exists but never meets

    Vibration lives with the technician's handheld meter, temperature in the PLC, current draw in the drive. Three separate truths that nobody puts on one timeline.

  • The calendar doesn't know the machine

    Servicing by running hours treats a pump at constant load the same as one that starts and stops three hundred times a day. One gets opened too early, the other too late.

The method

Three steps, from threshold to drift

Put the signals on one timeline

Vibration, temperature, draw, pressure and running hours come from existing sources and are aligned per asset rather than per originating system.

Build the machine's own baseline

The reference is that asset's normal behaviour under its own load conditions, not a handbook figure. This is why history has to come before prediction.

Alert on slope, not on peak

The alert fires when several signals drift together and coherently, with a minimum duration and a cooldown that keep the noise out.

What you can ask

Plain-language questions, answers from your own plants

  • Which assets are degrading against their own history?
    The machines with drift confirmed across several signals, ranked by slope. It is the list this week's plan gets built from.
  • Has motor M-04 got worse since we changed the cycle?
    The period before against the period after the change, at equal load conditions, across all three signals together.
  • How many running hours does the pump have since its last service?
    The per-asset counter with service history beside it, so the calendar due date can be compared with actual condition.
  • What happened in the two hours before yesterday's stop?
    The window around the event with every signal for that asset overlaid. This is the analysis that usually reveals whether the failure was announced.
What it actually takes

The conditions that make a prediction honest

  • History before prediction. A model recognises drift because it has seen the machine healthy. Without a few months of data you can do anomaly detection, not prediction — and that distinction belongs before the pilot, not after it.
  • At least one failure to learn from. Remaining-life estimates become trustworthy once there is a real case to anchor them to. Until then the value is in the warning time, not in an exact date.
  • An action attached. An alert that never reaches the person who opens the machine changes nothing. Every alert carries the asset, the context and the suggested intervention, with override always available.

Let's start with the critical assets.

A guided pilot on five machines that have already stopped your production: collect the history, build the baseline, and see which drifts were readable in advance.

FAQ

Frequently asked questions

  • Do we need vibration sensors on every machine?

    No, and usually it is not worth it. You start from assets whose failure stops production, and on many of those current draw and temperature are already available from the drive or the PLC. A dedicated sensor is added where the failure mode genuinely requires it.

  • How much history is needed before a failure can be predicted?

    Anomaly detection needs a few weeks of normal operation. A remaining-life estimate needs months and at least one observed failure: before that, the system tells you something is changing without telling you when it will break.

  • How is this different from the alarms we already have?

    Existing alarms fire when a threshold is crossed — that is, once the problem is present. Here the alert comes from the slope of several signals compared with the asset's baseline, so it arrives while the problem is still forming.

  • How do you stop operators from ignoring the alerts?

    With a minimum duration and a cooldown on every rule, and with cross-confirmation between signals. A system that notifies too often gets silenced within two weeks, and at that point it is worse than not having it.

  • Does it work on old machines with no modern electronics?

    Often yes, by measuring upstream: motor draw read at the switchboard says a great deal about bearings, transmission and load. Where more is needed a sensor is added — but one asset at a time, and for a reason.

Let's see whether your last breakdowns were readable in advance.

In a guided demo we start from your critical assets and your own history, not from an example.

Book a demo