🎓 Lesson 16
D5
FAT/SAT Execution for ROC Control Systems
FAT and SAT are step-by-step checklists used to prove that a Remote Operations Center’s control system works correctly before and after it’s installed at the mine site.
🎯 Learning Objectives
- ✓ Explain the purpose, scope, and deliverables of FAT versus SAT for ROC control systems
- ✓ Design a traceable FAT/SAT test protocol aligned with IEC 62443-3-2 and ISA-84.00.01 safety lifecycle requirements
- ✓ Analyze test failure root causes using a structured deviation log and apply corrective action tracking per ISO 9001:2015
- ✓ Apply cybersecurity validation criteria (e.g., network segmentation, role-based access control) during SAT execution
- ✓ Evaluate FAT/SAT documentation completeness against MSHA Part 46 and ICMM ROC Validation Guidelines
📖 Why This Matters
A single unvalidated ROC control system fault—like a misconfigured alarm suppression or delayed tele-remote command—can cause catastrophic delays, unsafe remote equipment operation, or even loss of life in autonomous haulage or ventilation control. FAT/SAT isn’t paperwork—it’s the final engineering gate that ensures every logic block, HMI screen, fail-safe, and cyber-hardened interface behaves exactly as designed—before operators trust their lives and production to it.
📘 Core Principles
FAT/SAT follows the V-model of systems engineering: requirements → design → implementation → verification. FAT validates *what was built* against specifications; SAT validates *how it works in context*. Key theoretical pillars include: (1) Traceability—each test case maps to a functional requirement (e.g., 'ROC must initiate emergency stop within ≤500 ms of button press'); (2) Independence—testing is performed by QA/QC, not developers; (3) Evidence-based closure—every test has pass/fail evidence (screenshots, logs, timestamps); (4) Cyber-physical integration—SAT must validate both software logic *and* hardware response (e.g., PLC output activation time + field device actuation). Industry practice treats FAT as 'design validation' and SAT as 'installation & operational qualification' (IQ/OQ), per GAMP 5 and ISO/IEC 17025 principles.
📐 Test Coverage Ratio (TCR)
TCR quantifies how thoroughly functional requirements are exercised during FAT/SAT. It is calculated as the ratio of tested requirements to total validated requirements—and is a key KPI reported to project governance. A TCR < 95% triggers rework; < 90% requires formal variance approval.
Test Coverage Ratio (TCR)
TCR = (N_tested / N_validated) × 100Percentage of functional requirements verified during FAT/SAT relative to total validated requirements.
Variables:
| Symbol | Name | Unit | Description |
|---|---|---|---|
| N_tested | Number of requirements tested and passed | count | Sum of passed tests from FAT and SAT |
| N_validated | Total number of requirements formally validated | count | Includes original FRS items plus approved additions |
Typical Ranges:
Tier-1 mining ROC projects: 95% – 100%
Legacy system integrations: 88% – 94%
💡 Worked Example
Problem: A ROC control system has 142 functional requirements documented in the FRS (Functional Requirements Specification). During FAT, 133 were executed and passed. During SAT, 9 additional requirements (relating to field integration) were added and all 9 passed. Two requirements were deferred due to vendor firmware delay and formally approved via change control.
1.
Step 1: Total validated requirements = 142 (original) + 9 (added) = 151
2.
Step 2: Total tested requirements = 133 (FAT) + 9 (SAT) = 142
3.
Step 3: Apply TCR = (142 ÷ 151) × 100 = 94.0%
4.
Step 4: Compare to minimum threshold: 94.0% > 90% but < 95%, so a formal variance is required per project QA plan.
Answer:
The result is 94.0%, which falls within the acceptable range only with approved variance—highlighting the need for early requirement freeze and change control discipline.
🏗️ Real-World Application
At Newmont’s Boddington Mine (WA), the 2022 ROC upgrade included a new distributed control system for integrated fleet management, ventilation-on-demand, and blast monitoring. FAT was executed over 12 days at Siemens’ Melbourne facility, validating 100% of SIL-2 safety logic (per IEC 61511) and all 217 HMI alarm behaviors. SAT occurred over 18 shifts across two weeks—revealing a 1.2-second latency in tele-remote bucket positioning due to unoptimized OPC UA polling intervals. The issue was resolved via firmware update and retested, with full evidence logged in the SAT report signed off by MSHA-certified ROC Commissioning Engineer and Newmont’s Functional Safety Manager.