Operational Data Fusion. Turning four siloed data streams into one decision surface.
Every operations team has the same five data systems and the same chronic complaint: they don't talk to each other. SCADA tells you what's happening. MES tells you what should be happening. CMMS tells you what's been done. ERP tells you what it costs. The weather feed tells you what's coming. The decision usually requires all five. The operator usually has access to one.
The five systems that almost never share
| System | What it knows | Why it doesn't share |
|---|---|---|
| SCADA | Real-time process state | Designed for the operator's eyes, not data export |
| Historian | Historical telemetry, archives | Query patterns optimized for time-series, not joins |
| MES | Production schedule, recipe, batch tracking | Different vendor, different schema, different team |
| CMMS | Work orders, maintenance history, parts inventory | Maintenance team's system; SCADA team rarely touches it |
| ERP | Cost accounting, raw materials, customer contracts | IT-owned; OT teams are walled off for security reasons |
Each system is well-designed for its own audience. The problem is that the operator standing in front of the abnormal-condition alarm needs context from all five at once.
What data fusion actually means
Operational data fusion is the architectural practice of bringing relevant context from multiple systems into a single decision surface — at the moment the decision needs to be made, without requiring the operator to log into four different applications.
Three layers of fusion, in increasing sophistication:
Layer 1: Reference-data fusion (the easy win)
Pull static reference data — equipment metadata, work-order history, design specifications, P&ID information — into the SCADA HMI so an operator looking at compressor 4-A immediately sees its model number, install date, last maintenance, current open work orders, and design pressure rating. Most modern SCADA platforms support this via tag metadata extensions.
Layer 2: Event-stream fusion (the harder win)
Combine event streams from multiple systems into a unified timeline. When an alarm fires on the SCADA, the operator sees correlated events from CMMS (recent work on this equipment), MES (current batch / recipe), ERP (downstream customer demand), and weather (incoming cold front affecting cooling-water temperature). Requires event-bus architecture — Kafka, EventBridge, or equivalent.
Layer 3: Inference fusion (the real value)
AI models that draw on data from all five systems to produce recommendations no single system could. "Compressor 4-A is showing bearing-distress signatures (SCADA), it's running a high-demand recipe (MES), bearing replacement parts are in stock at the regional warehouse (CMMS), the next maintenance window is in 12 hours (CMMS), and three downstream customer contracts will be in breach if you defer (ERP). Recommendation: plan controlled shutdown in 8 hours." This is where operational data fusion produces decisions that no human in any single system could make.
Why this is hard in practice
1. Vendor lock-in
Each of the five systems was sold by a different vendor with its own data model, its own API (or lack thereof), and its own posture on integration. Each vendor wants to be the integration hub. Without architectural discipline from the operator side, you end up with N-squared point-to-point integrations.
2. IT/OT cultural divide
ERP/CMMS live on the IT side of the network. SCADA/historian live on the OT side. The security boundary between them is intentional and important. Fusion requires well-architected pathways across that boundary, not flat connectivity.
3. Master-data hygiene
Equipment identifiers in SCADA ("CMP-4-A") rarely match equipment identifiers in CMMS ("EQ-2024-1837") which rarely match equipment identifiers in ERP ("ASSET-885120"). The first weeks of any fusion project are spent reconciling identifiers across systems. This is unglamorous and inevitable.
4. The cost of being wrong
A fusion-driven recommendation is only useful if it's correct. Bad context produces worse decisions than no context. Data quality at the source matters more than the sophistication of the fusion layer.
The reference architecture
- System-of-record-friendly extraction. Don't replace SCADA, MES, CMMS, ERP. Read from them in their preferred way (OPC UA from SCADA, REST API from CMMS, SOAP from ERP, whatever each supports natively).
- Unified event bus. Convert all the different system events into a common format, publish to a central event stream (Kafka, AWS Kinesis, Azure Event Hubs).
- Master-data resolution layer. Maintain explicit cross-system asset mappings. "Equipment X in SCADA = Equipment Y in CMMS = Asset Z in ERP." This is the most-overlooked-and-most-important piece.
- Fusion inference layer. The analytics / AI that consumes the unified stream and produces recommendations.
- Decision-surface delivery. Surface the recommendation where the operator already looks — usually the existing HMI, plus mobile.
The architectural commitment: the fusion layer is read-only from every source system. It never writes back. Each source system remains the authoritative system of record for its own data. The fusion layer adds a decision surface on top, not a replacement underneath.
How Aevus does fusion
Aevus is structurally a data-fusion platform. We read SCADA telemetry (via historian or OPC UA), CMMS work-order history (via REST API), MES batch context (via vendor API), ERP customer-contract impact (via reporting database), and external feeds (weather, carrier-network status, commodity pricing). We fuse these into the unified intelligence the operator sees in our recommendation surface.
We do not write to any of the source systems. The boundary is architecturally enforced via IL-9000 at the cloud-account level. Each customer's source-system data remains authoritative; Aevus is the intelligence layer above the fused stream.
Data fusion, done right.
If your operations team is staring at four browsers open to four different systems trying to make one decision, that's the gap we close.
Related Articles
Time-series databases, deadband compression, and query patterns.
Information models, certificate security, and when it's worth it.
Where AI earns its keep in the control room.
Ready to see how this applies to your operation? Start a pilot conversation — no commitment, no field changes.