Industrial AI does not fail because a factory lacks another dashboard. More often, it fails because the underlying production data has no consistent meaning.
A machine may report running, the operator may record waiting material, the MES may see no completed units, and the OEE system may classify the same period as an unplanned stop. All four records can be technically correct while still being useless for training a model.
This is becoming more relevant as industrial AI moves from demonstrations into normal manufacturing systems. At ENGINEER & MARVEX 2026 in Kuala Lumpur this week, Malaysian automation supplier Intellogic described its MACHHUB platform as infrastructure for organising factory data and deploying applications including AI. One cited automotive-parts implementation combined OEE and Andon data; the company reported that replacing manual records with real-time visibility helped the manufacturer identify losses and reduce downtime by at least 20%. That is a vendor-reported result, not an independent benchmark, but the architecture is familiar: useful analytics came after machine events were collected and classified properly.
At SMTA Penang on 23–24 September, ViTrox is showing AI-driven inspection, traceability and closed-loop manufacturing applications connected through its V-ONE manufacturing-intelligence platform. Singapore is moving in the same direction at a broader level. A*STAR and Microsoft announced an industrial-AI collaboration this year covering agentic manufacturing applications, engineering infrastructure and deployment, while A*STAR explicitly identifies data availability and standardisation as adoption problems.
None of this makes the old manufacturing-data problems disappear. AI simply makes bad definitions more expensive.
Start with events, not AI features
For an OEE or predictive-maintenance system, I would first ask whether the plant can reconstruct what happened to a machine yesterday without interviewing three people.
A useful event record normally needs more than a timestamp and one status bit. Depending on the process, it may need machine state, reason code, product or recipe, production order, good count, reject count, ideal cycle time, operator action, maintenance intervention and the source of each value.
The important part is ownership. A PLC is usually the best source for deterministic machine state. An MES or production system may own the work order. Quality may own accepted and rejected quantities. CMMS should own maintenance work. If each system independently invents its own version of the same event, analytics becomes reconciliation work.
This is also why simply sending every PLC tag to a data lake is not a data strategy. A historian full of signals can be very useful, but an AI model still needs context. Motor current rising from 18 A to 23 A means something different during acceleration, product changeover, idle running and steady production.
OEE definitions must survive contact with the factory
OEE looks simple:
OEE = Availability × Performance × Quality
The mathematics is not the difficult part. The definitions are.
| Data item | Typical ambiguity | What should be defined |
|---|---|---|
| Planned production time | Are breaks, cleaning and changeovers included? | Plant-wide calendar rules and approved exclusions |
| Downtime | Does a 20-second stop count? What about blocked/starved conditions? | State model, thresholds and reason hierarchy |
| Ideal cycle time | One value is often wrong across products and recipes | Product/recipe-specific engineering reference |
| Good count | PLC count, packing count and QA acceptance may differ | Authoritative count point and reconciliation rule |
| Rejects | Rework can be counted twice or disappear entirely | Quality-state transitions and final disposition |
| Changeover | Sometimes planned, sometimes treated as lost production | Consistent production and maintenance convention |
If these definitions change between lines or shifts, a machine-learning model can still produce a prediction. It just will not necessarily be predicting the thing management thinks it is predicting.
Downtime reason codes need engineering discipline
Most plants that have tried electronic downtime capture have seen the same failure mode: a long list of codes is created, operators choose the quickest one, and months later half the losses are classified as “Other”.
I prefer a short hierarchy with machine-detected states at the bottom and human-entered causes only where the control system cannot know the reason. For example, the PLC can normally determine faulted, blocked, starved, changeover mode or not enabled. The operator or maintenance technician can then add the cause: material shortage, upstream failure, tool wear, sensor fault, quality hold and so on.
Keep the original machine event as well as the later human classification. Do not overwrite history. If a maintenance engineer changes “unknown stop” to “photoelectric sensor contamination” two hours later, both the event and the correction are useful data.
Predictive maintenance needs operating context
This matters just as much for condition monitoring. A vibration spectrum without speed, load and machine state is often difficult to interpret. Temperature without ambient conditions or operating duty can be misleading. Current signature without process state can mix mechanical and production effects.
CANS works with condition monitoring and plant data systems, and the same rule applies whether the analysis is a threshold, FFT, statistical model or neural network: preserve the raw measurement, but attach enough operating context to make it comparable.
For rotating equipment I would normally want, where available, timestamp synchronisation, running state, rotational speed, load or process demand, product/recipe, recent maintenance activity and the sensor configuration alongside the vibration and temperature data. That is less glamorous than saying “AI predictive maintenance”, but it is what makes the analysis transferable from a demonstration to production.
Do not let the AI redefine the plant
AI can help classify downtime, detect anomalies and suggest probable causes. I would not let it silently rewrite the source taxonomy.
Keep an approved semantic layer between the physical plant and the models: equipment IDs, tag naming, machine states, reason-code definitions, units, sampling rules and ownership of production records. Model outputs can be added as another evidence layer. They should not quietly change the meaning of the underlying engineering data.
This becomes particularly important with agentic AI. An agent may eventually query OEE, inspect a maintenance history, compare alarms and open a CMMS work request automatically. That is useful only if “Line 2 filler unavailable” means the same thing in SCADA, MES, OEE and CMMS.
Our earlier article on AI agents and industrial control covered why general-purpose AI should not receive unrestricted PLC authority. The data side needs an equally clear boundary: AI may interpret data, but the plant still needs authoritative sources and controlled interfaces.
A practical data path
For many brownfield plants, I would not start by replacing controls that already work. Collect reliable machine events from the PLC, SCADA, drives, meters and instruments; normalise them at the edge or platform layer; attach production context from MES or ERP; and store both raw events and derived production states.
OEE monitoring can then sit on a defined production model rather than on ad-hoc spreadsheets. CansNEXUS and similar higher-level platforms can use the same governed data for OEE, MES, CMMS, predictive maintenance, optimisation and AI without every application rebuilding the machine model independently.
The architecture does not have to be elaborate. What matters is that one machine, one event and one production order have stable identities across the systems that use them.
For Malaysia and Singapore manufacturers
The current regional activity around smart manufacturing is useful because it shows that industrial AI is moving closer to ordinary production engineering. Malaysia has live examples this week around OEE, Andon, machine vision and manufacturing intelligence. Singapore is investing in manufacturing-specific AI platforms and deployment capability.
Factories do not need to wait for a perfect enterprise data model before starting. Pick one production line, define the states properly, automate the event capture, reconcile counts against a trusted source and run it long enough to expose the exceptions. Once the semantics are stable, AI has something worth learning from.
If the data cannot yet explain yesterday’s downtime, I would fix that before asking it to predict next month’s failure.
Discuss factory data, OEE or industrial AI with CANS
CANS integrates industrial automation and SCADA, machine connectivity, OEE, MES, condition monitoring, digitalisation and industrial AI for brownfield and new manufacturing systems.
Send CANS an enquiry or WhatsApp CANS.
References
- ENGINEER & MARVEX, 25 September 2026 — Turning Factory Data into Action at ENGINEER & MARVEX 2026.
- ViTrox, 18 September 2026 — AI-driven smart manufacturing and vision inspection at SMTA Penang 2026.
- Singapore EDB / A*STAR, 20 April 2026 — A*STAR and Microsoft manufacturing AI collaboration.
- A*STAR SIMTech — Industrial Artificial Intelligence in Manufacturing.
- Featured image: Shixart1985 / Wikimedia Commons, CC BY 2.0.
Recent Comments