The Electronic Centralised Aircraft Monitor displays faults in a strict hierarchy:

The EWD (Engine Warning Display) shows active warnings and cautions. The SD (System Display) shows the affected system page automatically.

Faults fall into distinct categories that determine the maintenance response:

Most A320/A321 LRUs include BITE for self-diagnosis:

• Power-Up Test (POST) — automatic self-test when power is applied. Runs every time the system starts.
• Continuous Monitoring — real-time monitoring during operation. Detects faults as they occur.
• Initiated Test — manually triggered by maintenance via CFDS. More detailed than continuous monitoring.
• Ground Test — comprehensive test available only on ground with specific conditions (e.g., weight on wheels, engines off).

BITE results are stored in the CMC (Centralized Maintenance Computer) and reported via the MCDU maintenance pages or the printer PFR.

The Centralized Fault Display System provides ground maintenance access:

• MCDU Menu → CFDS — access fault reports, initiated tests, system reports
• Post Flight Report (PFR) — automatic printout of faults recorded during last flight
• Current Flight Report (CFR) — faults recorded during current/ongoing flight
• Previous Legs — historical fault data from up to 64 previous flights
• Avionics Status — real-time LRU health and communication status

Always review the PFR before troubleshooting — it provides the chronological fault history that reveals cause-and-effect relationships.

When a pilot reports a fault, cross-reference with:

• ECAM message text — the exact alert the crew saw (from tech log or PFR)
• Flight phase — when did it occur (ground, takeoff, cruise, approach)?
• Environmental conditions — temperature, altitude, weather (relevant for intermittent faults)
• System status at time of fault — which systems were active, any previous deferrals?
• Crew actions taken — did they follow ECAM procedure? Any resets performed in flight?

A computer reset may be appropriate when:

• ECAM message appeared with no obvious physical cause
• Fault is suspected to be a software lock-up or transient condition
• The TSM procedure specifically directs a reset as a troubleshooting step
• Fault appeared after a power interruption or abnormal power sequence
• A reset has been successful for this fault type in previous occurrences

A reset is NOT a repair. It is a troubleshooting step. If the fault returns after reset, the LRU or wiring requires further investigation.

Do NOT perform a reset when:

• The fault has a clear physical cause (e.g., fluid leak, visible damage, known defect)
• The fault involves structural or flight control indications that must be physically verified
• The same fault has been reset multiple times without resolution — further resets mask the problem
• Multiple unrelated systems are faulting simultaneously — investigate common cause (power, wiring, bus)
• The TSM or AMM specifically prohibits reset for this fault condition

The Troubleshooting Manual (TSM) is an Airbus-issued document that provides systematic fault isolation procedures.

• Organised by ATA chapter — same structure as the AMM and MEL
• Indexed by ECAM message, CMS fault code, or symptom description
• Contains step-by-step procedures to isolate the root cause from symptoms
• References specific AMM tasks for corrective actions
• Includes reset procedures where applicable
• With each maintenance message, the TSM indicates the test or procedure to recheck the component on ground

The TSM bridges the gap between fault identification (what the PFR/ECAM says) and corrective action (what to fix).

Each TSM procedure follows this mandatory sequence:

Fault Confirmation is the critical decision point that determines the entire troubleshooting path:

IF PERMANENT (test confirms fault)

Proceed directly to Fault Isolation (Step 3). The procedure must be applied to troubleshoot the aircraft.

IF INTERMITTENT (test does NOT confirm fault)

Check history — Previous Leg Reports, PFR/Previous PFRs, logbook:

ELECTRICAL TRANSIENT (power-up/start/transfer only)

If the fault appeared during power-up, engine/APU start, or electrical transfer, and after reset the fault disappears → aircraft can be dispatched. If fault persists after reset → apply TSM or MEL.

The TSM and CFDS work together in a structured troubleshooting cycle:

As a general rule, the TSM will request the test of the system including the LRU incriminated by the maintenance message (message ATA). By default, the test of the system which generated the message (SOURCE) may be activated.

The TSM relies heavily on CFDS tests. Key principles from the Airbus TSM Introduction:

• Maintenance messages stored in the PFR or Ground Report are not erased until the next flight begins — a CFDS test confirms whether the fault is still present
• The TSM fault isolation procedure will specify which test to activate — it confirms the fault or eliminates ambiguity
• As a general rule, activate the test of the system containing the LRU incriminated by the PFR message (use the message ATA chapter)
• By default, the test of the system identified by the SOURCE field may be activated
• Test activation may also be part of the removal/installation procedure of an LRU in the AMM

In multiple fault cases, a CFDS test may only show the first fault encountered. After repair, always re-run the test — only "TEST OK" proves no remaining faults.

The TSM may request you to read Troubleshooting Data from the CFDS (MCDU → CFDS → System Menu → Troubleshooting Data):

• Contains primary and coded data about conditions when the maintenance message was generated
• Used for events that do not result from a clear part failure — the kind already resolved by component replacement
• Useful for identifying the cause of intermittent or environmental events
• If the TSM procedure requests specific data, it will indicate exactly which parameters to read
• Data is displayed decoded on the MCDU wherever possible

The TSM may request Ground Scanning for faults that are difficult to resolve with static tests:

• Allows the operator to activate functions normally performed during flight while on the ground (engine start, flight control movement, etc.)
• Displays all maintenance messages in real time (Class 1, 2, and 3, internal and external) — more comprehensive than a standard test
• Transient fault messages remain displayed until you exit the function — helps catch intermittent sources
• Always run a System Test first before Ground Scanning — this identifies static faults so you can distinguish them from dynamic faults during scanning
• The operator decides which actions to perform — not restricted to a predefined sequence

Ground Scanning is particularly valuable for faults that only appear under specific dynamic conditions (vibration, airflow, thermal cycling).

In practice, the process is often:

The MEL fault classification connects directly to TSM:

TSM isolation procedures use flowchart logic. Key principles:

• Follow the sequence exactly — do not skip steps even if you think you know the answer
• YES/NO only — each decision point has exactly two outcomes. If unsure, re-test.
• Record each step — if the procedure is interrupted, you can resume from the last completed step
• Note references — the TSM will reference AMM tasks for measurements, pin checks, or component removal. Have the AMM available.
• Multiple entry points — some TSM tasks can be entered from different symptoms. Ensure you start at the correct entry point for your specific fault.
• CFDS test at decision points — when the TSM says "run system test", go to MCDU → CFDS → select the system and run the test. Return to the TSM flowchart with the result.

The starting point for TSM troubleshooting comes from the PFR fault message:

• Use the ATA chapter from the PFR FAILURE MESSAGES — this is the entry point to the TSM
• The ATA is the chapter of the first suspected component, not necessarily the system that reported it
• For correlated faults (same GMT), focus on the SOURCE field — the internal message is most accurate
• Do NOT use IDENTIFIER systems as the entry point — their messages are external (lower accuracy)
• If the PFR shows a fault only in the ECAM WARNING section with no corresponding FAILURE MESSAGE, the SOURCE system may be unpowered or its BITE is inoperative

Intermittent faults require a different approach than hard faults:

• Check Previous Legs Report (CFDS, up to 64 flights) — establish if the fault recurs and in which flight phases
• Check Troubleshooting Data — environmental conditions (altitude, temperature, vibration) at the time of the fault
• Use Ground Scanning — try to reproduce the fault by activating the relevant function dynamically
• Flight phase correlation — faults in phases 05-06 (climb/cruise) suggest altitude/temperature sensitivity. Phase 02-03 (engine start/taxi) suggest vibration or power transients.
• Occurrence counter in PFR — a number like DAR(3) means the fault occurred 3 times in one flight. More occurrences = higher confidence it is a real defect.

Maintenance messages are stored only once per cycle at first detection. An intermittent fault that appears and disappears will show one fault message but may show multiple ECAM warnings in the PFR.

• Jumping to conclusions — replacing an LRU without following the full isolation procedure. The fault may be wiring, a connector, or an external cause.
• Ignoring secondary faults — the TSM addresses the primary fault, but secondary messages (identifiers in PFR) may indicate a different root cause.
• Incomplete verification — clearing the fault without running the post-action CFDS test. The fault may return on the next flight. Only TEST OK confirms resolution.
• Wrong TSM entry — entering the procedure from an identifier's ATA instead of the source's ATA. Always use the PFR FAILURE MESSAGE ATA, not the ECAM WARNING ATA.
• Skipping re-test after repair — in multiple fault cases the CFDS test may only show the first fault. After repair, re-run to check for additional faults hidden behind the first one.
• Not reading Ground Report — faults detected on ground after flight are NOT in the PFR. Check the Ground Report for faults that may have appeared during post-flight checks.
• Class 3 faults ignored — Class 3 messages are not on the PFR and crew is not aware. Check the Class 3 Report at MPD intervals — these faults may explain unexplained system behaviour.

Fault information flows through a layered architecture:

Physical sensors detect system parameters:

• Pressure transducers — hydraulic pressure, cabin pressure, bleed pressure
• Temperature probes — EGT, TAT, SAT, bleed air temperature
• Proximity sensors — door position, gear position, control surface position
• Current/voltage sensors — electrical bus monitoring
• Flow meters — fuel flow, bleed air flow
• Accelerometers / Gyros — ADIRU data (attitude, rates, acceleration)

Sensor signals are analog or discrete — they become digital when the receiving LRU processes them.

Each LRU processes its sensor inputs, runs its control logic, and monitors for faults:

• Compares sensor values against normal operating ranges
• Runs BITE algorithms to detect internal hardware/software faults
• Generates fault words (ARINC 429 labels with failure status bits)
• Transmits system data and fault status on its output data buses
• Cross-checks with redundant LRUs where applicable (e.g., ELAC 1 vs ELAC 2)

When a component fails, the effect ripples through connected systems:

The first fault in time (from PFR) is usually the root cause. Later faults are often consequences.

To find the primary fault in a chain of multiple messages:

• Check the PFR timestamp — the earliest fault entry is usually the root cause
• Look for the common source — which single component, if failed, would explain ALL the messages?
• Follow the data flow — trace backwards from the secondary messages to find what they all depend on
• Check system interconnections — use the schematic diagrams in the AMM/TSM to understand dependencies
• Consider power & bus architecture — a power bus failure affects all LRUs on that bus

An ADIRU (Air Data Inertial Reference Unit) failure demonstrates propagation clearly:

All 5 secondary messages are consequences of the single ADIRU failure. Replacing ADIRU 1 resolves all messages. Attempting to troubleshoot each secondary message independently would waste time.

When multiple unrelated systems fault at the same moment, always suspect a common power source rather than individual LRU failures.

The Post Flight Report (PFR) is automatically printed by the CFDIU 2 minutes 30 seconds after aircraft speed decreases below 80 kts after touchdown. It is the main source of information for troubleshooting.

• Generated by the CFDIU (Centralized Fault Display Interface Unit) — the automatic operating mode of the CFDS
• A backup is accessible via MCDU → CFDS → Last Leg Report — but the printed PFR contains more complete information
• Contains Class 1 and Class 2 maintenance messages detected during flight (Class 3 is NOT shown on PFR)
• The flight condition used by the CFDS runs from first engine start + 3 minutes to 80 kts + 30 seconds after touchdown
• Maintenance messages are stored only once per cycle at first detection after the beginning of the cycle

For engine run-ups (maintenance), a flight number must be entered in the MCDU to generate a PFR, since 80 kts is never reached.

The PFR has two main sections:

A single fault may disturb several systems, generating multiple maintenance messages. The CFDIU uses a priority system:

All faults detected by the CFDS are classified by cockpit consequence:

Some Class 1 faults have no automatic cockpit indication (e.g. flag on PFD only appears when that page is viewed, or standby system fault only appears when manually selected — e.g. ADIRU 3). The fault message is immediately in the PFR but the cockpit effect requires manual action to see.

Flight phase is critical for intermittent faults — a fault in phase 05-06 (altitude/temperature) suggests thermal or pressure-related issues. Phase 04 (takeoff roll) faults are safety-critical.

Type 2 systems use takeoff-to-landing as their flight condition. Faults detected between engine start +3 min and takeoff, if still present, may appear as phase 05 (Climb).

The CFDIU correlates fault messages to limit PFR length and highlight root causes:

• Fault-to-fault correlation: Based on GMT + ATA chapter. Messages at the same time with the same ATA are grouped — the internal (priority) message is retained, others become identifiers.
• Fault-to-ECAM correlation: Performed manually by the engineer using ATA chapter and GMT to link ECAM WARNING MESSAGES to FAILURE MESSAGES.
• Occurrence counter: If the same fault appears/disappears multiple times during one flight, the message is recorded only at first detection. A number in parentheses shows repeat count, e.g. DAR(3) = triggered 3 times.

DAR failed 3 times (counter = 3). Only the first occurrence at GMT 1000 generates a fault message. A different warning (CAB PR) at 1030 resets the counter, so the DAR at 1045 is recorded as a new event.

Systematic approach to reading the PFR:

• Step 1 — Read chronologically. The first fault entry is usually the root cause. Later entries are often secondary effects.
• Step 2 — Group by GMT. Faults at the same time are likely from the same event. Use ATA chapter to correlate ECAM warnings with failure messages.
• Step 3 — Check SOURCE. The SOURCE field identifies the system that generated the internal (priority) message — the LRU incriminated by the SOURCE is the prime suspect.
• Step 4 — Read IDENTIFIERS. These show which other systems were affected. They help confirm the propagation path and rule out independent faults.
• Step 5 — Check flight phase. Phase narrows the environmental cause (thermal, pressure, vibration, power transient during engine start).
• Step 6 — Correlate with crew report. An ECAM warning or Maintenance Status can be associated with a system shown only as an IDENTIFIER — because it is not the root cause.
• Step 7 — Check occurrence counter. A number in parentheses means the fault recurred during the flight — intermittent or recurring fault.
• Step 8 — Check previous legs. Use PREVIOUS LEGS REPORT (up to 64 flights) to confirm trend. A fault on multiple legs confirms a hard defect.

Conditional maintenance is triggered by crew observations in the logbook. The PFR provides the system view:

Use both together — the PFR tells you what the computer saw, the crew report tells you what the human experienced. The gap between them reveals the real story.

All functions accessible via MCDU → CFDS. Divided into CFDIU-driven (automatic) and system-driven (manual) functions:

Aircraft systems interface with the CFDIU in three ways, which affects available maintenance functions:

System type is transparent for normal PFR reading. The distinction matters when using Ground Reports (Type 2 format differs) or when understanding why some systems show simplified test results (Type 3).

When a system has multiple computers, one computer collects all maintenance information and provides the link to the CFDIU. This computer performs the BITE function and reports on behalf of all system computers.

• Provides better diagnosis by correlating data between system computers
• Reduces the number of bus links with the CFDIU
• The maintenance message itself identifies the source within the system

Two types of tests available via MCDU → CFDS → System Menu:

Test results:

• TEST OK / PASS / NO FAULT — no faults detected
• Maintenance messages displayed — at least one fault detected. In multiple fault cases, may only show the first fault. Re-run after repair — only "TEST OK" confirms no remaining faults.
• No response / no results — test not completed. Return to CFDS menu and reselect. If repeated, suspect BITE computer or wiring.

Initial aircraft configuration for tests: aircraft on ground, engines stopped, all systems powered (ADIRS/FADEC may be off), pushbuttons in normal configuration. Different configuration = described in AMM.

The CFDS separates faults detected on ground from faults detected in flight, because ground faults may be caused by maintenance actions (e.g. open circuit breaker):

• Flight faults → recorded in the PFR (Class 1 and 2)
• Ground faults → recorded in the Ground Report (not in PFR)
• If a ground fault is not corrected, it will still be present at the next flight start and will appear in the next PFR

Ground Report faults must always be confirmed by a test or TSM procedure — they may be caused by maintenance configuration, not actual failures.

Ground Scanning enables fault troubleshooting by allowing the operator to activate functions normally performed during flight:

• Operator decides which actions to perform (engine start, flight control movement, etc.)
• All maintenance messages (Class 1, 2, and 3, internal and external) are displayed in real time
• Transient fault messages remain displayed until exiting the function — helps identify intermittent sources
• Always precede with a System Test to identify static faults first
• May be requested by TSM procedures for difficult-to-resolve faults

Displays the identity of all systems with a Class 1, 2, or 3 fault at the time of access:

• Provides a global overview of all system health — quick check after aircraft power-up
• Gives direct access to the system menu of any faulting system for further investigation
• After power-up, verifies all computers have passed power-up tests
• To find the reason a system appears: access the system menu and activate the system test

Important: Supply all systems before checking Avionics Status. Unpowered computers don't report themselves — but systems using their data will appear as faulting.

Class 3 faults have no cockpit effect and are not shown on the PFR. After component replacement:

The ME section is the entry point — indexed by ECAM alert message.

Each ME entry contains:

• ECAM Alert — the exact message text shown on the EWD
• Aircraft Status — the failure mode (NIL, Actual alert, False alert)
• Condition of Dispatch — one of three outcomes:
  • NO DISPATCH — aircraft is grounded
  • Not Related to MEL — no system failure, correct the condition
  • Refer to Item XX-XX-XX — continue to MI section
• Applicable to — which aircraft registrations this entry covers

One ECAM alert may have multiple ME entries for different aircraft variants (CEO/NEO).

The MI section contains the dispatch conditions — the actual rules for dispatch.

Each MI item contains lettered sub-items (A, B, C...) with:

• Repair Interval — Category A, B, C, D, or dash
• Number Installed / Number Required — determines how many may be inoperative
• Placard — YES or NO
• (o) Operational Procedure — flight crew procedure required
• (m) Maintenance Procedure — AMM task required
• Provisos — numbered conditions that ALL must be met
• Applicable to — aircraft-specific applicability

Sub-items represent different dispatch options. The engineer selects ONE applicable sub-item that matches the aircraft condition.

When a dispatch condition says "Refer to Item 24-23-01", go to the MI section and find item 24-23-01.

A dispatch condition in the MI section may itself reference another MI item. This creates a cascade chain:

ME entry → MI item A → MI item B → MI item C

Every item in the chain must be entered in the logbook with its own dispatch condition, repair interval, and procedures applied.

Two distinct types of notes appear in MI items:

Always read item-level notes first — they may contain restrictions that override or supplement individual dispatch conditions.

The MO section contains operational procedures for flight crew, referenced by the (o) symbol.

• Procedures are split by flight phase (Before Start, During Taxi, In Flight, etc.)
• Crew must read and apply the applicable phase at the relevant time
• (o) procedures must be re-applied before every flight until the MEL is cleared
• The engineer must brief the crew and ensure they have the procedure

Repair interval is defined within the dispatch condition itself.

May be a number of flights, calendar days, or flight hours as stated in the proviso.

Read the dispatch condition carefully — the time limit is embedded in the text.

Must be rectified within 3 consecutive calendar days excluding the day of discovery.

Day of discovery does not count. The interval begins at 0001 UTC the day after discovery and expires at 2359 UTC on the third day.

Must be rectified within 10 consecutive calendar days excluding the day of discovery.

Same counting method as Category B.

Must be rectified within 120 consecutive calendar days excluding the day of discovery.

Typically for items with significant redundancy where safety is not compromised for an extended period.

The dash means this sub-item does not have its own repair interval.

The repair interval is determined by:

• The referenced MEL item's category (if "Refer to Item"), OR
• The condition results in NO DISPATCH

When entering a MEL deferral in the aircraft technical logbook, record:

• Use the MI sub-item number (e.g. 36-22-01E) as the MEL reference
• Record the discovery date — this is when the repair interval starts counting
• Calculate and record the expiry date based on the category

Under certain circumstances, a repair interval may be extended:

• Extension must be approved by the CAM (Continuing Airworthiness Manager) before the original interval expires
• Extension requests must include justification and risk assessment
• Category B items may be extended once to a maximum of Cat C equivalent (10 days)
• Category C items may be extended once to a maximum of Cat D equivalent (120 days)
• Category D extensions require authority approval and are assessed case-by-case

An expired MEL item without an approved extension is a regulatory non-compliance. The aircraft must not dispatch.

When multiple MEL items are active simultaneously:

• Each deferral has its own independent repair interval
• Check for interrelated systems — one deferral may affect the dispatch conditions of another
• Combined effect of multiple deferrals may require additional operational restrictions
• Some dispatch conditions explicitly state "provided no other system in ATA XX is deferred"

These columns indicate the system redundancy:

When Num Required = Num Installed and Category is dash (—), the sub-item provides NO DISPATCH RELIEF — the system cannot be dispatched inoperative.

Numbered conditions within a dispatch condition that ALL must be satisfied:

• Provisos are mandatory — if any proviso cannot be met, this dispatch condition cannot be used
• Some provisos restrict operations (e.g. ETOPS, RVSM, CAT II/III approaches)
• Some provisos require maintenance actions or configuration changes
• If no applicable dispatch condition has all provisos satisfied, the aircraft is NO DISPATCH

When an (m) maintenance procedure is required:

• Use the MEL item number to locate the corresponding task in the AMM
• If the dispatch condition says "Refer to AMM task" without a specific reference, consult the AMM to find the applicable task
• Multiple AMM tasks may be associated with a single MEL item — review all applicable tasks
• The (m) task must be completed and signed off before dispatch

For (m#) operator procedures, the task is located directly below the MI item in the MEL document — it is not an AMM reference.

Many MEL dispatch conditions contain provisos restricting ETOPS operations. Common patterns:

• "ETOPS is not conducted" — the flight must NOT be an ETOPS flight
• "ETOPS beyond 120 min is not conducted" — ETOPS limited to 120 minutes diversion time
• "ETOPS beyond 180 min is not conducted" — ETOPS limited to 180 minutes diversion time

ETOPS restrictions in MEL provisos are mandatory. If any active MEL deferral restricts ETOPS, the flight must not be conducted as ETOPS or must respect the reduced diversion time.

The following ATA chapters commonly contain ETOPS-significant items:

When multiple MEL items are deferred simultaneously:

• Check each active deferral for ETOPS restrictions
• The most restrictive ETOPS limitation applies
• If any deferral prohibits ETOPS entirely, the flight cannot be conducted as ETOPS regardless of other deferrals
• Combined effect of multiple deferrals may reduce redundancy below ETOPS minimum — assess each case

MEL provisos may restrict operations beyond ETOPS. Common patterns:

These restrictions must be communicated to flight crew and ATC/dispatch planning as applicable.

The Airbus maintenance concept is based on the use of CFDS and TSM together.

CFDS directly monitors and identifies faulty LRUs by analysing all cockpit events triggered by aircraft system monitoring. It contributes to avoiding unjustified removals by performing detailed analysis to confirm that an event was actually due to a hardware failure and not an intermittent fault.

CFDS provides three major capabilities:

• Post Flight Report (PFR) — printed at end of each flight, associates ECAM warnings with CFDS maintenance messages
• Directly usable maintenance messages — identify faulty LRUs
• System test access — test aircraft systems from the CFDS interface

TSM is a troubleshooting guide covering all probable aircraft faults — both monitored (displayed by aircraft systems) and non-monitored.

Based on TSM guidance, it is the operator's responsibility to establish specific fault management procedures in accordance with local regulations.

All these fault types serve as entry points into the TSM.

Troubleshooting is initiated by a logbook entry from flight crew or maintenance crew. The entry serves as the TSM entry point using:

• Fault Symptoms — descriptive text of the observed fault
• Warnings/Malfunctions — ECAM/EFIS messages reported by crew
• CFDS Fault Messages — maintenance messages from CFDS

Monitored faults (ECAM, EFIS) reported by flight crew are usually associated with CFDS fault messages. The association principle is described in the PFR correlation section.

CFDS messages can appear alone without an associated warning — in that case they are the direct entry point for maintenance troubleshooting.

Crew/maintenance observations are usually a single fault without an associated CFDS message — TSM entry is via fault text, keywords, and ATA chapters.

Step 1: Compare the ECAM warning or ECAM STS message with the CFDS fault message (if applicable) on the PFR to obtain the fault symptom and ATA chapter reference.

A time difference of 1–3 minutes between the fault message and the warning message may occur due to CFDIU internal behaviour.

Step 2: Use the Troubleshooting function to retrieve the fault symptom using Warnings/Malfunctions or the correlated CFDS messages, then retrieve the associated fault isolation procedure.

Step 1: Use the Troubleshooting function to retrieve the fault symptom and correlate the CFDS message (if any).

Step 2: The fault isolation procedure is displayed after identification of the relevant fault symptom.

Step 1: Note the CFDS fault message ATA chapter reference.

Step 2: Use the Troubleshooting function to retrieve the CFDS message. The fault isolation procedure is displayed when the CFDS message is identified.

Fault symptoms in TSM contain:

• "Correlated with" — primary faults directly linked to the symptom
• "Possible Warnings/Malfunctions" — associated faults that may appear alongside

APU Fault Symptom Peculiarities

When APU operation may result in damage, the ECB shuts it down automatically. The shutdown cause and associated LRUs are stored in ECB memory, available on the APU SHUTDOWNS menu page of CFDS.

The ECB also generates a PFR maintenance message:

Most operators prefer to enter TSM via the APU SHUTDOWNS menu (shows shutdown reason + faulty LRU). Airbus combines both into one fault symptom:

The fault confirmation task provides the information to confirm the fault before starting fault isolation actions. If it is not possible to confirm on ground due to specific aircraft/system configuration, this is specified and fault isolation is performed directly.

When the Fault Confirmation paragraph contains "Not Applicable" (or equivalent), you must proceed directly to Fault Isolation.

Permanent Fault

Fault is confirmed on ground by the test in the fault confirmation paragraph. The troubleshooting procedure must be applied.

Intermittent Fault

Fault is not confirmed on ground. CFDS may display (INTM) for intermittent operation:

When a fault is not confirmed on ground, Airbus recommends using Ground Scanning of the related system in addition to the fault confirmation test — Ground Scanning is an additional means to track intermittent faults.

If the fault confirmation test does not confirm the fault, check:

• Previous Leg Reports
• PFR / Previous PFRs (if available)
• Logbook of previous flights

< 3 Occurrences

Dispatch the aircraft. Monitor the reported symptom on subsequent flights. Record this occurrence in the Technical Log Book (TLB).

≥ 3 Occurrences

Although the fault is still not confirmed by fault confirmation, you must do each step of the fault isolation paragraph until subsequent monitoring confirms the root cause is found and the fault is fixed.

If a fault isolation step contains a confirmation test or requires confirming the symptom is still present — consider the fault as confirmed and do the related corrective actions.

Once fault isolation starts, it is acceptable to dispatch the aircraft between different fault isolation actions if fault monitoring is in place.

If Fault IS Confirmed (test result NOT OK)

Do the fault isolation paragraph immediately.

If an LRU is removed, provide the shop/supplier with: PFR, test result, troubleshooting data (if available), and rationale of removal (especially for intermittent faults).

On ground — especially during power-up, engine/APU start, electrical transfer — warnings may be generated by electrical transients without the related system being actually faulty.

Only in this situation: if after a reset the fault indication disappears, the aircraft can be dispatched.

If after a reset the fault is confirmed, apply the troubleshooting procedure or MEL if applicable for aircraft dispatch.

Swapping for Troubleshooting

When a fault is not confirmed on ground (all tests OK), it is possible to swap identical LRUs installed on the same aircraft for subsequent flights for data analysis and to decrease the NFF rate.

When a fault is confirmed on ground, it is not allowed to swap LRUs as a troubleshooting step unless the TSM tells you to do so.

Swapping for Dispatch

When a suspected faulty LRU is NO GO per MEL in its original position but less penalising in another position, swapping is permitted only if ALL conditions are met:

• LRU is confirmed faulty by applicable TSM fault isolation
• The TSM procedure does not forbid swapping
• No spare is available
• Both LRUs installed on the same aircraft
• Swapping is NOT used to extend a dispatch under MEL condition
• Both LRUs have dedicated C/Bs
• The faulty LRU (in new position) is de-energised

After swapping, perform a BITE test of the replacement LRU per AMM removal/installation procedures.

Apply MEL procedures and limitations for the faulty LRU in its new position. Corrective maintenance must be applied as soon as possible and before the MEL time limit.

• After a fault isolation action is completed — always verify the reported fault has been corrected
• AMM LRU replacement tests confirm correct installation — they do not always confirm correction of the fault symptom. The TSM refers to the appropriate operational or system test
• Continuity and isolation checks on ARINC 600 connectors should only be done with a breakout box and test cables
• On ground, a tripped C/B must not be engaged without troubleshooting the associated system
• Observe warnings about static sensitive devices
• If a suspect LRU removed during troubleshooting is found serviceable — apply airline internal replacement policy (reinstall or send to workshop)

A computer reset may clear an intermittent fault without correcting the cause.

In some cases, a reset may hide failure conditions (e.g. in-flight condition no longer present on ground) that may lead to unsafe conditions on the next flight.

The TSM system reset guidelines provide a reset table and system reset restrictions to confirm intermittent faults or faults generated by electrical transients.

Refer to the Reset Assessment tab for the computer reset flowchart.

The CFDS (BITE + CFDIU) has two operating modes:

At system BITE level:

• Permanent monitoring, detection and isolation of faults
• Storage of maintenance data in non-volatile memory
• Permanent transmission to CFDIU of last-flight fault messages

At CFDIU level:

• Reading by scanning all buses from connected systems
• Selection and memorisation of corresponding messages
• Correlation of faults to identify the primary cause
• Association of GMT timestamp with each event

CFDIU processing depends on the maintenance phase:

Key transitions:

• NULL → DC2 — ground to flight transition; CFDIU starts in-flight processing
• DC1 → NULL — flight to ground; CFDIU transfers Last Leg Report to Previous Legs

CFDIU scan activation:

The CFDIU monitors label 356 on all ARINC 429 input ports (except those excluded by pin-programming). Non-refreshment is confirmed after 4 seconds.

When detected, the CFDIU generates an internal fault message:

If the system operates intermittently, (INTM) is appended:

The CFDIU does NOT monitor ECB bus non-refreshment when the ECB is not supplied in flight.

Purpose: Memorise only one fault message per aircraft fault event — the one closest to the primary fault that generated the event.

Correlation criterion: Based on the ATA reference of the incriminated LRU.

• Messages are associated if first 3 ATA digits are identical (most cases)
• Some specific ATA codes require 4 digits identical or belong to a defined group

Correlation window:

• Minimum 1 minute open
• Minimum 2 scanning cycles from opening (DC1) or from DC2/DC1 transition (DC2)
• Window closes when both conditions are met
• Max 8 simultaneous correlation windows (16 on later FSN); 9th force-closes the oldest

Correlation rules:

Identifiers:

• Internal fault = SOURCE (the system that detected it)
• External faults within ±1 minute = IDENTIFIERS (systems that reacted)
• Max 6 identifiers per fault (1 page), max 200 identifiers per flight
• A given system appears as identifier only once per correlation

Purpose: Correlate ECAM warnings (LLER) with CFDS failure messages (LLR) from the same flight.

Each warning correlates to max 1 failure. Each failure correlates to max 1 warning.

When it runs:

• At DC1/NULL maintenance-phase transition
• After filter data loading (if active)
• After healthy discrete computation (if phase = NULL)

Stopped after: all warnings processed, 2 minutes of processing, or NULL/DC2 transition.

Correlation rules:

Rule 1 (strict): GMT within ±2 minutes AND first 4 ATA digits match (message, source, or identifier vs warning)

Rule 2 (relaxed — remaining warnings): GMT within ±2 minutes AND first 2 ATA digits match (excluding specific ATA codes in the exclusion list)

Viewing results on MCDU:

• From LLR: correlated faults show ">" prompt on right side → press LSK to see the correlated warning
• From LLER: correlated warnings show ">" prompt → press LSK to see the correlated fault

Warning/Failure correlation results are only available on MCDU — they cannot be printed, sent to ground, or memorised.

For Type 1 and Type 2 systems, the CFDIU validates received frames before memorisation:

• Delta Block Word Count (BWC) > 0 on first STX → indicates first or new fault detected
• Word count between first STX and EOT must equal the BWC
• Subsequent STX BWC must be zero; each preceded by ETX
• ETX always followed by STX
• Delta BWC ≤ 0 → frame immediately rejected, next system polled
• All message characters must be valid MCDU ASCII

The most recent fault message (which caused the BWC increase) is transmitted first in the frame.

CFDIU detects: fault type (internal/external), fault class (1&2 or 3), and whether it is "FAULT DATA".

Flight Warning Computers transmit on label 357 in real time:

• Warning message title (max 24 characters) displayed on upper/lower ECAM DU
• ATA reference (4 digits) — always the first 5 characters of the warning

Sent once at the moment of FWC warning computation — flight-phase display inhibition has no effect on this transmission.

CFDIU selects the valid FWC bus, reads/filters label 357, and associates GMT + flight phase with each ECAM warning.

The CFDIU monitors system health in real time by scanning:

Capacity: 40 lines of 24 characters. Operates in real time to the nearest system scan period.

At each DC1/NULL transition (end of flight), the complete Last Leg Report is transferred to the Previous Legs Report.

• Capacity: up to 200 fault data across 64 flights
• Faults older than 64 flights are automatically deleted
• Only flights with at least one fault appear in the report

Flight identification data:

• Flight count — LEG -00 = last flight, LEG -13 = 13 flights ago
• Flight date — from CLOCK or CFDIU (label 260)
• Aircraft ID — from FDIU (labels 301–304)
• City pair — FROM/TO from FMS via FAC (labels 040–042, printer only)

If ACARS is installed, fault messages and their identifiers are transmitted:

• In real time — as faults are detected and correlated
• Complete PFR — transmitted as a batch report

This enables ground-based maintenance planning before the aircraft arrives.

On ground, the CFDIU:

• Monitors refreshment of fault information on all buses (same as in-flight)
• Does NOT memorise fault messages on ground — monitoring is for Avionics Status only
• Determines real-time status of all aircraft systems

Ground faults are recorded in system BITE memory (zones 3/5), but the CFDIU only uses ground scanning for status display — not for report building.