Division 19 — ALCMS / Control & Monitoring Troubleshooting

01 · ALCMS / Control & Monitoring Faults

20 of 20 topics published

ALC-471 ALCMS Not Starting

Symptom — The ALCMS server/workstation application fails to start or complete its boot sequence after a restart, power cycle, or scheduled maintenance.

Equipment / System

ALCMS server/workstation — the central software application (client/server) running on redundant servers/workstations in the ATC tower or airport operations building, providing the operator interface for lighting control and monitoring.

Possible Causes

HighOS or a critical application service failing to start after a restart or power cycle

HighDatabase service (SQL Server/Oracle or equivalent) not starting, blocking the application from initialising

MedSoftware licence or dongle/licence-server unreachable at startup

MedCorrupted application configuration file preventing a clean startup

LowServer hardware fault (disk, RAM, power supply)

LowAntivirus or an OS update conflicting with the ALCMS service

Required Tools

Server console/KVM accessOS event log viewerALCMS application/service logsDatabase administration toolLicence server diagnostic utilitySpare server/workstation hardware

Safety Precautions

Coordinate with ATC before restarting the primary ALCMS server, since lighting control may need to fail over to a backup system or local manual control.
Follow the site change-management procedure for any server-level intervention.

Diagnostic Procedure

ObservationCheck the server power and OS boot status to confirm whether the hardware/OS layer started correctly.
ObservationReview the OS and application event logs for the specific point of startup failure.
MeasurementConfirm the database service status independently of the ALCMS application.
MeasurementCheck licence server or dongle connectivity if the application reports a licensing error.
DecisionOS/hardware boots correctly but the application service fails → database or configuration fault. OS itself fails to boot → hardware fault.
Fault LocationIsolate to the OS/hardware layer, the database service, the licence system, or a corrupted configuration file.
Root CauseConfirm the specific failed component or file before restoring service.

Test Points

OS boot status

Database service status

Licence server connectivity

Application configuration file integrity

Root Cause Verification

Confirm ALCMS starts cleanly, all expected services report running, and the operator interface displays current field status correctly for a sample of monitored devices.

Corrective Action

Restart or repair the failed OS or database service.
Restore the application configuration from a known-good backup.
Repair or replace failed server hardware.
Renew or reconnect the software licence.

Preventive Action

Maintain a tested backup/standby ALCMS server with automatic or documented manual failover.
Schedule regular configuration backups.
Keep OS and database patching current within a controlled maintenance window.

Related References

SOP: SOP-ALC-01 (ALCMS Server Startup and Recovery Procedure)

Standards: ICAO Annex 14 Vol I (lighting control requirements), ALCMS vendor documentation

Diagram: ALCMS Server/Network Architecture Drawing

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-472 ALCMS Communication Failure

Symptom — ALCMS loses communication with the field PLC/RTU network broadly, affecting visibility and control of multiple CCRs or field devices simultaneously.

Equipment / System

Overall ALCMS communication path linking the ALCMS server to the field PLC/RTU network, which in turn communicates with individual CCRs and field devices.

Possible Causes

HighNetwork switch or router failure on the path between ALCMS and the field network

HighServer-side communication service or driver fault

MedProtocol converter or gateway failure

MedA misconfigured IP address/subnet following a network change

LowA widespread cable or fibre cut affecting the whole field network

LowServer-side firewall or security policy change blocking the communication port

Required Tools

ALCMS system log reviewNetwork diagnostic tools (ping/traceroute)Protocol analyserServer communication service diagnosticsNetwork architecture drawing

Safety Precautions

Coordinate with ATC — a full communication loss typically requires falling back to local manual CCR control per the documented fallback procedure.

Diagnostic Procedure

ObservationConfirm the scope of the failure from ALCMS — a single field device, a segment, or the entire network.
MeasurementCheck the server-side communication service status.
MeasurementPing/test the network path to a representative sample of field devices.
MeasurementCheck network switch/router status along the path.
DecisionOnly a segment affected → isolate to that segment's switch/cable. Entire network affected → server-side service or core network fault.
Fault LocationIsolate to the server communication service, a network switch/router, a protocol gateway, or a widespread cable fault.
Root CauseConfirm the specific failed component before restoring communication.

Test Points

Server communication service status

Network path continuity to field devices

Network switch/router status

Protocol gateway diagnostics

Root Cause Verification

Confirm ALCMS re-establishes communication with all field devices, and cross-check reported status against a physical inspection for a sample of devices.

Corrective Action

Restart the server communication service.
Replace failed network hardware.
Correct IP/network configuration.
Repair the identified cable/fibre fault.

Preventive Action

Implement redundant communication paths where practical.
Monitor network health proactively with management tools.
Maintain accurate network documentation and change records.

Related References

SOP: SOP-ALC-02 (ALCMS Communication Fault Isolation Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS/SCADA vendor documentation

Diagram: ALCMS Network Architecture Drawing

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-473 CCR Not Visible on ALCMS

Symptom — A specific CCR that should be reporting to ALCMS no longer appears, or appears with no data, while other CCRs continue reporting normally.

Equipment / System

An individual CCR's representation/tag within the ALCMS system — the specific point/device address that should report that CCR's status.

Possible Causes

HighThat CCR's RTU/PLC communication module has failed or lost power

MedThe CCR's device address/point configuration has been removed or corrupted in the ALCMS database

MedA local communication segment (e.g. a sub-network from a field cabinet) is down, affecting this CCR and others on the same segment

LowA physical comm cable/fibre fault specific to that CCR's connection

LowThe CCR was intentionally powered down or isolated for maintenance without updating ALCMS

Required Tools

ALCMS diagnostic terminalField RTU/PLC diagnostic toolTrue-RMS multimeterCable testerCCR-to-ALCMS point configuration list

Safety Precautions

Coordinate access to the CCR cabinet.
LOTO before any RTU/communication module work.

Diagnostic Procedure

ObservationConfirm whether other CCRs on the same communication segment are also missing (segment-level) or only this one (device-level).
MeasurementCheck the RTU/PLC communication module at the CCR for power and status.
ObservationVerify the device address/point configuration in ALCMS matches the CCR's actual field address.
MeasurementInspect the local cable/fibre connection for that CCR.
DecisionOther CCRs on the segment also missing → segment-level fault, route to ALC-483/485/486. Only this CCR affected → device-level fault.
Fault LocationIsolate to the RTU/PLC comm module, the ALCMS point configuration, or the local cable/fibre connection.
Root CauseConfirm the specific cause before restoring visibility.

Test Points

RTU/PLC comm module status at the CCR

ALCMS point configuration

Local segment communication status

Cable/fibre continuity

Root Cause Verification

Confirm the CCR reappears on ALCMS with correct real-time status matching its actual field state.

Corrective Action

Restore power to or repair the RTU/PLC comm module.
Correct the ALCMS point configuration.
Repair the identified local cable/fibre fault.
Confirm and document the CCR's state if it had been intentionally isolated.

Preventive Action

Maintain an accurate CCR-to-ALCMS point configuration list.
Include RTU/PLC health checks in the periodic maintenance cycle.
Update ALCMS promptly whenever a CCR is taken out of service.

Related References

SOP: SOP-ALC-03 (Field Device Visibility Verification Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: CCR-to-ALCMS Point Configuration List

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-474 Wrong CCR Status

Symptom — ALCMS displays a CCR status (ON/OFF or fault) that does not match the CCR's actual physical state, confirmed by field inspection.

Equipment / System

CCR status feedback point on ALCMS — the ON/OFF or fault status displayed for a specific CCR, sourced from a status sensor or contact at the CCR.

Possible Causes

HighStatus feedback sensor/contact at the CCR reporting incorrectly (stuck relay, miswired feedback)

MedALCMS point configured against the wrong CCR (a mapping error)

MedA stale/latched status not updating after the actual field state changed

LowA communication delay causing a temporarily stale display

LowA genuine intermittent fault at the CCR being masked by an apparently incorrect status

Required Tools

True-RMS multimeterALCMS diagnostic terminalCCR feedback wiring diagramDirect physical CCR inspection

Safety Precautions

Coordinate access to the CCR cabinet.
LOTO before feedback wiring work.

Diagnostic Procedure

ObservationPhysically verify the actual CCR status against what ALCMS displays.
MeasurementCheck the feedback sensor/contact wiring at the CCR.
ObservationConfirm the ALCMS point mapping is assigned to the correct CCR.
ObservationObserve over a short period to check whether the discrepancy is a communication delay rather than a hard fault.
DecisionPhysical state and feedback wiring correct but ALCMS shows a different CCR's status → mapping error. Feedback wiring itself faulty → repair at the CCR.
Fault LocationIsolate to the feedback sensor/contact, the ALCMS point mapping, or a communication delay.
Root CauseConfirm the specific cause before correction.

Test Points

Physical CCR status

Feedback sensor/contact continuity

ALCMS point mapping

Communication update latency

Root Cause Verification

Change the CCR's actual state under a controlled test and confirm ALCMS updates correctly and promptly.

Corrective Action

Repair or replace the feedback sensor/contact.
Correct the ALCMS point mapping.
Address the communication delay if it is source-side.

Preventive Action

Verify feedback wiring and point mapping during commissioning and after any CCR replacement.
Include status accuracy spot-checks in the periodic maintenance cycle.

Related References

SOP: SOP-ALC-04 (Status Feedback Verification Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: CCR Feedback Wiring Diagram

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-475 Wrong CCR Current Display

Symptom — The output current value displayed on ALCMS for a specific circuit does not match a reference measurement taken directly at the CCR.

Equipment / System

CCR output current value displayed on ALCMS for a specific circuit, sourced from a current transducer (CT) at the CCR and reported through the RTU/PLC analog input.

Possible Causes

HighCurrent transducer (CT) at the CCR faulted or drifted out of calibration

HighAnalog signal wiring fault between the CT and the RTU/PLC analog input

MedIncorrect scaling/calibration configured in the ALCMS point (engineering units mismatch)

MedAnalog input module fault on the RTU/PLC

LowElectrical noise or interference on the analog signal wiring producing an unstable reading

Required Tools

Calibrated clamp-on ammeter (reference measurement)True-RMS multimeterCT calibration/test equipmentRTU/PLC analog input diagnostic toolALCMS point scaling configuration

Safety Precautions

LOTO before CT or wiring work.
Treat CT secondary circuits with care per applicable practice — do not open-circuit an energised current transformer secondary.

Diagnostic Procedure

MeasurementTake a reference current measurement directly at the CCR with a calibrated clamp-on ammeter.
ObservationCompare the reference measurement against the ALCMS displayed value.
MeasurementCheck the CT and its wiring to the RTU/PLC analog input.
ObservationVerify the ALCMS point scaling/calibration configuration.
DecisionReference measurement and ALCMS display disagree with CT/wiring confirmed sound → scaling/configuration fault. CT itself out of calibration or wiring faulty → repair at the CCR.
Fault LocationIsolate to the CT, the analog signal wiring, the analog input module, or the ALCMS point scaling.
Root CauseConfirm the specific cause across a range of operating currents before correction.

Test Points

Reference clamp-on ammeter reading

CT output signal

Analog input module reading

ALCMS point scaling configuration

Root Cause Verification

Confirm the ALCMS displayed current matches a reference measurement across the operating range and at each intensity step.

Corrective Action

Replace or recalibrate the CT.
Repair the analog signal wiring.
Correct the ALCMS point scaling configuration.
Replace a faulted analog input module.

Preventive Action

Include CT calibration verification in the periodic maintenance cycle.
Shield and route analog signal wiring away from sources of interference.
Verify scaling configuration after any RTU/PLC replacement.

Related References

SOP: SOP-ALC-05 (Analog Signal Verification Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: CCR Analog Signal Wiring Diagram

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-476 Wrong Intensity Display

Symptom — The intensity step shown on ALCMS for a circuit does not match the CCR's actual commanded or operating intensity step, confirmed at the CCR panel.

Equipment / System

Intensity step indication displayed on ALCMS for a specific circuit, reflecting the CCR's actual commanded/operating intensity step.

Possible Causes

HighCCR reporting an incorrect step status back to the RTU/PLC (an internal CCR feedback fault)

MedALCMS point configuration mismatched to the CCR's actual step numbering/convention

MedCommunication or scaling error in the step feedback signal

LowA stale display not updating after a step change

LowA discrepancy between commanded step (sent by ALCMS) and actual step (reported by the CCR) due to a CCR-side fault

Required Tools

True-RMS multimeterALCMS diagnostic terminalCCR step feedback wiring diagramDirect physical intensity observation at the CCR panel

Safety Precautions

LOTO before feedback wiring work.
Coordinate any live step-change testing with ATC.

Diagnostic Procedure

ObservationPhysically confirm the CCR's actual operating step directly at the CCR panel.
ObservationCompare the physical step against the ALCMS displayed value.
MeasurementCheck the step feedback wiring/signal from the CCR to the RTU/PLC.
ObservationVerify the ALCMS point configuration matches the CCR's step convention.
DecisionPhysical step and feedback signal correct but ALCMS shows a different step → ALCMS point configuration fault. Feedback signal itself wrong → CCR-side fault.
Fault LocationIsolate to the CCR's internal step feedback, the ALCMS point configuration, or the feedback wiring/signal path.
Root CauseConfirm the specific cause before correction.

Test Points

CCR panel actual step indication

Step feedback signal

ALCMS point configuration

Commanded vs. reported step comparison

Root Cause Verification

Command a step change from ALCMS and confirm the displayed value updates correctly and matches the CCR's actual operating step.

Corrective Action

Repair the CCR's internal step feedback.
Correct the ALCMS point configuration.
Repair the feedback wiring/signal path.

Preventive Action

Verify step feedback accuracy during commissioning and after any CCR firmware/configuration change.
Include step display accuracy in periodic functional testing.

Related References

SOP: SOP-ALC-05 (Analog Signal Verification Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: CCR Step Feedback Wiring Diagram

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-477 Remote Command Failure

Symptom — A command issued from the ALCMS operator interface to a CCR or lighting circuit is not correctly executed in the field, without being specific to a step-change or ON/OFF command.

Equipment / System

General remote command path from the ALCMS operator interface to a CCR or lighting circuit — command generation, transmission, and CCR-side execution.

Possible Causes

HighCommunication path failure between ALCMS and the target field device

HighThe CCR-side controller not accepting or executing the command

MedThe operator interface command not generated correctly

MedA command queue conflict from simultaneous operator/ATC input

LowA permission or interlock condition legitimately preventing the command from executing

Required Tools

ALCMS system log reviewNetwork diagnostic toolsRTU/PLC diagnostic softwareCCR local control panel

Safety Precautions

Coordinate with ATC before testing remote commands.
Confirm local manual control is available as a fallback before extended testing.

Diagnostic Procedure

ObservationConfirm the command was generated and logged correctly at ALCMS.
MeasurementCheck the communication path status to the target device.
MeasurementCheck the CCR's local controller for command receipt and execution.
ObservationCheck for any interlock or permission condition blocking the command.
DecisionCommand logged and communication path healthy but CCR does not execute → CCR-side controller fault. Command not logged at ALCMS → operator interface fault.
Fault LocationIsolate to the operator interface/command generation, the communication path, the CCR local controller, or an interlock/permission condition.
Root CauseConfirm the specific cause before correction.

Test Points

ALCMS command log

Communication path status

CCR local controller diagnostics

Interlock/permission status

Root Cause Verification

Issue a series of test commands and confirm each is executed correctly with accurate status feedback.

Corrective Action

Correct the operator interface/command generation fault.
Repair the communication path.
Repair the CCR local controller.
Resolve the interlock/permission conflict.

Preventive Action

Log and periodically review remote command success rate.
Verify interlock logic after any configuration change.
Provide clear operator guidance for handling command conflicts.

Related References

SOP: SOP-ALC-06 (Remote Command Fault Isolation Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: ALCMS Command Path Drawing

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-478 Remote Step Change Failure

Symptom — A commanded intensity step change from ALCMS fails to execute at the CCR, while other remote commands for the same CCR continue to work normally.

Equipment / System

Remote intensity step change command path — the specific function within the ALCMS remote command system for raising or lowering a circuit's intensity step.

Possible Causes

HighCCR-side step controller/relay not responding to the step-change command

HighA communication timeout specific to the step command, while ON/OFF commands work normally

MedThe ALCMS step command mapped to the wrong output/register on the RTU/PLC

MedA step limit or interlock preventing the requested step (e.g. a minimum step enforced under certain conditions)

LowAn intermediate protocol converter dropping step-change telegrams specifically

Required Tools

ALCMS diagnostic terminalRTU/PLC diagnostic softwareCCR step controller test equipmentProtocol analyser

Safety Precautions

Coordinate with ATC before testing step changes, since intensity affects visual guidance for active operations.

Diagnostic Procedure

ObservationConfirm whether ON/OFF commands work normally for the same CCR, isolating the fault to step-change specifically.
ObservationCheck the ALCMS command log for the step-change command.
MeasurementCheck the CCR's step controller/relay for command receipt.
ObservationCheck for a step limit or interlock condition preventing the requested step.
DecisionCommand logged and reaches the RTU/PLC but the CCR step controller does not respond → CCR-side fault. Command not reaching the correct register → mapping fault.
Fault LocationIsolate to the CCR step controller/relay, the RTU/PLC register mapping, a step limit/interlock, or a protocol converter.
Root CauseConfirm the specific cause before correction.

Test Points

ALCMS step command log

CCR step controller/relay status

RTU/PLC register mapping for the step command

Step limit/interlock status

Root Cause Verification

Command a series of step changes across the full intensity range and confirm each is executed correctly with accurate feedback.

Corrective Action

Repair the CCR step controller/relay.
Correct the RTU/PLC register mapping.
Resolve the step limit/interlock condition.
Repair the protocol converter.

Preventive Action

Verify step command mapping during commissioning and after any CCR or RTU/PLC replacement.
Include step-change testing in periodic functional checks.

Related References

SOP: SOP-ALC-06 (Remote Command Fault Isolation Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: ALCMS Command Path Drawing

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-479 Remote ON/OFF Failure

Symptom — A commanded ON or OFF from ALCMS fails to execute at the CCR, while step-change commands for the same CCR continue to work normally.

Equipment / System

Remote ON/OFF command path — the specific function within the ALCMS remote command system for switching a circuit fully on or off.

Possible Causes

HighCCR-side main contactor/relay not responding to the ON/OFF command

HighA communication timeout specific to the ON/OFF command

MedThe ALCMS ON/OFF command mapped to the wrong output on the RTU/PLC

MedAn interlock (e.g. a stop bar interlock) legitimately preventing the requested state

LowA local selector switch at the CCR left in a position that overrides remote control

Required Tools

ALCMS diagnostic terminalRTU/PLC diagnostic softwareCCR contactor test equipmentProtocol analyser

Safety Precautions

Coordinate with ATC before testing ON/OFF commands, especially for circuits governed by a safety interlock.

Diagnostic Procedure

ObservationConfirm whether step-change commands work normally for the same CCR.
ObservationCheck the ALCMS command log for the ON/OFF command.
MeasurementCheck the CCR's main contactor/relay for command receipt.
ObservationCheck the local selector switch position at the CCR and any interlock condition.
DecisionLocal selector switch found off remote → return to remote position. Interlock condition confirmed genuine → route to the relevant interlock procedure. Otherwise → contactor/relay or mapping fault.
Fault LocationIsolate to the CCR contactor/relay, the RTU/PLC register mapping, the local selector switch, or an interlock condition.
Root CauseConfirm the specific cause before correction.

Test Points

ALCMS ON/OFF command log

CCR contactor/relay status

RTU/PLC register mapping

Local selector switch position

Interlock status

Root Cause Verification

Command ON and OFF from ALCMS several times and confirm each is executed correctly with accurate feedback.

Corrective Action

Repair the CCR contactor/relay.
Correct the RTU/PLC register mapping.
Return the local selector switch to the remote position.
Resolve a genuine interlock fault per the relevant division's procedure.

Preventive Action

Verify ON/OFF command mapping during commissioning.
Include selector switch position checks in the periodic maintenance cycle.
Document interlock behaviour clearly for operators.

Related References

SOP: SOP-ALC-06 (Remote Command Fault Isolation Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: ALCMS Command Path Drawing

Case Study: Division 09 — Stop Bar/Guard Light Troubleshooting (interlock cross-reference); Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-480 Alarm Not Received

Symptom — A field condition that should have triggered an ALCMS alarm (fault, out-of-tolerance reading, communication loss) occurred, but no alarm was raised or displayed.

Equipment / System

ALCMS alarm management system — the logic and display that should generate an operator-visible alarm when a monitored field condition occurs.

Possible Causes

HighThe alarm point is not configured, or is disabled, in the ALCMS alarm database

HighThe alarm threshold/logic is set incorrectly so the actual field condition does not trigger it

MedThe alarm was generated at the field/RTU level but not transmitted or displayed due to a communication issue

MedThe alarm is suppressed by an active acknowledgement/silence setting from a previous event

LowAn ALCMS alarm server/service fault

Required Tools

ALCMS alarm configuration/database review toolALCMS system logRTU/PLC alarm logic diagnosticPhysical field condition verification

Safety Precautions

Treat any discovered alarm gap as a priority given its role in surfacing safety-relevant field conditions.

Diagnostic Procedure

ObservationConfirm the field condition that should have triggered an alarm actually occurred, and establish its timing.
ObservationCheck the alarm point configuration and threshold/logic in ALCMS.
MeasurementCheck whether the alarm was generated at the RTU/PLC but not transmitted to ALCMS.
ObservationCheck for an active suppression/silence setting on that alarm point.
DecisionAlarm generated at RTU/PLC but not received → transmission/communication fault. Alarm never generated → configuration/threshold fault.
Fault LocationIsolate to the alarm point configuration, the threshold/logic setting, the transmission path, or a suppression setting.
Root CauseConfirm the specific cause before correction.

Test Points

Alarm point configuration

Threshold/logic setting

RTU/PLC alarm generation

Alarm transmission/communication

Suppression/silence status

Root Cause Verification

Trigger a controlled test condition, or simulate the alarm point where safe to do so, and confirm it is correctly received, displayed, and logged.

Corrective Action

Correct the alarm point configuration or threshold.
Repair the transmission/communication path.
Clear an inappropriate suppression setting.
Restart or repair the ALCMS alarm service.

Preventive Action

Periodically audit the alarm configuration database against the actual field point list.
Test alarm generation end-to-end on a defined schedule.
Review suppression/silence usage logs.

Related References

SOP: SOP-ALC-07 (Alarm Verification Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: ALCMS Alarm Configuration List

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-481 False Alarm

Symptom — ALCMS raises an alarm without a corresponding genuine field condition, confirmed by physical inspection or independent measurement.

Equipment / System

ALCMS alarm management system, in this case generating an alarm without a corresponding genuine field condition.

Possible Causes

HighAlarm threshold set too tight/sensitive for normal operating variation (e.g. current fluctuation within normal tolerance)

HighA faulty sensor/transducer at the field device generating an erroneous reading that trips the alarm

MedElectrical noise or interference on a signal or communication line intermittently triggering the alarm logic

MedA software/logic fault in the alarm evaluation

LowA genuine but transient/self-clearing condition perceived as false because it resolved before investigation

Required Tools

ALCMS alarm history/log reviewField sensor/transducer test equipmentALCMS alarm configuration toolSignal quality logger/thermal camera

Safety Precautions

Do not disable or widen an alarm threshold without first confirming the underlying field condition is genuinely within normal tolerance.

Diagnostic Procedure

ObservationReview the alarm history log to identify the pattern and frequency of the alarm.
MeasurementCorrelate the alarm timing against the actual field condition via physical inspection or independent measurement.
ObservationCheck the alarm threshold/logic configuration for appropriateness.
MeasurementCheck the relevant sensor/transducer and signal path for noise or drift.
DecisionIndependent measurement confirms no genuine condition at alarm times → threshold too tight or sensor drift. Independent measurement confirms a genuine but transient condition → alarm is correct, review response process instead.
Fault LocationIsolate to the alarm threshold/logic, the sensor/transducer, or the signal path.
Root CauseConfirm the specific cause across several alarm occurrences before adjustment.

Test Points

Alarm history/log pattern

Independent field measurement at the time of alarm

Alarm threshold/logic configuration

Sensor/transducer and signal path condition

Root Cause Verification

Monitor the point over a subsequent period to confirm the alarm no longer triggers inappropriately, while still correctly triggering for a genuine test condition.

Corrective Action

Adjust the alarm threshold/logic to an appropriate value.
Repair or replace the faulty sensor/transducer.
Address the noise/interference source.
Correct the alarm evaluation logic.

Preventive Action

Review alarm threshold settings periodically against actual operating data.
Include sensor/transducer calibration in the periodic maintenance cycle.
Document the rationale for each alarm threshold to avoid future drift.

Related References

SOP: SOP-ALC-07 (Alarm Verification Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: ALCMS Alarm Configuration List

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-482 Alarm Not Clearing

Symptom — An active alarm persists on the ALCMS display after the underlying field condition appears to have been resolved.

Equipment / System

ALCMS alarm management system — in this case, an active alarm that persists after the underlying field condition has been resolved.

Possible Causes

HighThe underlying field condition has not actually been fully resolved despite appearing corrected

HighA latched alarm requiring manual acknowledgement/reset that has not been performed

MedA stale communication link preventing the cleared status from being received

MedAn alarm logic fault holding the alarm active regardless of the actual condition

LowA database/software fault in the alarm server retaining the alarm state

Required Tools

ALCMS alarm management terminalPhysical field condition verification/measurementRTU/PLC alarm logic diagnosticALCMS alarm server diagnostics

Safety Precautions

Confirm the field condition is genuinely resolved before manually clearing/acknowledging an alarm, to avoid masking a real ongoing fault.

Diagnostic Procedure

ObservationPhysically verify the underlying field condition is actually resolved.
ObservationCheck whether the alarm requires manual acknowledgement/reset per its configured behaviour.
MeasurementCheck communication status to confirm the cleared field status is being received.
ObservationCheck the alarm logic and server for a fault retaining the state.
DecisionField condition confirmed genuinely resolved and alarm configured to auto-clear → communication or logic fault. Field condition not actually resolved → investigate the underlying fault directly.
Fault LocationIsolate to the required manual acknowledgement, the communication link, or the alarm logic/server.
Root CauseConfirm the specific cause before clearing the alarm.

Test Points

Physical field condition

Alarm acknowledgement/reset requirement and status

Communication link status

Alarm server/logic diagnostics

Root Cause Verification

Confirm the alarm clears correctly and the alarm history log correctly timestamps the resolution.

Corrective Action

Complete the required manual acknowledgement/reset.
Repair the communication link.
Correct the alarm logic fault.
Restart or repair the alarm server.

Preventive Action

Document which alarms require manual acknowledgement vs. auto-clear.
Include alarm-clearing behaviour verification in periodic testing.
Monitor for a pattern of alarms not clearing that may indicate a systemic issue.

Related References

SOP: SOP-ALC-07 (Alarm Verification Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: ALCMS Alarm Configuration List

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-483 Communication Intermittency

Symptom — The ALCMS-to-field communication path exhibits periodic drop-outs rather than a complete or permanent loss, with connectivity intermittently recovering on its own.

Equipment / System

ALCMS-to-field communication path generally, exhibiting periodic drop-outs rather than a complete/permanent loss.

Possible Causes

HighMarginal signal quality on a communication cable/fibre segment (partial damage, poor termination) causing intermittent drop-outs

HighA network switch/port with an intermittent hardware fault

MedElectromagnetic interference affecting a communication segment periodically (e.g. near high-power equipment)

MedA communication device (RTU/PLC/gateway) overheating or resetting intermittently

LowA network loading/congestion issue causing periodic timeouts under peak polling load

Required Tools

Network diagnostic tools (extended ping/packet loss logging)Protocol analyserCable/fibre test equipment (OTDR for fibre)Thermal imaging cameraNetwork switch port diagnostics

Safety Precautions

Treat intermittent communication as a developing fault requiring investigation before it becomes a complete failure.

Diagnostic Procedure

ObservationReview the ALCMS communication log to establish the pattern, frequency, and any correlation with time of day, weather, or load.
MeasurementTest the suspect cable/fibre segment for signal quality/loss.
MeasurementCheck network switch port statistics for errors.
MeasurementCheck for a communication device resetting or overheating intermittently.
DecisionIntermittency correlates with load/time of day → congestion or thermal cause. Intermittency correlates with a specific segment regardless of load → cable/fibre or switch fault.
Fault LocationIsolate to the cable/fibre segment, the network switch/port, an interference source, or an overheating/resetting device.
Root CauseConfirm the specific cause before correction.

Test Points

Communication log pattern and correlation

Cable/fibre signal quality

Network switch port error statistics

Communication device thermal/reset behaviour

Root Cause Verification

Monitor the communication path over an extended period after correction to confirm the intermittency is resolved.

Corrective Action

Repair or replace the degraded cable/fibre segment.
Replace a faulted network switch/port.
Address the interference source.
Repair or replace an overheating/resetting communication device.

Preventive Action

Include periodic communication log review and packet-loss trending in the maintenance cycle.
Test cable/fibre segments proactively on ageing sections.
Monitor network switch port health.

Related References

SOP: SOP-ALC-02 (ALCMS Communication Fault Isolation Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: ALCMS Network Architecture Drawing

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-484 PLC Failure

Symptom — The field PLC/RTU that interfaces between the ALCMS network and one or more CCRs/field devices fails, taking multiple connected devices out of ALCMS visibility or control simultaneously.

Equipment / System

The field PLC (or RTU) that interfaces between the ALCMS communication network and one or more CCRs/field devices, handling local I/O, alarm logic, and communication.

Possible Causes

HighPLC CPU module hardware failure

HighPLC power supply failure

MedI/O module failure affecting a subset of connected devices

MedFirmware/program corruption after a power interruption during a write cycle

LowOverheating in the PLC cabinet from a failed cooling fan or blocked ventilation

LowA program logic fault introduced by an uncontrolled configuration change

Required Tools

PLC programming/diagnostic softwareTrue-RMS multimeterPLC cabinet thermal checkSpare PLC modulesPLC program backup/version records

Safety Precautions

LOTO the PLC cabinet before module replacement.
Coordinate the affected circuits' outage with ATC since a PLC failure can take multiple field devices out of ALCMS visibility/control simultaneously.

Diagnostic Procedure

ObservationCheck the PLC CPU status LEDs/diagnostics for fault codes.
MeasurementCheck the power supply output.
MeasurementCheck individual I/O module status for the affected devices.
ObservationCheck cabinet temperature and cooling fan operation.
DecisionCPU fault code present → CPU module fault. Power supply output absent/low → power supply fault. Only specific I/O affected → I/O module fault.
Fault LocationIsolate to the CPU module, the power supply, a specific I/O module, or cabinet cooling.
Root CauseConfirm the specific failed component before replacement.

Test Points

PLC CPU diagnostic status

Power supply output

I/O module status

Cabinet temperature

Root Cause Verification

After repair, confirm the PLC boots correctly, the program is running as expected, and all connected field devices report correct status to ALCMS.

Corrective Action

Replace the failed CPU or I/O module.
Replace the power supply.
Restore the program from a verified backup.
Repair the cooling system.

Preventive Action

Maintain current PLC program backups after every verified configuration change.
Include PLC cabinet cooling checks in the periodic maintenance cycle.
Follow a controlled change-management process for any program modification.

Related References

SOP: SOP-ALC-08 (PLC/RTU Fault Isolation Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor and PLC manufacturer documentation

Diagram: PLC/RTU Cabinet Wiring Diagram

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-485 Network Failure

Symptom — The communication network infrastructure connecting the ALCMS server(s) to the field PLC/RTU network fails, disrupting communication across a large portion of the system.

Equipment / System

Communication network infrastructure connecting the ALCMS server(s) to the field PLC/RTU network — switches, routers, and the backbone cabling/fibre linking the control room to field cabinets.

Possible Causes

HighNetwork switch or router hardware failure

HighA network loop or broadcast storm degrading or halting traffic

MedPower failure at a network cabinet/enclosure

MedA misconfigured VLAN/routing change disrupting connectivity

LowA backbone fibre/cable cut affecting a whole network segment

LowA cybersecurity event or unauthorised device causing network disruption

Required Tools

Network diagnostic tools (ping, traceroute, port mirroring)Managed switch diagnostic interfaceNetwork architecture drawingSpare network switch/routerFibre test equipment (OTDR)

Safety Precautions

Coordinate an extended network outage with ATC given the scale of impact.
Follow IT/OT change-management and cybersecurity procedures for any network-level intervention.

Diagnostic Procedure

ObservationIdentify the scope of the network failure — single switch, segment, or whole network — from ALCMS and direct network diagnostics.
MeasurementCheck network switch/router status and port diagnostics.
ObservationCheck for a loop or broadcast storm on the network.
MeasurementCheck power status at network cabinets.
DecisionScope limited to one switch/segment → hardware/cable fault at that point. Scope covers the whole network → core switch, loop, or power failure.
Fault LocationIsolate to a failed switch/router, a network loop/broadcast storm, a power failure, or a backbone cable/fibre fault.
Root CauseConfirm the specific cause before restoring the network.

Test Points

Network switch/router diagnostic status

Port error/traffic statistics

Power status at network cabinets

Backbone cable/fibre continuity

Root Cause Verification

Confirm full network connectivity is restored and ALCMS re-establishes communication with every field device, cross-checked against a physical inspection sample.

Corrective Action

Replace the failed switch/router.
Resolve the network loop/broadcast storm.
Restore power to the affected cabinet.
Repair the backbone cable/fibre fault.
Correct the VLAN/routing configuration.

Preventive Action

Implement network redundancy (ring topology, redundant switches) where practical.
Monitor network health proactively with SNMP/management tools.
Maintain accurate network documentation and change records.

Related References

SOP: SOP-ALC-02 (ALCMS Communication Fault Isolation Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation, applicable OT cybersecurity guidance

Diagram: ALCMS Network Architecture Drawing

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-486 Communication Cable Failure

Symptom — A specific communication cable or fibre segment within the ALCMS network is identified as faulted following investigation of a device- or segment-level communication issue.

Equipment / System

A specific communication cable or fibre segment within the ALCMS network — between a field cabinet and a PLC/RTU, or between network nodes.

Possible Causes

HighPhysical cable/fibre damage from excavation, pavement maintenance, or rodent activity

HighA degraded or improperly terminated connector/splice

MedMoisture ingress into a below-grade cable/fibre joint

MedUV or mechanical degradation of an above-ground cable run

LowA cable route exceeding the maximum specified length/attenuation for the protocol in use

LowCrosstalk or interference from routing alongside a high-power circuit

Required Tools

Cable/fibre test equipment (TDR for copper, OTDR for fibre)Continuity testerCable route as-built drawingSplice/termination toolsExcavation permit and utility locate if digging is required

Safety Precautions

LOTO the associated communication equipment before cable work.
Obtain excavation clearance and utility locates before opening pavement or ground.
Coordinate airside access as required.

Diagnostic Procedure

ObservationIdentify the specific cable/fibre segment implicated from the network diagnostic and route drawing.
MeasurementTest the segment with a TDR/OTDR to locate the fault distance and type (break, high attenuation, poor splice).
ObservationPhysically inspect accessible portions of the route for damage.
DecisionFault localised to a specific distance/splice → targeted repair at that point. No localised fault found but attenuation is high overall → route length/specification issue.
Fault LocationIsolate to a specific point along the cable/fibre route, a splice/termination, or an overall route length/attenuation issue.
Root CauseConfirm the specific cause once the fault location is exposed.

Test Points

Cable/fibre continuity and attenuation

Splice/termination quality

Physical route condition

Cable length/attenuation vs. protocol specification

Root Cause Verification

After repair, re-test the segment to confirm continuity/attenuation is within specification, and confirm communication is restored end-to-end.

Corrective Action

Repair or replace the damaged cable/fibre segment.
Re-terminate or re-splice a degraded connection.
Reroute a cable found too close to a high-power circuit source of interference.

Preventive Action

Maintain an accurate cable/fibre route as-built drawing.
Coordinate with civil works teams before excavation near known routes.
Use appropriately rated cable for below-grade or high-interference environments.

Related References

SOP: SOP-ALC-02 (ALCMS Communication Fault Isolation Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation, applicable cabling standards (e.g. TIA/EIA)

Diagram: ALCMS Network Architecture Drawing

Case Study: Division 25 — Field Case Study Troubleshooting

Rev 0 — Initial issue

ALC-487 HMI Failure

Symptom — The ALCMS Human-Machine Interface (HMI) application or workstation stops responding, crashes, or is otherwise unable to display status or accept commands.

Equipment / System

The ALCMS Human-Machine Interface (HMI) — the operator workstation/display application through which lighting status is viewed and commands are issued, distinct from the underlying server/database.

Possible Causes

HighHMI application crash or hang requiring a restart

HighGraphics/display driver fault on the operator workstation

MedCorrupted HMI project/configuration file

MedWorkstation hardware failure (monitor, GPU, power supply)

LowLoss of connection between the HMI client and the ALCMS server

LowAn operating system update or conflict affecting the HMI application

Required Tools

Workstation diagnostic toolsHMI application/service logsSpare workstation hardwareHMI project/configuration backupOS event log viewer

Safety Precautions

Confirm a backup/secondary HMI workstation or local manual control is available before taking the primary HMI out of service.
Coordinate with ATC.

Diagnostic Procedure

ObservationAttempt to restart the HMI application and, if unsuccessful, the workstation.
ObservationReview the HMI application/OS logs for the failure cause.
MeasurementCheck the connection between the HMI client and the ALCMS server.
MeasurementCheck workstation hardware for a fault.
DecisionHMI restarts cleanly but the connection to the server is lost → connection/network fault. Application will not restart at all → corrupted configuration or hardware fault.
Fault LocationIsolate to the HMI application, the HMI-to-server connection, or workstation hardware.
Root CauseConfirm the specific cause before restoring service.

Test Points

HMI application/service status

HMI-to-server connection status

Workstation hardware diagnostics

HMI project/configuration integrity

Root Cause Verification

Confirm the HMI restarts cleanly, displays accurate real-time field status, and correctly issues a test command.

Corrective Action

Restart or repair the HMI application or workstation.
Restore the HMI project/configuration from a verified backup.
Repair or replace failed workstation hardware.
Restore the HMI-to-server connection.

Preventive Action

Maintain a tested backup/secondary HMI workstation.
Schedule regular configuration backups.
Keep the HMI workstation OS/application patching current within a controlled maintenance window.

Related References

SOP: SOP-ALC-09 (HMI Fault Isolation Procedure)

Standards: ICAO Annex 14 Vol I, ALCMS vendor documentation

Diagram: ALCMS Server/Network Architecture Drawing

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-488 HMI Touchscreen Failure

Symptom — The touchscreen input on an HMI workstation or panel fails to register touch correctly, either entirely or in specific screen areas.

Equipment / System

Touchscreen input hardware on an HMI workstation or panel, where operator commands are issued via touch rather than (or in addition to) keyboard/mouse.

Possible Causes

HighTouchscreen digitiser hardware failure (no response to touch)

HighTouchscreen calibration drift causing inaccurate touch registration

MedA damaged or scratched screen surface affecting touch sensitivity in specific areas

MedA loose or damaged USB/connection cable between the touchscreen and the workstation

LowDriver software fault following an OS update

LowSurface contamination (dust, grease) reducing touch responsiveness

Required Tools

Touchscreen calibration utilityUSB/connection cable testerScreen cleaning kit rated for touchscreen surfacesDriver installation mediaReplacement touchscreen unit

Safety Precautions

Confirm keyboard/mouse fallback control is available before taking the touchscreen out of service for testing or replacement.

Diagnostic Procedure

ObservationConfirm whether the touchscreen responds at all or only in specific screen areas.
MeasurementCheck the touchscreen calibration.
MeasurementCheck the physical connection cable.
ObservationCheck driver status in the OS, and inspect the screen surface for contamination or damage.
DecisionTouch registration off by a consistent offset across the screen → calibration drift. No response at all → connection or driver fault.
Fault LocationIsolate to touchscreen calibration, the connection cable, the driver, or physical screen damage/contamination.
Root CauseConfirm the specific cause before correction.

Test Points

Touch registration accuracy across the full screen

Connection cable continuity

Driver status

Screen surface condition

Root Cause Verification

Run a full-screen calibration/touch test and confirm accurate registration across the entire display before returning to operational use.

Corrective Action

Recalibrate the touchscreen.
Reseat or replace the connection cable.
Reinstall or update the driver.
Clean the screen surface.
Replace the touchscreen unit if hardware-faulted.

Preventive Action

Include touchscreen calibration and cleaning in the periodic maintenance cycle.
Protect the screen surface where practical.
Maintain keyboard/mouse as a standing fallback input method.

Related References

SOP: SOP-ALC-09 (HMI Fault Isolation Procedure)

Standards: ALCMS vendor documentation

Diagram: ALCMS Server/Network Architecture Drawing

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-489 Data Logging Failure

Symptom — The ALCMS data logging/historian function stops recording periodic field values, or a review finds a gap in the recorded data for one or more points.

Equipment / System

ALCMS data logging function — the database/historian recording periodic field values (current, status, intensity step) for trending, reporting, and compliance records.

Possible Causes

HighDatabase service failure, or the logging database reaching its storage capacity limit

MedA logging configuration error omitting a point that should be recorded

MedA communication interruption preventing data from reaching the logging database during an outage

LowDatabase corruption from an improper shutdown

LowA scheduled maintenance/archiving task failing to run and filling the active database

Required Tools

Database administration toolALCMS logging configuration reviewServer storage capacity monitoringDatabase backup/restore utility

Safety Precautions

Follow standard IT/OT change-management procedure for any database-level intervention.
Coordinate with data/compliance stakeholders if historical records may be affected.

Diagnostic Procedure

ObservationCheck the database service status and available storage capacity.
ObservationReview the logging configuration for the affected point(s).
ObservationCheck for a communication gap correlating with the missing data period.
MeasurementCheck for database corruption.
DecisionStorage capacity reached → free/expand capacity and check archiving task. Configuration omits the point → correct the configuration.
Fault LocationIsolate to the database service/capacity, the logging configuration, a communication gap, or database corruption.
Root CauseConfirm the specific cause before correction.

Test Points

Database service status

Storage capacity

Logging configuration completeness

Communication log correlation with any data gap

Root Cause Verification

Confirm logging resumes correctly for all configured points and a subsequent data export/report reflects complete, accurate records.

Corrective Action

Restart or repair the database service.
Free or expand storage capacity.
Correct the logging configuration.
Repair the database from a verified backup if corrupted.

Preventive Action

Monitor database storage capacity proactively with alerting before capacity is reached.
Schedule regular archiving/maintenance tasks.
Verify logging configuration completeness after any system change.

Related References

SOP: SOP-ALC-10 (Data Logging and Archiving Procedure)

Standards: ICAO Annex 14 Vol I (record-keeping requirements), ALCMS vendor documentation

Diagram: ALCMS Server/Network Architecture Drawing

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

ALC-490 Event Recording Failure

Symptom — The ALCMS event/alarm history log — the chronological record of operator actions, alarms, and system events — is found to have missing, incomplete, or incorrectly timestamped entries.

Equipment / System

ALCMS event/alarm history log — the chronological record of operator actions, alarms, and system events used for audit trail and incident investigation, distinct from the periodic value logging in ALC-489.

Possible Causes

HighEvent logging service failure, or the event log reaching a rollover/capacity limit that overwrites older records prematurely

MedSpecific event types not configured to be logged

MedA timestamp/clock synchronisation fault causing events to be logged with incorrect or inconsistent times

LowDatabase corruption in the event log table

LowA communication gap preventing field-generated events from being captured during an outage

Required Tools

Database administration toolALCMS event logging configuration reviewNetwork time synchronisation check (NTP status)Database backup/restore utility

Safety Precautions

Follow standard IT/OT change-management procedure for any database-level intervention.
Treat any confirmed gap in the event record as significant if it may affect an incident investigation or audit trail, and notify airfield operations/quality management accordingly.

Diagnostic Procedure

ObservationCheck the event logging service status and log capacity/rollover configuration.
ObservationConfirm which event types are configured to be logged.
MeasurementCheck system clock/NTP synchronisation across the ALCMS servers and field devices.
MeasurementCheck for database corruption in the event log.
DecisionLog capacity/rollover has overwritten older records → correct retention/archiving configuration. Timestamps inconsistent across records → clock synchronisation fault.
Fault LocationIsolate to the event logging service/capacity, missing event type configuration, clock synchronisation, or database corruption.
Root CauseConfirm the specific cause before correction.

Test Points

Event logging service status

Log capacity/rollover configuration

Clock/NTP synchronisation

Event log database integrity

Root Cause Verification

Generate a test event (e.g. a controlled operator action) and confirm it is correctly logged with an accurate timestamp, and confirm the log capacity is adequate for the required retention period.

Corrective Action

Restart or repair the event logging service.
Correct the log capacity/rollover configuration.
Resynchronise system clocks.
Repair the event log database from a verified backup.

Preventive Action

Verify event log retention meets the required audit/compliance period.
Include clock synchronisation checks in the periodic maintenance cycle.
Periodically export/archive event logs to protect against rollover loss.

Related References

SOP: SOP-ALC-10 (Data Logging and Archiving Procedure)

Standards: ICAO Annex 14 Vol I (record-keeping requirements), ALCMS vendor documentation

Diagram: ALCMS Server/Network Architecture Drawing

Case Study: Division 01 — CCR Troubleshooting

Rev 0 — Initial issue

No topics match your search. Try a different term.

Frequently Asked Questions

Quick answers about ALCMS / Control & Monitoring troubleshooting in the AGL Troubleshooting Atlas.

Q1What does Division 19 of the AGL Troubleshooting Atlas cover?

Division 19 is the ALCMS / Control & Monitoring Troubleshooting reference. It publishes 20 diagnostic topics, ALC-471 to ALC-490, for ALCMS / Control & Monitoring faults on airfield ground lighting systems.

Q2What information does each topic include?

Every topic follows the same diagnostic record: the symptom, equipment/system, possible causes ranked by likelihood (high, medium or low), required tools, safety precautions, diagnostic procedure, test points, root cause verification, corrective action, preventive action and related references (SOPs, standards, diagrams and case studies).

Q3Which ALCMS / Control & Monitoring faults are covered?

The 20 topics are ALC-471 to ALC-490: ALCMS Not Starting; ALCMS Communication Failure; CCR Not Visible on ALCMS; Wrong CCR Status; Wrong CCR Current Display; Wrong Intensity Display; Remote Command Failure; Remote Step Change Failure; Remote ON/OFF Failure; Alarm Not Received; False Alarm; Alarm Not Clearing; Communication Intermittency; PLC Failure; Network Failure; Communication Cable Failure; HMI Failure; HMI Touchscreen Failure; Data Logging Failure; Event Recording Failure.

Q4How does a diagnostic procedure begin in Division 19?

Each procedure starts with observation before any intervention. For example, ALC-471 (ALCMS Not Starting) begins: Check the server power and OS boot status to confirm whether the hardware/OS layer started correctly.

Q5What safety precautions apply when troubleshooting ALCMS / Control & Monitoring?

Each topic lists its own precautions. For example, ALC-471 (ALCMS Not Starting) starts with: Coordinate with ATC before restarting the primary ALCMS server, since lighting control may need to fail over to a backup system or local manual control.

Q6Which SOPs are referenced in Division 19?

Related references in the topics include SOP-ALC-01 (ALCMS Server Startup and Recovery Procedure), SOP-ALC-02 (ALCMS Communication Fault Isolation Procedure), SOP-ALC-03 (Field Device Visibility Verification Procedure), SOP-ALC-04 (Status Feedback Verification Procedure), SOP-ALC-05 (Analog Signal Verification Procedure), SOP-ALC-06 (Remote Command Fault Isolation Procedure), SOP-ALC-07 (Alarm Verification Procedure) and SOP-ALC-08 (PLC/RTU Fault Isolation Procedure), and 2 more.

Q7Which standards are referenced in the ALCMS / Control & Monitoring topics?

Where a standard applies, it appears in the topic's Related References. Those cited in this division include ICAO Annex 14 Vol I.

Q8How can I find a specific fault in Division 19 quickly?

Use the search box at the top of the page to filter the 20 published topics by code, fault name or keyword; matching topics open automatically. Each diagnostic record can also be downloaded as a Word (.doc) file.