Our principal consultant has spent 18 years inside PI, Ampla and Citect systems on Australian mine sites and processing plants, so the first conversation is about your tags, your reason codes and your interfaces.
Systems our principal consultant has worked with hands-on
All product names and trademarks are the property of their respective owners. Solve8 is not an AVEVA or Schneider Electric partner.
These arrive as an argument about a number, a system going out of support, or an obligation with a date attached, and only later as an AI project.
SCADA says one tonnage, the historian says another, and the monthly report says a third. Usually the break is in a reason code model or an interface nobody has opened in years.
Unplanned stops get recorded. Slow running, off-spec product and short feed do not, so the biggest losses never reach the report the site manages by.
Citect to Plant SCADA, PI Server to Data Infrastructure, an Ampla version nobody upgrades. An upgrade is costed in tags, drivers, graphics and downtime, and the count is usually higher than the last estimate.
A CIRMP risk program under the Security of Critical Infrastructure Act, a Safeguard Mechanism baseline, or a principal mining hazard management plan that has to evidence control effectiveness from monitoring data.
Six areas, from the plant floor up to the report the board reads. Most engagements start in one and grow into the next.
Plant floor systems, and the data that comes off them.
Turning process data into something a manager can act on.
The Level 3 layer that records what the plant actually produced.
Making plant systems talk to the business systems above them.
One version of the operational numbers across several sites.
The upkeep and the steady stream of changes after go-live.
AI on top of operational systems works when the data underneath it is trustworthy and the problem is narrow. Most of what goes wrong here is a data foundation problem wearing an AI badge, which is the part 18 years in historians makes obvious early.
Operators on a flooded alarm list stop reading it. Clustering and sequence analysis over historian data finds the chattering tags, the duplicates and the standing alarms, so rationalisation starts from evidence instead of a workshop.
Shift logs, downtime coding, deviation notes and handover written once and pushed to the systems that need them, rather than rekeyed into three. The reconciliation it removes is worth more than the model doing the writing.
Models over instrumentation you already have, aimed at a specific failure mode on specific equipment. Narrow and measurable beats a plant-wide predictive maintenance programme that nobody trusts by month three.
An assistant that answers questions about the plant is only as good as the asset context behind it. Tag naming, asset framework and a read-only boundary decide whether it answers correctly, so that work comes first.
Our principal consultant worked on industrial, mining and processing projects for these operations over 18 years, across multiple projects and several different clients.
This experience is personal and was gained while working with previous consulting employers. It predates Solve8, and these companies are not Solve8 clients. We name them for the systems and the site conditions, which are what transfer to your plant.
The OSIsoft PI System and its Asset Framework and PI Vision layers, AVEVA Ampla (now AVEVA Production Management), AVEVA System Platform, Citect SCADA (now AVEVA Plant SCADA), Citect Historian, and asset performance management tooling. Our principal consultant has worked hands-on with these across 18 years in mining, manufacturing and energy.
Yes. Our principal consultant spent 18 years on industrial and mining projects for BHP, Rio Tinto, Anglo American, BMA, Santos, Mackay Sugar, Ok Tedi and Whitehaven, delivered while working with previous consulting employers. That experience is personal and predates Solve8, and those companies are not Solve8 clients.
Only where the site wants us to, and normally we do not need to. Most of the work sits at Level 3 and above: historian, production management, reporting and the integration up to business systems. Where a read-only boundary is required, we design to it.
Yes, and the trick is doing it without building a second historian by accident. The usual failure is extracting raw tags into a warehouse and losing the asset context that made the data meaningful. We have built Power BI reporting frameworks over process data before.
With a scoping conversation and, where it helps, a short assessment of the systems already on site. We would rather tell you the problem is a reason code model than sell you a platform. Engagements typically start from $3,500 for integration work and $4,500 for strategy and roadmap work.
On top of data that is already trustworthy. The useful applications are narrow and specific: alarm rationalisation from historian evidence, anomaly detection aimed at a named failure mode, and removing the rekeying between shift logs, downtime coding and production systems. An assistant answering questions about the plant depends on tag naming and asset context far more than on model choice, so that groundwork usually comes first. Agentic AI on a weak data foundation fails slowly and expensively.
Both, and for operational technology the ongoing arrangement is usually the more useful one. It covers maintenance and upkeep, health checks on historian and SCADA environments, patching and upgrades, modifications as the plant changes, and steady improvement of the reports, screens and models people actually use. Retained support runs from $2,000 to $5,000 a month depending on scope and response level.
Yes. Much of this work is brownfield: an existing historian, SCADA or production system that has drifted from its documentation and lost the people who built it. We start by working out what is actually running and what it is connected to, then keep it maintained and improve it from there.
Yes. We are Brisbane-based and work across Australia, including the Pilbara, the Goldfields, the Bowen Basin and remote sites in the Territory. Much of this work is done remotely, with site visits where the job genuinely needs them.
Written for engineers and plant managers rather than for procurement. We resell none of the products below.
We are Brisbane-based and work nationally. These pages cover the data problems specific to each region rather than repeating the same copy with the place name changed.
Or which system is going out of support, or which obligation has a date on it. If the answer is that you do not need us, we will say so.