The dedicated failure-intelligence division for AGL control, monitoring, automation, communication and supervisory systems — PLC, SCADA, HMI, network infrastructure, communication modules, sensors, control panels, control logic, commands, interlocks, status indication and system synchronization.
Key principle — Do not record a control-system problem simply as “SCADA failure” or “PLC failure.” Identify the failed control function, communication path, symptom, failure mechanism, root cause and resulting AGL operational effect. This prevents the database from accumulating thousands of records labelled simply “SCADA failure.”
Failure of the Programmable Logic Controller responsible for control, monitoring, sequencing or automation functions.
PLC failure should be used when the PLC itself is determined to be defective. If the PLC is healthy but cannot communicate with SCADA, classify the primary failure as SCADA communication loss or communication failure, as applicable.
Loss of communication between the supervisory control system and the field/control equipment.
Determine where communication is lost along the path: SCADA → network → control panel → PLC → field equipment. This prevents incorrectly identifying the SCADA application itself as defective.
Failure of the network infrastructure required for control-system communication.
Identify whether the failure is single-link, single-device, network segment or network-wide.
Sensor provides incorrect, unstable, missing or unavailable input to the control/monitoring system.
Failure of the control system to correctly generate, display, transmit or acknowledge an alarm.
An alarm failure can be more serious than an ordinary indication failure because it may prevent personnel from recognising an abnormal AGL condition.
Incorrect software parameter, configuration, database, address, logic or system setting affecting control-system operation.
Compare current configuration ↔ approved configuration/baseline.
Failure of the Human-Machine Interface used for monitoring and/or controlling the AGL system.
Separate HMI hardware failure from HMI communication/software failure.
Failure of a dedicated communication module/interface used to exchange data between control-system components.
Failure of an AGL control panel or associated control-panel hardware affecting system operation.
Inspect the control panel as an integrated assembly while identifying the specific failed component where possible.
Failure to control AGL equipment from the designated remote-control/SCADA location.
A remote-control failure does not automatically mean the controlled equipment itself has failed.
Failure to control the AGL equipment from the local control interface/panel.
Determine whether local control fails but remote control works, or both local and remote control fail. This distinction is diagnostically important.
Failure of the control system's intended interlocking function.
Expected communication response is not received within the configured/required period.
Communication timeout is the observed failure condition. The root cause may be network failure, module failure, configuration error or device failure.
Loss, corruption or unavailability of required control/monitoring data.
Control system displays a status that does not correspond to the actual field/equipment condition.
Compare actual field condition ↔ PLC status ↔ SCADA status ↔ HMI indication. This four-point comparison is particularly useful for control-system troubleshooting.
System executes a command differently from the intended/authorized command.
Verify the full path: operator command → HMI/SCADA command → PLC command → output → field equipment response.
Incorrect programmed control logic causes unexpected or incorrect system behaviour.
Compare actual logic against the approved control philosophy and baseline configuration.
Mismatch between configuration settings of connected control-system components.
PLC address/configuration ≠ SCADA database configuration → communication failure.
Intermittent or unstable network performance resulting in unreliable control-system communication.
Look for recurring/intermittent patterns, rather than treating each communication interruption as an independent failure.
Failure of connected control-system components to maintain the required synchronization of data, states, timing or system operation.
Compare synchronization between: SCADA ↔ PLC ↔ HMI ↔ communication modules ↔ field equipment.
Failure chains, diagnostic matrix, standard record structure, RCA relationships and classification that apply across all 20 Division 07 control-system-failure topics.
These relationships are built into the failure database so a control-system problem is never recorded as a single, undifferentiated “SCADA failure.”
These relationships become extremely valuable when Division 07 is later connected to the Root Cause Analysis Database and Reliability & Failure Trend Analysis.
| No. | Failure | Primary Investigation |
|---|---|---|
| 1 | PLC failure | PLC diagnostics/I/O/power |
| 2 | SCADA communication loss | End-to-end communication |
| 3 | Network failure | Network infrastructure |
| 4 | Sensor malfunction | Sensor/input signal |
| 5 | Alarm failure | Alarm logic/display/communication |
| 6 | Software configuration error | Approved configuration comparison |
| 7 | HMI failure | HMI hardware/software |
| 8 | Communication-module failure | Module/power/configuration |
| 9 | Control-panel failure | Panel hardware/interface |
| 10 | Remote-control failure | Remote command path |
| 11 | Local-control failure | Local command path |
| 12 | Interlocking failure | Interlock logic/status |
| 13 | Communication timeout | Communication response |
| 14 | Data loss | Data transmission/storage |
| 15 | Incorrect status indication | Field/PLC/SCADA comparison |
| 16 | Incorrect command execution | Command-to-output path |
| 17 | Control logic error | PLC/control philosophy |
| 18 | Configuration mismatch | Configuration baseline |
| 19 | Network instability | Intermittent network behaviour |
| 20 | System synchronization failure | System state/time/data synchronization |
For every Division 07 case, capture:
System identification
Failure information
Diagnostic information
Evidence
RCA
Restoration
Reliability
Division 07 distinguishes system symptom, failure mode, and root cause. This prevents the database from accumulating thousands of records labelled simply “SCADA failure.”
The 20 topics are organised into six logical groups while retaining the original numbering, making the database easier to search without changing the master architecture:
Every failure receives a severity classification, plus operational-impact tagging:
Critical / Safety-Critical — immediate operational or safety risk
Major / Operationally Critical — significant availability impact
Moderate — reduced performance, not yet critical
Minor / Non-Critical — limited or no operational effect
Degradation / Intermittent / Latent — developing or hidden fault
Division 07 links every failure to the Root Cause Analysis Database. The most relevant RCA categories for control-system failures are:
This makes Division 07 suitable not only for PLC/SCADA troubleshooting, but also for AGL control-system RCA, configuration management, alarm reliability, communication reliability, change management and long-term control-system performance analysis.
Divisions 01 and 02 capture failures at the fixture and electrical-path level — LED, driver, cable, connector, insulation. Division 07 captures failures in the control, monitoring, automation and supervisory layer sitting above them — PLC, SCADA, HMI, network, sensors and control logic. Before recording a fixture as failed, confirm the command actually reached it: a fixture that appears failed may in fact be correctly following an incorrect PLC command, an interlock condition, or a status indication that never matched the field.
Quick answers about AGL control, monitoring, automation and communication failures, as covered in Division 07 of the AGL Failure Database.
Division 07 covers failures in AGL control, monitoring, automation, communication and supervisory systems. It contains 20 published topics (CSF-01 to CSF-20) covering PLC, SCADA, network, sensor, alarm, HMI, communication modules, control panels, remote and local control, interlocking and control logic.
PLC failure, SCADA communication loss, network failure, sensor malfunction, alarm failure, software configuration error, HMI failure, communication-module failure, control-panel failure, remote-control failure, local-control failure, interlocking failure, communication timeout, data loss, incorrect status indication, incorrect command execution, control logic error, configuration mismatch, network instability and system synchronization failure.
They are organised into six groups while keeping the original numbering: PLC & Control Hardware (4 topics), Alarm, HMI & Communication (5), Control-Mode Failures (3), Communication & Data (3), Command & Logic (3) and Network & System Performance (2).
Division 07 distinguishes system symptom, failure mode and root cause so the database does not accumulate thousands of records labelled simply “SCADA failure”. For example, a remote-control failure may be a communication timeout caused by network instability, with a network infrastructure problem as the root cause. An incorrect status indication may trace to an incorrect PLC input caused by sensor malfunction.
In the network chain, network failure leads to communication loss, communication timeout, SCADA status unavailable, remote-control failure and loss of operational control. In the configuration chain, a configuration mismatch leads to a communication problem, incorrect or missing data, incorrect status indication and an incorrect operator decision.
Divisions 01 and 02 capture failures at the fixture and electrical-path level, such as LED, driver, cable, connector and insulation. Division 07 captures failures in the control, monitoring, automation and supervisory layer above them: PLC, SCADA, HMI, network, sensors and control logic. Before recording a fixture as failed, confirm the command actually reached it, because a fixture may be correctly following an incorrect PLC command.
The diagnostic matrix assigns a primary investigation to each topic. PLC failure starts with PLC diagnostics, I/O and power, SCADA communication loss with end-to-end communication, network failure with network infrastructure, sensor malfunction with the sensor and input signal, alarm failure with alarm logic, display and communication, and software configuration error with comparison against approved configuration.
Records capture system identification (system name, PLC, SCADA/HMI and control-panel IDs, network segment, field equipment affected), failure information including alarm generated, actual field condition and displayed condition, and diagnostic information such as PLC, I/O, communication, network, HMI, SCADA and configuration status. The recommended architecture runs from failure event through mode, symptom, diagnostic evidence, mechanism and root cause to functional verification and reliability trend.
Every failure receives a severity classification, plus operational-impact tagging. The classes are Critical / Safety-Critical (immediate operational or safety risk), Major / Operationally Critical (significant availability impact), Moderate (reduced performance, not yet critical), Minor / Non-Critical (limited or no operational effect), and Degradation / Intermittent / Latent (a developing or hidden fault).
ALCMS and control-system failures can stem from communication faults, software logic errors or field-device miscommunication — real troubleshooting means understanding the monitoring and control architecture well enough to isolate where the failure actually began.
Take that knowledge further with Precision AGL Academy.
Learn how to connect:
Develop structured knowledge across AGL fundamentals, components, electrical systems, testing, photometry, troubleshooting, maintenance and commissioning.
Find the failure. Understand the cause. Build the engineering skill.
Please read before relying on any content on this page or on any record downloaded from it.