AGL-CS-097 — Local Control Works but Remote Control Fails
The AGL Knowledge Hub | Engineering Case Study Series. A control-system investigation where an incorrectly configured remote-authorization signal prevented remote operation — from local verification through PLC logic analysis, authorization testing, and configuration correction.
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 evening operations, the airport operations center reported that Taxiway Circuit TW-7 could not be switched ON from the ALCMS workstation.
Operators observed:
- Remote ON command failed.
- Remote OFF command failed.
- Brightness changes failed.
- ALCMS communication appeared healthy.
- No major communication alarms were active.
However, field inspection confirmed that:
- Local control-panel operation was normal.
- Circuit energized correctly locally.
- CCR output was normal.
- Field lights operated correctly.
Because local operation remained fully functional while remote operation failed, a detailed investigation was initiated covering remote/local selection, PLC control logic, command processing, control-permission logic, interlocks, communication verification, control relays, and command acknowledgment.
The investigation identified a control-permission logic lockout caused by an incorrectly configured remote-control authorization signal, preventing PLC remote commands from reaching the field control circuit.
This case demonstrates that local operation confirms equipment health, while remote-control failure usually indicates a problem in the automation control path, authorization logic, or control interface.
2Learning Objectives
After completing this case study, the learner should be able to:
- Diagnose local-vs-remote control failures.
- Verify remote control architecture.
- Test PLC command processing.
- Investigate control-permission logic.
- Analyze interlock conditions.
- Restore remote control functionality.
- Validate automation control integrity.
3System Background
A typical remote-control architecture includes:
- ALCMS workstation.
- SCADA server.
- PLC controller.
- Communication network.
- Remote-control authorization logic.
- Interlock logic.
- Output relays.
- Local/remote selector.
- Field control panel.
- Lighting circuit.
Remote-control failures may result from:
- Authorization logic errors.
- Local/remote selector problems.
- PLC output failures.
- Interlock activation.
- Control relay failures.
- Command-processing errors.
- Configuration errors.
- Software modifications.
Remote operation requires both communication and control authorization.
4Problem Statement
The reported condition was:
- Local control operational.
- Remote control failed.
- Communication healthy.
- Field equipment operational.
- ALCMS commands ineffective.
Why does local control operate normally while remote control commands are not executed?
5Initial Observations
| Local operation | Normal |
| Remote operation | Failed |
| Communication | Healthy |
| Field equipment | Healthy |
| ALCMS alarms | None |
The symptoms suggested a remote-control path problem.
6Initial Engineering Hypotheses
The investigation considered:
Communication failure.
PLC output failure.
Remote authorization failure.
Control relay failure.
Interlock logic activation.
7Control-Path Principle
Local operation bypasses part of the remote control path.
8Test Equipment
The investigation used:
- PLC programming software.
- Digital multimeter.
- Signal analyzer.
- Relay test equipment.
- ALCMS diagnostics.
- Network diagnostic tools.
- Control schematics.
- Event logs.
9Investigation
Step 1: Verify Local Operation
Testing confirmed:
| Local ON/OFF | Normal |
| Circuit energization | Normal |
| CCR operation | Normal |
| Field lighting | Normal |
The field equipment was healthy.
Step 2: Verify Communication
Communication testing showed:
- PLC communication healthy.
- ALCMS connected.
- Status updates normal.
- No communication errors.
Communication was healthy.
Step 3: Verify Command Transmission
ALCMS event logs showed:
- Command transmitted.
- PLC received command.
- Command processed.
- No output activation occurred.
The PLC received the remote command.
Step 4: PLC Logic Analysis
PLC monitoring showed:
Remote command bit: ON
Output command bit: OFF
Authorization bit: OFF
The authorization logic blocked the command.
Step 5: Authorization Logic Verification
Logic analysis identified:
Remote output permitted only when:
- Remote authorization active.
- Maintenance lockout inactive.
- Emergency interlock clear.
- Local override disabled.
The remote authorization signal was inactive.
Step 6: Authorization Input Test
Input testing showed:
Remote authorization input: OFF
Expected: ON
The authorization signal was missing.
Step 7: Configuration Review
Investigation revealed:
- Recent software modification.
- Incorrect remote-permission mapping.
- Authorization signal assigned to the wrong input address.
The PLC configuration was incorrect.
10Root Cause
Remote control failed because of incorrect PLC remote-control authorization logic configuration, resulting in:
- Remote command rejection.
- Output inhibition.
- Failure of remote control.
- Normal local operation.
Communication and field equipment remained healthy.
The primary failure mechanism was control-permission logic misconfiguration.
11Corrective Action
The engineering team:
- Corrected PLC authorization mapping.
- Verified input addressing.
- Tested authorization logic.
- Verified interlock operation.
- Tested remote ON/OFF commands.
- Tested brightness control.
- Verified command acknowledgment.
- Updated software documentation.
- Implemented configuration validation.
- Performed full remote-control testing.
12Post-Repair Verification
Configuration correction restored full remote control.
13Root-Cause Analysis
Remote control failed
Healthy
Healthy
Received
Blocked
Incorrect mapping
Remote control verified operational
Remote-control authorization logic error
Restore PLC control-permission integrity
14Why This Case Was Important
Remote-control failures can cause:
- Loss of centralized lighting control.
- Increased manual operation.
- Delayed operational response.
- Reduced automation capability.
- Increased maintenance workload.
- Operational inefficiency.
Control authorization is a critical automation function.
15Engineering Lessons
Successful local operation confirms field-equipment health.
Successful local operation confirms field-equipment health.
Communication alone does not guarantee remote control.
Communication alone does not guarantee remote control.
Authorization logic should be verified before replacing hardware.
Authorization logic should be verified before replacing hardware.
PLC monitoring provides valuable control-path diagnostics.
PLC monitoring provides valuable control-path diagnostics.
Configuration validation is essential after software modifications.
Configuration validation is essential after software modifications.
16Engineer's Decision Point
You observe: Local control works. Remote control fails. Communication healthy. Field equipment operational. What should you investigate first?
17Knowledge Check
18Interview Questions
19Frequently Asked Questions
Quick answers about remote control failure and PLC authorization logic.
Q1What is AGL-CS-097?
AGL-CS-097 is an engineering training case study. It covers a taxiway circuit that worked locally but could not be switched from the ALCMS because of a control-permission lockout. It is an engineering simulation created for training, not a report of an actual airport incident.
Q2What does it mean when local control works but remote fails?
Local operation confirms the equipment is healthy. Remote failure points to the automation control path, authorization logic or control interface.
Q3How did the command flow in AGL-CS-097?
The ALCMS transmitted the command and the PLC received and processed it, but no output activated. The remote command bit was ON while the output command bit and authorization bit were OFF.
Q4What does the PLC require before it permits a remote output?
Remote authorization active, maintenance lockout inactive, emergency interlock clear and local override disabled. The remote authorization input was OFF when it should have been ON.
Q5Was communication or the field equipment at fault?
No. PLC communication was healthy, the ALCMS was connected, status updates were normal and the CCR and lights worked locally.
Q6What was the root cause of AGL-CS-097?
Incorrect PLC remote-control authorization logic configuration, caused by a recent software modification with incorrect remote-permission mapping. This inhibited outputs and rejected remote commands.
Q7How was it corrected?
The team corrected the PLC authorization mapping and verified input addressing, authorization logic and interlock operation. They tested remote ON/OFF and brightness control, verified command acknowledgment, updated software documentation, implemented configuration validation and performed full remote-control testing.
Q8How does this differ from AGL-CS-092?
In 092 a physical interface relay failed. Here the hardware was fine and the PLC logic itself blocked the command.
Q9What is the key lesson from this case?
After software changes, test the full remote-control path, including permissions and interlocks.
Engineering & Expert Notes
Review the Authorisation Conditions in the PLC
LogicRemote commands are accepted only if conditions are met. Check them.
Use Monitoring to Watch the Command Path
DiagnosticsOnline monitoring shows where the command is blocked.
Control Changes to Control Logic
Change ControlLogic changes need review and testing before release.
Test Remote Control After Software Changes
VerificationInclude remote commands in post-change checks.
20Case Study Conclusion
When local control works but remote control fails, the field equipment is usually healthy, and effective diagnosis requires systematic verification of the remote control path, PLC command processing, authorization logic, interlock conditions, output relays, communication integrity, and control-system configuration.
Systematic local verification, communication testing, PLC logic analysis, authorization verification, interlock testing, and post-repair remote-control validation provide a complete engineering methodology for restoring reliable remote airfield lighting control and maintaining airport automation integrity.
In AGL engineering, the most valuable diagnostic clue is often the fact that the equipment responds perfectly to local control, because that immediately tells the engineer where not to look and where the real control-system problem is likely to exist.
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.