Scattered data into
one body of knowledge

Most industrial sites already produce vast amounts of data. Sensors on equipment leave readings by the second, SCADA records the state of the grid, and MES and ERP accumulate the flow of production and materials. Add documents such as inspection reports, work orders and equipment manuals, and the volume of data is never the shortfall.

Even so, at the moment a judgment is needed, this data goes unused. Values sit scattered across systems, and even the name for the same piece of equipment differs from system to system. When an anomaly is detected, checking its cause means moving between screens and piecing the data together in one’s head.

“Data integration” usually brings to mind gathering several sources into one store. That is, moving values with ETL and putting them side by side on a dashboard. That work is needed, but on its own it is not integration.

Even with values from different systems on one screen, if the machine does not know what those values are about or how they relate, a person still has to interpret them. Putting a vibration graph next to a temperature graph and having the system understand that “this temperature and that vibration are signals from the same pump, and this pump belongs to that line” are altogether different levels.

The first has gathered data and the second has connected it. Automating judgment calls for the second.

An ontology is a structure that defines what data is about. It defines equipment, lines, processes and documents as objects, and describes the relations between them (containment, connection, sequence). It is the work of attaching to every scattered number and record the meaning of “what is this data about.”

Once meaning is attached, data is no longer a value inside an individual system but one body of knowledge. When a sensor reading jumps, the system can follow on its own which equipment that sensor belongs to, which process that equipment sits in, and what inspection history it has had recently.

Integration starts from a different place at every site. Some have run SCADA, MES and ERP for years, while others are only beginning to collect data. A way of integrating has to carry both cases.

Layering onto what you have

Where a system is already in place, it is not torn out. Replacing an existing SCADA, MES or ERP costs a great deal and carries a high risk of failure. Instead a unified intelligence layer goes on top of it and integrates in both directions. The existing systems keep running, and a layer that adds meaning to their data and helps with judgment is laid over them.

Building new where none exists

Where systems are not in place, building from the data collection stage up is in fact the cleaner route. With no legacy to fit around, the data structure can be designed with the ontology in mind from the start.

What matters is not the method but whether, either way, the result comes together as one body of knowledge.

Industrial data brings sensor time series to mind first. But much of the information a judgment needs sits outside the time series, such as the specification of a piece of equipment, what was replaced at the last inspection, or which conditions a work order set out.

Integration that stays with the time series can draw graphs but cannot answer “why.” Only when time series, equipment information, documents and work history are tied together on an ontology can a single signal be read alongside its several contexts.

And once data of this range runs through one structure, a single platform gives rise naturally to uses that cross industries, such as predictive maintenance, quality, energy, safety and administration.

The result of integration done well is not more dashboards. It is data you can decide with right away. When something goes wrong, the related equipment, history and documents are already connected, so following the cause takes no moving between screens.

Once things stand this way, AI can be set on top. Working from data that carries meaning, an AI agent answers questions, infers causes and suggests the next action. Integration is not an end in itself but the ground that lets AI help you decide with the evidence shown.

Rather than drawing company-wide integration in one go, it is more realistic to start at a single point where judgment is often needed.

• Find the judgment people currently piece together by moving between screens.
• Set out where the data that judgment needs is scattered, and what the same thing is called.
• Draw those things as objects and relations, and stand up a small ontology first.
• Layer onto the existing system, or build from collection up where there is none, and widen the scope from there.