OBJECTIVE

To refresh the Engineer with the necessary knowledge to perform

maintenance procedure during inspections in safely accordance with
the requirements to ensure continued airworthiness for further flights.
BATIK AIR 1
 System Focus Manufacture Lesson
TRAINING
AGENDA
Architecture study Information learn

BATIK AIR 2
 ELECTRONIC INSTRUMENT SYSTEM (EIS)
EIS Architecture (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

INDICATING Engine/Warning Display Presentation (2) . . . . . . . . . . . . . . . . . . . . . .

ECAM Warnings Presentation (2) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Indicating System Control & Indicating (2) . . . . . . . . . . . . . . . . . . . .
EIS ECAM Normal and Manual Mode Description (3) . . . . . . . . . . .
ECAM Advisory & Failure Related Modes (3) . . . . . . . . . . . . . . . . .
ECAM Description/Operation (3) . . . . . . . . . . . . . . . . . . . . . . . . . . .
EFIS Description/Operation (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ELECTRONIC INSTRUMENT SYSTEM (EIS) DMC ARINC BUS Reconfiguration (3) . . . . . . . . . . . . . . . . . . . . . .
EIS Abnormal Operation (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CLOCK Indicating System Operation, Control & Indicating (3) . . . . . . . . . .
CLOCK
CENTRALIZED FAULT DISPLAY SYSTEM Electrical Clock D/O (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(CFDS) CENTRALIZED FAULT DISPLAY SYSTEM (CFDS)
CFDS Component location (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CFDS Fault Processing (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PRINTER CFDS Aircraft System Types (2) . . . . . . . . . . . . . . . . . . . . . . . . . . .
CFDS Failure Classification (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CFDS Reports (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CFDS Phases (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CFDIU Functions (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trouble Shooting Procedure with CFDS (3) . . . . . . . . . . . . . . . . . .
Post Flight Report Filtering Function (3) . . . . . . . . . . . . . . . . . . . . .
PRINTER
Printer Description/Operation (3) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Printer Paper Loading (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MAINTENANCE PRACTICE
Computer Removal and Installation (3) . . . . . . . . . . . . . . . . . . . . . .
Pushbutton Removal and Installation (3) . . . . . . . . . . . . . . . . . . . . .

BATIK AIR 3
  GENERAL

 FAILURE CLASSIFICATION & INDICATION

FOCUS OF STUDY
THE USE OF THE  ACCESS TO CFDS
CFDS AND TSM
 PFR CORRELATION PRINCIPLE

 AIRNAV FOR TROUBLESHOOTING

BATIK AIR 5
FOCUS OF STUDY CFDS ARCHITECTURE

The A320 Family maintenance concept is based on the use of the CFDS
and TSM
Main purpose of the CFDS is to ease Aircraft maintenance by compiling
failure information from system BITE and providing system BITE test
capability from cockpit
GENERAL
The CFDS is made of the CFDIU which interface with:
- Built in test Equipment (BITE) of each connected LRU
- MCDU
- Portable loader (PDL) or MDDu ( multipurpose disk drive unit)
- ACARS or ATSU
- Printer
- Clock

YOUR COMPANY NAME 6

 Cockpit Philosophy

FOCUS OF STUDY

GENERAL

YOUR COMPANY NAME 7

 Cockpit Philosophy

FOCUS OF STUDY

GENERAL

YOUR COMPANY NAME 8

FOCUS OF STUDY

GENERAL

YOUR COMPANY NAME 9

 CFDS ARCHITECTURE
FOCUS OF STUDY

GENERAL

YOUR COMPANY NAME 10

FOCUS OF STUDY CFDIU
The CFDIU receives failure messages from all aircrafts with BITE capability. The
CFDIU memorizes and manages the system Faults and complies various
maintenance report
BITE
Most aircraft system computers are equipped with a Built-In Test
Equipment (BITE). The BITE, which is an electronic device (hard + soft),
monitors permanently the system operation. When a failure is detected,
it is stored in the BITE memory and is transmitted to the Centralized
Fault Display Interface Unit (CFDIU).
GENERAL The bite is a function in corporate in the computer

MCDU
The MCDU is a display unit and a keyboard used by the CFDS to display
and interrogate BITE and initiate system test. both MCDUs are
connected to the CFDS. The CFDS can be used on one MCDU at a time .

YOUR COMPANY NAME 11

FOCUS OF STUDY

FAILURE
REPORTING PER
FLIGHT PHASE

BATIK AIR 12
 The failures are classified
The maintenance message classification is based on fault consequences on flight operation:
 Class 1 failures are the most serious ones and require an immediate maintenance action subject to
the Minimum Equipment List (MEL). May have an operational consequence of flight.

 Class 2 failures may have consequences if a second failure occurs. A class 2 failure must be repaired
within 10 days. No immediate operational consequence on flight.

 Class 3 failures can be left uncorrected

until the next scheduled maintenance
check. No consequence of flight.
FAILURE
CLASSIFICATION
AND INDICATION
CLASS 1
Class 1 failures have an operational
consequence on the flight. You can
display the class 1 failures on the
MCDU:
- in the LAST (or CURRENT) LEG REPORT.
- in the LAST (or CURRENT) LEG ECAM
REPORT.
These faults are also indicated to the
crew in flight:
- by the ECAM system (upper and/or
lower Display Unit (DU)).
- by local warning in the cockpit.
Refer to the Minimum Equipment List
(MEL): "GO", "GO IF" or "NO GO".
CLASS 2
Class 2 failures have no immediate
operational consequence and can
be displayed on request on the
ECAM STATUS page, under the
MAINTENANCE title.
You can display the class 2 failures
on the MCDU:
- in the LAST (or CURRENT) LEG
REPORT.
- in the LAST (or CURRENT) LEG
ECAM REPORT.
A class 2 failure has to be repaired
within 10 days. Refer to the MEL:
"GO" without condition.
The example given here concerns
the Cabin Intercommunication
Data System (CIDS) fault.
CLASS 3
Class 3 failures have no operational
consequence. All aircraft systems
remain available. These faults are not
indicated to the crew but you can
display the name of the systems
affected by at least a class 3 failure in
the AVIONICS STATUS (only available on
ground). Do not refer to the
MEL. Class 3 failures have no fixed time
for correction. However,
correction is recommended to improve
the dispatch reliability. Class 3
failures may be corrected during the A
CHECK programmed maintenance
operations.
 ACCES TO CFDS REPORT
GENERAL
On ground, all the functions are available. In flight, only CURRENT LEG REPORT and CURRENT LEG
ECAM REPORT are available.
NOTE: Note: The Centralized Fault Display System (CFDS) menu
comprises two pages

LAST (CURRENT ) LEG ECAM REPORT :

ECAM warning / Caution messages seen by crew during the last ( current) flight leg.

LAST (CURRENT) LEG REPORT:

FAILURES recorded during the last flight (current) leg.

PREVIOUS LEGS REPORT:

Equivalent to last LEG report but accessible for the last 64 flights

AVIONIC STATUS:
LIST in real time of the system affected by at least one internal or external failure ( Class 1,2
or 3)

POST FLIGHT REPORT:

SUM of LAST LEG ECAM REPORT and LAST LEG REPORT
HOW TO ACCESS THE LIST OF SYSTEM REPORTING TO THE CFDS?

THE SYSTEM REPORT/TEST function is available on ground only. It

enables an interactive dialogue between the CFDS and One Particular
system.
Pressing the line key adjacent to a system name enables acces to the menu of
system, generally made up of below item ( SYSTEM TYPE 1 ):
• LAST LEG REPORT
• PREVIOUS LEGS REPORT
• LRU IDENTIFICATION

FOR some system , the following optional function may ne available:

• TROUBLESHOOTING DATA (TSD)
• CLASS 3 FAULTS
• TEST
• GROUNDSCANNING
 HOW TO USE THE CFDS

Types of systems
Systems have been divided into three categories in order to limit the complexity:
· type 1
· type 2
· type 3

depending on the type of interface that they may have with the CFDIU.
This system organization in three types essentially remains transparent for the operator as the
CFDIU manages any differences. Nonetheless, their definitions make it possible to understand
why certain menus are simplified.

Type 1 systems
These systems are characterized by an input/output interface with the CFDIU of the ARINC 429 bus/
ARINC 429 bus type. Most systems are provided with this type of interface.
This type of system enables:
· output: permanent transmission to the CFDIU of maintenance messages generated during the current
flight or during the last flight
· input: an operator to dialog on the ground with the BITEs and therefore have access to
complementary information (test, ground report, etc.).
Type 2 systems
These systems are characterized by an input/output interface with the CFDIU of the discrete/ARINC 429
bus type.
This type of system enables:
· output: permanent transmission to the CFDIU of maintenance messages generated during the current
flight or during the last flight, as well as permanent transmission while on the ground of maintenance
messages generated on the ground
· input: an operator to launch on the ground the system test and to obtain the results via the output bus.

Type 3 systems

These systems are characterized by an input/output interface with the CFDIU of the discrete/discrete
type.
This type of system enables:
· output: permanent transmission of the operating status (OK, not OK)
· input: an operator to launch on the ground the system test and to obtain the result (OK, or not OK) via
the discrete output.
The CFDIU decodes the corresponding maintenance message into plain language.
Flight/ground conditions

Information concerning detected faults is generated by

the CFDS according to flight/ground conditions.
Faults detected on ground may be due to maintenance
actions on the aircraft and therefore are not to be
taken into account (e.g. loss of a system because the
circuit breaker is open).

This is the reason why the aircraft systems have 2 types of

memorization:
· the first one for the faults detected on ground
· the second one for the faults detected in flight.

The flight/ground condition used by the CFDS is specific

and has been selected so as to eliminate the false faults
while covering, in the best possible manner, all
operations. This is calculated by the CFDIU.

The flight condition is located between first engine start

up plus three minutes (or eighty knots plus thirty
seconds if flight plan is not available in the FMS) and
eighty knots plus thirty seconds after touch down.

NOTE: In case of engine run up for maintenance purpose, a flight number (at least one
character) must be entered using the MCDU to get a PFR, the eighty knots condition being
never reached.
Type 1 systems provided with an ARINC bus from the CFDIU Nonetheless, type 2 systems having no specific function
will use this flight/ground condition defined by during these phases, the probability of
the CFDIU (correct synchronization, monitored range occurrence of these cases is very low.
optimized). For the CFDS, a cycle is defined as a set of sequences
between two ground/flight transitions as
Management of messages of type 3 systems (no input or defined by the CFDS.
output bus) is via the CFDIU which uses its own
flight/ground condition. Conclusion:
Faults detected during flight will generate maintenance
Type 2 systems cannot receive this information (no input messages in the PFR associated with
bus) and generate it by default. For these systems, this flight (if class 1 or 2 as defined in Para 4.D.).
the flight condition is between takeoff and landing. Other faults, exceptionally detected on the ground after the
This difference only causes minor consequences for flight, may generate maintenance
maintainability of type 2 systems. messages in a ground report (Ref. Para. 4.E.(3)(b)) of the
In fact, only: associated system. However, if no corrections are made,
· the faults which may be detected between startup of the effective faults will still be present in the next cycle and will
first engine plus three minutes and takeoff, still consequently generate maintenance messages in the next
present after the ground/fight transition, are reported on PFR following the ground/flight transition.
the PFR as faults occurred in the CLIMB phase Maintenance messages are stored only once during a given
(phase 5). cycle at the first detection after the
· the faults which may be detected between touch down beginning of the cycle.
and eighty knots plus thirty seconds are not
reported on the PFR on the last flight (Ref. Para. 4.E.(1)).
 Faults with operational cockpit event later than the "rectification
This event is also called a cockpit effect. Examples of cockpit effects are: interval" required as per MMEL section MI-00-05 "Repair Interval".
an ECAM warning, a local warning, a flag, or any invalid function such as a The crew must make an entry into the LOG BOOK (Pilot report) because
missing audio signal, amber crosses on a system page, this information is provided by
etc. the FWS at the end of the flight, after engines shutdown, through the
Some of these faults have consequences on the system safety objective ECAM MAINTENANCE STATUS.
and are NO GO items (i.e.: the failure must be fixed before the next In order to launch at the first opportunity the proper maintenance action it is
departure) or GO IF items (GO if the conditions given in the MEL necessary to provide
are fulfilled). The others are GO without conditions. the information to the maintenance teams. Consequently, these faults are
covered by a CLASS 2
For some of these faults the cockpit effect does not automatically appear to maintenance message transmitted to the CFDIU.
the crew when it is activated Class 2 maintenance messages are presented in the Post Flight Report at
(e.g.: amber crosses on a system page). the end of the flight.
The status regarding all these faults is given by the MEL. (4) Faults without cockpit event
When the crew take notice of a fault through the cockpit effect they must (a) General philosophy
report it in the aircraft LOG These faults have no consequence on the system operating conditions and
BOOK. the crew is not aware of
In order to be able to launch the proper maintenance actions, all faults: them.
· having a cockpit effect and All faults detected by the systems without cockpit event are covered by a
· detected by the systems are covered by a CLASS 1 maintenance CLASS 3 fault
message transmitted to the CFDIU. maintenance message.
Class 1 maintenance messages are presented in the Post Flight Report at These messages are recorded in each system BITE (class 3 report).
the end of the AIRBUS recommend through the MPD (Maintenance Planning Document)
flight. to read Class 3 failures
NOTE: Some of the system faults having an effect in the cabin are also every 750 flight hours / 6 months.
covered by a CLASS 1 maintenance
message transmitted to the CFDIU.
(3) Faults triggering an ECAM MAINTENANCE STATUS
These faults have no consequence on the system operating conditions.
They are always GO without
any restriction. These faults must be fixed at the first opportunity and not
Engine system
The class 3 faults (without cockpit event) have been classified in the two following categories:

· the TIME LIMITED dispatch faults: which means that the fault may remain uncorrected within a maximum
time frame specified by the Maintenance Planning Document.
· the UNLIMITED TIME dispatch faults: which means that the fault may remain uncorrected within an unlimited
time frame.

All these faults are presented by the FADEC BITE in the 'Scheduled Maintenance Report' at the aircraft level
and classified "S" in the Trouble Shooting Manual.
Within class "S" faults, an (*) at the end of the maintenance message will highlight UNLIMITED TIME dispatch
faults.
Faults without the (*) correspond to TIME LIMITED dispatch faults.
Example:
'CFDIU,EIU (FLGT), J3*' is an UNLIMITED TIME dispatch fault and should be treated like any other aircraft
system CLASS 3 fault.
'T495L harn (En-4028 KS2)J9/ECU(En-4000Ks)' is a TIME LIMITED dispatch fault and must be corrected in
accordance with the Maintenance Planning Document.
NOTE: For engines that give separate "Class 3" and "Scheduled Maintenance Report" (SMR) reports, the (*) is
not used in the message wording. The CLASS 3 messages are classified directly as CLASS 3 in the TSM and not
"S".
Internal fault/external fault Under these conditions this message is qualified by the unit
A unique fault may disturb several generating it as having priority over all messages transmitted
by the other systems for the same fault. It will be the one
systems. In this case, it will lead to the retained by the CFDIU (refer to the PFR). This message is called
generation of several internal.
maintenance messages (one per
The other maintenance messages related to the same fault are
system). One of these messages may be called external by the other systems.
more accurate than the others.
Depending on the fault and its effect, it They have less accuracy, have not priority and are not recorded
in this case by the CFDIU. Only their origins are memorized by
will be the one generated either by a the CFDIU as identifiers (refer to the PFR).
computer which detects itself faulty Therefore, each system has in memory an information linked
(self monitoring) or by the computer in to every message transmitted to the CFDIU which defines its
internal or external attribute so that the CFDIU can give priority
charge of the BITE of the system. to the most accurate one.
When no priority messages are received by the CFDIU for the
same event it is considered that the accuracy is the same for all
messages received. In this case the CFDIU retains the first one
received.
Remark: as a general rule, the LRUs incriminated by the
maintenance messages shown in the PFR are
part of the systems which generated the internal messages.
 A fault of the ADM sensor is detected by the ADIRU.
The ADIRU sends a fault message (e.g. ADIRU1: NO ADM 19FP1 DATA) to
the CFDIU and invalidates some parameters on its output buses (e.g.
Airspeed). This fault message is coded as internal by the
ADIRU.

The users of the ADIRU data (EIS, AFS, ECAM, FADEC, ...) detect the loss of
the airspeed parameter.
They send fault messages to the CFDIU, coded as external (e.g. EIS1: NO
ADIRU1 DATA).

The CFDIU stores the fault message from the ADIRU and the name of the
systems which have detected the fault.

The PFR is:

SOURCE IDENTIFIERS
ADIRU1 : NO ADM19 FP1 DATA ADIRU1 EIS, AFS, ECAM
FADEC

Example:
(Ref. Fig. Example of ADM Sensor Fault Detection )
 The following data are recorded in the PFR:
· ECAM WARNING MESSAGES
The ECAM WARNING MESSAGES contains:
. the warning message available on the upper ECAM display unit
. the maintenance status
These warning messages are associated with their ATA reference (aid for cross
referencing with the maintenance message).
· FAULTS:
Maintenance messages are listed in the PFR in the FAILURE MESSAGES part.
Additional information is associated with each message.
· FLIGHT PHASE - GMT
Flight operational phases (CLIMB, CRUISE, etc.) are indicated in coded form in
the PFR in front of the warning message. The time (GMT) is also given in front of
the warning message and the maintenance message.
. FLIGHT PHASE decoding:
02 : Engine start + 3 mn up to TO Power
03 : TO Power up to 80 kts
04 : 80 kts up to lift off
05 : Climb
06 : Cruise
07 : Descent
08 : Touch down up to 80 kts
09 : 80 kts up to last engine shut down.

ATA: This is the ATA chapter of the first suspected component. It is the entry point to the technical documentation. It may also be an aid in relation to the
corresponding warning message and with the GMT.
· SOURCE: The source is the system (for system BITE) or the computer which generated the
maintenance message retained by the CFDIU for this event and recorded in the PFR.
· IDENTIFIER(S):
The identifier(s) are the computers which have also reacted in relation to the fault
by generating:
. external maintenance messages not retained by the CFDIU
. cockpit effects.
 PFR Correlation principle Example:
THE PURPOSE OF CORRELATION is to define the fault symptoms from ECAM WARNING MESSAGES
LogBooks entries, and input the relevant TSM task required to isolate GMT PH ATA
and fix the faults reported by the crew.
The fault symptom is the result of a manual warning /failure correlation :
1000 06 31-00 DAR(3)
It is consist in associating each cockpit effect ( logbook entries) to the 1030 06 21-31 CAB PR SYS 2 FAULT
relevant failure messages ( PFR or result of the system BITE test ) 1045 06 31-00 DAR
FAILURE MESSAGES
1 Correlation between fault messages: GMT PH ATA SOURCE IDENT.
In order to limit the number of fault messages printed on the PFR and to 1000 06 31-36-52 DAR DMU
give the line mechanic 1030 06 21-31-34 PRESS CONTR 2 CPC2
only the root cause of a fault, the CFDIU correlates the fault messages. The DAR fails several times during the flight.
This correlation is based on the GMT and the ATA chapter of the The figure (3) displayed after the Maintenance Status "DAR"
received fault messages. means that this Maintenance Status was sent 3 consecutive
times to the CFDIU for PFR recording. In order to prevent
2 Correlation between fault message and ECAM warning or Maintenance the recording of 3 "DAR" messages, the "occurrence
Status: counter" has been activated, and only the fault message
This correlation has to be performed by the line mechanic. The ATA related to the first occurrence of the DAR fault is recorded
Chapter and the GMT have to be used (general case).If a fault appears and (GMT = 1000).
disappears several times during the same flight leg, the corresponding But as a warning "CAB PR SYS 2 FAULT" has been recorded
fault message is transmitted only at the first detection, but the ECAM (GMT = 1030), followed by a new "DAR" Maintenance Status
warning (for a Class 1 fault) or the Maintenance Status (for a Class 2 fault) (GMT=1045), then in this case the "occurrence counter" is
is displayed every time in the cockpit and transmitted every time to the reset.
CFDIU. Therefore, it is possible to find in the PFR several times the same If the warning "CAB PR SYS 2 FAULT" would have not been
ECAM warning or Maintenance Status but only one fault message. recorded, the "DAR" message would have been recorded at
GMT=1000 with a counter set to 4.
CFDIU NEW STANDARDS CAPABILITIES
FROM the CFDIU standard 10A,
warning/failure correlation is possible
on MCDU through the CFDS main page,
From the LAST LEG ( ECAM) Report.
If warning is correlated to fault , a
prompt (“>”) is added on the right of
corresponding fault
An ECAM warning or a
Maintenance Status can be
associated with a system only
shown as an identifier in the
PFR, because it is not the root
cause of the fault.

There is a Radio Altimeter 2 fault.

The RA2 is really faulty and is not able to send a fault message. The users of the RA2 signals detect the fault
(CFDS, EFCS, ECAM, EIS). For the EFCS, the loss of the RA2 is a class 2 fault. The associated Maintenance Status
is available (F/CTL).

The installation of a new RA2 on the aircraft will eliminate the ECAM warning and the Maintenance Status.

NOTE:
The number of identifiers is limited to 6. If more than 6 are correlated, the CFDIU keeps only the first six
systems received. The remaining are ignored. It is therefore theorically possible to have an ECAM warning or a
Maintenance Status without any indication on the associated system in the FAILURE MESSAGES part.
The operators request information
regarding the meaning of
"spurious".

1. What is a spurious message?

2. How to identify a spurious?
3. What are the faults that Airbus consider as
spurious?
4. What is the way to identify a spurious?
5. Where to find literature regarding the spurious?
1. Spurious message

A message is spurious because it has been verified that no maintenance action is due
when it is triggered. A message may be spurious because its associated monitoring
detects a fault whereas there is no actual fault on aircraft. For example when an
aircraft is taxiing with only one engine running, the Flight Warning System (FWS)
BITE and Electronic Instrument System (EIS) BITE will trigger Fault Messages
because they detect that no information is received from the Full Authority Digital
Engine Control (FADEC) of the engine not started. These Fault Messages are
spurious.

2. Confirmation of spurious messages

Airbus is in charge to confirm the nuisance of fault messages and identify them as
spurious messages.
Identification of spurious messages is also done thanks to Airbus internal (vendor
information / laboratory tests, limitations notes) and external (airlines) feedbacks.
After analysis, a confirmed spurious message is then documented in the SILs in
references which are updated according to these new spurious messages. Airbus
recommends the operators to consult the SIL in case they suspect that an item in the
PFR is spurious, as depicted in the extract of A320 Family Maintenance Poster /
Troubleshooting & dispatch guidelines.
3. Faults considered as spurious
Several ways permit to consider a message as a spurious one:
- the occurrence rate of this message (if the message appears more than once every 5 flights without any logbook
complaints),
- the flight phase apparition could also be a decision element (e.g. a monitoring activated although system not yet
started). A fault message could be spurious according to the aircraft configuration, to a known misbehaviour of a system
or to optional systems not installed.
In all cases, Airbus will classify a fault message as spurious only when the conditions
of occurrence are known, precise and reproducible.

4. Identification of a spurious
Spurious messages are listed in the SILs in references. The CFDS/CMS Filter file,
associated to the SIL, covers all spurious messages that Airbus recommend to filter from the PFR.
Nevertheless, according to systems evolutions, new spurious can be detected and the filter + SIL are updated accordingly.
Airlines can use the Fault Tracking / Nuisance Fault functions of AIRMAN to detect
specific messages (nuisance message tag). Airlines are able to customize the settings
of detection of nuisance message and therefore may contribute to provide in-service
feedback to Airbus.
5. Literature regarding the spurious
The SILs in reference are the document used by the operators to check if a message
has been identified as spurious by Airbus.
Refer to the extract from A320 Maintenance concept poster in attachment.
The Maintenance concept is based
on the use of CFDS and TSM.
NOTE:
The aircraft is equipped with a high number of digital items of equipment. In most of the cases, computers
may be recovered after an abnormal behavior or a detected fault, either by a software reset (reset of
microprocessor) or by interrupting the power supply of its processing parts for a short time. This is achieved
with the normal cockpit controls (engagement levers, pushbutton switches) by selecting the related control
off then on or by action on the corresponding circuit breaker.
 Repetitive handling
It is recalled that the TSM has been designed to isolate/troubleshoot hard faults.
However depending on the airlines organization, the following can be applied "to
trap" intermittent faults:
· if the test result is "TEST OK" (fault not confirmed), dispatch the aircraft, then
monitor the reported symptom on the following flights by checking:
* the previous leg reports
* the PFR/Previous PFRs (if available)
* the log book of the previous flights.
After three occurrences of the same phenomenon (even though the test is
still OK), the other steps of the TSM procedure must be followed and the
LRU involved must be removed.
In this case, as for all LRUs removed from the aircraft, AIRBUS
recommend providing shop people or suppliers with data related to the
removal: PFR, test result, trouble shooting data (if available).