Step 1 — Select Aircraft
Tap the aircraft icon in the header bar to open the aircraft picker. Select the registration (e.g. VH-VFD). All data throughout the app is filtered by the selected aircraft's FSN and family (CEO/NEO).
Step 2 — Choose a Function
The home screen has two sections:
The primary function of the app. Use this when a fault is reported and you need to determine dispatch conditions.
How to use:
The dispatch screen shows:
The search bar at the top of the home screen searches across all data:
Type any keyword — results are grouped by category. Tap a result to go directly to the relevant screen.
Tap REFERENCE GUIDES on the home screen to access:
| AMM Procedures | Quick-reference summaries of common AMM tasks |
| CB Locator | Search circuit breakers by name or system. Shows grid location (e.g. Y17), panel position, and associated systems. Track open CBs. |
| Alpha Call-ups | Alphabetical index of system call-up codes for ECAM/SD pages |
| Acronyms | Aviation and Airbus-specific acronym dictionary |
Access from Reference Guides. Two key functions:
CB Locator: Search by name, system, or FIN code. Results show the grid location (e.g. Y17) as the primary identifier so you can find it on the panel quickly.
CB Tracker: When a MEL deferral requires opening a CB, the app tracks it. A banner on the home screen shows any open CBs requiring attention. The summary screen lists all currently tracked CBs for the aircraft.
Search reset procedures by ECAM alert name. The app provides:
You are currently in the FMP section. The tabs are organised from general concepts to detailed procedures:
| General | Philosophy & Use — Airbus maintenance concept, TSM entry points, fault types, swapping policy |
| System | CFDS System — CFDIU architecture, system types 1/2/3, correlation logic, reports |
| Identify | Fault ID — How to identify and classify faults |
| Flow | Info Flow — Sensor → LRU → SDAC/FWC/CMC → ECAM/PFR data path |
| Chain | Propagation — Primary vs secondary faults, cascade effects, root cause identification |
| Analyse | PFR Analysis — Reading the PFR, message classes, flight phases, CFDS functions |
| Fix | TSM — Troubleshooting workflow: symptom → confirmation → isolation → correction → verify |
| Reset | Reset Assessment — Computer reset decision logic and restrictions |
| Dispatch | MEL Process — 9-step MEL application from fault notification to dispatch |
| Reference | MEL Structure, Repair Intervals, Symbols, ETOPS — Quick-reference tables |
The dispatch conditions screen has a Print button that generates a clean printout formatted for the technical log. The filename follows the convention:
The printout includes the MEL item, applicable conditions, and operational/maintenance procedures — ready for the flight crew pack.
| NIL | Only one failure mode — proceed directly |
| Actual Alert | Monitored system is inoperative |
| False Alert | Monitoring system is inoperative — actual system is OK |
The Electronic Centralised Aircraft Monitor displays faults in a strict hierarchy:
| Level 3 — WARNING | Red text, continuous repetitive chime, master WARNING light. Immediate crew action required. Examples: engine fire, cabin depressurisation. |
| Level 2 — CAUTION | Amber text, single chime, master CAUTION light. Crew awareness and action required. Examples: system faults, degraded redundancy. |
| Level 1 — ADVISORY | Green or amber memo on SD, no master light. Status information only. Examples: system configuration, maintenance memo. |
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:
| Hard Fault | Fault is present and repeatable. System consistently fails. Confirmed by BITE/test. Clear maintenance action. |
| Intermittent Fault | Fault appears and disappears. May not be reproducible on ground. Requires trend monitoring and correlation with flight conditions. |
| False Alert | ECAM message triggered but no actual system failure exists. The monitoring/detection system itself is faulty. |
| Nuisance Warning | Repeated spurious warnings without genuine system degradation. Often caused by sensor or wiring defects. |
| Latent Fault | Fault exists but has no ECAM indication during normal operation. Discovered during BITE test, scheduled maintenance, or when redundant system is demanded. |
Most A320/A321 LRUs include BITE for self-diagnosis:
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:
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:
A computer reset may be appropriate when:
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:
| CB Reset | Pull and re-engage the circuit breaker for the specific LRU. Removes and restores power. Wait minimum 30 seconds before re-engaging. |
| Full Power Cycle | Remove all aircraft power (batteries OFF, external power disconnected). Wait 2 minutes minimum. Restores all computers to factory-start state. Use when multiple systems affected. |
| Software Reset | Some computers can be reset via MCDU maintenance pages or cockpit pushbutton without power interruption. Faster but less thorough than CB reset. |
| Warm Reset | Computer restarts without full initialization. Some stored fault data is retained. Used when quick recovery is needed. |
| Cold Reset | Complete initialization from power-off state. All volatile memory cleared. Most thorough reset type. |
| FMGC 1+2 | Flight Management & Guidance — navigation, performance. Reset via CB or MCDU. |
| ELAC 1+2 | Elevator Aileron Computer — primary flight controls. CB reset, verify control law after. |
| SEC 1+2+3 | Spoiler Elevator Computer — secondary flight controls. CB reset. |
| FAC 1+2 | Flight Augmentation Computer — yaw damper, rudder trim. CB reset. |
| ADIRU 1+2+3 | Air Data Inertial Reference — attitude, airspeed, altitude. Reset requires full alignment (up to 10 min). |
| FWC 1+2 | Flight Warning Computer — ECAM messages, aural warnings. CB reset. |
| LGCIU 1+2 | Landing Gear Control Interface — gear status, ground/flight logic. CB reset on ground only. |
| DMC 1+2+3 | Display Management Computer — PFD/ND/ECAM display. Switching or CB reset. |
| SDAC 1+2 | System Data Acquisition Concentrator — system parameter data. CB reset. |
| FCDC 1+2 | Flight Control Data Concentrator — flight control position data. CB reset. |
The Troubleshooting Manual (TSM) is an Airbus-issued document that provides systematic fault isolation procedures.
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:
| 1. Fault Symptom | Entry point — the reported ECAM warning, CFDS maintenance message from PFR, or crew observation. Contains: • "Correlated with" = primary faults directly linked • "Possible Warnings/Malfunctions" = associated faults that may appear alongside |
| 2. Fault Confirmation | Run the specified test on ground to confirm the fault exists before starting isolation. • Test result NOT OK → fault is permanent → proceed to Step 3 • Test result OK → fault is intermittent → apply intermittent fault logic (see below) • "Not Applicable" → skip directly to Step 3 (fault cannot be confirmed on ground) |
| 3. Fault Isolation | Step-by-step procedure with YES/NO branching to identify the faulty LRU. TSM may direct you to run specific CFDS/BITE tests via MCDU. Follow the sequence exactly — do not skip steps. |
| 4. Corrective Action | AMM task reference for repair, component replacement, or adjustment. |
| 5. Verification | Re-run the CFDS test after repair. Only TEST OK confirms no remaining faults. In multiple-fault cases, re-test may reveal additional faults hidden behind the first. |
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:
| < 3 occurrences | Dispatch aircraft. Monitor on subsequent flights. Record in TLB. |
| ≥ 3 occurrences | Treat as confirmed — do every step of Fault Isolation. If a step requires fault confirmation, consider it confirmed. Dispatch between isolation steps is acceptable if monitoring is in place. |
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:
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):
The TSM may request Ground Scanning for faults that are difficult to resolve with static tests:
Ground Scanning is particularly valuable for faults that only appear under specific dynamic conditions (vibration, airflow, thermal cycling).
| TSM | Use when you have time to troubleshoot and repair at base or during a scheduled maintenance window. Goal: fix the aircraft. |
| MEL | Use when the aircraft needs to dispatch with a known defect. Goal: determine if safe to fly with the fault deferred. |
In practice, the process is often:
The MEL fault classification connects directly to TSM:
| NO GO | Failure must be fixed before next departure. TSM troubleshooting is mandatory before dispatch. |
| GO IF | Dispatch permitted if MEL conditions are met. TSM should be performed within the repair interval. |
| GO | Dispatch without conditions. TSM at first opportunity. |
TSM isolation procedures use flowchart logic. Key principles:
The starting point for TSM troubleshooting comes from the PFR fault message:
Intermittent faults require a different approach than hard faults:
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.
TEST OK confirms resolution.Fault information flows through a layered architecture:
Physical sensors detect system parameters:
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:
| SDAC 1+2 | System Data Acquisition Concentrator — collects system parameters from multiple LRUs, processes them into display-ready format for the DMC/ECAM system display pages. |
| FWC 1+2 | Flight Warning Computer — monitors all system fault words, applies priority logic, generates ECAM messages on the EWD, triggers aural warnings (chimes, voice). This is the computer that decides which ECAM alert to show. |
| CMC | Centralized Maintenance Computer — records all fault data with timestamps and flight phase. Generates PFR, stores fault history for up to 64 flights. Primary maintenance data source. |
| DMC 1+2+3 | Display Management Computer — renders the PFD, ND, upper ECAM (EWD), and lower ECAM (SD) displays using data from SDAC and FWC. |
| EWD | Engine/Warning Display (upper ECAM) — shows active warnings/cautions and engine parameters. What the crew sees first. |
| SD | System Display (lower ECAM) — shows the affected system page automatically when a fault occurs. |
| MCDU | Multipurpose Control Display Unit — CFDS maintenance pages for BITE access, initiated tests, and system reports. |
| Printer | Cockpit printer — prints PFR automatically after engine shutdown. Hard copy fault record. |
| ACARS | Real-time fault reporting to ground via datalink (if equipped and configured). |
When a component fails, the effect ripples through connected systems:
| Primary Fault | The actual failed component or system. The root cause. This is what needs to be fixed. |
| Secondary Fault | ECAM messages triggered because a downstream system lost its input from the failed component. These clear automatically when the primary fault is resolved. |
| Cascading Effect | A chain reaction where secondary faults trigger further downstream effects, creating a "waterfall" of ECAM messages. |
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:
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.
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:
| GMT | UTC time of fault occurrence |
| PH | Flight phase code (see table below) |
| ATA | ATA chapter of the first suspected component — entry point to technical documentation |
| SOURCE | The system or computer that generated the internal (priority) maintenance message retained by the CFDIU |
| IDENTIFIER(S) | Other computers that also reacted to the fault by generating external messages or cockpit effects (max 6 shown) |
A single fault may disturb several systems, generating multiple maintenance messages. The CFDIU uses a priority system:
| Internal | Generated by the computer that detects itself faulty (self-monitoring) or is the BITE owner of the failed system. Highest accuracy — this message is retained by the CFDIU and shown as SOURCE in the PFR. |
| External | Generated by other systems that detect the loss of input data from the failed component. Lower accuracy — only the system name is retained as an IDENTIFIER in the PFR. |
ADIRU1: NO ADM19 FP1 DATAAll faults detected by the CFDS are classified by cockpit consequence:
| Class 1 | Cockpit Effect — ECAM warning, local warning, flag, invalid function (e.g. amber crosses on SD). Shown on PFR. May be NO GO or GO IF (per MEL). Crew must report in logbook. |
| Class 2 | ECAM Maintenance Status — no effect on system operation. Dispatch permitted without condition (unless specified in MMEL MI-00-08). Shown on PFR. Must be fixed within MMEL repair interval. |
| Class 3 | No Cockpit Effect — crew is NOT aware. NOT shown on PFR. Stored in system BITE Class 3 Report only. Read at intervals per Maintenance Planning Document (MPD). |
| Class S | Engine & SFCC specific. Not shown on PFR. Engine FADEC reports Class S in "Scheduled Maintenance Report". Faults with (*) are unlimited time dispatch; without (*) are time-limited per MPD. |
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.
| 02 | Engine start + 3 min up to takeoff power |
| 03 | Takeoff power up to 80 kts |
| 04 | 80 kts up to lift-off |
| 05 | Climb |
| 06 | Cruise |
| 07 | Descent |
| 08 | Touchdown up to 80 kts |
| 09 | 80 kts up to last engine shutdown |
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:
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:
Conditional maintenance is triggered by crew observations in the logbook. The PFR provides the system view:
| PFR | Computer-generated, objective. Records every Class 1/2 fault with exact time, source, and identifiers. May include faults the crew did not notice (e.g. amber crosses on an unviewed SD page, standby system faults). |
| Crew Report | Human observation, subjective. May describe symptoms differently from ECAM text. Includes observations the computer cannot detect (vibration, smell, noise, handling characteristics). |
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:
| HISTORY DATA | |
| Post Flight Report | CFDIU-driven. Class 1+2 messages from last flight. Primary troubleshooting document. |
| Last Leg Report | System-driven. Backup of PFR data with less complete presentation. |
| Previous Legs Report | System-driven. History of Last Leg data for up to 64 flights. Trend analysis. |
| Ground Report | System-driven. Class 1, 2, 3 internal messages for new faults detected on ground (not in PFR). Must be confirmed by test. |
| Class 3 Report | System-driven. All Class 3 (internal + external) messages for the selected system. |
| Troubleshooting Data | System-driven. Additional coded data on conditions when fault was generated. Used for events not caused by part failure. |
| REAL TIME | |
| Avionics Status | CFDIU-driven. Global overview of all systems with Class 1, 2, or 3 faults at this moment. Quick health check after power-up. |
| System Test | System-driven. Basic and complementary tests. See BITE Testing section below. |
| Ground Scanning | System-driven. Real-time fault monitoring during operator-activated functions (engine run, flight control movement). Shows all classes in real time. |
| LRU Identification | System-driven. Part numbers and serial numbers of system computers. Configuration management aid. |
Aircraft systems interface with the CFDIU in three ways, which affects available maintenance functions:
| Type 1 | ARINC 429 in/out. Most systems. Full bidirectional communication — receives CFDIU flight/ground condition, can transmit fault messages and accept test commands. Full maintenance function coverage. |
| Type 2 | Discrete in / ARINC 429 out. Can transmit fault messages but cannot receive CFDIU commands. Generates own flight/ground condition (takeoff to landing). Minor differences in ground fault reporting — uses combined Last Leg/Ground Report. |
| Type 3 | Discrete in/out. Only transmits OK/not OK status. CFDIU decodes the corresponding maintenance message. Limited test capability (result is OK or not OK only). No Class 3 report available. |
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.
SDAC1: NO DATA FROM BMC1Two types of tests available via MCDU → CFDS → System Menu:
| Basic Test (System Test) | No effect on aircraft. Single operator from cockpit. Can be run at terminal gate during stopovers. Detects all faults present on ground. Must be run first to check BITE computer integrity. |
| Complementary Tests | May affect aircraft (sends stimuli to actuators, valves). CAUTIONS displayed before activation. Normally not performed during short stopovers. Instructions in AMM. May be menu-guided with operator actions. |
Test results:
TEST OK / PASS / NO FAULT — no faults detectedInitial 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):
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:
Displays the identity of all systems with a Class 1, 2, or 3 fault at the time of access:
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:
| Computer replaced, internal failure | Class 3 message should clear after BITE test. Class 3 Report should be empty (shop-reset memory). If no new faults, report empty after next flight. |
| Computer replaced, external failure | Class 3 message should re-trigger after BITE test (root cause is external). Previous faults still in report. If intermittent and self-cleared, report empty after next flight. |
| Other component replaced | Class 3 message should clear after BITE test (root cause removed). Previous faults still in report history. If no new faults, report empty after next flight. |
The ME section is the entry point — indexed by ECAM alert message.
Each ME entry contains:
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:
Sub-items represent different dispatch options. The engineer selects ONE applicable sub-item that matches the aircraft condition.
| ME-24-00007877 | ME entry: ATA 24, unique ID |
| 24-23-01 | MI item: ATA 24, section 23, item 01 |
| 24-23-01A | MI sub-item: letter A under item 24-23-01 |
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:
| Item-level notes | Appear at the top of the MI item, above all lettered sub-items. Apply to ALL dispatch conditions under this item. |
| Condition-level notes | Appear within a specific lettered sub-item (e.g. under 24-23-01A). Apply only to that particular dispatch condition. |
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.
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:
When entering a MEL deferral in the aircraft technical logbook, record:
Under certain circumstances, a repair interval may be extended:
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:
| (o) | Operational Procedure Flight crew must perform an operational procedure before each flight. Found in the MO (MEL Operations) section. Crew must be briefed. |
| (m) | Maintenance Procedure A maintenance action is required before dispatch. Reference the AMM task associated with this MEL item number. |
| (m#) | Operator Maintenance Procedure Operator-specific maintenance procedure located directly below the MI item in the MEL document. Not an AMM task. |
| Placard YES | Placard Required An INOP placard must be affixed adjacent to the inoperative item. Specific wording may be defined in the dispatch condition. |
| Placard NO | No Placard Required No physical placard is necessary, but the defect must still be entered in the logbook. |
| NIL | No specific aircraft status — only one failure mode exists. Proceed directly to the condition of dispatch. |
| Actual Alert | The monitored system is genuinely inoperative. The ECAM alert correctly reflects a real failure. |
| False Alert | The monitoring/detection system is faulty, but the actual system is operative. The ECAM alert is spurious. |
| PRE MOD SB | Dispatch condition applies to aircraft that have NOT been modified by the specified Service Bulletin. |
| POST MOD SB | Dispatch condition applies to aircraft that HAVE been modified by the specified Service Bulletin. |
| NO DISPATCH | Aircraft is grounded. The defect must be rectified before the aircraft can return to service. |
| Not Related to MEL | The ECAM alert does not represent a system failure covered by the MEL. Correct the operational condition (e.g., close a door, insert speeds). No MEL action required. |
| Refer to Item | Proceed to the referenced MI item for dispatch conditions. The format is "Refer to Item XX-XX-XX" where XX-XX-XX is the MI item number. |
These columns indicate the system redundancy:
| 2 / 1 | 2 installed, 1 required → 1 may be inoperative |
| 2 / 0 | 2 installed, 0 required → all may be inoperative (with provisos) |
| 1 / 1 | 1 installed, 1 required → must be operative — NO DISPATCH RELIEF |
| 1 / 0 | 1 installed, 0 required → may be inoperative |
| 3 / 2 | 3 installed, 2 required → 1 may be inoperative |
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:
When an (m) maintenance procedure is required:
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 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:
| ATA 21 | Air Conditioning — pack failures, pressurisation |
| ATA 24 | Electrical Power — generator, APU generator |
| ATA 26 | Fire Protection — engine fire detection loops |
| ATA 28 | Fuel — fuel quantity, crossfeed, transfer |
| ATA 29 | Hydraulic Power — hydraulic systems |
| ATA 30 | Ice & Rain Protection — engine anti-ice, wing anti-ice |
| ATA 34 | Navigation — IRS, GPS, radio navigation |
| ATA 36 | Pneumatic — bleed systems |
| ATA 70-80 | Powerplant — engine systems, oil, ignition |
When multiple MEL items are deferred simultaneously:
MEL provisos may restrict operations beyond ETOPS. Common patterns:
| RVSM | "RVSM is not conducted" — aircraft cannot operate in RVSM airspace (FL290–FL410) |
| CAT II/III | "CAT II/III approach is not conducted" — precision approach capability restricted |
| MNPS/NAT | "MNPS operations are not conducted" — North Atlantic operations restricted |
| Icing | "Known icing conditions are avoided" — routing/altitude restrictions |
| Autoland | "Autoland is not used" — manual landing required |
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:
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.
| Monitored Faults | |
| ECAM | Engine/system warnings & cautions on upper ECAM DU |
| EFIS | Flight instrument flags and advisories |
| CFDS | Maintenance messages identifying faulty LRUs |
| Non-Monitored Faults | |
| Observations | Crew and/or maintenance observations |
| Local effects | Physical symptoms not captured by monitoring systems |
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:
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:
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:
< 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:
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.
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:
| Normal Mode | Permanent and systematic operation in flight and on ground. Real-time memorisation of fault data at two levels: system BITE and CFDIU. |
| Menu Mode | Operator-initiated access via MCDU to view reports, run tests, and retrieve maintenance data. |
At system BITE level:
At CFDIU level:
| Type 1 | Type 2 | Type 3 | |
| In-flight detection | Class 1 & 2 internal → flight memory (zones 1, 2); Class 3 → zone 5 | Class 1, 2, 3 internal & external → flight memory (zone 1) | Class 1, 2, 3 internal & external — no memorisation in BITE |
| Ground detection | Class 1 & 2 internal → ground memory (zone 3); Class 3 → zone 5 | Class 1, 2, 3 internal → ground memory (zone 3) | Permanent detection, no memorisation |
| History depth | Last 64 flights (400 hrs for Class 3) | Current + last flight only | Real-time only |
| Transmission | Label 356 on output bus (50–250 ms rate) | Label 356 on output bus (50–250 ms rate) | Output discrete (correct/faulty) |
| Memory erase | Flight memory to CFDIU erased at ground→flight transition (remains in BITE) | Flight + ground memories erased at ground→flight transition | N/A — no memory |
| Workshop data | Zone 4 — detailed LRU-parts-level data (test bench only) | Zones 2, 4 — complementary data (test bench only) | None |
CFDIU processing depends on the maintenance phase:
| NULL | On ground — system at rest |
| DC2 | In-flight phase (early): NULL confirmed >120s + engine running >180s + flight phase 4–9 |
| DC1 | In-flight phase (stable): DC2 confirmed >30s |
Key transitions:
CFDIU scan activation:
| "At the soonest" | Type 1 & 3 systems — phases 2b through 9a |
| "At the latest" | Type 1 & 3 systems — phases 4 through 9a |
| Type 2 systems | Phases 5a through 7a only |
| Current/Last Leg Report (LLR) | All fault messages from the current or last flight — internal faults with correlated identifiers, GMT timestamps, flight phases |
| Last Leg ECAM Report (LLER) | All ECAM warnings from FWC (label 357) — warning text (max 24 chars), ATA reference, GMT, flight phase. Sent once per FWC computation regardless of display inhibition. |
| Avionics Status | Real-time status of all connected systems. Non-refreshment detected in 4 seconds → "NO X DATA". Status restored when system resumes normal transmission. |
| Previous Legs Report | Up to 200 fault data across 64 flights. Transferred from LLR at DC1/NULL transition. Includes flight count, date, aircraft ID, city pair. |
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.
Correlation window:
Correlation rules:
| Rule 1 | Any fault occurring outside an active correlation window → new fault, new correlation processing |
| Rule 2 | Any fault occurring during an active correlation: same ATA → correlated (grouped); different ATA → new fault, new processing |
Identifiers:
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:
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:
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:
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:
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:
| Type 1 & 2 | Bits 20 and 21 of the initial STX word of label 356: Bit 21 = 1 → system has Class 1 or 2 fault Bit 20 = 1 → system has Class 3 fault Bit 21 returns to 0 → system name display erased |
| Type 3 | Discrete status monitored regularly — incorrect status → system identity displayed |
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.
Flight identification data:
If ACARS is installed, fault messages and their identifiers are transmitted:
This enables ground-based maintenance planning before the aircraft arrives.
On ground, the CFDIU:
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.