Connecting OT signals without creating another dashboard

Most industrial AI projects solve the wrong problem: they build better visualisation on top of the same fragmented data. How evidence from MES, CMMS, quality systems, and PLCs becomes one investigation workspace instead of four more screens.

The starting point for almost every industrial AI project is data integration — connecting PLCs, historians, MES systems, and quality databases into a unified data layer. This is real, necessary work. It is also where most projects go wrong, not because they fail to connect the data, but because they optimize for the wrong outcome.

The dominant mental model for OT data integration is the dashboard: aggregate signals from multiple sources into a single display that lets operators and managers see more of the plant at once. A well-designed dashboard is genuinely useful for monitoring. The problem is that monitoring and investigation are different activities, and optimizing for one produces something poorly suited for the other.

Dashboard vs. investigation workspace

A dashboard aggregates signals for continuous monitoring. It is optimized for at-a-glance status: green/yellow/red, trend sparklines, KPI summaries. The relevant question it answers is 'what is happening right now across the plant.' It is designed for normal operations — for a trained operator scanning a 48-inch screen at a control station.

An investigation workspace links signals to incidents. It answers a different question: 'given that this machine just stopped, what is the full context of that event — the signal history, the related assets, the open work orders, the quality holds, the last process change.' The workspace is not a monitoring tool; it is a diagnostic tool, assembled on demand for a specific event, dissolving when the investigation closes.

These are not the same thing, and they are not produced by the same integration architecture. Dashboards need aggregation and display logic. Investigation workspaces need incident-scoped context assembly — the ability to answer 'what was the state of everything relevant to this machine in the 24 hours before this alarm fired.'

The four-screen problem

Many production facilities have 'solved' the unified view problem by putting four monitors at every engineering station — one for the SCADA/historian, one for the MES, one for the CMMS, one for the quality system. This is not integration. It is four independent systems displayed in proximity. The investigator still has to mentally join data from four different schemas, four different time bases, and four different event models.

Where context gets lost in the OT/IT stack

The typical OT/IT connectivity stack in a manufacturing facility looks like this: PLCs (Siemens S7, Allen-Bradley ControlLogix, Beckhoff TwinCAT) communicate via OPC-UA, OPC-DA, or Modbus to a SCADA layer. The SCADA layer feeds a historian — OSIsoft PI (now AVEVA PI), Ignition Historian, or Inductive Automation's equivalent — which stores the time-series record. The MES (SAP ME, Siemens Opcenter, Rockwell Plex) tracks production orders, genealogy, and OEE. The CMMS (SAP PM, IBM Maximo, Infor EAM) tracks maintenance work orders. The quality system (Q-DAS, Minitab, or a custom SPC implementation) tracks measurement results, holds, and NCRs.

At each handoff in this stack, context is lost. The historian stores tag values but not the process step they were recorded during. The MES tracks production orders but not the machine's signal state at the time. The CMMS records work orders but does not know the historian trend that was present when the work order was created. The quality system records the measurement result but not the machine parameter set that produced it.

Each system is internally coherent but contextually isolated. The information exists to answer the question 'was this machine running a deferred maintenance work order when the fault occurred' — but answering it requires a cross-system join that no existing interface performs automatically.

What integration means when the goal is investigation

When integration is designed for dashboarding, the primary concern is data connectivity and display normalization — getting tag values from OPC-UA into a rendering layer with consistent units and refresh rates. This is an engineering problem with well-established solutions.

When integration is designed for investigation, the primary concerns are different. The historian must be queryable by incident — not 'give me tag X from T1 to T2' but 'give me all tags for machine M-IMM-04, with their baseline deviations, for the 24-hour window ending at alarm time.' The CMMS must be queryable by machine and time — 'what open work orders existed on M-IMM-04 at alarm time.' The quality system must be queryable by machine and production window. The MES must contribute production order context: what product, what recipe, what lot, what shift.

This means integration needs a topology layer — a model of which tags belong to which machine, which machine belongs to which cell and line, which machines share utilities, which processes are upstream and downstream. OPC-UA provides a browsable node hierarchy, but the node hierarchy reflects the PLC program's structure, not the physical production topology. Building the topology layer is manual work, and it is the most time-consuming part of a real integration project.

Practical integration architecture for incident context

An integration architecture designed to support incident investigation rather than dashboarding has specific characteristics. First: a Unified Namespace (UNS) that maps raw OPC-UA tag paths to semantic identifiers — not 'ns=2;s=PLC1.M04.Zone3.ActTemp' but 'machine:M-IMM-04/process:barrel/zone:3/temperature/actual.' This normalization makes cross-machine and cross-site queries possible without site-specific query logic.

Second: baseline models for every process parameter on every relevant machine. Not just the alarm limit — typically set wide for operational tolerance — but the statistical operating range derived from normal production windows. Deviation detection relative to the machine's own baseline is far more sensitive than deviation relative to a generic alarm threshold.

Third: incident-scoped evidence windows. When an alarm fires, the system automatically assembles the historian context, CMMS context, quality context, and MES context for that machine and time window into a single structured object. This assembly happens before any human investigation begins — it is the starting state of the investigation, not something built during it.

Building this takes longer than building a dashboard. The payoff is that it stops generating a fifth screen and starts generating something that changes how investigations are conducted — and how long they take.