π Lesson 8
D5
Building the Multi-Site ROC Workflow Map
A multi-site ROC workflow map is a visual blueprint that shows how data, decisions, and actions flow between multiple remote operations centers and their connected mines to coordinate blasting, monitoring, and response in real time.
π― Learning Objectives
- β Design a latency-aware workflow map linking three distinct mine sites to a central ROC and regional backup ROC
- β Analyze message routing paths for blast initiation commands to identify single points of failure and propose redundancy solutions
- β Explain how ISO/IEC 27001 controls apply to cross-site ROC data handoff protocols
- β Apply IEC 62443-3-3 security zones and conduits to segment a multi-site ROC workflow diagram
- β Evaluate workflow handoff SLAs (e.g., <200 ms command-to-initiation latency) against field-measured network performance data
π Why This Matters
When a blast initiates at Site A, the ROC must simultaneously suppress conveyor alarms at Site B, re-route haul trucks from Site C, and trigger post-blast dust suppression β all within seconds. Without a rigorously mapped, validated, multi-site workflow, coordination collapses under latency, ambiguity, or cascading failures. This map isnβt documentation β itβs the operational constitution for safe, scalable remote blasting.
π Core Principles
Multi-site ROC workflows rest on three foundational layers: (1) The *Process Layer* defines sequential, parallel, and conditional steps (e.g., 'Confirm seismic silence β Validate blast permit β Transmit encrypted initiation signal'); (2) The *Information Layer* specifies data types, formats, ownership, and refresh rates (e.g., 'Blast-ready flag: Boolean, updated every 500 ms, owned by Mine A Blasting Engineer'); and (3) The *Infrastructure Layer* assigns physical/logical pathways β including primary fiber links, LTE backup channels, OPC UA servers, and firewall-constrained DMZs β with defined MTTR and failover triggers. Critically, the map must enforce *separation of duties*: no single ROC site may unilaterally authorize blasts outside its designated jurisdiction without dual authorization and time-stamped audit logging.
π Workflow Latency Budget Allocation
Total end-to-end latency (T_total) must be allocated across subsystems to guarantee reliable blast initiation timing. This ensures compliance with IEC 61511 SIL-2 requirements for safety-critical command chains.
Latency Budget Allocation
T_total = Ξ£(T_i) + T_jitter + T_failover + T_verificationAllocates total allowable latency across processing, transmission, security, and human-factor components to meet SIL-2 or regulatory timing requirements.
Variables:
| Symbol | Name | Unit | Description |
|---|---|---|---|
| T_total | Maximum allowable end-to-end latency | ms | Regulatory or safety-system upper limit (e.g., 350 ms for SIL-2 blast initiation) |
| T_i | Individual subsystem latency | ms | Measured or modeled delay for each component (application, network, firewall, server, PLC) |
| T_jitter | Network timing jitter allowance | ms | Statistical variation buffer (typically Β±50β100 ms for industrial Ethernet) |
| T_failover | Failover switchover time | ms | Time to detect failure and activate backup path (e.g., <80 ms for PRP/HSR networks) |
| T_verification | Human or system verification timeout | ms | Allowable time for operator confirmation or automated validation before command execution |
Typical Ranges:
Fiber-optic primary link (100 km): 40 β 85 ms
OPC UA server processing (industrial grade): 25 β 50 ms
SIL-2 blast initiation chain: 200 β 350 ms
π‘ Worked Example
Problem: A multi-site ROC must deliver a blast initiation command from Central ROC to Mine Dβs firing panel within β€350 ms (SIL-2 requirement). Measured network path includes: ROC application logic (45 ms), primary fiber link (62 ms), regional firewall inspection (18 ms), Mine D OPC UA server (33 ms), and local PLC scan cycle (12 ms). Does current allocation meet the budget? If not, where should optimization occur?
1.
Step 1: Sum measured latencies: 45 + 62 + 18 + 33 + 12 = 170 ms
2.
Step 2: Compare to budget: 170 ms β€ 350 ms β Yes, headroom remains
3.
Step 3: Allocate remaining 180 ms as buffer for jitter (Β±90 ms), failover switchover (β€50 ms), and human verification timeout (β€40 ms)
Answer:
The result is 170 ms, which falls within the safe range of β€350 ms. Available buffer = 180 ms, sufficient for worst-case jitter and failover.
ποΈ Real-World Application
Rio Tintoβs Pilbara Multi-ROC Architecture (2022β2024) integrated 6 iron ore mines across 400 km under two active ROCs (Tom Price and Yandi), with automated handoff triggered by seismic event magnitude >M_L 1.8. When a blast at West Angelas exceeded predicted ground vibration, the workflow map automatically routed all real-time geotech data to Yandi ROC while locking out Tom Priceβs override authority for 90 seconds β enforcing jurisdictional boundaries and preventing conflicting interventions. This map was validated via 147 simulated cross-site failure scenarios and certified under AS/NZS IEC 62443-3-3:2022.
π§ Interactive Calculator
π§ Open Mine Remote Operations Center (ROC) Design Calculatorπ Case Connection
π Coal Mine ROC Cybersecurity Hardening in Appalachia
Legacy PLCs exposed to corporate IT network with no segmentation; failed NIST SP 800-82 audit