What a Remote Operations Centre Needs
The Room Is The Easy Part
Australia has been doing this longer than almost anywhere. Rio Tinto opened its Operations Centre near Perth Airport on 28 June 2010, described at the time as the first of its kind in Australian mining, running mines, rail and port across the Pilbara from up to 1,500 kilometres away. BHP's Integrated Remote Operations Centre began operating in Perth at the end of 2012, and in marking its tenth anniversary the company described it as coordinating four processing hubs and five mining hubs along with more than 1,000 kilometres of rail and port facilities in the Pilbara.
Both are cited constantly in board papers as proof the model works. It does work. What the board papers tend to skip is that the room, the video wall and the desks were the cheapest and fastest part of either programme.
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, which means every weakness already present in the site's data becomes load bearing. Two systems disagreeing about a tonnage is an annoyance on site, where someone can look at the stockpile. It is a work stoppage from 1,200 kilometres away.
This is a practitioner's list of what has to be true before a centre in a capital city can actually run a remote plant. It comes from 18 years of industrial data and operational technology work, including plant, production and reporting systems projects delivered for BHP, Rio Tinto and Senex Energy while employed by other consulting and engineering firms.
Latency: Most Things Do Not Need To Be Real Time
The first conversation on every remote operations project is about latency, and it is usually the wrong conversation, because it treats all data as though it has the same timing requirement.
Very little does. A fixed plant remote operator adjusting a setpoint, acknowledging an alarm, or watching a process trend is working on a timescale of seconds to minutes. A production figure, a shift summary, an availability rollup or a reason coded delay record can be a minute old, or five, with no operational consequence at all. The small set of genuinely latency critical functions tends to be interlocks, protection and anything with a person or a moving machine at the other end, and most of that should not be crossing a wide area link in the first place.
Getting this classification right early changes the network design and the budget. The physics is unforgiving at the top end. Geostationary satellite services carry real world round trip latency in the range of roughly 600 to 700 milliseconds, which independent testing across 2022 to 2025 has shown moving only modestly. Low earth orbit services changed the picture: Ookla based testing reported Starlink median latency around 45 milliseconds in the first quarter of 2025, with typical figures in the 25 to 60 millisecond band.
That difference decides what is possible. Half a second of round trip is fine for a trend display and unacceptable for closed loop supervisory control. Forty five milliseconds opens up a great deal more, though it still argues for keeping fast control local and sending the centre a view of it.
Classify Before You Engineer The Link
| Metric | Needs to be current | Can be a minute old | Improvement |
|---|---|---|---|
| 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 |
The practical consequence is that a centre can usually be built on a far more modest link than the initial specification assumes, provided somebody does the work of sorting functions into these buckets. Skipping that sort is how projects end up paying for a network sized to the worst case requirement of every data flow at once.
One Agreed Source Per Measurement
On site, two systems disagreeing about production is a known quirk. Everyone knows the historian reads high, everyone knows to use the metallurgist's figure, and the informal knowledge patches the gap.
Centralise, and that patch disappears. A remote operator has no way to adjudicate between two numbers, no way to check the stockpile, and no relationship with the person who knows which one to trust. Worse, a centre usually covers several sites, so the operator is now holding four sites' worth of informal exceptions, none of which are written down.
Every measurement a remote operator acts on needs one agreed source, produced the same way every time, with the reconciliation done before it reaches the screen. This is the single most underestimated item on a remote operations readiness list, and it is a substantial piece of work in its own right. We have set out the mechanics of it in a piece on why SCADA, the historian and the ERP disagree on tonnes and how to reconcile them, and the general failure it causes in analytics programmes in our note on why industrial analytics projects stall.
The test to apply is simple. Pick your ten most operationally important measurements. For each one, can you name the single system of record, the exact tag or calculation, and the person who owns it? If the answer involves the phrase "it depends who you ask", that measurement is not ready to be operated on remotely.
Asset Context So A Remote Operator Can Find Anything
Site operators carry a mental map. They know that the conveyor with the recurring tracking problem is the one past the secondary screen, and they know it by walking past it for three years. A remote operator has no map, may be covering four sites, and may have never stood on any of them.
That knowledge has to move from heads into the data model, and the vehicle for it is an asset hierarchy. Raw historian tags are a flat namespace of cryptic names that mean something only to whoever commissioned them. A remote operator cannot work from CV104_WT_PV. They need a structure that says which circuit the conveyor belongs to, what type of equipment it is, what its normal operating range looks like, what it is interlocked with, and what the last three faults on it were.
In a PI estate this is Asset Framework, and building templates that survive plant changes is a discipline we have written about in designing PI Asset Framework templates that last. In other estates it is the equipment hierarchy in the production management system plus a naming standard that is actually enforced. The technology matters less than whether the model is complete and maintained.
There is a multi-site trap here worth naming. Four sites that each built a perfectly good local hierarchy, with different depths, different naming and different equipment class definitions, cannot be presented to one operator on one screen without a translation layer. Aligning those hierarchies is slow work and it is nearly always discovered late, after the room has been fitted out.
Alarm Ownership: Who Acknowledges, Who Actions, What Happens When The Link Drops
Alarms are where remote operations projects get genuinely difficult, because the problem is half technical and half accountability.
Start with the technical half, which most sites already have a problem with. An alarm system that floods is survivable on site, where an experienced operator filters by knowing which alarms matter. It is not survivable remotely across several sites at once. The relevant standard is ANSI/ISA-18.2, first published in 2009 and revised in 2016, adopted internationally as IEC 62682, covering the management of alarm systems for the process industries across a lifecycle from philosophy and rationalisation through to monitoring and audit. The EEMUA 191 guidance most Australian operators work to sets the benchmarks: in steady state, an average below one alarm per operator per ten minutes is likely acceptable and more than one a minute is likely unacceptable, while an alarm flood is defined as more than ten new alarms in any ten minute window.
Rationalise the alarm system before you centralise it. A centre that inherits a flooding alarm system inherits it multiplied by the number of sites.
The accountability half is harder and it is where the arguments happen. For every alarm class, three things need to be written down and agreed before go live: who acknowledges it, who actions it, and what happens if the two are in different places. A remote operator acknowledging an alarm that only a person on site can resolve has created a gap, because the acknowledgement suppresses the annunciation while the hazard continues.
Alarm Path That Has To Be Agreed Before Go Live
The link failure step is the one most often left as an assumption. It needs a documented answer to what the plant does when the centre goes dark, who at the site takes control, how that handback is signalled, and how long the site can run unsupervised before it has to shut down. Australian regulators now expect this to be written down rather than assumed. Queensland's Resources Safety and Health Legislation Amendment Act 2024 amended the state's mining safety legislation to explicitly cover remote operating centre workers, with the ROC provisions commencing on 1 September 2024 and the related worker induction, training and safety and health management system requirements following on 1 March 2025. In 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 squarely inside the duty holder's obligations.
Reason Codes And Shift Handover Across Sites
The moment you centralise, a common reason code model stops being a reporting nicety and becomes an operational requirement.
Consider four sites that each built their own delay reason code tree, at different times, for different flowsheets, with different levels of depth. Each tree is defensible on its own site. A remote operator covering all four now has to code the same physical event four different ways depending on which site it happened at, and the consolidated Pareto that the centre exists to produce is arithmetic performed on four incompatible vocabularies.
Reason code trees also decay over time in ways that are invisible until someone looks, which we have covered in our guide to how Ampla delay accounting drifts away from the plant it was built for. Centralising exposes that decay immediately and across every site at once.
Building a common tree is a negotiation, not a configuration exercise. It takes an agreed level of granularity, an owner with authority to settle disputes between sites, and a mapping from each legacy tree so history remains comparable. Where coding consistency is the problem rather than the structure, there is a real role for assisted classification, which we have written about in where a trained model beats hand-written delay classification rules.
Shift handover deserves the same treatment. Handover on site is partly a conversation in a crib room. Remotely, whatever is not in the system did not happen, so the handover record has to carry what the conversation used to: what is degraded, what is being watched, what was tried, and what the next crew should not be surprised by.
Network And Control Boundaries: What Stays Local Regardless
Some things do not go to the centre, and the decision should be made on principle rather than on what the link can carry.
Safety instrumented systems stay local. IEC 61511, the process sector standard for safety instrumented systems, is built on the principle that the safety function is independent of the control system, with its own sensors and logic solver taking the plant to a safe state. A safety function whose execution depends on a wide area network link is not independent, and no latency figure makes that acceptable.
Basic regulatory control stays local. The centre should be operating at the supervisory level and above, which is the distinction ISA-95, published internationally as IEC 62264, already draws between the control layers and the operations management layers above them. The Purdue model that most Australian sites use for network segmentation maps to the same structure, and a remote operations project is a good moment to check that the segmentation on paper matches the segmentation in the racks.
Security boundaries follow. IEC 62443 frames industrial control security in terms of zones, which group assets sharing security requirements, and conduits, which are the controlled communication paths between them. A remote operations link is a conduit connecting a corporate zone to a control zone, and it should be designed, documented and monitored as one. In practice this usually means the link is read mostly, with a small, explicitly enumerated set of write capabilities, each one justified.
Local Or Remote
One regulatory nuance worth knowing, because it is frequently stated incorrectly in vendor material: mining is not one of the sectors listed under the Security of Critical Infrastructure Act 2018. Energy, transport, water and data storage assets are, and a mining business often owns assets that fall into those categories, such as port and rail infrastructure or an electricity asset. The critical infrastructure risk management program obligation applies to those listed asset classes, and the relevant entities were required to have an adopted program from 17 August 2023. Work out which of your assets are actually in scope rather than assuming the whole operation is or is not. Our note on SOCI Act and CIRMP obligations for critical infrastructure operators covers the detail.
The Part That Sinks Most Of Them: Who Decides
Every item above is solvable with money and time. The one that ends remote operations programmes is an unresolved disagreement about authority.
The pattern is consistent. A centre is established to improve consistency across sites and to concentrate scarce expertise. Site leadership retains accountability for safety, production and cost at their site. Nobody writes down what happens when the centre's judgement and the site's judgement differ, because at the design stage everyone assumes it will be worked out collaboratively.
Then a decision arrives where the centre wants to hold a circuit offline and the site superintendent wants it running, and there is no rule. Whatever happens next sets the precedent. If the site overrides the centre a few times, the centre becomes an expensive monitoring function whose recommendations are advisory, and the business case evaporates while the fit-out invoice stands.
This has to be settled in writing before the centre opens: which decisions the centre makes, which the site makes, which need both, and how a disagreement escalates and how fast. It is a governance document, not a technical one, and it is usually written by the people least interested in writing it. Queensland's 2024 amendments pushing remote operating centre workers explicitly into the safety and health management system are a useful forcing function here, because a management system has to name who is responsible for what.
Readiness Sequence Before The Fit-Out
What Readiness Work Protects
Start With A Readiness Review, Not A Floor Plan
If a remote operations centre is on your capital plan, the most useful thing you can do in the next month costs very little. Take the ten measurements a remote operator would act on, and for each one name the system of record, the exact calculation and the owner. Take your alarm rates per operator per hour and compare them to the EEMUA 191 benchmarks. Take the reason code trees from every site in scope and lay them side by side. Then write one page on which decisions the centre makes and which the site makes.
That exercise takes a fortnight and it tells you whether you have a twelve month readiness programme or a three month one. It is considerably cheaper to find out now than after the video wall is installed.
This work sits inside the operational technology, production systems and centralised reporting capability we provide to asset-heavy Australian operators, and it draws heavily on the system integration discipline needed to get plant data to a corporate location safely. Getting the resulting data into reporting that a centre can actually use is its own problem, covered in our note on getting historian data into Power BI without building a second historian. For resources businesses running these programmes from head office, our Brisbane practice works across the same Bowen Basin and Queensland operations this applies to.
If you are planning a centre, or you have one that is not delivering what the business case promised, start a scoping conversation and we will review the data layer before anyone talks about furniture.
Common Questions
What does a remote operations centre need before it can run a remote plant?
Four data conditions and one organisational one. Every measurement a remote operator acts on needs a single agreed source. Raw tags need an asset hierarchy so an operator without site knowledge can find equipment. Alarms need documented ownership and a tested behaviour when the link drops. Reason codes need to be common across sites. And the authority split between centre and site has to be written down.
How much latency can a remote operations centre tolerate?
It depends entirely on the function, which is why the classification work comes first. Supervisory control and alarm acknowledgement work on seconds. Production rollups, reason coding and reporting can be a minute old or more with no operational consequence. Geostationary satellite round trip latency sits around 600 to 700 milliseconds, while Ookla based testing put Starlink median latency near 45 milliseconds in early 2025.
Which Australian remote operations centres are the usual reference points?
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, and at its tenth anniversary BHP described it as coordinating four processing hubs and five mining hubs plus more than 1,000 kilometres of rail and port facilities.
What should never be operated from a remote centre?
Safety instrumented functions and basic regulatory control. IEC 61511 builds the safety instrumented system on independence from the control system, with its own sensors and logic solver, and a safety function that depends on a wide area link is not independent. Regulatory control loops stay local too, with the centre operating at the supervisory layer and above as ISA-95 and IEC 62264 describe it.
Why do reason codes matter more once operations are centralised?
Because a remote operator covering several sites has to code the same physical event differently at each one if the trees differ, and the consolidated reporting the centre exists to produce is then arithmetic over incompatible vocabularies. A common tree needs an agreed granularity, an owner with authority to settle disputes between sites, and a mapping from each legacy tree so historical comparisons still hold.
What Australian regulation applies to remote operations centre workers?
Queensland's Resources Safety and Health Legislation Amendment Act 2024 amended the state's mining safety legislation to cover remote operating centre workers, with ROC provisions commencing 1 September 2024 and worker induction, training and safety and health management system requirements from 1 March 2025. In Western Australia, the Work Health and Safety (Mines) Regulations 2022 define plant to include autonomous, semi-autonomous and remote-controlled plant.