Why mining operations are still flying blind, even after fixing their connectivity problem
It is 2:47am. A SAG mill bearing is running hot. The vibration sensor, a modern IIoT device, has been flagging elevated readings for six hours. The PLC controlling the mill logged a thermal warning at 1:15am. The SCADA historian recorded it four seconds later. The maintenance management system received nothing. By 6am, the bearing seizes. The mill stops. Eight hours of unplanned downtime follow.
Here is the uncomfortable detail: this operation had already solved its connectivity problem. Kepware was running on the plant floor, bridging Modbus, OPC-UA, and Profibus into a single data stream. Every system was talking. The data was flowing. It just wasn't understood.
The Problem the Industry Has Solved, And the One It Hasn't
Over the past decade, the mining and heavy industrial sectors have made real progress on what we might call protocol harmonisation; the engineering challenge of making equipment that speaks different languages communicate with each other.
Tools like Kepware, Ignition, and a mature open-source ecosystem of protocol bridges have largely solved this problem. A Modbus PLC, an OPC-UA analyser, a CAN bus haul truck, and an MQTT-enabled IoT sensor can now be coaxed into feeding data into a common stream. It took years, it required specialist automation engineers, and for many operations it is still a work in progress, but the tools exist, the expertise exists, and the path is well understood.
This is a genuine achievement. However, it only solves an engineering problem, not an operational one.
Because when the data arrives, even unified, flowing, timestamped, but it is still raw telemetry. Tag names that mean something to the PLC programmer who created them fifteen years ago and nothing to anyone else. Values with no operational context. Streams with no understanding of what the equipment is, how it behaves, what failure looks like, or what any given reading means for the health of the asset or the quality of the ore.
Protocol harmonisation makes the data available, but does not make the data meaningful as business or operational intelligence.
That gap between data that flows and data that thinks is what we call the intelligence harmonisation problem. In our experience working with mining operations, this gap is far more consequential than the connectivity problem it follows.
What Intelligence Harmonisation Actually Means
Consider what happens to raw telemetry after it leaves the PLC and arrives in a unified data stream. A Modbus register labelled AI_032 changes value from 847 to 923. Protocol harmonisation has successfully delivered that reading to your data historian.
But what does it mean?
Without an intelligence layer, nothing. With one, it means the bearing temperature on the primary crusher's main drive motor has risen 76 degrees in four hours, a pattern that, when correlated with a simultaneous 12% increase in power draw and a marginal drop in vibration frequency, matches the thermal runaway signature that precedes a bearing failure with 94% historical accuracy.
The difference between those two outcomes is not connectivity. It is context. It is the semantic layer that knows what AI_032 is, what equipment it belongs to, how that equipment behaves under normal operating conditions, what deviations are meaningful, and how this reading relates to every other reading across the plant at this moment. This is what intelligence harmonisation provides, and it requires something that no protocol bridge, however sophisticated, can supply: domain knowledge encoded into the data layer itself.
Why This Problem Is Harder Than the Protocol Problem
Protocol harmonisation, for all its complexity, is ultimately a deterministic engineering problem. Given enough time, budget, and specialist knowledge, any two systems that generate data can be made to communicate. The rules are fixed. The protocols are documented. The solution, once implemented, does not require ongoing domain expertise to maintain.
Intelligence harmonisation is a different class of problem entirely, for three reasons.
First, it requires mining-specific knowledge that cannot be generalised. The semantic meaning of a temperature reading on a SAG mill gearbox is not the same as the semantic meaning of the same reading on a flotation cell agitator. The failure modes are different. The criticality thresholds are different. The downstream consequences are different. An intelligence layer that does not encode these distinctions is not useful. Encoding these requires people who have worked in mining, not just people who have worked in software.
Second, it requires understanding relationships, not just values. The most valuable insights in a processing plant come not from individual sensor readings but from correlations across unit operations — crusher throughput affecting mill feed particle size affecting flotation recovery affecting concentrate grade. These relationships are not visible in any single data stream. They emerge only when data from across the plant is interpreted together, in context, with an understanding of the physical and chemical processes connecting each unit operation.
Third, it requires an operational ontology — a structured model of what everything is, how it relates to everything else, and what matters. Without this, even a perfectly clean, unified data stream is just a large collection of numbers. The ontology is what transforms numbers into knowledge: this asset, at this location, in this process, with this function, exhibiting this behaviour, with these consequences if it fails. Building that ontology for a mining operation is not a software problem. It is a knowledge engineering problem. It is a problem that no generic middleware vendor, however well-funded, has solved for the mining industry.
The Stack And Where the Value Actually Lives
It is worth being explicit about where protocol harmonisation ends and intelligence harmonisation begins, because the two are often conflated in vendor conversations.
The protocol harmonisation layer, largely solved by existing tools, sits at the bottom. The decisions and automation that mining operators ultimately want sit at the top. The intelligence harmonisation layer sits in between, and it is the critical missing piece that prevents the bottom layer from delivering the outcomes at the top.
This is important because it reframes the conversation about where investment should go. Most operations that have already deployed Kepware or a similar connectivity solution have spent significant budget and engineering effort on the protocol layer, and then found themselves stuck. The data flows, but the insights do not follow automatically. The instinct is often to buy more tooling at the protocol layer, or to invest in a cloud analytics platform that turns out to require the clean, contextualised data it was supposed to help create.
The actual investment required is in the intelligence layer, and that investment pays returns across every use case simultaneously, because everything built above it inherits its context.
What Becomes Possible With Intelligence Harmonisation in Place
The use cases that unlock when the intelligence layer exists are not incremental improvements on what was possible before.
They are categorically different.
Predictive maintenance becomes genuinely predictive. Not "this sensor value exceeded a threshold" — every SCADA system can do that, but "this combination of readings across these five assets matches a failure pattern that has historically preceded an unplanned stop with 90% accuracy, and the predicted time to failure is 68 hours." That distinction is the difference between an alarm and an insight.
Process optimisation becomes continuous and autonomous. When the intelligence layer understands the relationships between unit operations — how ore hardness affects crusher throughput affects mill power draw affects flotation recovery — it can identify optimisation opportunities in real time and either recommend actions to operators or, where appropriate, execute them automatically through closed-loop control.
Natural language becomes a valid interface for operational data. When the data has meaning — when every reading is tagged with equipment identity, process context, and operational significance — a metallurgist can ask "why did recovery drop on the afternoon shift last Thursday" and receive a coherent, evidence-based answer drawn from across the plant's data history. Without the intelligence layer, that question requires a data analyst, three spreadsheet exports, and two days.
Autonomous systems get a brain, not just eyes. Every autonomous mining system — drill automation, autonomous haulage, closed-loop process control — currently depends on either heavily engineered rule sets or narrow machine learning models trained on limited datasets. An intelligence layer that provides rich operational context to these systems dramatically expands what they can reason about and act on safely.
The Path Forward: Building on What You Have
The practical implication of this framing is encouraging for operations that have already invested in protocol harmonisation: you do not need to start over. The connectivity layer you have built is a genuine asset, and intelligence harmonisation builds on top of it rather than replacing it.
For operations that have not yet solved connectivity, the order of operations is clear: establish a unified, timestamped data stream first using whatever combination of Kepware, Ignition, Node-RED, or custom integration work fits your environment and then build the intelligence layer above it.
For operations at either stage, the starting point is the same: a clear-eyed assessment of what data you have, what it currently means to your systems, and what it would need to mean to deliver the operational outcomes you are trying to achieve.
That gap between what the data says and what you need it to mean is the intelligence harmonisation gap. And closing it is, in our experience, the single highest-return investment a mining operation can make in its data infrastructure.
Conclusion
The mining industry has done hard, expensive, necessary work to solve the protocol problem. Equipment that once refused to communicate now shares data across a common stream. That work deserves credit and it is not wasted.
But it has also, in many operations, created a false expectation: that connected data is the same as intelligent data. It is not.
Protocol harmonisation makes your plant floor speak one language. Intelligence harmonisation makes it say something worth hearing.
The tools and the expertise to build the intelligence layer now exist. The operations that invest in it first will not just have better data — they will have a compounding operational advantage that grows with every asset added, every failure pattern learned, and every process relationship encoded into the semantic layer.
The connectivity problem is largely solved. The intelligence problem is wide open.
Ready to harmonise your data and start building your intelligence layer?
We run free Data Readiness Assessments for mining operations who want to understand what's possible. Send us a sample of your site data and we'll show you specifically which assets are candidates for predictive maintenance, where your data gaps are, and what ROI is realistic for your operation.
Contact us today to schedule a demo or discuss a pilot project.
