Before Predictive Maintenance, We Had to Make the Plant Observable

Project Status : Discovery / design Phase

The team was exploring OEE, equipment health and predictive maintenance. During discovery, a more basic constraint surfaced: critical operating signals were fragmented across equipment interfaces and manual checks.

Generators had controllers. Chillers had their own monitoring environment. Other utilities exposed operating parameters through their equipment interfaces. Maintenance history existed elsewhere.

The problem became obvious only when we followed how that information actually moved through the plant.

Technicians were still making physical inspection rounds. Equipment readings were being checked locally. Findings travelled through calls and WhatsApp. Several monitoring systems existed, but separately. There was no single operating view from which the maintenance team could see the state of the utility estate.

This mattered because the conversation had initially extended much further: OEE, predictive maintenance, AI, energy optimisation, equipment health.

All legitimate possibilities.

But the plant visit exposed a dependency underneath all of them.

Before we could ask what is likely to fail, we needed to establish what is happening now.

The information existed. The operating state did not.

There is an easy mistake to make when assessing industrial data readiness.

You ask whether the equipment produces data.

The answer is yes.

So the operation appears ready for analytics.

That test turned out to be too shallow.

At this facility, several critical utility systems already produced useful signals. The issue was that those signals lived in different places and required people to go looking for them.

The maintenance process depended partly on scheduled inspection rounds. Different OEM systems provided their own views. Observations and anomalies travelled back through messaging and phone calls. The maintenance manager remained an important human aggregation point.

The machinery was producing information.

The operation still depended on people to assemble the picture.

That distinction changed the project.

The first phase was deliberately narrowed away from predictive models and advanced AI. The immediate scope became much less fashionable: identify the relevant assets, understand their controllers and communication protocols, connect them reliably, validate the readings and provide the maintenance team with one operational view.

Predictive maintenance was moved to a later phase.

Not because prediction had become unimportant.

Because prediction had dependencies.

You Can't Calculate Availability If You Don't Know Machine State

A second observation came from the production environment.

The customer described a simple situation: one machine could stop while other machines kept running. Production continued, but the lost capacity of that individual machine was not necessarily being captured centrally.

That creates an awkward problem for OEE.

Overall Equipment Effectiveness sounds like a calculation problem. Availability, performance and quality go into the equation.

But availability requires reliable knowledge of machine state.

When did the machine stop?

For how long?

Was it producing, waiting, blocked, under maintenance or operating below expected output?

If the underlying system cannot answer those questions consistently, calculating OEE more elegantly does not improve the truth underneath it.

The discussion therefore moved one layer down.

Instrumentation first.

Then history.

Then operating-state logic.

Then OEE.

Then, where the data justified it, prediction.

That sequence looks obvious afterwards. It was not where the conversation started.

Connect the Machines, Became Ten Questions Per Machine

Once connectivity became the first problem, the work changed character.

Connect the machines sounds simple when written inside a box on an architecture diagram.

On the floor, it becomes a list of questions.

1. Which controller does this asset use?
2. Does it expose Ethernet?
3. Modbus RTU or TCP?
4. BACnet?
5. Is the register map available?
6. Who owns the PLC configuration?
7. Can the machine be connected directly, or does it need a protocol converter?
8. What happens with equipment where the native interface is unavailable?
9. Which part of the plant network can the device communicate with?
10. How will the displayed reading be validated against the physical equipment?

The Phase-1 technical design eventually reflected that reality. Asset discovery had to capture manufacturer, model, controller, communication protocol and integration readiness before the digital gateway could be configured. The project also required validation that values shown centrally matched the parameters observed on the actual equipment.

This is the point where industrial digitalisation stops being a slide.

The difficult part is often not moving data once it reaches a modern platform. The difficult part is establishing a dependable path from equipment built by different manufacturers, at different times, with different interfaces, into a common operational context.

Some Problems Needed Detection, Not Prediction

Another useful decision followed. The first operational alerts did not need machine learning.

They could be deterministic.

If an operating parameter moved outside an agreed range, the system could identify the breach and surface it.

There was no reason to wait for months of historical data simply to automate something the maintenance team already understood as a rule.

That distinction matters.

Some industrial conditions require prediction because the deterioration pattern is difficult to see directly.

Others require reliable detection because the condition is already understood; the operation simply learns about it too late.

Those are different engineering problems.

Using machine learning for both can add complexity without adding much intelligence.

The first phase therefore separated them: continuous acquisition and rule-based operating alerts first; predictive models later, once the data foundation existed.

A Dashboard Would Have Solved the Wrong Problem

Centralizing the readings could easily have become another dashboard project.

That would miss what the site visit showed.

The real change was intended to be in the maintenance loop.

Previously, someone had to inspect equipment, record or photograph what they saw, send it onwards, and wait for the information to reach the person able to interpret it.

A connected system shortens that chain.

But even that is only the beginning.

Once reliable state exists, the operation can start asking better questions:

Which deviations matter?

Which require immediate intervention?

Which can wait until the next maintenance window?

When should an alert create work automatically?

When should spare-parts availability affect the maintenance decision?

Which patterns justify moving from deterministic rules to a predictive model?

Those are decision problems.

Without the underlying operational data, they remain theoretical.

The Human Aggregation Layer

One thing became increasingly visible during discovery: the maintenance manager was effectively functioning as an integration layer.

Equipment systems produced readings. Technicians performed inspections. Observations moved through messaging and calls. Maintenance history sat somewhere else.

The operating picture existed because experienced people knew how to assemble it. That works until scale, absence, shift changes or response time expose the dependency.

One purpose of making the plant observable is not to replace that expertise. It is to stop requiring experienced people to spend their time collecting the information before they can apply it.

What we would investigate first next time?

Industrial AI programmes are often framed from the top down.

1. Predict the failure.
2. Optimise the asset.
3. Build the digital twin.
4. Automate the maintenance decision.

Our work at this plant moved in the opposite direction.

1. Start with the equipment.
2. Determine what signals actually exist.
3. Find out whether those signals can leave the machine.
4. Check whether they can be trusted.
5. Establish whether the operation has a reliable history of state changes.

Only then decide what deserves prediction.

That does not make the ambition smaller. It makes the sequence more defensible.

A plant can have modern equipment, maintenance software, dashboards and years of operating expertise and still have gaps in the basic chain between physical state and digital state.

Those gaps matter more as systems become autonomous.

A human engineer can notice that a sensor value looks wrong, walk to the equipment and investigate. A predictive model will treat the value it receives as evidence.

An automated workflow may act on it.The further an operation moves from dashboards towards automated decisions, the more important the reliability of that first signal becomes.

So before beginning the next predictive-maintenance programme, we would start with a less ambitious question:

Can the operation reliably tell us what every critical asset is doing now, without asking someone to walk over and check?

If the answer is no, that is probably where the engineering starts.