To Connect or Not to Connect Is the Question
A report on matching a unified IT/OT platform to four very different mining data architectures
Every platform decision looks binary from a distance: adopt it or don’t. Up close, on an engagement spanning four workstreams across three mining sites, the honest answer was neither yes nor no. It was “it depends on which site, which system, and whether the rework is worth what it buys you.” This article walks through that engagement: what AVEVA CONNECT was expected to do for a multi-site mining operation, where it was technically capable, and where, even when it was technically capable, the logical recommendation was no. The key being that a platform can be technically able to do something, but that something may not be worth the effort and spend required to implement it. Of the four workstreams evaluated, CONNECT was recommended for exactly one.
The Setup
The client operates three mine sites worldwide. In addition to those three sites, we also evaluated an enterprise digital initiative called ATLAS, which ran parallel to the site-by-site reporting work. For this article, site names and company identity have been fictionalized; we’ll refer to the three sites as Site A, Site B, and Site C. Across all three, the reporting goal was the same: unify plant-side time-series data with mine-side relational SQL data, in one platform, queryable side by side, and well-structured enough to feed downstream reporting cleanly. ATLAS had a narrower, more concretely scoped goal: to get operating-hours and equipment-condition data flowing automatically into the client’s maintenance system to enable condition-based maintenance. This would replace their less efficient, calendar-based manual maintenance program. A future roadmap item would include predictive analytics. Two systems dominate the source landscape everywhere:
- PI Historian: every site runs its own instance, all on the 2024 R2 release for time-series plant data.
- A relational SQL database fed by more than one mine operation, including vendors like Caterpillar MineStar, Surface Manager, Acquire, TerraTrack, Minesight, and Nomadis, depending on the site, for mine operations data.
At Site A, the split was roughly 60% relational mine data to 40% time-series plant data. However, that ratio was a starting point, not a portfolio average. It varied by site: at Site C, mine data alone ran at about 98% relational. That variance traced back as much to the underlying mine architecture as to software choice, since one was an automated, purpose-built open-pit operation generating a fundamentally different data footprint than an underground mine drawing on a wider spread of legacy systems. That variance became the entire story.
AVEVA CONNECT was the platform under evaluation: a cloud-hosted layer that promised to ingest from both PI and relational sources and present a unified, queryable surface. The question this engagement had to answer, site by site, was whether CONNECT’s actual ingestion mechanics could deliver on that promise without quietly discarding the relational structure the client’s reporting and future analytics depend on.
One Platform, Two Very Different Kinds of Data
Time-series data is CONNECT’s home turf. PI Web API, PI Asset Framework, and PI Vision integrate cleanly: tags flow in, timestamps are native, and the platform does what it was built to do.
Relational data is where the story gets complicated, not because CONNECT can’t talk to a SQL database (it can, easily), but because of what this particular relational data looked like. Mining operations systems like MineStar, Surface Manager, and Minesight don’t produce time-series streams; they produce normalized relational tables, dozens of tables per subject area, and at this client, twenty-five to fifty foreign keys deep in places with no native timestamp column on most of them. Any ingestion path that resolves it to a flat, single-grain table on the way in silently discards that structure, and with it the ability to reproduce those reports accurately, let alone build anything more sophisticated on top of them later. That fault line runs through the rest of this report.
CONNECT’s own answer to this problem is the RDBMS Adapter, and it was tested directly against this scenario. An RDBMS Adapter is AVEVA’s standard tool for pulling data from a relational database, like SQL Server, and feeding it into AVEVA’s data platform. It works well for simple tables, but it has two limitations relevant here: it stamps each piece of data with the time it happened to be read, rather than preserving the time the event actually occurred, and it collapses linked, multi-table relationships such as one Sector containing many Polygons into a single flat table, losing that structure along the way. Rather than reading a true event timestamp, it stamps records with read time, the moment the adapter happened to poll the row and, in doing so, flattens the relational structure on the way in. A sector-to-polygon relationship, or any comparable one-to-many hierarchy the client’s reporting depends on, doesn’t survive that flattening intact. That’s a real, current limitation, and it recurs at every reporting site in this engagement, not just one.
Site A
Site A is a large, highly automated open-pit operation, designed and built in the last few years around a fully autonomous haul fleet, the kind of clean-sheet build that makes for tidy data architecture almost by default. Its business problem was the same one every site in this engagement shared: produce daily, weekly, monthly, and COO reports without a slow custom pipeline or manual aggregation of fragmented plant and mine data. Plant data made up roughly 40% of Site A’s reporting inputs: PLCs feed PI interfaces, PI Archive and Asset Framework calculate around 150 KPIs every day at 6 a.m., and a custom script pivots that output into roughly 15 SQL tables before Power BI picks it up. That custom script also adds 20 minutes of daily latency, which is a pain point, and the client initially wanted CONNECT to remove it by replacing the script with a direct PI-to-CONNECT integration. Technically, that’s something CONNECT can do. But on closer look, the 20-minute delay wasn’t shown to cost the business anything identifiable; no decision, workflow, or downstream system depended on the data arriving faster, and a platform being capable of closing a gap isn’t the same as that gap being worth paying to close.
The mine-data side was the larger share of Site A’s reporting inputs- roughly 60%- and it was also the more complicated one: mine data was spread across four vendor systems, such as MineStar, Surface Manager, Acquire, and TerraTrack, totaling more than 300 tables and over 1,000 relationships. Most reporting already ran through Power BI and Microsoft Fabric, and about ten reports were still stitched together manually in Excel. Agglomerating that mine-data schema with the plant-side data proved a significant undertaking, not a solved problem waiting for a platform to move. This is the same relational complexity the rest of this report keeps running into: deeply nested, multi-table structures that a platform can move but can’t easily preserve or reproduce.
Put plainly: Site A did not qualify for AVEVA CONNECT, and not because the platform couldn’t handle it. Site A already had a working Power BI and Fabric reporting pipeline. Moving that pipeline onto CONNECT would mean building custom connectors for four separate mine-ops vendor systems, rebuilding the relational structure those systems carry, rewriting the KPI queries, and revalidating every existing report against the new pipeline, which is a substantial rebuild for incremental value that’s hard to point to, on top of a mine-data landscape that adds real cost of its own. The client’s desired future state confirmed as much: keep Power BI as the reporting tool, replicate the existing reports, convert the ten manual ones, and don’t introduce a new platform. Layered on top of that business case was the same structural blocker every reporting site in this engagement ran into: the relational mine data has no native timestamps, and CONNECT’s RDBMS Adapter flattens the one-to-many relationships, which is a sector containing many polygons, for instance, that the source structure depends on. Even where that technical problem might eventually be solved, it wouldn’t change the answer, because the business case for re-platforming a system that already worked wasn’t there to begin with.
Site B — An Existing PI Footprint, Mine Data Still Being Scoped
Site B was a mature underground operation, running remote-operated rather than autonomous equipment, where mine-ops systems had accumulated piecemeal over a decade rather than being designed cleanly from day one. Site B already ran AVEVA PI for plant data, the same PI footprint every site in this engagement shares. So the platform itself wasn’t new to the site; what was unresolved was the mine data’s half of the picture. In its current state, the site’s reporting data sources included SQL, SharePoint, PI, Excel, and disparate vendor SQL databases. At the time of this engagement, the mine-data reports themselves were still being filtered down to figure out which of them actually mattered, a materially earlier stage than Site A’s already-inventoried, four-vendor mine-data landscape.
The challenges here were less about a specific vendor’s table structure and more about the underlying effort: heavy manual work to gather, reconcile, and validate data; report preparation that depended on specific individuals rather than a repeatable process; and limited near-real-time visibility into what was actually happening underground. The desired future state was an automated reporting platform that consolidated enterprise and site systems into one trusted source, with standardized KPIs and dashboards. This was a real gap, but one whose shape, unlike Site A’s, hadn’t yet been fully mapped.
Site B didn’t qualify for AVEVA CONNECT for reporting either. For the same underlying reason as Site A: the same structural blocker, which is relational mine data with no native timestamps, and an RDBMS Adapter that flattens exactly the structure that needed preserving, and that sat underneath a mine-data reporting effort that wasn’t fully scoped yet. This made the business case harder to prove than at Site A. Site B did have a genuine, well-scoped need for CONNECT, but it’s a separate initiative, ATLAS, covered later in this piece.
Site C — Plant Data Flowing, Mine-Data Schema Not Mapped Yet
Site C’s plant side was, in some ways, the most automated of the three: a daily 7 a.m. stand-up report on crusher and grinding KPIs sourced from PI, imported into SQL, and fed a Power BI dataset that already refreshed automatically. This data was bridged through an intermediate tool, Homesoft, that moved PI data into a warehouse ahead of Power BI. The wrinkle was that a portion of that PI data itself originated from manual HMI reads keyed into PI Vision by hand – this was a limitation confirmed across every plant in this engagement, not unique to Site C. The mine-data side was where Site C was hardest to characterize cleanly, because it was the least mapped of the three. Roughly 98% of Site C’s mine data was relational, spread across six separate vendor systems, and at the time of this engagement the schema and a representative sample database were still pending. Site A’s four-vendor, 300-plus-table landscape was at least fully inventoried; Site C’s six-vendor landscape wasn’t yet documented enough to inventory in the same way.
Across all three reporting sites, the pattern held: wherever the source data was relational and mine-side, the same timestamp gap and the same adapter limitation showed up, and in every case the honest answer was to hold off not because CONNECT’s plumbing was incapable, but because none of the three sites had a business case strong enough to justify rebuilding a pipeline that, in each case, already does the job today. Site C, with heavy reliance on manual data entry upstream and a six-vendor mine-data schema that hadn’t been mapped yet, was arguably the site furthest from being ready to make that case at all. CONNECT wasn’t disqualified there so much as the question was premature.
The Bridge That Wasn’t Ready
Two candidate architectures were pressure-tested to see if either could close the relational gap CONNECT’s RDBMS Adapter couldn’t, in case any reporting site’s business case ever justified pursuing it.
The first was AVEVA’s BI Gateway, run on CONNECT itself: a promise of a native SQL Server connector writing into Azure SQL storage, preserving relational structure rather than flattening it. This was exactly the property the RDBMS Adapter lacked. On paper, it looked like the fix. It wasn’t for a mundane but decisive reason: the cloud-hosted BI Gateway on CONNECT cannot reach on-premises SQL Server at all today. Its supported connectors are AVEVA Insight, Azure SQL Database, and a generic REST API, none of which is where any of the three sites’ relational data lives. A future release was said to be adding on-premises SQL Server support, but with no confirmed date – this is a roadmap item, not an architecture.
The natural next question was what about the on-premises version of BI Gateway, run inside the client’s own network? This surfaced the knowledge that an on-premises BI Gateway was flagged as unlikely to be updated for compliance with the EU Cyber Resilience Act. For a client running global infrastructure and expecting EU-adjacent regulatory exposure over the life of this platform, recommending an architecture built on a product with an open compliance question was not a risk worth taking. Both halves of BI Gateway—cloud and on-prem — turned out to have a real, current limitation between the promise and the production architecture.
The Number That Changed the Quote
Underneath the technical detail sat a commercial fact worth stating plainly: whether including relational mine data in a site’s reporting scope was worth the cost. That’s close to the difference between two different projects wearing the same name, and it was exactly the rework this report keeps describing. This rework includes the new connectors per vendor system, rebuilt relational structure, rewritten KPI queries, and revalidated reports. Once we compared that number to the value it provided to the business, the answer at all three reporting sites was the same: the client’s existing Power BI and Fabric pipelines already work. The incremental business value of moving them onto CONNECT was limited, and the mine-data complexity at every site, whether fully inventoried like Site A’s or still being mapped like Site B’s and Site C’s, only added to that cost. None of the three reporting sites moved forward, and that conclusion holds independent of AVEVA CONNECT’s technical fit for the workload; it’s a rework-versus-value call, not a capability verdict.
ATLAS — Where CONNECT Was Exactly Right
Running in parallel to the site-by-site reporting work was a narrower, differently shaped initiative called ATLAS. This would allow the mines to automatically collect operating-hours and equipment-condition data from fixed plant assets to trigger condition-based maintenance (CBM) work orders inside Oracle Fusion Maintenance. This would eliminate the inefficiency of leaving each maintenance work order as calendar-based and manual. ATLAS was scoped explicitly to two of the three sites, Site A and Site B, rather than all three. At Site B specifically, the initiative extended further by integrating Oracle Fusion with four additional systems: ConformIT, TerraTrax, Spartacus, and Deswik. Today, mobile equipment inspection cards are manually transcribed into a separate system, Guide Ti, and planners manually create the resulting work orders in Oracle. The architecture put CONNECT in the middle of a simple, bounded pipeline: plant and mine source systems feed into CONNECT, and CONNECT in turn feeds both Oracle Fusion Maintenance and the reporting platform sitting alongside it. Critically, the scope had a hard boundary: CONNECT’s job stops at landing correctly structured data in one place. Anything past that line (ie: the integration into Oracle itself or the configuration of the trigger logic inside it) was explicitly out of scope.
That boundary was exactly why ATLAS was the one place where CONNECT was the right tool. A bounded landing zone that ingested data from known sources and handed off a well-defined payload to a downstream system is a major strength of CONNECT. The same competency that made Site A’s plant-data ingestion straightforward, without the open-ended relational-modeling ask that sank the reporting workstreams. Unlike the reporting sites, ATLAS also came with concrete, agreed success criteria: an asset structure aligned to Oracle Fusion, automatic Oracle maintenance-meter updates, and condition– or usage-based triggers that automatically generate maintenance work requests. These targeted outcomes were better than 99% automated meter updates and better than 99% successful OT-to-Oracle integration. Additional metrics included reduced planning effort, improved preventative-maintenance compliance, and lower unplanned downtime.
An engineering colleague raised a fair mid-project counterpoint: a more direct path existed that would skip CONNECT entirely and push PI-side events straight into the receiving cloud platform. And that alternative had its own open issues, chiefly that the network needed an outbound path from an on-premises OT environment to a cloud endpoint, and that the underlying asset-ID-to-equipment mapping still depended on the same relational systems either way. That last point is worth noting: the relational-mapping dependency didn’t disappear no matter which platform sat in the middle. It was a property of the data, not a flaw specific to CONNECT. What made ATLAS different wasn’t that CONNECT solved the relational problem here; it was that the initiative was scoped narrowly enough, and specifically enough, that CONNECT was never asked to.
The Verdict
None of this argues that AVEVA CONNECT is a poor product. It’s an argument that “is CONNECT a good fit” is the wrong question to ask about a portfolio. The right question became “what is CONNECT a good fit for, at which site, doing which job, and is the implementation cost worth the impact it brings to the business?” Of the four workstreams this engagement evaluated, CONNECT was recommended for only one. Reporting at Site A, Site B, and Site C all came back as a “no, not right now.” Each site already had a working reporting pipeline, and the effort needed to re-platform it onto CONNECT outweighed the incremental value. Technical challenges with the relational-data – including the structural blocker, lack of native timestamps, and an adapter that flattens the structure that must be preserved= adds further cost and complexity. ATLAS was the opposite story. It addresses a genuine integration gap with no automated path today. Specific data points and systems were already defined on both sides, Oracle Fusion Maintenance provided a clear downstream system of action, and measurable success criteria were established before the architecture was even drawn.
The engagement’s real deliverable wasn’t a single answer to the question “should this client use AVEVA CONNECT?” It was a site-by-site and workstream-by-workstream analysis as to where the platform’s real capabilities meet the client’s real data and real business case. It logically assessed where a technically possible integration wasn’t worthwhile. Further, it also showed how pricing, scoping, and making recommendations based on analysis, rather than selling one uniform strategy and architecture, provides the best value to both ourselves and the client.
Is CONNECT Right for Your Operation?
Not every use case needs the same answer. Talk with our team about where CONNECT fits, where it doesn’t, and what makes sense for your operation.