A remote operations centre needs five things in place before it can run a remote plant: one agreed source for every measurement an operator acts on, an asset hierarchy so operators can find equipment they have never seen, documented alarm ownership with a tested link-loss fallback, common reason codes across sites, and a written split of authority between centre and site.
The room, the video wall and the desks are the cheapest and fastest part. This guide is for operations, technology and asset leaders at Australian mining, processing and energy operators who have a centre on the capital plan, or one that is not delivering what its business case promised.
Key takeaways
- Most data does not need to be real time. Classify every flow by its actual timing need before you size the network.
- Every measurement a remote operator acts on needs one system of record, one calculation and one named owner.
- Rationalise alarms before you centralise them, or you multiply a flooding alarm system by the number of sites.
- Safety instrumented functions and basic regulatory control stay local, whatever the link can carry.
- The programmes that fail usually fail on an unwritten rule about who decides when centre and site disagree.
Why is the remote operations room the easy part?
Australia has run remote operations longer than almost anywhere. Rio Tinto opened its Operations Centre near Perth Airport on 28 June 2010, running Pilbara mines, rail and port from up to 1,500 kilometres away. BHP's Integrated Remote Operations Centre began operating in Perth at the end of 2012. At its tenth anniversary BHP described it as coordinating four processing hubs, five mining hubs and more than 1,000 kilometres of rail and port facilities.
Both appear in board papers as proof the model works. It does. What those papers tend to skip is that the expensive part is the data layer underneath and the organisational agreement beside it.
A remote operations centre does not create information. It removes a person's ability to walk outside and check, so every weakness in the site's data becomes load bearing. Two systems disagreeing about tonnage is an annoyance on site, where someone can look at the stockpile. From 1,200 kilometres away it stops work.
Across our consultants' careers, including direct and indirect project engagements at BHP, Rio Tinto and Senex Energy, the same readiness gaps come up. The sections below set them out in the order they bite.
Does a remote operations centre need real-time data for everything?
No. The first conversation on most projects is about latency, and it usually treats all data as if it had the same timing requirement.
A fixed plant remote operator adjusting a setpoint, acknowledging an alarm or watching a trend works on seconds to minutes. A production figure, shift summary, availability rollup or reason-coded delay record can be one to five minutes old with no operational consequence. The genuinely latency-critical functions are interlocks, protection and anything with a person or moving machine at the other end, and most of that should not cross a wide area link at all.
The physics matters at the top end. Geostationary satellite services carry real-world round trip latency of roughly 600 to 700 milliseconds. Low earth orbit services changed the picture: Ookla-based testing reported Starlink median latency around 45 milliseconds in the first quarter of 2025. Half a second is fine for a trend display and unacceptable for closed-loop supervisory control. Forty-five milliseconds opens up more, but still argues for keeping fast control local.
| Needs to be current | Can be a minute old | Impact | |
|---|---|---|---|
| Process control | Setpoint changes, supervisory loops | Loop tuning history and performance review | Seconds vs daily |
| Alarms | Annunciation and acknowledgement | Alarm rate analysis and rationalisation | Seconds vs weekly |
| Production | Current equipment running state | Tonnes, grade, availability rollups | Seconds vs minutes |
| Delay records | Event start and stop timestamps | Reason coding and approval workflow | Seconds vs shift |
| Reporting | Nothing | Shift, daily and monthly reporting | Batch is fine |
Sorting functions into these buckets usually means a centre can run on a more modest link than the first specification assumed. Skipping the sort is how projects pay for a network sized to the worst case of every data flow at once.
Why does every measurement need one agreed source?
On site, two systems disagreeing about production is a known quirk. Everyone knows the historian reads high and to use the metallurgist's figure. Informal knowledge patches the gap.
Centralise and that patch disappears. A remote operator cannot adjudicate between two numbers, cannot check the stockpile, and does not know the person who knows which one to trust. A centre usually covers several sites, so the operator now holds several sites' worth of unwritten exceptions.
Every measurement a remote operator acts on needs one agreed source, produced the same way every time, reconciled before it reaches the screen. This is the most underestimated item on a readiness list. We set out the mechanics in why SCADA, the historian and the ERP disagree on tonnes, and the wider failure pattern in why industrial analytics projects stall.
The test: pick your ten most operationally important measurements. For each, name the system of record, the exact tag or calculation, and the owner. If any answer starts with "it depends who you ask", that measurement is not ready to be operated remotely.
How does a remote operator find equipment they have never seen?
Site operators carry a mental map built by walking past the plant for years. A remote operator may cover four sites and never have stood on any of them.
That knowledge has to move from heads into the data model through an asset hierarchy. Raw historian tags are a flat list of cryptic names. An operator cannot work from CV104_WT_PV. They need to see which circuit the conveyor belongs to, its equipment class, normal operating range, interlocks and last three faults.
In a PI estate this is Asset Framework, and we cover building templates that survive plant changes in designing PI Asset Framework templates that last. Elsewhere it is the equipment hierarchy in the production management system plus an enforced naming standard.
The multi-site trap: four sites that each built a sound local hierarchy, with different depths, names and equipment classes, cannot be shown to one operator on one screen without a translation layer. Aligning them is slow, and it is usually discovered after the room is fitted out.
Who owns alarms in a remote operations centre?
Alarms are half technical and half accountability.
The technical half: a flooding alarm system is survivable on site, where an experienced operator knows which alarms matter. It is not survivable remotely across several sites. The relevant standard is ANSI/ISA-18.2 (first published 2009, revised 2016), adopted internationally as IEC 62682, which covers the alarm lifecycle from philosophy and rationalisation through to monitoring and audit. The EEMUA 191 guidance most Australian operators use sets the benchmarks: in steady state, an average below one alarm per operator per ten minutes is likely acceptable, more than one a minute is likely unacceptable, and a flood is more than ten new alarms in any ten-minute window.
Rationalise the alarm system before you centralise it.
The accountability half: for every alarm class, write down who acknowledges it, who actions it, and what happens if those two are in different places. A remote acknowledgement of an alarm only a person on site can resolve creates a gap, because it silences the annunciation while the hazard continues.
- Alarm raisedLocal system annunciates at the plant
- Presented remotelyCentre sees it with asset context attached
- AcknowledgedNamed role acknowledges, recorded against a person
- ActionedRemote action, or dispatch to a person on site
- Link failsDefined local fallback, site reverts to local control
- Closed outReason coded against a model both sites share
The link failure step is the one most often left as an assumption. Document what the plant does when the centre goes dark, who on site takes control, how handback is signalled, and how long the site can run unsupervised.
What Australian regulation applies to remote operations centre workers?
Regulators now expect remote operation to be written into safety management, not assumed.
- Queensland: the Resources Safety and Health Legislation Amendment Act 2024 amended mining safety legislation to explicitly cover remote operating centre workers. The ROC provisions commenced on 1 September 2024, with worker induction, training and safety and health management system requirements following on 1 March 2025.
- Western Australia: the Work Health and Safety (Mines) Regulations 2022 define plant to include autonomous, semi-autonomous and remote-controlled plant, which brings remotely operated equipment inside the duty holder's obligations.
- Critical infrastructure: mining is not a listed sector under the Security of Critical Infrastructure Act 2018, but energy, transport, water and data storage assets are. A mining business often owns port, rail or electricity assets that fall into those classes, and the risk management program obligation applies to those assets. Our note on SOCI Act and CIRMP obligations covers the detail.
Why do reason codes and shift handover matter more once you centralise?
A common reason code model stops being a reporting nicety and becomes an operational requirement.
Four sites that each built their own delay reason tree, at different times and depths, force a remote operator to code the same physical event four ways. The consolidated Pareto the centre exists to produce becomes arithmetic over four incompatible vocabularies.
Reason trees also decay quietly, which we cover in how Ampla delay accounting drifts away from the plant it was built for. Centralising exposes that decay across every site at once.
A common tree is a negotiation more than a configuration task. It needs agreed granularity, an owner with authority to settle disputes between sites, and a mapping from each legacy tree so history stays comparable. Where coding consistency is the issue, assisted classification can help, as we explain in where a trained model beats hand-written delay classification rules.
Shift handover needs the same discipline. On site it is partly a conversation in the crib room. Remotely, whatever is not in the system did not happen, so the handover record must carry what is degraded, what is being watched, what was tried, and what the next crew should expect.
What should never be operated from a remote centre?
Some functions stay local on principle, whatever the link can carry.
- Safety instrumented systems. IEC 61511 builds the safety function on independence from the control system, with its own sensors and logic solver. A safety function that depends on a wide area link is not independent.
- Basic regulatory control. The centre operates at the supervisory layer and above, the distinction ISA-95 (IEC 62264) draws between control and operations management. A remote operations project is a good moment to check the Purdue segmentation on paper matches the racks.
- Security boundaries. IEC 62443 frames control system security as zones and conduits. A remote operations link is a conduit from a corporate zone to a control zone. Design it as mostly read-only, with a small, listed set of write capabilities, each one justified.
Where should this function sit?
- Safety instrumented functionLocal always. IEC 61511 independence is not negotiable.
- Basic regulatory control loopLocal. Centre supervises, site controls.
- Supervisory setpoint and mode changesRemote, with an enumerated write path and audit trail.
- Alarm annunciation and acknowledgementBoth, with agreed ownership and a documented link-loss fallback.
- Production reporting and reason codingRemote. Batch timing is fine.
Who decides when the centre and the site disagree?
Every item above is solvable with time and money. The one that ends remote operations programmes is an unresolved disagreement about authority.
A centre is set up to improve consistency and concentrate scarce expertise. Site leadership keeps accountability for safety, production and cost. Nobody writes down what happens when the two judgements differ, because at design stage everyone assumes it will be worked out.
Then the centre wants a circuit held offline and the superintendent wants it running, and there is no rule. If the site overrides the centre a few times, the centre becomes an expensive advisory function and the business case evaporates.
Settle it in writing before opening day: which decisions the centre makes, which the site makes, which need both, and how a disagreement escalates and how fast. Queensland's 2024 amendments help here, because a safety and health management system has to name who is responsible for what.
- Months 1-2Classify and decide authoritySort every data flow by real timing need, and write down who decides what
- Months 2-4Single source per measurementReconcile the measurements a remote operator will act on
- Months 3-6Asset context and common codesAlign hierarchies and reason code trees across every site in scope
- Months 5-7Alarm rationalisationGet alarm rates to benchmark before multiplying them by four sites
- Months 6-8Boundaries and link behaviourZones, conduits, enumerated writes, and a tested link-loss fallback
- Months 8+Room and cutoverFit out, run parallel with the site, then transfer functions one at a time
- Measurements a remote operator can act onOne agreed source each
- Alarm load when four sites are combinedAt benchmark, not multiplied
- Consolidated delay reportingOne vocabulary across sites
- Centre versus site disagreementsSettled in writing before day one
How do you start a remote operations readiness review?
Start with a review, not a floor plan. In the next month:
- Take the ten measurements a remote operator would act on and name the system of record, calculation and owner for each.
- Compare alarm rates per operator against the EEMUA 191 benchmarks.
- Lay the reason code trees from every site side by side.
- Write one page on which decisions the centre makes and which the site makes.
That fortnight of work tells you whether you face a twelve-month readiness programme or a three-month one, before the video wall goes in. Getting the resulting data into reporting the centre can use is covered in getting historian data into Power BI without building a second historian.
How Solve8 can help
Our consultants and engineers review the data layer of a planned or underperforming centre: measurement sources, asset context, alarm data, reason codes and the connections from plant to head office. See our mining, resources and manufacturing work and system integration service, or contact us to scope a readiness review.
