AGL-CS-096 — SCADA Communication Failure
The AGL Knowledge Hub | Engineering Case Study Series. A SCADA supervisory communication investigation where an OPC gateway failure isolated the supervisory layer — from field verification through gateway diagnostics, OPC testing, and supervisory restoration.
Important: This is an engineering simulation created for training. It is not presented as an actual airport incident. All readings, values, dates and outcomes are illustrative, and no airport, organisation, person or manufacturer is identified or implied.
1Case Study Overview
During routine night operations, the airport central control room reported that the SCADA system had lost communication with the airfield lighting automation network.
Operators observed:
- Multiple communication alarms.
- Frozen equipment status.
- Loss of historical data updates.
- Remote control unavailable.
- Alarm notifications not updating.
However, field verification confirmed that:
- CCRs remained operational.
- ALCMS local workstations functioned correctly.
- PLCs continued controlling lighting circuits.
- Field equipment remained operational.
Because the failure affected supervisory communication rather than field control, a detailed investigation was initiated covering SCADA servers, OPC communication, communication gateways, historian database, industrial Ethernet, firewall configuration, protocol conversion, and redundant server synchronization.
The investigation identified failure of the OPC communication gateway connecting the SCADA system to the ALCMS network, resulting in complete loss of supervisory communication.
This case demonstrates that SCADA communication failures can isolate the supervisory layer while automation and field equipment continue operating normally.
2Learning Objectives
After completing this case study, the learner should be able to:
- Diagnose SCADA communication failures.
- Verify supervisory-system architecture.
- Test OPC communication.
- Investigate gateway failures.
- Verify historian and alarm communication.
- Restore SCADA connectivity.
- Validate supervisory-system functionality.
3System Background
A typical airport SCADA architecture includes:
- SCADA servers.
- Operator workstations.
- Historian servers.
- OPC servers.
- Communication gateways.
- ALCMS servers.
- PLC networks.
- Industrial Ethernet.
- Firewall and security systems.
- Redundant communication paths.
SCADA communication failures may result from:
- OPC server failure.
- Gateway failure.
- Firewall blocking.
- Network segmentation.
- Protocol-conversion failure.
- Database communication failure.
- Server synchronization failure.
- Redundancy malfunction.
Supervisory reliability depends on gateway and communication integrity.
4Problem Statement
The reported condition was:
- SCADA communication lost.
- ALCMS operational.
- PLC control operational.
- Field equipment operational.
- Supervisory functions unavailable.
Why has the SCADA system lost communication while the automation system remains operational?
5Initial Observations
| SCADA communication | Lost |
| ALCMS operation | Normal |
| PLC operation | Normal |
| Field equipment | Operational |
| Historian updates | Stopped |
The symptoms suggested a supervisory-layer communication problem.
6Initial Engineering Hypotheses
The investigation considered:
SCADA server failure.
OPC communication failure.
Gateway failure.
Firewall configuration error.
Database communication failure.
7SCADA Communication Principle
The supervisory layer depends on communication gateways.
8Test Equipment
The investigation used:
- SCADA diagnostics.
- OPC diagnostic software.
- Network analyzer.
- Ethernet communication tester.
- Gateway diagnostic tools.
- Firewall diagnostics.
- Database monitoring software.
- Server performance monitoring tools.
9Investigation
Step 1: Verify Field Operation
Field testing confirmed:
| CCRs | Normal |
| Taxiway circuits | Normal |
| Stop bars | Normal |
| PLCs | Operational |
Field equipment was healthy.
Step 2: Verify ALCMS Operation
Testing showed:
- Local HMI operational.
- PLC communication normal.
- Remote control functional.
- Alarm processing operational.
The ALCMS was healthy.
Step 3: Verify SCADA Server
Server diagnostics showed:
- Server running.
- HMI functional.
- Historian operational.
- No hardware alarms.
The SCADA server was healthy.
Step 4: Test OPC Communication
OPC diagnostics showed:
- No active data points.
- Gateway connection failed.
- Subscription timeout.
- Data quality invalid.
The OPC server was not receiving ALCMS data.
Step 5: Verify Gateway Communication
Testing showed:
| Connection | Result |
| SCADA to gateway | Healthy |
| Gateway to ALCMS | Failed |
| Gateway diagnostics | Fault active |
The communication gateway had failed.
Step 6: Gateway Inspection
Inspection revealed:
- Gateway power normal.
- Network interfaces healthy.
- Protocol-conversion process failed.
- Communication service stopped.
The gateway software had failed.
Step 7: Gateway Restart and Replacement
After restarting the gateway service:
- Communication partially restored.
- Data updates resumed.
- Alarm synchronization restored.
A subsequent gateway replacement restored full communication reliability.
10Root Cause
The SCADA communication failure was caused by failure of the OPC communication gateway, resulting in:
- Loss of SCADA data updates.
- Loss of supervisory alarms.
- Loss of historical data transfer.
- Loss of remote supervisory control.
The ALCMS and field equipment remained operational.
The primary failure mechanism was gateway communication failure.
11Corrective Action
The engineering team:
- Restarted gateway services.
- Replaced the failed gateway.
- Verified OPC communication.
- Restored historian updates.
- Verified alarm synchronization.
- Tested remote supervisory control.
- Verified data quality.
- Tested redundancy switching.
- Updated gateway software.
- Implemented gateway health monitoring.
12Post-Repair Verification
Gateway restoration recovered full SCADA functionality.
13Root-Cause Analysis
SCADA communication lost
Healthy
Healthy
Healthy
Failed
Failed
Communication verified operational
OPC communication-gateway failure
Restore supervisory communication interface
14Why This Case Was Important
SCADA communication failures can cause:
- Loss of centralized monitoring.
- Loss of alarm visibility.
- Loss of historical trending.
- Reduced operational awareness.
- Increased manual monitoring.
- Reduced maintenance coordination.
The supervisory layer is critical operational infrastructure.
15Engineering Lessons
SCADA communication failures do not necessarily affect field control.
SCADA communication failures do not necessarily affect field control.
Gateways are critical supervisory-system components.
Gateways are critical supervisory-system components.
OPC diagnostics provide valuable communication information.
OPC diagnostics provide valuable communication information.
Historian failures often indicate communication problems.
Historian failures often indicate communication problems.
Gateway redundancy should be regularly tested.
Gateway redundancy should be regularly tested.
16Engineer's Decision Point
You observe: SCADA communication alarms. ALCMS operational. PLCs operational. Field equipment operating normally. Historian updates stopped. What should you investigate first?
17Knowledge Check
18Interview Questions
19Frequently Asked Questions
Quick answers about SCADA communication failure and OPC gateway diagnosis.
Q1What is AGL-CS-096?
AGL-CS-096 is an engineering training case study. It covers a SCADA system that lost communication with the airfield lighting automation network while field equipment and the ALCMS kept operating. It is an engineering simulation created for training, not a report of an actual airport incident.
Q2What was lost and what kept working?
SCADA showed communication alarms, frozen status, stopped historical updates and no remote control. CCRs, PLCs, local ALCMS workstations and field equipment all kept working.
Q3Which layers were verified healthy?
Field equipment, the ALCMS and the SCADA server, including its HMI and historian, were all healthy.
Q4How was the fault located?
OPC diagnostics showed no active data points, a failed gateway connection, subscription timeouts and invalid data quality. Testing found SCADA to gateway healthy but gateway to ALCMS failed, with an active gateway fault.
Q5What was the root cause of AGL-CS-096?
Failure of the OPC communication gateway connecting SCADA to the ALCMS network, causing loss of data updates, supervisory alarms, historical transfer and remote supervisory control.
Q6Why does this matter operationally?
The supervisory layer depends on its gateway. When it fails, operators lose monitoring and alarms even though lighting control continues locally.
Q7How was supervision restored?
The team restarted gateway services, replaced the failed gateway and verified OPC communication. They also restored historian updates, verified alarm synchronization, data quality and remote supervisory control, tested redundancy switching and updated gateway software.
Q8What preventive step followed?
The team implemented gateway health monitoring.
Q9What is the key lesson from this case?
Work through the layers: field, PLC, ALCMS, gateway, OPC and SCADA. A lost supervisory view does not mean the field equipment has failed.
Engineering & Expert Notes
Treat the Gateway as a Critical Component
ArchitectureA single gateway can silence the supervisory layer.
Check the Alarm and Historian Data for Gaps
EvidenceMissing data shows when the interruption began.
Verify Field Systems Are Unaffected
VerificationConfirm local operation to avoid unnecessary work.
Maintain Configuration Backups for the Gateway
BackupRestore quickly if replacement is needed.
20Case Study Conclusion
SCADA communication failures are supervisory-system communication failures caused by gateway defects, OPC communication interruptions, protocol-conversion failures, and supervisory-interface problems, and effective diagnosis requires independent verification of field equipment, PLC operation, ALCMS functionality, gateway communication, OPC status, historian data flow, and supervisory-system integrity.
Systematic field verification, ALCMS testing, OPC diagnostics, gateway analysis, historian validation, redundancy testing, and post-repair supervisory verification provide a complete engineering methodology for restoring reliable SCADA communication and centralized airport lighting supervision.
In AGL engineering, the field equipment may still be working perfectly while the SCADA system has lost the ability to observe, record, and supervise it, which makes supervisory communication one of the most important invisible systems in airport operations.
Turn Case Studies Into Engineering Capability
A case study shows you how a problem is investigated. Precision AGL Academy helps you build the knowledge to understand why it happens, diagnose it systematically, and apply the right engineering approach.
Study real-world-style engineering scenarios, identify failure patterns, understand root causes, and develop a systematic approach to AGL troubleshooting.
Study the case. Understand the system. Build the skill.
Follow the Academy
Important Notice, Disclaimer & Limitation of Liability
Please read before relying on any content on this page or on any record downloaded from it.
- Purpose and intended users. This page is an independent educational and informational reference for competent, suitably trained and authorised airfield ground lighting (AGL) and aerodrome electrical personnel. It is not professional engineering, legal or regulatory advice, and using it does not create any professional or client relationship.
- Fictional training simulation. This case study is an engineering simulation created for training. It is not a report of an actual airport incident. Scenarios, sequences, dates, readings, measurements, outcomes and numerical values are illustrative and invented for teaching. No fault, failure, cause or liability is attributed to any person, company, airport, regulator, manufacturer or product, and any resemblance to a real event is coincidental. The content is not a forensic, legal, insurance, regulatory or accident-investigation finding and must not be cited as evidence, as a record of an event, or as a basis for disciplinary, contractual, insurance or legal action.
- Safety. Work on series circuits, constant current regulators (CCRs), isolating transformers, cables, connectors and control equipment can be fatal. Always apply the aerodrome’s permit-to-work and isolation/LOTO procedures, prove dead, use correctly rated instruments and PPE, and follow the manufacturer’s instructions. Nothing here authorises work on live equipment or the bypassing of any safety device or interlock. Where a case narrates an inspection, measurement or test, that narrative is not an instruction or an endorsement of the method.
- Values, test results and acceptance. Test voltages, insulation-resistance and current values, tolerances, thresholds, photometric and angular figures and pass/fail or “acceptable” wording in a case are specific to its invented scenario. They are not acceptance criteria, limits or targets. Use the project specification, the applicable standard and the manufacturer’s data for real work. Completing or following a case produces no test certificate, calibration record, acceptance or evidence of compliance.
- Aviation operations. Nothing here authorises return to service, a change of operating category (CAT I/II/III), a NOTAM, a flight inspection outcome or any aerodrome certification decision. These rest with the aerodrome operator, the air navigation service provider and the competent regulator.
- Standards and regulations. References to ICAO, FAA, IEC, IEEE, ISO and other standards are for orientation only. They are summarised, may be incomplete or out of date, and standards are revised from time to time. Consult the current official editions. Following this content does not guarantee compliance with any law, standard or regulatory approval. Official documents, regulations and manufacturers’ instructions always prevail.
- Learning aids. Knowledge checks, decision points, interview questions, FAQs and suggested answers are teaching aids with illustrative answers. They are not an assessment, certification, accreditation or competency or authorisation to work on any aerodrome, and they do not predict or guarantee the outcome of any job interview or application.
- Generic content; no warranty. Diagnostic sequences, cause rankings, tolerances and values are generic and indicative; real installations differ in design, equipment make and model, age and condition. Content is provided “as is” and “as available”, without warranty of any kind, express or implied, including accuracy, completeness, currency or fitness for a particular purpose.
- Limitation of liability. To the fullest extent permitted by applicable law, Precision AGL Academy and its owners, authors and contributors are not liable for any injury, death, loss, damage, downtime, penalty or regulatory consequence, whether direct or indirect, arising from the use of, reliance on, or inability to use this content. Nothing in this notice excludes or limits any liability that cannot lawfully be excluded or limited.
- Independence and trademarks. This is an independent publication, not affiliated with or endorsed by ICAO, the FAA, the IEC, DGCA, any airport, regulator or equipment manufacturer. Third-party names, standard designations and trademarks belong to their respective owners and are used for identification only.
- Copyright and use. © 2026 Precision AGL Academy. All rights reserved. You may read this page and use it for personal reference and internal training, keeping this notice attached. Any other copying, republication, redistribution, scraping or commercial use requires our prior written permission.
- Corrections. Content is reviewed periodically, with no obligation to update. To report an error, safety concern or rights issue, write to precisionaglsolutions@gmail.com.