Division 30 — Advanced RCA / Engineering Investigation

01 · Advanced RCA / Engineering Investigation Topics

20 of 20 topics published

AEI-681 5-Why Analysis for AGL Failure

Purpose — A structured, iterative questioning technique that traces a failure from its immediate symptom back through successive causes to a systemic root cause, by repeatedly asking "why" against each answer until further questioning stops yielding new, actionable information.

Applicable Scope

Applicable to single, relatively well-bounded AGL faults (a specific fixture, transformer, or connector failure) where the causal chain is expected to be linear rather than branching; less suited on its own to complex, multi-factor system-level failures.

Common Pitfalls / Misapplication

HighStopping too early — accepting the first plausible answer at "why #2 or #3" instead of continuing until a true systemic cause (process, design, or training) is reached

HighFollowing a single linear chain when the real causal structure branches, so a genuine contributing factor on a parallel path is never asked about

MediumConducting the analysis solo from a desk rather than with the people who did the work and can supply the actual facts at each step

MediumTreating "human error" or "operator forgot" as a terminal answer instead of continuing to ask why the error was possible or likely

LowNo documentation of the answer at each "why," making the analysis unreviewable and its logic unverifiable later

LowUsing 5-Why on a genuinely complex, multi-cause system failure where a fishbone or fault tree would represent the problem more accurately

Required Tools

5-Why worksheet or whiteboard templateThe specific work order / fault record being analysedAccess to the technician(s) or data involved at each causal stepFishbone diagram as a cross-check for branching causesFacilitator experienced in root-cause interviewing technique

Safety Precautions

Conduct any interview involved in the analysis in a non-punitive, just-culture manner.
Apply the standard LOTO/access precautions for any physical verification performed as part of the analysis.

Methodology Steps

Step 1State the problem precisely and factually — the specific fault, location, and date — rather than a vague or generalised description.
Step 2Ask "why did this happen?" and record the direct, evidence-based answer, not a guess or assumption.
Step 3For each answer, ask "why" again, continuing to peel back the causal layer until the answer points to a process, design, training, or systemic condition rather than a further physical symptom.
Step 4Typically continue for five iterations as a guideline, but stop earlier if a clear systemic cause is reached, or continue further if the chain has not yet reached one.
Step 5Cross-check the final answer against the evidence gathered at each step to confirm the logic holds end-to-end, not just that five "whys" were asked.
Step 6Convert the confirmed root cause into a specific, assignable corrective action rather than leaving it as a diagnostic statement alone.

Key Outputs

A documented chain of question-and-answer pairs from symptom to root cause

Evidence supporting each answer in the chain, not assumption alone

The final systemic (process/design/training) cause identified

A specific, assignable corrective action tied to the root cause

Confirmation the chain did not stop prematurely at a symptom

Validation Criteria

Read the completed chain back from the final root cause forward to the original symptom and confirm each "why" logically and factually follows from the one before it, with no unsupported leaps, before accepting the analysis as complete.

Typical Findings & Actions

Where the chain reveals a procedural gap, route the finding into the relevant SOP/checklist update.
Where the chain reveals a training gap, route the finding into the training programme.
Where the chain reveals the failure is more complex or branching than a single line supports, escalate to a fishbone or fault tree analysis instead.

Programme Integration

Use 5-Why as the default first-pass technique for single, well-bounded faults, reserving fishbone/FTA for more complex ones.
Retain completed 5-Why worksheets in the CMMS/RCA record for future reference and pattern-checking.
Train investigators to recognise when a linear 5-Why is inadequate and a branching technique is needed instead.
Periodically audit completed 5-Why analyses for premature stopping at a symptom rather than a systemic cause.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-HR-01 (Just Culture and Non-Punitive Investigation Procedure)

Standards: ISO 9001:2015 Cl. 10.2, ICAO Doc 9859 (SMS principles)

Diagram: 5-Why Worksheet Template

Case Study: Division 23 — Root Cause Analysis (RCA-561 Human Error Root Cause)

Rev 0 — Initial issue

AEI-682 Fishbone Analysis for AGL Failure

Purpose — A structured cause-and-effect diagramming technique (Ishikawa diagram) that maps every plausible contributing cause of a failure across standard categories — typically Equipment, Process, People, Materials, Environment, and Measurement — to ensure a broad, systematic search rather than following only the first hypothesis that comes to mind.

Applicable Scope

Applicable to failures with multiple, potentially interacting contributing factors — repeated component failures, circuit-level degradation, or any fault where the cause is not obviously a single linear chain.

Common Pitfalls / Misapplication

HighPopulating only the categories the investigator is personally familiar with (e.g., only Equipment causes) and neglecting People, Process, or Environment branches

HighListing symptoms or effects on the bone rather than genuine contributing causes, conflating the diagram with a simple fault list

MediumStopping after the first pass without a facilitated brainstorm involving people from different roles (technician, engineer, planner) who would surface different branches

MediumFailing to prioritise or weight the identified causes afterward, leaving the diagram as an unranked list rather than a basis for action

LowUsing generic, non-specific category labels that do not map well to AGL-specific causal categories

LowTreating the completed diagram as the root cause itself, rather than as an input to further verification of the leading candidate causes

Required Tools

Fishbone/Ishikawa diagram template (6M or similar category structure)Whiteboard or diagramming softwareFacilitated brainstorming session with cross-functional participantsThe specific fault/failure history data being analysedCategory definitions adapted to AGL causes (Equipment, Process, People, Materials, Environment, Measurement)

Safety Precautions

Conduct the brainstorming session in a non-punitive environment so People-category causes are surfaced honestly.
Apply standard LOTO/access precautions for any physical verification of a candidate cause identified on the diagram.

Methodology Steps

Step 1State the effect (the specific failure) clearly at the head of the diagram, as precisely as the 5-Why problem statement.
Step 2Establish the major cause categories on the main bones — typically Equipment, Process, People, Materials, Environment, and Measurement for AGL applications.
Step 3Facilitate a structured brainstorm with cross-functional participants, populating each category with candidate contributing causes, not effects.
Step 4Use sub-branches to break down a broad candidate cause into more specific, testable factors (e.g., under Equipment: "transformer" → "wattage mismatch").
Step 5Review the completed diagram as a group to identify the most plausible candidate causes for further investigation, based on available evidence rather than opinion alone.
Step 6Carry the leading candidates forward into targeted testing/verification (physical inspection, data review) rather than concluding the RCA from the diagram alone.

Key Outputs

Coverage across all relevant cause categories, not just one

Causes (not effects/symptoms) populated on each bone

Cross-functional participation in the brainstorm

Leading candidate causes identified for further verification

Sub-branch specificity sufficient to support targeted testing

Validation Criteria

Confirm the diagram was populated with genuine causes across multiple categories by a cross-functional group, and that the leading candidates identified were subsequently tested against physical or data evidence before the RCA was closed.

Typical Findings & Actions

Carry the leading candidate cause(s) forward into physical inspection or data verification to confirm or rule out each before selecting a corrective action.
Re-run the brainstorm with broader participation if the initial diagram shows clear category imbalance (e.g., nothing under People or Environment).

Programme Integration

Use fishbone analysis as the standard technique for any failure with more than one plausible contributing factor.
Retain completed fishbone diagrams in the CMMS/RCA record for future reference and cross-division pattern-checking.
Train facilitators in structured brainstorming technique to avoid one-sided category population.
Periodically review closed fishbone RCAs for category coverage as a quality check on the technique's application.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure)

Standards: ISO 9001:2015 Cl. 10.2

Diagram: Fishbone (Ishikawa) Diagram Template — 6M Category Structure

Case Study: Division 23 — Root Cause Analysis (all topics use fishbone branching in the investigation procedure)

Rev 0 — Initial issue

AEI-683 Fault Tree Analysis for CCR Failure

Purpose — A deductive, top-down logic-diagram technique that starts from a defined CCR-level failure (the "top event") and systematically breaks it down through AND/OR logic gates into the combinations of lower-level equipment, protection, and human-factor events that could cause it.

Applicable Scope

Constant Current Regulators (transformer-type and TSCR/inverter-type), their protection relays, power supply, and the human/procedural events that interact with them (e.g., an unresolved trip being reset without investigation).

Common Pitfalls / Misapplication

HighDefining the top event too broadly (e.g., "CCR fails") rather than a specific, well-bounded failure mode (e.g., "CCR trips on overcurrent and will not reset"), making the tree unmanageably large

HighIncorrect gate logic — using an OR gate where an AND relationship actually exists between contributing events, overstating the failure probability

MediumStopping the tree decomposition at an intermediate event without breaking it down to a basic, independently verifiable event

MediumOmitting human-factor or procedural basic events (e.g., "trip reset without investigation") and modelling only hardware failure modes

LowBuilding the tree without input from the technicians who actually operate and maintain the CCR, missing practical failure paths

LowTreating the completed tree as static, rather than updating it as new failure modes are discovered through field experience

Required Tools

Fault tree diagramming software or template with standard AND/OR gate symbolsCCR single-line diagram and protection coordination studyCCR trip/failure history for calibrating basic event likelihoodCross-functional review team (electrical engineer, technician, protection specialist)Basic event probability/frequency data where available from Division 23/27 records

Safety Precautions

LOTO the CCR before any physical verification of a basic event identified in the tree.
Apply standard safety precautions relevant to the specific basic event being field-verified.

Methodology Steps

Step 1Define the top event precisely — a specific, well-bounded CCR failure mode rather than a generic "CCR fails" statement.
Step 2Identify the immediate, necessary and/or sufficient contributing events directly beneath the top event, connected by the correct AND/OR gate logic.
Step 3Continue decomposing each intermediate event downward until reaching basic events — independently verifiable hardware, environmental, or human-factor causes.
Step 4Include human-factor and procedural basic events (e.g., incorrect relay setting, trip reset without investigation) alongside hardware events, not hardware alone.
Step 5Where data is available, estimate the relative likelihood of each basic event using CCR failure history to identify the dominant cut sets (combinations most likely to produce the top event).
Step 6Review the completed tree with a cross-functional team to validate the gate logic and confirm no plausible basic event has been omitted.

Key Outputs

Top event definition — specific and well-bounded

Gate logic (AND/OR) correctness at each level

Decomposition depth — basic events, not stopped at intermediate events

Human-factor/procedural basic events included

Dominant cut sets identified from available failure data

Validation Criteria

Cross-check the completed tree against actual CCR trip/failure history to confirm the identified dominant cut sets are consistent with observed failure patterns, and have the tree reviewed and signed off by a cross-functional team before use.

Typical Findings & Actions

Where a dominant cut set points to a specific hardware weakness, route the finding into corrective replacement/upgrade.
Where a dominant cut set points to a procedural gap (e.g., trip reset without investigation), route the finding into SOP revision.
Use the tree to prioritise which basic events warrant the most rigorous field verification during an active investigation.

Programme Integration

Maintain the CCR fault tree as a living document, updated as new failure modes are discovered through Division 23 RCA findings.
Use the tree during design review for new CCR installations or protection setting changes to anticipate failure paths proactively.
Train protection and maintenance engineers in fault tree construction and gate logic to avoid the common pitfalls above.
Cross-reference the tree's basic events against the PM checklist to ensure each is actually inspected/tested periodically.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-CCR-04 (CCR LOTO Procedure)

Standards: IEC 61025 (fault tree analysis), ICAO Annex 14 Vol I

Diagram: CCR Fault Tree Diagram

Case Study: Division 23 — Root Cause Analysis (RCA-547 Repeated CCR Trip RCA)

Rev 0 — Initial issue

AEI-684 Fault Tree Analysis for Series Circuit Failure

Purpose — A top-down logic-diagram technique applied to a series-circuit-level failure (e.g., "multiple lights dark on Circuit X"), decomposing the top event through AND/OR gates into the cable, transformer, connector, CCR, and earthing basic events that could combine to produce it.

Applicable Scope

Complete series circuits — CCR output, primary series cable loop, all transformers and fixtures on the loop, and the earthing system supporting it.

Common Pitfalls / Misapplication

HighModelling only a single fault path (e.g., cable break) when a series circuit's topology often allows multiple distinct basic events to produce the same top-level symptom (dark section)

HighIncorrect gate logic between a genuine circuit-wide cause (e.g., CCR output failure, which is a single event affecting everything downstream) and a localised cause (e.g., one cable segment), which have fundamentally different tree structures

MediumNot accounting for circuit topology changes (added fixtures, extended loop) in the tree, so it no longer reflects the as-built circuit

MediumTreating "cable fault" as a single basic event rather than decomposing it by segment, obscuring which specific section is implicated

LowBuilding the tree without reference to the as-built circuit layout drawing, missing physical segment boundaries

LowFailing to distinguish a series-circuit-specific topology (one break affects everything downstream) from a parallel or radial topology in the gate logic

Required Tools

As-built circuit design calculation and topology drawingFault tree diagramming software or templateCircuit-level fault history from Division 23 recordsInsulation resistance test history by segmentCross-functional review team familiar with the specific circuit

Safety Precautions

LOTO the CCR before any physical verification of a basic event on the affected circuit.
Coordinate airside access for any field verification through ATC/airfield operations.

Methodology Steps

Step 1Define the top event precisely — the specific symptom (e.g., "Circuit X, Section 4-9 dark, other sections normal") rather than a generic circuit failure statement.
Step 2Distinguish circuit-wide basic events (CCR output failure, upstream cable break) from localised basic events (a specific segment fault) using the correct gate logic for series topology.
Step 3Decompose the cable-fault branch by physical segment, referencing the as-built layout drawing, rather than treating "cable" as a single undifferentiated basic event.
Step 4Include transformer, connector, and earthing basic events at each fixture position within the affected section.
Step 5Where circuit-level fault history exists (Division 23), estimate relative likelihood of each basic event/segment to identify the dominant cut set for the specific symptom observed.
Step 6Validate the tree against the current as-built topology, updating it if fixtures have been added or the loop extended since the tree was last built.

Key Outputs

Top event definition — specific symptom and section

Circuit-wide vs. localised basic event gate logic

Cable-fault decomposition by physical segment

Transformer/connector/earthing basic events included per position

Tree currency against as-built topology

Validation Criteria

Cross-check the dominant cut set identified by the tree against the actual insulation resistance test pattern and fault-location result from the current investigation, confirming the tree correctly predicted where the fault would be found.

Typical Findings & Actions

Use the dominant cut set to prioritise fault-location effort (which segment or component to test first) during an active investigation.
Where the tree reveals a topology not reflected in current records, update the as-built drawing and design calculation.

Programme Integration

Maintain circuit fault trees for high-criticality or historically fault-prone circuits as living documents.
Update the tree whenever a change-control record shows fixtures added or the loop extended.
Use the tree during design review to identify single points of failure (e.g., an upstream basic event that would affect an unacceptably large section) for design mitigation.
Cross-reference dominant cut sets against the PM programme to ensure the most likely basic events receive proportionate inspection attention.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-RCL-02 (Series Circuit Fault Location Procedure)

Standards: IEC 61025, ICAO Annex 14 Vol I, FAA AC 150/5340-30

Diagram: Series Circuit Fault Tree Diagram

Case Study: Division 23 — Root Cause Analysis (RCA-558 Repeated Circuit Failure RCA)

Rev 0 — Initial issue

AEI-685 Fault Tree Analysis for Transformer Failure

Purpose — A top-down logic-diagram technique applied to isolation transformer failure, decomposing the top event (e.g., "transformer open/short circuit") through AND/OR gates into the design, material, environmental, and workmanship basic events that could combine to produce it.

Applicable Scope

L-830 series-circuit isolation transformers and their base-can environment, wattage/tap specification, and installation/maintenance history.

Common Pitfalls / Misapplication

HighConflating "insulation failure" as a single basic event rather than decomposing it into its distinct sub-causes — moisture, thermal, mechanical, and age-related degradation — which each have different corrective paths

HighTreating wattage/tap mismatch (a specification/workmanship event) and manufacturing defect (a material event) as the same basic event when they require entirely different corrective actions

MediumNot including base-can drainage/moisture events as basic events feeding into the insulation-failure branch

MediumOmitting batch/lot traceability as a basic event, preventing the tree from being used to investigate a suspected manufacturing-batch issue

LowBuilding a generic transformer fault tree not calibrated to the specific transformer type/rating in use on the affected circuit

LowFailing to update the tree with basic event likelihood data as Division 23 RCA findings accumulate over time

Required Tools

Fault tree diagramming software or templateTransformer specification and wattage/tap design referenceTransformer failure history by location and batch (Division 23 records)Base-can moisture/drainage inspection dataCross-functional review team (electrical engineer, technician, procurement/quality)

Safety Precautions

LOTO the circuit before removing any transformer for basic-event verification.
Treat a suspect transformer as potentially still hazardous from stored energy or induced voltage until confirmed isolated.

Methodology Steps

Step 1Define the top event precisely — the specific failure mode (e.g., "transformer primary-to-secondary short") rather than a generic "transformer fails" statement.
Step 2Decompose the top event into its major branches — insulation failure, thermal failure, mechanical damage, and manufacturing defect — using appropriate gate logic.
Step 3Further decompose the insulation-failure branch into moisture, thermal, mechanical, and age-related basic events, referencing base-can and loading data.
Step 4Include wattage/tap mismatch and installation workmanship as distinct basic events feeding the thermal-failure branch, separate from a genuine material/manufacturing defect.
Step 5Include batch/lot traceability as a basic event to support investigation of a suspected manufacturing-batch pattern.
Step 6Where Division 23 failure history is available, weight the basic events by observed frequency to identify the dominant cut set for the specific population being analysed.

Key Outputs

Top event definition — specific failure mode

Insulation-failure branch decomposition (moisture/thermal/mechanical/age)

Wattage/tap mismatch modelled as distinct from manufacturing defect

Batch/lot traceability included as a basic event

Basic event likelihood weighting from failure history, where available

Validation Criteria

Cross-check the dominant cut set identified by the tree against the physical teardown findings from the current failed unit, confirming the tree correctly anticipated the observed failure signature.

Typical Findings & Actions

Use the dominant cut set to prioritise which basic events to verify first during a repeated-failure investigation (see RCA-546).
Where the tree points to a batch-level cut set, escalate to supplier quality engagement.
Where the tree points to a wattage/tap specification gap, correct the design/verification process.

Programme Integration

Maintain the transformer fault tree as a living document, recalibrated as Division 23 RCA findings accumulate.
Use the tree during procurement/specification review to anticipate failure paths for new transformer types before large-scale deployment.
Cross-reference dominant cut sets against the PM programme (wattage verification, insulation trending) to ensure proportionate coverage.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-RCL-12 (Transformer Test and Replacement Procedure)

Standards: IEC 61025, FAA AC 150/5345-26, IEEE C57.12.91

Diagram: Transformer Fault Tree Diagram

Case Study: Division 23 — Root Cause Analysis (RCA-546 Repeated Transformer Failure RCA)

Rev 0 — Initial issue

AEI-686 Fault Tree Analysis for Cable Failure

Purpose — A top-down logic-diagram technique applied to primary or secondary cable failure, decomposing the top event (e.g., "cable insulation breakdown at a specific segment") through AND/OR gates into the environmental, mechanical, electrical, and workmanship basic events that could combine to produce it.

Applicable Scope

L-824 primary series cable and secondary cable, including duct banks, pull boxes, and field splices along the route.

Common Pitfalls / Misapplication

HighTreating the entire cable route as a single basic event rather than decomposing it by segment/joint, which prevents the tree from being used for actual fault-location prioritisation

HighOmitting splice/joint quality as a distinct basic event separate from the cable itself, understating how often the repair, not the original cable, is the true failure point

MediumNot including civil works/mechanical damage as a time-varying basic event whose likelihood should be re-weighted when nearby excavation or resurfacing is known to be occurring

MediumConflating overvoltage/harmonic electrical stress with age-related insulation degradation as a single "insulation failure" event, when they call for different corrective actions

LowBuilding the tree without reference to the as-built route drawing, losing the physical segment structure needed for practical use

LowNot updating basic event likelihood as insulation resistance trend data accumulates over successive PM cycles

Required Tools

As-built duct and cable route drawingFault tree diagramming software or templateInsulation resistance trend data by segment (Division 23/27 records)Civil works/vehicle-loading history for the routeSplice/joint installation and inspection records

Safety Precautions

LOTO the CCR before any cable work or basic-event verification.
Obtain excavation clearance and utility locates before any physical verification requiring pavement or verge opening.

Methodology Steps

Step 1Define the top event precisely — the specific segment or symptom (e.g., "insulation failure, Segment 12-15") rather than a generic cable-failure statement.
Step 2Decompose by physical segment/joint using the as-built route drawing, so each basic event corresponds to a specific, locatable point.
Step 3For each segment, include distinct basic events for moisture ingress, mechanical damage, splice/joint quality, and electrical overstress.
Step 4Weight civil works/vehicle-loading basic events higher for segments currently under or recently subject to nearby works.
Step 5Use accumulated insulation resistance trend data to identify segments already showing degradation, raising their basic event likelihood in the tree.
Step 6Validate the tree against the current investigation's fault-location result to confirm the dominant cut set correctly anticipated the failure location.

Key Outputs

Top event definition — specific segment/symptom

Segment-level decomposition against the route drawing

Splice/joint quality modelled as distinct from the cable itself

Civil works/vehicle-loading basic events time-weighted appropriately

Insulation resistance trend data incorporated into basic event likelihood

Validation Criteria

Cross-check the dominant cut set identified by the tree against the actual TDR/fault-location result from the current investigation, confirming the segment predicted matches the segment found.

Typical Findings & Actions

Use the dominant cut set to prioritise which segment to test first during an active fault-location investigation.
Where the tree points to a splice/joint-quality cut set, escalate to splice technique/training review (see PRV-635).
Where civil works basic events dominate, coordinate protective measures with the civil works team.

Programme Integration

Maintain segment-level fault trees for chronically fault-prone routes as living documents, updated with each PM cycle's insulation data.
Use the tree during route planning for new circuits to identify segments at elevated inherent risk (e.g., planned proximity to future civil works).
Cross-reference dominant cut sets against the PM programme to ensure the highest-likelihood segments receive proportionate insulation testing frequency.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-RCL-02 (Series Circuit Fault Location Procedure)

Standards: IEC 61025, IEC 60364, ICAO Annex 14 Vol I

Diagram: Cable Route Fault Tree Diagram

Case Study: Division 23 — Root Cause Analysis (RCA-548 Repeated Cable Failure RCA, RCA-555 Repeated Insulation Failure RCA)

Rev 0 — Initial issue

AEI-687 Fault Tree Analysis for Fixture Failure

Purpose — A top-down logic-diagram technique applied to complete fixture failure, decomposing the top event (e.g., "fixture fails to illuminate") through AND/OR gates into the transformer, connector, lamp/LED, housing/seal, and physical-damage basic events that could combine to produce it.

Applicable Scope

Complete inset or elevated AGL fixture assemblies — housing, optics, lamp/LED module, transformer, connector, and base can.

Common Pitfalls / Misapplication

HighBuilding a generic "fixture fails" tree that does not distinguish between the several independent subsystems (electrical supply, light source, housing integrity) that can each independently cause the same top-level symptom

HighTreating "fixture failure" and "transformer failure" (AEI-685) as separate, unrelated trees rather than recognising the transformer branch as a sub-tree feeding into the fixture-level top event

MediumNot weighting basic events by the specific location's known stress profile (jet-blast zone, chronically wet base can), understating the dominant cut set for that specific fixture population

MediumOmitting physical/mechanical damage (impact, jet blast, snow plough) as a basic event distinct from a purely electrical or material cause

LowBuilding the tree without reference to fixture batch/model-specific failure history, missing a design or manufacturing basic event

LowNot distinguishing photometric/optical degradation (a gradual basic event) from an abrupt "not working" failure mode in the same tree

Required Tools

Fault tree diagramming software or template, incorporating the transformer sub-tree (AEI-685) and connector considerationsFixture-level failure history by position and batchHigh-stress zone mapping (jet blast, snow-plough routes, traffic)Photometric survey trend dataCross-functional review team (electrical, civil, quality)

Safety Precautions

LOTO the circuit before fixture removal for basic-event verification.
Coordinate airside access through ATC/airfield operations.
Use FOD-safe tools and account for every item before leaving the movement area.

Methodology Steps

Step 1Define the top event precisely — the specific symptom (e.g., "fixture completely dark" vs. "fixture dim/out of photometric tolerance") since these have different dominant branches.
Step 2Structure the tree around the fixture's independent subsystems — electrical supply (linking to the transformer sub-tree), light source, housing/seal integrity, and physical structure.
Step 3Incorporate the transformer fault tree (AEI-685) as a sub-tree feeding into the fixture-level electrical-supply branch, rather than duplicating its logic.
Step 4Include physical/mechanical damage as a distinct basic event branch, weighted by the specific location's known stress profile.
Step 5Include fixture batch/model as a basic event to support investigation of a suspected design or manufacturing pattern.
Step 6Where fixture-level failure history is available, weight basic events by observed frequency for the specific position/batch to identify the dominant cut set.

Key Outputs

Top event definition distinguishing failure symptom types

Subsystem structure with transformer sub-tree properly incorporated

Physical/mechanical damage weighted by location stress profile

Fixture batch/model included as a basic event

Basic event likelihood weighting from position-specific failure history

Validation Criteria

Cross-check the dominant cut set identified by the tree against the physical inspection findings from the current failed fixture, confirming the tree correctly anticipated the observed failure mode.

Typical Findings & Actions

Use the dominant cut set to prioritise inspection sequence (transformer, connector, lamp/LED, housing) during an active fixture investigation.
Where the tree points to a location-driven cut set, consider fixture-type upgrade or physical protection for that zone.
Where the tree points to a batch-level cut set, escalate to supplier quality engagement.

Programme Integration

Maintain the fixture fault tree as a living document, incorporating updated transformer and LED sub-trees as those are revised.
Use the tree during fixture specification review for new installations, particularly in known high-stress zones.
Cross-reference dominant cut sets against the PM/photometric survey programme to ensure proportionate inspection coverage.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-RCL-03 (Fixture Replacement Procedure)

Standards: IEC 61025, FAA AC 150/5345-46 (L-852), ICAO Annex 14 Vol I

Diagram: Fixture Fault Tree Diagram (with Transformer Sub-Tree)

Case Study: Division 23 — Root Cause Analysis (RCA-550 Repeated Fixture Failure RCA)

Rev 0 — Initial issue

AEI-688 Fault Tree Analysis for Sign Failure

Purpose — A top-down logic-diagram technique applied to illuminated sign failure, decomposing the top event (e.g., "sign panel dark or internal fault") through AND/OR gates into the light source/driver, housing/seal, ventilation/cooling, and structural basic events that could combine to produce it.

Applicable Scope

L-858 illuminated taxiway/runway guidance signs — housing, door seal, internal light source/driver, panel assembly, and ventilation provision.

Common Pitfalls / Misapplication

HighBuilding a generic "sign fails" tree that does not distinguish an internal electrical fault (light source/driver) from an environmental fault (moisture, heat) with entirely different corrective paths

HighOmitting ballast/driver-to-light-source compatibility as a distinct basic event, missing a common specification-mismatch failure path

MediumNot including cooling-fan function as a basic event feeding the thermal-failure branch where fans are fitted

MediumTreating sign structural instability (vibration, impact) as unrelated to internal component failure rather than recognising it as a basic event that fatigues internal connections over time

LowBuilding the tree without reference to sign-specific batch/wiring-harness records, missing a manufacturing-defect basic event

LowNot weighting basic events by the specific sign's proximity to known vibration/traffic sources

Required Tools

Fault tree diagramming software or templateSign internal wiring and ventilation detail drawingSign failure/repair history by sign ID and locationBallast/driver specification vs. fitted light source referenceVibration/traffic proximity mapping

Safety Precautions

LOTO the circuit before opening the sign housing for basic-event verification.
Confirm sign structural stability before working at height or near traffic.

Methodology Steps

Step 1Define the top event precisely — the specific symptom (e.g., "sign panel fully dark" vs. "sign dim/one panel section out") since these have different dominant branches.
Step 2Structure the tree around the sign's independent subsystems — electrical supply, light source/driver, housing/seal integrity, ventilation/cooling, and structural mounting.
Step 3Include ballast/driver-to-light-source compatibility as a distinct basic event, separate from a genuine component failure.
Step 4Include cooling-fan function as a basic event feeding the thermal-failure branch where fitted.
Step 5Weight structural/vibration basic events by the specific sign's proximity to known high-traffic or vibration sources.
Step 6Where sign-level failure history is available, weight basic events by observed frequency for the specific sign ID/class to identify the dominant cut set.

Key Outputs

Top event definition distinguishing failure symptom types

Subsystem structure covering electrical, housing, ventilation, and structural branches

Ballast/driver compatibility modelled as a distinct basic event

Cooling-fan function included where applicable

Basic event likelihood weighting from sign-specific failure history

Validation Criteria

Cross-check the dominant cut set identified by the tree against the internal inspection findings from the current failed sign, confirming the tree correctly anticipated the observed failure mode.

Typical Findings & Actions

Use the dominant cut set to prioritise inspection sequence (driver compatibility, seal, ventilation, structure) during an active sign investigation.
Where the tree points to a vibration/proximity-driven cut set, consider mounting reinforcement.
Where the tree points to a batch-level wiring-harness cut set, escalate to supplier quality engagement.

Programme Integration

Maintain the sign fault tree as a living document, updated as Division 23 RCA findings and PM inspection data accumulate.
Use the tree during sign specification/siting review for new installations, particularly near known vibration sources.
Cross-reference dominant cut sets against the PM programme (door seal, cooling-fan checks) to ensure proportionate coverage.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-SGN-01 (Illuminated Sign Maintenance Procedure)

Standards: IEC 61025, FAA AC 150/5345-44 (L-858 signs), ICAO Annex 14 Vol I

Diagram: Sign Fault Tree Diagram

Case Study: Division 23 — Root Cause Analysis (RCA-552 Repeated Sign Failure RCA)

Rev 0 — Initial issue

AEI-689 Failure Mode Identification

Purpose — The systematic process of enumerating every distinct way a specific AGL component, assembly, or system can fail — the first and foundational step of an FMEA (Failure Mode and Effects Analysis) — performed before any severity, frequency, or detectability scoring is attempted.

Applicable Scope

Applicable at any level — component (transformer, connector), assembly (fixture), or system (circuit, CCR) — and typically performed as a structured team exercise for a defined scope.

Common Pitfalls / Misapplication

HighListing failure effects (e.g., "runway light out") instead of failure modes (e.g., "isolation transformer open-circuit primary winding"), conflating two distinct FMEA columns

HighRelying on memory/intuition alone rather than systematically reviewing maintenance/RCA history, design documentation, and manufacturer failure-mode data, missing modes that have not yet occurred locally but are documented elsewhere

MediumStopping enumeration once a few "obvious" failure modes are listed, rather than continuing until the team genuinely runs out of plausible modes

MediumFailing to specify the failure mode at a consistent level of detail across the analysis (some modes very specific, others vague), making later scoring inconsistent

LowNot distinguishing between failure modes that are functionally equivalent but have different underlying causes, which matters for later severity/detectability differentiation

LowPerforming the exercise without input from technicians who have direct field experience of how the component actually fails in practice

Required Tools

FMEA worksheet template with distinct failure mode, effect, and cause columnsDesign/specification documentation for the component or systemDivision 23 RCA history and Division 27 preventive-topic library as a failure-mode reference baseManufacturer failure-mode/reliability data, where availableCross-functional team (design, maintenance, quality)

Safety Precautions

Not directly safety-critical as a desk exercise, though any physical verification of an identified mode should follow standard LOTO and access precautions.

Methodology Steps

Step 1Define the scope precisely — the specific component, assembly, or system boundary being analysed.
Step 2Systematically review internal RCA history (Division 23), preventive-topic library (Division 27), design documentation, and manufacturer data for every documented way the item has been known to fail.
Step 3Facilitate a structured team brainstorm to surface additional plausible failure modes not yet captured in the historical record.
Step 4Record each failure mode at a consistent, specific level of detail (the physical or functional way the item fails, not the downstream effect).
Step 5For each failure mode, briefly note the associated effect and potential cause(s) to support later severity/frequency/detectability scoring.
Step 6Review the completed list with the team to confirm no obvious mode has been missed and that modes are not duplicated under different wording.

Key Outputs

Failure modes recorded distinctly from effects

Coverage against internal RCA/preventive history

Coverage against design and manufacturer documentation

Consistent level of specificity across all listed modes

Cross-functional team input, including field-experienced technicians

Validation Criteria

Cross-check the completed failure mode list against the internal RCA and preventive-topic records to confirm every previously documented mode is captured, with no unexplained gaps.

Typical Findings & Actions

Not applicable directly — this topic feeds into AEI-690 (Failure Mode Classification) and the severity/frequency/detectability assessment topics (AEI-691 to AEI-693) rather than producing its own corrective action.

Programme Integration

Maintain the failure mode list as a living reference, updated whenever a new failure mode is discovered through Division 23 RCA.
Use the list as the starting point for any future FMEA, fault tree, or design review on the same component/system.
Cross-reference the list against the PM checklist to confirm each significant failure mode has a corresponding inspection/monitoring point.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-DESIGN-01 (Design Calculation and Review Procedure)

Standards: IEC 60812 (FMEA), SAE J1739 (potential failure mode and effects analysis)

Diagram: FMEA Worksheet Template

Case Study: Division 23 — Root Cause Analysis; Division 27 — Preventive Troubleshooting

Rev 0 — Initial issue

AEI-690 Failure Mode Classification

Purpose — The process of organising an enumerated list of failure modes (AEI-689) into meaningful categories — by mechanism (electrical, mechanical, thermal, environmental), by subsystem, by detectability, or by criticality — to support pattern recognition, targeted prevention, and prioritised engineering attention.

Applicable Scope

Applicable to the failure mode inventory across any AGL component, assembly, or system already enumerated via failure mode identification.

Common Pitfalls / Misapplication

HighUsing a single classification scheme when different questions require different schemes — e.g., classifying only by subsystem when a mechanism-based view (electrical vs. environmental) would better reveal a cross-cutting pattern

HighInconsistent category boundaries, so the same underlying failure mode gets classified differently depending on who is doing the classifying

MediumClassifying by the most recent or most memorable instance of a failure mode rather than by its actual underlying mechanism

MediumNot revisiting the classification scheme as new failure modes are identified, leaving newer entries mis-fitted into old categories

LowOver-engineering the classification with too many narrow categories, fragmenting the data and obscuring genuine patterns

LowClassifying failure modes without reference to their actual field frequency, so classification effort is spent evenly regardless of practical importance

Required Tools

The failure mode inventory from AEI-689Standard classification taxonomy (mechanism, subsystem, criticality) adapted to AGLSpreadsheet or database tool for tagging and filteringDivision 23/27 records for cross-checking mechanism assignmentCross-functional review for classification consistency

Safety Precautions

Not directly safety-critical as a desk exercise.

Methodology Steps

Step 1Select the classification scheme(s) relevant to the current analytical question — mechanism-based for prevention planning, subsystem-based for design review, criticality-based for prioritisation.
Step 2Define clear, consistent category boundaries and example entries for each category before classifying the full list.
Step 3Classify each failure mode from the AEI-689 inventory against the chosen scheme(s), cross-checking ambiguous entries with a second reviewer.
Step 4Tag or tabulate the classified list to allow filtering/grouping by category for subsequent Pareto or trend analysis.
Step 5Review the classified list as a group to identify any category with disproportionate representation, flagging it for closer attention.
Step 6Revisit and, where needed, revise the classification scheme as new failure modes are added over time.

Key Outputs

Classification scheme(s) selected and defined with clear boundaries

Consistency of classification across reviewers

Full coverage of the AEI-689 failure mode inventory

Category representation reviewed for disproportionate patterns

Scheme revisited periodically as new modes are added

Validation Criteria

Have a second reviewer independently classify a sample of the failure mode list against the same scheme and confirm agreement, before relying on the classification for further Pareto or trend analysis.

Typical Findings & Actions

Not applicable directly — this topic feeds into AEI-697 (Failure Pareto Analysis) and AEI-696 (Trend Analysis) rather than producing its own corrective action.

Programme Integration

Maintain the classification scheme as a documented standard, applied consistently across all future failure mode work.
Use the classified data as the direct input for periodic Pareto and trend analysis (AEI-696, AEI-697).
Review classification consistency periodically as part of the cross-division RCA review (see PRV-640).

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure)

Standards: IEC 60812 (FMEA), ISO 14224 (equipment failure classification, adapted)

Diagram: Failure Mode Classification Taxonomy

Case Study: Division 23 — Root Cause Analysis; Division 27 — Preventive Troubleshooting

Rev 0 — Initial issue

AEI-691 Failure Severity Assessment

Purpose — The structured scoring of how serious the consequence of a given failure mode would be if it occurred — the "S" in an FMEA-style S×O×D risk assessment — covering safety, operational, and regulatory-compliance impact, distinct from how likely the failure is to occur.

Applicable Scope

Applicable to any failure mode identified via AEI-689, scored against the consequence it would produce for aircraft operations, safety, and regulatory compliance if undetected and uncorrected.

Common Pitfalls / Misapplication

HighConflating severity with frequency — scoring a failure mode as "low severity" simply because it rarely happens, when severity should reflect consequence alone, independent of likelihood

HighScoring severity based on the average or typical outcome rather than the worst credible outcome the failure mode could plausibly produce

MediumUsing an ungrounded, purely subjective severity scale without reference to defined criteria (e.g., safety impact, runway closure duration, regulatory non-compliance)

MediumInconsistent scoring across different assessors due to a lack of shared, documented scoring criteria

LowNot revisiting severity scores after an operational change (e.g., increased traffic, new Cat III approach) that could alter the actual consequence of a given failure mode

LowScoring severity in isolation without input from operations/ATC perspective on the actual operational consequence

Required Tools

Defined severity scoring scale (e.g., 1–10) with documented criteria for safety, operational, and regulatory impactFailure mode inventory from AEI-689Cross-functional team including an operations/ATC perspectiveHistorical incident/consequence data where availableICAO Annex 14 / FAA AC compliance impact reference

Safety Precautions

Not directly safety-critical as a desk exercise, but the assessment itself directly informs safety-relevant prioritisation and must be conducted rigorously.

Methodology Steps

Step 1Define and document the severity scoring scale with explicit criteria at each level, covering safety, operational disruption, and regulatory/compliance consequence.
Step 2For each failure mode, identify the worst credible consequence if the failure occurred and went undetected/uncorrected, not the average or best-case outcome.
Step 3Score the severity against the documented scale, referencing the specific criteria rather than an intuitive gut-feel number.
Step 4Include an operations/ATC perspective in the scoring session for failure modes with potential aircraft-operational consequence.
Step 5Cross-check the assigned score against any available historical incident data for that or a comparable failure mode.
Step 6Record the score with its supporting rationale so it can be reviewed and revisited consistently in future.

Key Outputs

Documented severity scale with explicit criteria

Worst-credible-consequence basis for each score, not average case

Cross-functional input including operations/ATC

Consistency check against comparable failure modes

Rationale documented alongside each score

Validation Criteria

Have a second reviewer independently score a sample of failure modes against the same documented scale and confirm reasonable agreement before the severity data is used for risk prioritisation.

Typical Findings & Actions

Not applicable directly — severity scores feed into AEI-694 (Risk-Based Troubleshooting) for prioritisation rather than producing a standalone corrective action.

Programme Integration

Maintain the documented severity scale as a stable reference, revisited only when operational conditions genuinely change (e.g., new approach category).
Combine severity scores with frequency (AEI-692) and detectability (AEI-693) scores to drive risk-based prioritisation (AEI-694).
Periodically re-validate severity scores against actual incident consequence data as it accumulates.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-SMS-01 (Safety Risk Assessment Procedure)

Standards: IEC 60812 (FMEA), ICAO Doc 9859 (Safety Management Manual — risk assessment), ICAO Annex 14 Vol I

Diagram: Severity Scoring Scale and Criteria Table

Case Study: Division 23 — Root Cause Analysis; Division 27 — Preventive Troubleshooting

Rev 0 — Initial issue

AEI-692 Failure Frequency Assessment

Purpose — The structured scoring of how often a given failure mode is expected to occur — the "O" (occurrence) in an FMEA-style S×O×D risk assessment — grounded in actual field failure history rather than intuition, distinct from the severity of its consequence.

Applicable Scope

Applicable to any failure mode identified via AEI-689, scored against its actual or reasonably estimated rate of occurrence across the relevant population (by component, location, or circuit).

Common Pitfalls / Misapplication

HighEstimating frequency from memory or recent, salient events rather than from the actual CMMS/FRACAS failure history, producing a biased (recency-weighted) score

HighScoring frequency for the wrong population size — e.g., treating a failure that has occurred twice out of 5 units as equally frequent as one that has occurred twice out of 500 units

MediumNot normalising frequency data by exposure time (e.g., failures per operating hour or per year) when comparing components with different installation ages

MediumUsing an ungrounded, purely subjective frequency scale without reference to actual historical rate bands

LowFailing to account for underreporting — some failure modes may be systematically under-logged in the CMMS relative to others

LowNot revisiting frequency scores as more field data accumulates, leaving early, data-poor estimates unrevised for years

Required Tools

CMMS/FRACAS failure history export by failure mode and populationDefined frequency scoring scale (e.g., 1–10) with documented rate-band criteriaPopulation/exposure data (installed quantity, age, operating hours)Spreadsheet or statistical tool for rate calculationCross-functional review for scoring consistency

Safety Precautions

Not directly safety-critical as a desk exercise.

Methodology Steps

Step 1Define and document the frequency scoring scale with explicit rate-band criteria (e.g., failures per 1,000 unit-years) at each level.
Step 2Pull the actual failure count for the specific failure mode from the CMMS/FRACAS history over a defined period.
Step 3Determine the correct denominator (population size, exposure time) to normalise the raw failure count into a genuine rate rather than an absolute count.
Step 4Score the frequency against the documented rate-band scale using the normalised rate, not the raw count alone.
Step 5Note any known underreporting risk for that failure mode and adjust the confidence (not necessarily the score itself) accordingly.
Step 6Record the score with its supporting data (count, population, period) so it can be revisited and recalculated as more data accumulates.

Key Outputs

Documented frequency scale with explicit rate-band criteria

Actual CMMS/FRACAS data used as the basis for the score

Correct population/exposure normalisation applied

Underreporting risk noted where relevant

Supporting data (count, population, period) recorded with the score

Validation Criteria

Recalculate a sample of frequency scores directly from the underlying CMMS export and confirm they match the recorded score and rate-band assignment before the data is used for risk prioritisation.

Typical Findings & Actions

Not applicable directly — frequency scores feed into AEI-694 (Risk-Based Troubleshooting) for prioritisation rather than producing a standalone corrective action.

Programme Integration

Recalculate frequency scores on a defined periodic cycle (e.g., annually) as more field data accumulates, rather than treating early estimates as permanent.
Combine frequency scores with severity (AEI-691) and detectability (AEI-693) scores to drive risk-based prioritisation (AEI-694).
Periodically audit CMMS logging completeness for failure modes suspected of underreporting.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-SMS-01 (Safety Risk Assessment Procedure)

Standards: IEC 60812 (FMEA), ISO 14224 (reliability data collection, adapted)

Diagram: Frequency Scoring Scale and Rate-Band Table

Case Study: Division 23 — Root Cause Analysis; Division 21 — Preventive Maintenance Troubleshooting

Rev 0 — Initial issue

AEI-693 Failure Detectability Assessment

Purpose — The structured scoring of how likely a given failure mode is to be detected before it produces an operational consequence — the "D" (detection) in an FMEA-style S×O×D risk assessment — reflecting the effectiveness of current inspection, monitoring, and alarm coverage for that specific mode.

Applicable Scope

Applicable to any failure mode identified via AEI-689, scored against the current PM inspection programme, ALCMS/SCADA monitoring, and any other detection mechanism in place for that mode.

Common Pitfalls / Misapplication

HighAssuming a failure mode is well-detected simply because a PM programme exists, without verifying the specific inspection actually checks for that specific mode

HighScoring detectability optimistically for a mode that is only caught reactively (i.e., after it has already produced a visible symptom), rather than proactively before consequence occurs

MediumNot accounting for detection latency — a mode that is technically detectable but only at long PM intervals may still allow significant undetected dwell time

MediumIgnoring alarm/monitoring reliability itself as a factor — an ALCMS alarm that is prone to being dismissed as a nuisance (see PRV-629) provides weaker actual detection than its nominal capability suggests

LowUsing an ungrounded, purely subjective detectability scale without reference to actual PM interval and monitoring coverage data

LowNot revisiting detectability scores after a PM programme or monitoring system change that alters actual detection capability

Required Tools

PM checklist and interval schedule for the relevant component/failure modeALCMS/SCADA monitoring and alarm capability referenceDefined detectability scoring scale (e.g., 1–10) with documented criteriaAlarm reliability/nuisance-rate data (see PRV-629 findings)Cross-functional review for scoring consistency

Safety Precautions

Not directly safety-critical as a desk exercise, though poor detectability findings should be treated with urgency given their direct link to undetected safety-relevant conditions.

Methodology Steps

Step 1Define and document the detectability scoring scale with explicit criteria (e.g., proactive automated detection vs. detection only after visible symptom) at each level.
Step 2For each failure mode, identify the specific PM inspection step, test, or monitoring/alarm mechanism (if any) that would actually catch it.
Step 3Assess the detection latency — the interval or delay between the failure mode occurring and it actually being caught by the identified mechanism.
Step 4Factor in the reliability of any automated alarm/monitoring mechanism, referencing known nuisance-alarm or reliability data where available.
Step 5Score detectability against the documented scale, distinguishing proactive detection from reactive (post-symptom) detection.
Step 6Record the score with its supporting rationale, including which specific PM/monitoring step provides the detection.

Key Outputs

Documented detectability scale with explicit criteria

Specific PM/monitoring mechanism identified per failure mode

Detection latency assessed, not assumed instantaneous

Alarm/monitoring reliability factored into the score

Rationale documented alongside each score

Validation Criteria

Cross-check a sample of detectability scores against the actual PM checklist and monitoring configuration to confirm the identified detection mechanism genuinely exists and covers the specific failure mode as scored.

Typical Findings & Actions

Where a failure mode is found to have poor detectability, add or strengthen a specific PM/monitoring step to close the gap, rather than leaving the score as an accepted risk without justification.

Programme Integration

Combine detectability scores with severity (AEI-691) and frequency (AEI-692) scores to drive risk-based prioritisation (AEI-694).
Revisit detectability scores whenever the PM programme or monitoring/alarm system is changed.
Prioritise closing detectability gaps for failure modes with high severity and non-trivial frequency, even if detectability alone would not otherwise flag them.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-SMS-01 (Safety Risk Assessment Procedure)

Standards: IEC 60812 (FMEA), ICAO Doc 9859

Diagram: Detectability Scoring Scale and PM/Monitoring Coverage Map

Case Study: Division 23 — Root Cause Analysis (RCA-559 Repeated Communication Failure RCA); Division 27 — Preventive Troubleshooting (PRV-629 Preventing CCR False Alarms)

Rev 0 — Initial issue

AEI-694 Risk-Based Troubleshooting

Purpose — The practice of prioritising maintenance, investigation, and preventive-action effort according to combined risk (typically Severity × Occurrence × Detectability, or an equivalent risk matrix) rather than treating every open fault or identified failure mode as equally deserving of immediate, equal attention.

Applicable Scope

Applicable across the entire AGL system — used to sequence which faults get investigated first, which failure modes receive PM programme enhancement first, and which preventive actions are funded first when resources are limited.

Common Pitfalls / Misapplication

HighPrioritising purely by recency or visibility (the most recent complaint, or the fault an executive happened to notice) rather than by calculated risk

HighUsing severity alone without incorporating frequency and detectability, over-prioritising rare-but-severe items at the expense of frequent-but-moderate ones that produce more cumulative risk

MediumApplying risk scores inconsistently across different assessors or time periods, so the resulting priority ranking is not genuinely comparable

MediumTreating the risk ranking as static once calculated, rather than recalculating periodically as frequency and detectability data change

LowNot communicating the risk-based rationale to stakeholders, so a lower-ranked but visible item is escalated outside the process anyway, undermining its value

LowApplying risk-based prioritisation only to new findings while ignoring a backlog of previously identified, unscored risks

Required Tools

Risk matrix or S×O×D scoring templateSeverity (AEI-691), Frequency (AEI-692), and Detectability (AEI-693) scores for the relevant failure modesPrioritised action backlog/registerResource/budget constraint data for the current planning periodStakeholder communication template for risk-based rationale

Safety Precautions

Ensure risk-based prioritisation never delays an item with an identified imminent safety risk, regardless of its calculated relative ranking against other items — genuine urgency overrides the process.

Methodology Steps

Step 1Compile the current backlog of identified failure modes, open findings, and candidate preventive actions requiring prioritisation.
Step 2Ensure each item has (or is assigned) a Severity, Frequency, and Detectability score using the methods in AEI-691 through AEI-693.
Step 3Calculate the combined risk score (e.g., Risk Priority Number = S × O × D, or an equivalent matrix position) for each item.
Step 4Rank the backlog by combined risk score, distinguishing this ranking from a purely severity-based or purely recency-based ordering.
Step 5Allocate available resources (investigation time, preventive-action budget) to the highest-ranked items first, documenting the rationale.
Step 6Recalculate rankings periodically as new frequency/detectability data accumulates or as corrective/preventive actions change the underlying risk.

Key Outputs

Backlog completeness — all known items scored, not only new ones

S×O×D or equivalent scores present for every ranked item

Combined risk score correctly calculated and ranking genuinely risk-based

Resource allocation aligned to the ranking, with documented rationale

Periodic recalculation cadence established

Validation Criteria

Review the current prioritised backlog against the underlying S×O×D data to confirm the ranking is mathematically consistent, and confirm actual resource allocation over the period followed the documented ranking (or that any deviation is explicitly justified).

Typical Findings & Actions

Where an item is escalated outside the risk-based process, document the justification and feed it back into refining the scoring criteria if it reveals a genuine scoring gap.
Re-rank the backlog immediately if new data reveals a previously low-ranked item has a materially higher actual risk than scored.

Programme Integration

Institutionalise risk-based prioritisation as the default method for allocating RCA and preventive-action resources, documented in the maintenance/quality management programme.
Recalculate the risk-ranked backlog on a defined periodic cycle (e.g., quarterly) aligned with the cross-division RCA review (see PRV-640).
Train planners and engineers in S×O×D scoring and risk-matrix interpretation to ensure consistent application.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-SMS-01 (Safety Risk Assessment Procedure), SOP-PRV-01 (Preventive Maintenance Procedure)

Standards: IEC 60812 (FMEA), ICAO Doc 9859 (SMS risk management), ISO 55001 (asset management)

Diagram: Risk Matrix / Prioritised Backlog Register

Case Study: Division 23 — Root Cause Analysis; Division 27 — Preventive Troubleshooting

Rev 0 — Initial issue

AEI-695 Recurrence Analysis

Purpose — The focused analytical technique of identifying, across the full fault history, which specific fault instances represent a genuine repeat of a previously closed issue — at the same location, on the same component type, or with the same failure signature — as distinct from routine, generally distributed maintenance activity.

Applicable Scope

Applicable across the CMMS/FRACAS fault history field-wide, cross-referenced by location, component ID/batch, and failure-mode classification (from AEI-690).

Common Pitfalls / Misapplication

HighRelying on manual memory to notice a repeat pattern rather than a systematic CMMS query, so recurrence is only caught if a technician happens to recall the earlier instance

HighDefining "recurrence" too narrowly (only an exact same-location repeat) and missing a pattern that recurs across a batch, model, or fault-mode category rather than a single position

MediumNot setting a defined recurrence interval threshold, so a genuinely unrelated failure years apart is treated the same as a suspicious repeat within weeks

MediumClosing a work order without recording enough structured data (failure mode classification, batch/location) to allow future recurrence queries to actually find the match

LowTreating every recurrence automatically as requiring a full RCA, without a triage step to filter out genuinely coincidental repeats from suspicious ones

LowAnalysing recurrence only reactively (after a third or fourth repeat) rather than proactively flagging after the second occurrence

Required Tools

CMMS/FRACAS query tool with location, batch, and failure-mode filteringDefined recurrence interval threshold and matching criteriaFailure mode classification data from AEI-690Recurrence flag/escalation configuration in the CMMSHistorical fault record with sufficient structured data fields

Safety Precautions

Not directly safety-critical as a desk/data exercise.

Methodology Steps

Step 1Define the matching criteria for what counts as a "recurrence" — same location, same component batch, same failure-mode classification, or a combination, and the time interval considered relevant.
Step 2Query the CMMS/FRACAS fault history systematically against the defined criteria, rather than relying on manual recall.
Step 3Compile the list of matched recurrence candidates, distinguishing genuine repeats from coincidental unrelated events using the structured data available.
Step 4Triage the recurrence list by combined risk (see AEI-694) to prioritise which recurring patterns warrant a full RCA versus lower-level monitoring.
Step 5For prioritised recurrences, route into the appropriate Division 23 RCA topic for full investigation.
Step 6Configure the CMMS, where possible, to automatically flag a second occurrence matching the defined criteria for earlier proactive review rather than waiting for a third or fourth repeat.

Key Outputs

Matching criteria explicitly defined and documented

Systematic CMMS query used, not manual recall alone

Recurrence candidates compiled with supporting structured data

Triage applied by combined risk, not treated uniformly

Automatic second-occurrence flagging configured where possible

Validation Criteria

Spot-check the CMMS query results against a manually reviewed sample of the fault history to confirm the systematic query is correctly identifying genuine recurrences and not missing matches due to inconsistent data entry.

Typical Findings & Actions

Route confirmed, risk-significant recurrences into the appropriate Division 23 RCA topic for full investigation.
Correct any data-entry inconsistency found that prevented the systematic query from matching a genuine recurrence.

Programme Integration

Configure the CMMS with a standing recurrence-flag rule, escalating automatically at the second matching occurrence within the defined interval.
Require structured, consistent data entry (location, batch, failure-mode classification) at every work order closure to support future recurrence queries.
Review recurrence analysis output as a standing item in the periodic cross-division RCA review (see PRV-640).

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-QA-01 (Work Order Closure and Verification Procedure)

Standards: ISO 9001:2015 Cl. 10.2, ISO 55001

Diagram: Recurrence Query Criteria and Flag Configuration

Case Study: Division 23 — Root Cause Analysis (all "Repeated ___ RCA" topics)

Rev 0 — Initial issue

AEI-696 Trend Analysis

Purpose — The technique of plotting a failure, condition, or performance metric over time — insulation resistance, fault frequency, thermal readings, photometric output — to detect a gradual, directional change before it crosses a threshold and becomes an actual fault, distinct from single-point pass/fail inspection.

Applicable Scope

Applicable to any AGL parameter with repeated measurement over time — insulation resistance, CCR output, earth-loop resistance, photometric survey results, alignment survey results, connector contact resistance, and fault frequency itself.

Common Pitfalls / Misapplication

HighRelying on single-point pass/fail readings without retaining and plotting the historical series, so a genuine downward trend approaching (but not yet crossing) the threshold goes unnoticed

HighComparing readings taken with inconsistent test methodology (different test voltage, different equipment, different technician) across the trend, introducing noise that masks or mimics a real trend

MediumNot normalising for known cyclical factors (seasonal moisture, temperature) when interpreting a trend, causing a genuine cyclical pattern to be misread as directional decline or vice versa

MediumApplying a simple linear trend line to data that is genuinely non-linear (e.g., an accelerating end-of-life decline), producing a misleading projection

LowTrending too infrequently (long intervals between readings) to catch a fast-developing issue before it crosses the threshold

LowNot setting a defined action threshold on the trend itself, so even a clearly declining trend does not trigger proactive action until an actual failure threshold is crossed

Required Tools

Trend data export from CMMS/test records for the parameter of interestSpreadsheet or statistical/plotting toolStandardised test methodology (consistent voltage, equipment, technique) across all readingsSeasonal/cyclical reference data for normalisationDefined action threshold distinct from the hard failure threshold

Safety Precautions

Not directly safety-critical as a desk/data exercise, though action triggered by a trend (e.g., proactive replacement) should follow standard LOTO and access precautions.

Methodology Steps

Step 1Compile the full historical series of the parameter for the specific location/component, not just the most recent reading.
Step 2Confirm the readings were taken with consistent methodology; flag or exclude any reading known to use a different test voltage/equipment/technique.
Step 3Plot the trend and visually and statistically assess its shape — stable, linear decline, or accelerating (non-linear) decline.
Step 4Normalise or annotate the trend for known cyclical factors (season, temperature) to distinguish genuine directional decline from expected cyclical variation.
Step 5Compare the trend's trajectory against a defined proactive action threshold, set comfortably ahead of the hard failure threshold.
Step 6Trigger proactive investigation or preventive action when the trend crosses the action threshold, rather than waiting for the hard failure threshold to be reached.

Key Outputs

Full historical series compiled, not single-point readings

Test methodology consistency confirmed across the series

Trend shape assessed (stable/linear/accelerating)

Seasonal/cyclical normalisation applied where relevant

Defined proactive action threshold distinct from hard failure threshold

Validation Criteria

Confirm that recent trend reviews have correctly identified any parameter approaching its proactive action threshold, and that the corresponding preventive action was triggered before the hard failure threshold was reached.

Typical Findings & Actions

Trigger proactive investigation/preventive action for any parameter confirmed to have crossed its action threshold.
Correct test methodology inconsistency identified in the historical series to improve the reliability of future trend analysis.

Programme Integration

Standardise test methodology across all technicians and equipment for every trended parameter.
Set and document a proactive action threshold, distinct from the hard failure threshold, for every parameter trended in the PM programme.
Review trend data on a defined periodic cycle as a standing PM/quality activity, not only reactively.

Related References

SOP: SOP-PRV-01 (Preventive Maintenance Procedure), SOP-TEST-03 (Insulation Resistance Test Procedure), SOP-PHM-01 (Photometric Survey Procedure)

Standards: ISO 55001 (asset management), IEEE 43 (insulation testing practice)

Diagram: Trend Chart Template with Action/Failure Threshold Lines

Case Study: Division 23 — Root Cause Analysis (RCA-555 Repeated Insulation Failure RCA, RCA-556 Repeated Photometry Failure RCA)

Rev 0 — Initial issue

AEI-697 Failure Pareto Analysis

Purpose — The application of Pareto (80/20) analysis to the classified AGL failure mode inventory — ranking failure categories by frequency or cumulative risk contribution to identify the small number of categories responsible for the large majority of field failures, focusing engineering and preventive resources accordingly.

Applicable Scope

Applicable to the field-wide or division-wide classified failure mode data (from AEI-690), typically compiled from CMMS/FRACAS records over a defined analysis period.

Common Pitfalls / Misapplication

HighRanking by raw failure count alone without considering severity, so a high-frequency but low-consequence category dominates the chart at the expense of a lower-frequency but high-severity one that deserves more attention

HighUsing an analysis period too short or too long for the actual failure rate, either producing a noisy chart from too little data or masking a recent emerging pattern by diluting it with old data

MediumNot re-running the Pareto analysis periodically, so resource allocation continues to follow an outdated pattern after a previously dominant category has been successfully addressed

MediumClassifying at too coarse a level (e.g., "electrical failure" as one bar) which obscures which specific sub-category is actually driving the count

LowPresenting the Pareto chart without the underlying data table, making it harder for stakeholders to interrogate the classification behind each bar

LowTreating the "vital few" categories in isolation without also tracking whether the "trivial many" collectively remain trivial or are quietly growing

Required Tools

Classified failure mode data from AEI-690CMMS/FRACAS export for the defined analysis periodSpreadsheet or statistical/charting tool for Pareto chart generationCombined risk data (from AEI-691–694) for a risk-weighted Pareto variantDefined, documented analysis period and re-run cadence

Safety Precautions

Not directly safety-critical as a desk/data exercise.

Methodology Steps

Step 1Define the analysis scope and period — field-wide or division-specific, and a time window appropriate to the actual failure rate of the categories involved.
Step 2Compile the classified failure count (or combined risk score) by category from the CMMS/FRACAS data for that scope and period.
Step 3Rank categories in descending order and calculate the cumulative percentage to identify the "vital few" categories responsible for the majority of failures or risk.
Step 4Where severity varies significantly across categories, produce a risk-weighted Pareto (using combined S×O×D or similar) alongside the simple frequency-based chart.
Step 5Present the chart with its underlying data table so the classification behind each bar can be interrogated by stakeholders.
Step 6Re-run the analysis on a defined periodic cycle to confirm whether previously dominant categories have declined and whether a new category is emerging.

Key Outputs

Analysis scope and period explicitly defined

Classified data correctly compiled from the CMMS/FRACAS source

Cumulative percentage/vital-few categories correctly identified

Risk-weighted variant produced where severity varies significantly

Underlying data table available alongside the chart

Validation Criteria

Cross-check the top-ranked category in the Pareto chart against a manual review of a sample of the underlying fault records to confirm the classification and count are accurate before the chart is used to justify resource allocation.

Typical Findings & Actions

Direct RCA and preventive-action resources toward the "vital few" categories identified, consistent with the risk-based prioritisation approach in AEI-694.

Programme Integration

Re-run the Pareto analysis on a defined periodic cycle (e.g., quarterly) as a standing input to the cross-division RCA review (see PRV-640).
Track whether previously addressed "vital few" categories have genuinely declined in subsequent Pareto cycles, confirming corrective/preventive action effectiveness (see AEI-699, AEI-700).
Watch for a category migrating from the "trivial many" into the "vital few" over successive cycles as an early warning of an emerging pattern.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-PRV-01 (Preventive Maintenance Procedure)

Standards: ISO 9001:2015 Cl. 9.1 (monitoring, measurement, analysis and evaluation), ISO 55001

Diagram: Pareto Chart Template with Cumulative Percentage Line

Case Study: Division 23 — Root Cause Analysis (all topics); Division 27 — Preventive Troubleshooting

Rev 0 — Initial issue

AEI-698 Maintenance History Analysis

Purpose — The systematic review of a component's or circuit's complete maintenance record — every PM visit, repair, part replacement, and inspection finding over its full service life — to extract patterns, verify maintenance adequacy, and inform investigation, distinct from looking only at the immediate fault at hand.

Applicable Scope

Applicable to any AGL component, fixture, circuit, or CCR with an accumulated maintenance record in the CMMS, used both during active RCA investigations and as a standalone periodic review activity.

Common Pitfalls / Misapplication

HighReviewing only the most recent one or two work orders rather than the full service-life history, missing an earlier finding that is directly relevant to the current investigation

HighTreating the maintenance record as complete and accurate without cross-checking for gaps — missed PM visits, incomplete checklists, or undocumented informal repairs

MediumNot distinguishing between a genuine repeat fault and a series of unrelated, coincidental faults when reviewing the history, leading to a false pattern conclusion

MediumReviewing the history in isolation from the equipment's actual operating conditions (load, environment, traffic) over the same period, missing a contextual explanation for the pattern

LowReviewing history from a single data source (e.g., CMMS only) without cross-referencing paper records, photographs, or informal notes that may hold additional context

LowExtracting the history but not converting the findings into a structured input for further Pareto, trend, or recurrence analysis

Required Tools

Full CMMS/FRACAS work order history export for the itemCross-reference to paper records, photographs, or informal maintenance notesEquipment operating condition data (load, environment) for the same periodMaintenance history review checklist/templateAccess to prior RCA findings referencing the same item, where they exist

Safety Precautions

Not directly safety-critical as a desk/record-review exercise.

Methodology Steps

Step 1Compile the complete maintenance history for the item across its full service life, not only the most recent entries.
Step 2Cross-check the CMMS record against any available paper records, photographs, or informal notes for completeness and consistency.
Step 3Identify gaps in the record — missed PM visits, incomplete checklists — and note them as a limitation on the analysis rather than assuming full coverage.
Step 4Distinguish genuine repeat findings (same fault type/location recurring) from a series of unrelated events across the history.
Step 5Cross-reference the maintenance timeline against known operating condition changes (traffic increase, nearby civil works, seasonal patterns) for contextual explanation.
Step 6Feed the structured findings into the relevant Pareto (AEI-697), trend (AEI-696), or recurrence (AEI-695) analysis, or directly into an active RCA investigation.

Key Outputs

Full service-life history compiled, not recent entries only

Cross-referenced against paper/photographic records where available

Record gaps identified and noted as a limitation

Genuine repeat findings distinguished from coincidental events

Operating condition context cross-referenced against the timeline

Validation Criteria

Confirm the compiled history against the CMMS source data for completeness, and confirm any pattern conclusion drawn is supported by genuinely comparable, correctly classified events rather than coincidental unrelated ones.

Typical Findings & Actions

Route any genuine repeat pattern identified into the appropriate Division 23 RCA topic for full investigation.
Address any identified maintenance record gap (missed PM, incomplete checklist) as its own corrective finding.

Programme Integration

Make full-history review, not just recent-record review, a standard step in any RCA investigation procedure.
Improve CMMS data entry discipline to close the specific gaps identified during history reviews.
Retain paper/photographic records in a way that is cross-referenceable with the CMMS for future history analysis.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-QA-01 (Work Order Closure and Verification Procedure)

Standards: ISO 55001 (asset management), ISO 9001:2015 Cl. 7.5 (documented information)

Diagram: Maintenance History Timeline Template

Case Study: Division 23 — Root Cause Analysis (RCA-560 Repeated Maintenance Failure RCA)

Rev 0 — Initial issue

AEI-699 Corrective Action Effectiveness

Purpose — The structured follow-up review conducted after a corrective action has been implemented, to confirm the action actually eliminated or reduced the specific fault it targeted, rather than assuming effectiveness from the work order being closed.

Applicable Scope

Applicable to any corrective action taken from a Division 23 RCA, Division 27 preventive topic, or any other fault-response work order, reviewed against the specific fault/failure mode it was intended to address.

Common Pitfalls / Misapplication

HighClosing the review at "action was implemented" rather than "action was verified effective," conflating completion with effectiveness

HighReviewing effectiveness too soon after implementation, before enough time/exposure has passed for the fault to plausibly recur if the action was inadequate

MediumReviewing effectiveness only at the exact location of the original fault, missing whether the same action needs to be (or was) applied to other units with the same underlying cause

MediumNot defining, at the time the corrective action is decided, what specific evidence would constitute proof of effectiveness

LowAttributing an apparent improvement to the corrective action without ruling out a coincidental factor (season change, reduced traffic) that could explain the same result

LowNot tracking effectiveness review as a formal, closeable step in the CMMS, so it is informally skipped under workload pressure

Required Tools

The original RCA/corrective action record with defined success criteriaCMMS fault history for the specific item/location post-implementationDefined review interval appropriate to the fault type's expected recurrence timescaleComparable baseline data (pre-action fault rate) for before/after comparisonEffectiveness review checklist/template

Safety Precautions

Not directly safety-critical as a desk/data review, though any physical re-inspection performed as part of the review should follow standard LOTO and access precautions.

Methodology Steps

Step 1At the time the corrective action is decided, explicitly define what evidence (e.g., "zero recurrence over 12 months" or "insulation resistance trend stabilises") would constitute proof of effectiveness.
Step 2Allow an appropriate review interval to pass — long enough for the fault to plausibly recur if the action was inadequate, based on the fault type's expected timescale.
Step 3Pull the post-implementation fault history for the specific item/location and compare it against the defined success criteria and the pre-action baseline.
Step 4Consider whether any coincidental factor (season, traffic change) could explain an apparent improvement independent of the corrective action itself.
Step 5Where the action was intended to apply beyond the single original location (e.g., a batch-wide replacement), confirm it was actually implemented across the full intended population.
Step 6Formally close the effectiveness review as its own tracked step in the CMMS, distinct from the original work order closure.

Key Outputs

Success criteria defined at the time the action was decided, not retrospectively

Review interval appropriate to the fault type's recurrence timescale

Post-implementation data compared against pre-action baseline

Coincidental explanatory factors considered and ruled out

Action population coverage confirmed where broader than a single location

Validation Criteria

Confirm the effectiveness review was completed as a distinct, documented step with a clear conclusion (effective / not effective / inconclusive, pending further time) against the originally defined success criteria.

Typical Findings & Actions

Where the action is found not effective, re-open the original RCA for further investigation rather than assuming the case is closed.
Where the action is found only partially effective, extend or supplement the corrective action rather than accepting a partial improvement as success.

Programme Integration

Make effectiveness review a mandatory, tracked step in the CMMS for every corrective action arising from a Division 23 RCA.
Define success criteria and review interval as a standard part of every corrective action decision, not an afterthought.
Feed effectiveness review outcomes into the periodic cross-division RCA review (see PRV-640) to identify any systemic pattern of ineffective actions.

Related References

SOP: SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-QA-01 (Work Order Closure and Verification Procedure)

Standards: ISO 9001:2015 Cl. 10.2 (corrective action effectiveness review is an explicit requirement)

Diagram: Corrective Action Effectiveness Review Template

Case Study: Division 23 — Root Cause Analysis (all topics)

Rev 0 — Initial issue

AEI-700 Preventive Action Effectiveness

Purpose — The structured follow-up review conducted after a preventive action (Division 27) has been implemented, to confirm it actually reduced the field-wide incidence of the failure mode it targeted, distinct from corrective action effectiveness (AEI-699) which reviews a single fault response rather than a proactive, population-wide measure.

Applicable Scope

Applicable to any preventive action from Division 27 or any other proactive programme measure (PM checklist change, training update, design standard revision), reviewed against the field-wide failure mode frequency it was intended to reduce.

Common Pitfalls / Misapplication

HighReviewing only whether the preventive action was implemented (e.g., "checklist was updated") rather than whether field-wide failure frequency for the targeted mode actually declined

HighReviewing too soon relative to the PM cycle length, before the new checklist/procedure has actually been applied across a representative sample of the population

MediumNot maintaining a clean pre-action baseline frequency for comparison, making it difficult to quantify the actual improvement

MediumAttributing an observed decline to the preventive action without considering a coincidental factor (fewer new installations, milder weather season) that could explain part of the change

LowReviewing field-wide frequency without also checking whether the preventive action was actually adopted consistently across all relevant teams/locations

LowNot distinguishing a genuine reduction in occurrence from a reduction in reported occurrence, where reporting/detection practices may have also changed

Required Tools

The Division 27 preventive topic or programme measure with its defined intent/targetPre-action baseline field-wide frequency data (from AEI-692/AEI-696/AEI-697)Post-action field-wide frequency data over an appropriate review periodAdoption/compliance check across relevant teams/locationsEffectiveness review checklist/template

Safety Precautions

Not directly safety-critical as a desk/data review.

Methodology Steps

Step 1At the time the preventive action is implemented, capture or confirm the pre-action baseline field-wide frequency for the targeted failure mode.
Step 2Allow a review period appropriate to the PM cycle length and the failure mode's expected timescale, so the action has genuinely had a chance to take effect across the population.
Step 3Pull the post-action field-wide frequency data (via Pareto/trend analysis, AEI-696/AEI-697) for the same failure mode and compare against the baseline.
Step 4Check adoption/compliance — confirm the preventive measure (checklist item, training, standard) was actually applied consistently across relevant teams and locations, not only in isolated instances.
Step 5Consider whether any coincidental factor could explain part of an observed change, and whether reporting/detection practice itself changed over the same period.
Step 6Formally document the effectiveness conclusion and feed it into the periodic cross-division RCA/preventive review (see PRV-640).

Key Outputs

Pre-action baseline frequency captured and retained

Review period appropriate to PM cycle and failure mode timescale

Post-action frequency compared against baseline using consistent methodology

Adoption/compliance verified across relevant teams/locations

Coincidental and reporting-practice factors considered

Validation Criteria

Confirm the effectiveness conclusion is supported by a genuine before/after comparison using consistent data sources and methodology, with adoption verified across the intended population, before the preventive action is considered validated.

Typical Findings & Actions

Where the preventive action is found ineffective, revisit the underlying Division 23 RCA and Division 27 topic for a more fundamental review rather than assuming the measure simply needs more time.
Where adoption is found inconsistent, address the compliance gap directly (retraining, process reinforcement) before concluding the measure itself is ineffective.

Programme Integration

Make preventive action effectiveness review a standing, periodic item in the cross-division RCA review (see PRV-640), not a one-off check.
Maintain clean, consistent baseline and post-action frequency data as a standard output of the Pareto/trend analysis programme (AEI-696, AEI-697).
Use validated-effective preventive actions as reference case studies when designing future preventive measures for comparable failure modes.

Related References

SOP: SOP-PRV-01 (Preventive Maintenance Procedure), SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-QA-01 (Work Order Closure and Verification Procedure)

Standards: ISO 9001:2015 Cl. 9.1/10.2, ISO 55001 (asset management)

Diagram: Preventive Action Effectiveness Review Template

Case Study: Division 27 — Preventive Troubleshooting (all topics); Division 23 — Root Cause Analysis

Rev 0 — Initial issue

No topics match your search. Try a different term.

Frequently Asked Questions

Quick answers about Division 30 — Advanced RCA / Engineering Investigation in the AGL Troubleshooting Atlas.

Q1What does Division 30 of the AGL Troubleshooting Atlas cover?

Division 30 is the Advanced RCA / Engineering Investigation reference. It publishes 20 diagnostic topics, AEI-681 to AEI-700, in a single subsection.

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 topics are in Division 30?

The 20 topics are AEI-681 to AEI-700: 5-Why Analysis for AGL Failure; Fishbone Analysis for AGL Failure; Fault Tree Analysis for CCR Failure; Fault Tree Analysis for Series Circuit Failure; Fault Tree Analysis for Transformer Failure; Fault Tree Analysis for Cable Failure; Fault Tree Analysis for Fixture Failure; Fault Tree Analysis for Sign Failure; Failure Mode Identification; Failure Mode Classification; Failure Severity Assessment; Failure Frequency Assessment; Failure Detectability Assessment; Risk-Based Troubleshooting; Recurrence Analysis; Trend Analysis; Failure Pareto Analysis; Maintenance History Analysis; Corrective Action Effectiveness; Preventive Action Effectiveness.

Q4How does a diagnostic procedure begin in Division 30?

Each procedure starts with observation before any intervention. For example, AEI-681 (5-Why Analysis for AGL Failure) begins: State the problem precisely and factually — the specific fault, location, and date — rather than a vague or generalised description.

Q5What safety precautions apply in Division 30?

Each topic lists its own precautions. For example, AEI-681 (5-Why Analysis for AGL Failure) starts with: Conduct any interview involved in the analysis in a non-punitive, just-culture manner.

Q6Which SOPs are referenced in Division 30?

Related references in the topics include SOP-RCA-01 (Root Cause Analysis and FRACAS Procedure), SOP-HR-01 (Just Culture and Non-Punitive Investigation Procedure), SOP-CCR-04 (CCR LOTO Procedure), SOP-RCL-02 (Series Circuit Fault Location Procedure), SOP-RCL-12 (Transformer Test and Replacement Procedure), SOP-RCL-03 (Fixture Replacement Procedure), SOP-SGN-01 (Illuminated Sign Maintenance Procedure) and SOP-DESIGN-01 (Design Calculation and Review Procedure), and 5 more.

Q7Which standards are referenced in Division 30?

Where a standard applies, it appears in the topic's Related References. Those cited in this division include ISO 9001:2015 Cl. 10.2, ICAO Doc 9859, IEC 61025, ICAO Annex 14 Vol I, FAA AC 150/5340-30, FAA AC 150/5345-26, IEEE C57.12.91, IEC 60364, FAA AC 150/5345-46 and FAA AC 150/5345-44, among others.

Q8How can I find a specific topic in Division 30 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.