How To Use TSM

Customer : GFA Type : A330 Rev.
Date : Jul 01/11 How to Use the CMS

** ON A/C ALL
8. How to Use the CMS A. Reminder of Design Definition (1) Types of systems Systems have been divided into three categories in order to limit the complexity: - type 1 - type 2 type 3
Manual: TSM Selected effectivity: ALL
depending on the type of interface that they may have with the Central Maintenance Computer (CMC). This system organization in three types essentially remains transparent for the operator as the CMC manages any differences. Nonetheless, their definitions make it possible to understand why certain menus are simplified. In fact, ARINC 429 type interfaces are more difficult to manage and are only used when necessary. (a) Type 1 systems These systems are characterized by an input/output interface with the CMC 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 CMC 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.). (b) Type 2 systems These systems are characterized by an input/output interface with the CMC of the discrete/ARINC 429 bus type. This type of system enables: - output: permanent transmission to the CMC 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. Certain other functions available for type 1 systems (last leg report, LRU identification, etc.) may also be performed directly by the CMC. (c) Type 3 systems
Print Date: Nov 29/11 Local Time
Page 1 of 26
Customer : GFA Type : A330 Rev. Date : Jul 01/11 How to Use the CMS
These systems are characterized by an input/output interface with the CMC 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 CMC decodes the corresponding maintenance message into plain language (2) System BITE (Ref. Fig. System BITE SHEET 1)
When a system includes several computers, one of the computers collects the maintenance information and provides the link between the system and the CMC. It then performs the BITE function and therefore reports on behalf of all system computers. This architecture provides a better targeted diagnosis by correlating data between system computers as well as reducing bus links with the CMC. For the operator, the resulting consequences are minor: - it is the maintenance message itself which identifies, where necessary, the message source in the system. Example: source = FWS; message = ECMU1(1XM1)/SDAC1(1WV1). The SDAC which is part of the Flight Warning System has generated the message - it is also necessary to indicate the system BITE to launch tests in another computer of the same system. For this aircraft the system BITEs are the following: ACMS for DMU & DAR AFS for FMGEC 1 & 2, MCDU 1, 2 & 3, FCU AIS for AMU and all ACPs ECS for ZC, PC EFCS1 for FCPC 1, 2 & 3, FCSC 1 & 2, FCDC 1 & 2 EPGS for GPCU, GCU 1, 2, 3 & 4, APU GCU FWS for FWC 1 & 2, SDAC 1 & 2 DFDRS for FDIU, DFDR & QAR (option) (3) Flight/ground conditions (Ref. Fig. Flight/Ground Condition SHEET 1) Information concerning detected faults is generated by the CMS according to flight/ground conditions. The flight/ground condition used by the CMS is specific and has been selected to eliminate the pseudo faults while covering all operations. This condition is calculated by the CMC. The flight condition is located between start up of the first engine plus three minutes with flight plan available in the FMS and eighty knots and thirty seconds after touch down. Type 1 systems provided with an ARINC bus from the CMC will use this flight/ground condition defined by the CMC (correct synchronization, monitored range optimized). Management of messages of type 3 systems (no input or output bus) is via the CMC which uses its own flight/ground condition.
Page 2 of 26
Type 2 systems cannot receive this information (no input bus) and generate it by default. For these systems, the flight condition is between takeoff and landing. This difference only causes minor consequences for maintainability of type 2 systems. In fact, only: - the faults which may be detected between start up of the first engine plus three minutes and takeoff are reported on the PFR, next to the CLIMB phase the faults which may be detected between touch down and eighty knots and thirty seconds are not reported on the PFR on the last flight (Ref. Para. 4.A.(6)). Nonetheless, since type 2 systems have no specific function during these phases, the probability of occurrence of these cases is very low. For the CMS, a cycle is defined as a set of sequences between two ground/flight transitions as defined by the CMS. Conclusion: Faults detected during flight will generate maintenance messages in the PFR associated with this flight (if class 1 or 2 as defined in Para 4.A.(5)). Other faults, exceptionally detected on the ground after the flight, may generate maintenance messages in the GROUND REPORT (Ref. Para. 4.A.(6)(c)2_) of the associated system. However, if no corrections are made, effective faults will still be present in the next cycle and will consequently generate maintenance messages in the next PFR following the ground/flight transition. Maintenance messages are stored only once during a given cycle, the first time they are detected after the beginning of the cycle. (4) Maintenance message definition (may not apply to some BFE) As the purpose of the CMS is to analyze faults in order to identify the responsible components, the maintenance messages indicate these components (an LRU in most cases) as directly as possible and do not describe the event, (this would oblige the operator to perform the analysis himself). (a) Message parts The maintenance messages are all made up of one or several parts which are defined in compliance with the following syntax: - the name of the suspect component is mentioned - if it is an LRU, its (FIN) is indicated between parentheses immediately after its name - if necessary, complementary information is given after the (FIN). These three data constitute one message part. Example of message part: ADIRU1 (1FP1) BUS ADR. As a general rule, up to three parts can be included in a maintenance message, each part representing a suspect component. Any part of a maintenance message is necessarily in one of these five forms: 1 LRU (FIN) Either the computer identifies and declares itself suspect, or a computer or a system receiving several signals from another computer performs an analysis and concludes that the computer generating these signals is suspect. Example : GCU4 (1XU4). 2 LRU (FIN) COMPLEMENTARY INFO
Page 3 of 26
such as : LRU (FIN) BUS NAME LRU (FIN) SIGNAL NAME LRU (FIN) DISCRETE NAME In this case, the component suspected in priority is an LRU generating several signals. The complementary info enables to identify the suspect signal among the others. This signal can be checked on the aircraft. The signal name is consistent with the designations used throughout the Airbus manuals. Example: FDU4 (1WD4) LOOP B INOP DISCRETE. 3 WRG : SIGNAL NAME such as : WRG : LRU1 BUS NAME TO LRU2 WRG : LRU1 SIGNAL NAME TO LRU2 WRG : LRU1 DISCRETE NAME TO LRU2 WRG : PIN PROG NAME. Wiring is suspected only when BITE analysis has revealed its fault. Wiring is always identified by the name of the signal it transmits. The signal name is in accordance with the technical manuals. Example : WRG : BARO SOURCE SELECT PIN PROG. 4 Specific message form This type is used in the cases where precise identification of the suspect LRU would require unjustified BITE complexity and would therefore be inefficient. In this case, only the analysis of the problem by the operators will enable to identify the suspect LRU. The procedure to follow is then described in the maintenance manual. Example : LOW OIL LEVEL. 5 LRU (FIN) SPLY A message part belongs to this type when LRU supply loss is identified without ambiguity. LRU power supply must then be checked accurately (as the LRU itself can be one of the causes of this power supply loss). Example: FDU2 (1WD2) CHAN B SPLY. For all the other maintenance messages, it is however recommended to make sure, on the ECAM C/B status page, that all the circuit breakers used are really closed. (b) Complete message The following rules apply to the complete message: - the sign "/" separates each message part the elements are indicated in the order of highest occurrence probability (only one component is really responsible).
Page 4 of 26
In some cases of multiple faults, a BITE may generate only one maintenance message which may report several faulty components. These components are then separated by the sign "+" - The ATA reference facing the message corresponds to the first suspected component. (The ATA reference is a documentation entry point) - As soon as there is more than one component (more than one part) in the message, aircraft wiring can be suspected but it is not indicated in the messages (Ref. form 3) except if it has been clearly identified as being the origin of the fault - When, in a message part, the (FIN) is missing, this means that no LRU is directly involved in this part. In a maintenance message, the combination of the different parts which constitute the complete message depends on the architecture of the signals detected faulty. Example of combinations: LRU 1 (FIN)/LRU 2 (FIN) (form 1/form 1) LRU 1 (FIN) BUS NAME/LRU2 (FIN) (form 2/form 1) LRU 1 (FIN)/WRG : B DISCRETE NAME TO A (form 1/form 3) The purpose of these constitution rules is to enable the operator to quickly understand, when required, the architecture of the suspect signals, their nature, as well as the type of monitoring performed, only by reading the maintenance message. (c) Utilization of the messages The maintenance messages can be used as follows: - either by taking into account each part of the message in the order in which they occur, and checking on aircraft the suspect component. This is the basic method which gives the suspect components directly. This is the main method used in the trouble shooting manual (TSM) or by using the complete message. In this case, the architecture of the monitored signals can be retrieved from the combination of the parts which constitute the complete message. Correspondence between complete maintenance messages (combination of parts) and main signal architecture is given in the MESSAGE TYPE/FAULT CONFIGURATION tables. The following rules have been used for these tables: each rectangle represents an LRU the grey rectangle, noted A, represents the computer generating the maintenance message (source) the arrows represent the data flows between the LRUs. Each arrow represents one type of complete medium. e.g. : ARINC bus, analog signal, etc. the crosses indicate the signals detected faulty by the computer. They are always related to data input or output of a computer (except for internal faults = crosses in the box).
NOTE: The logic used by the computer to detect the fault is not detailed. It extends from monitoring of Sign/Status Matrix (SSM), parity and refresh rate for an ARINC bus to the comparison with a "model" for some analog signals. Its utilization is linked to that of the trouble shooting data.
Page 5 of 26
each cross represents an independent monitoring. When a cross covers several signals, this means that detection is performed through comparison of these signals and only in this case - the analysis performed by the BITEs is based on simultaneous appearance of faults (X). This represents occurrence of a single fault. The signals which are valid at the same moment and used by the BITEs to conclude the analysis are represented without a cross. (5) Maintenance message classification (a) general Maintenance message classification is based on fault consequence. All faults can be divided into three groups: - the faults leading to an operational event in the cockpit - the faults leading to an operational event in the cabin - the fault leading to an ECAM MAINTENANCE STATUS - the faults without cockpit events and cabin events. (b) faults with operational cockpit event This event is also called a cockpit effect. examples of cockpit effects are: an ECAM warning, a local warning, a flag, or any invalid function such as a missing audio signal, amber crosses on a system page, etc. Some of these faults have consequences on the system safety objective and are NO GO items (i.e.: the failure must be fixed before the next departure) or GO IF items(GO if the conditions given in the MEL are fulfilled). The others are GO without conditions. For some of these faults the cockpit effect does not automatically appear to the crew when it is activated (e.g.: amber crosses on a system page). The status regarding all these faults is given by the MEL. When the crew take notice of a fault through the cockpit effect they can report it in the aircraft LOG BOOK. In order to be able to launch the proper maintenance actions, all faults: - having a cockpit effect and - detected by the systems are covered by a CLASS 1 maintenance message transmitted to the CMC. Class 1 maintenance messages are presented in the Post Flight Report at the end of the flight. (c) Faults with operational cabin event without cockpit effect. This event is also called a cabin effect. Example of cabin effects are: message displayed in the cabin on the Forward Attendant Panel (FAP), caution lights, chimes, etc. Few of these fault have consequences on the system safety objective. In case they have consequences on the system safety objective, they are listed in the MEL and are GO IF. The others faults with operational cabin event without cockpit effect have no impact on system safety objectives and are GO without conditions and not listed in MEL. However, they have in most of cases an impact on operation for transport of passenger.
Page 6 of 26
When the cabin crew take notice of a fault through the cabin effect, they can report it in the CABIN LOGBOOK and may report it to cockpit crew, depending on operator policies. In order to be able to launch the proper maintenance actions in both cases, all faults: - having a cabin effect and - detected by the systems are covered by a CLASS 1 maintenance message transmitted to the CMC Class 1 maintenance messages are presented in the Post Flight Report at the end of the flight. (d) Faults triggering an ECAM MAINTENANCE STATUS These faults have no consequence on the system operating conditions. They are always GO without any restriction. However by correcting them before the next scheduled maintenance task it is possible to significantly increase the dispatch reliability of the aircraft and/or to reduce the maintenance costs. In order to reach this objective it is considered that these faults should be fixed at the first opportunity and not later than 800 flight hours. Maintenance Status corresponds to class 2 maintenance messages, presented on the Post Flight Report. In order to launch at the first opportunity the proper maintenance action, it is recommended to check the MAINT STS at every long stop at the main maintenance base. The respect of the maximum 800FH delay can be ensured by systematic repair of all class 2 faults every A check, or record and count the flight hours of each class 2 failure displayed on the PFR. For operators equipped with ACARS, the ground station can also process the PFRs automatically transmitted after each flight, and issue a report when a class 2 message is generated on more than 3 flights every 7 days. (e) Faults without cockpit event and cabin event 1 General philosophy These faults have no consequence on the system operating conditions and the crew is not aware of them. These faults neither have impact on operation. All faults detected by the systems without cockpit event and cabin event are covered by a CLASS 3 maintenance message. These messages are recorded in each system BITE (class 3 report). Class 3 fault are UNLIMITED TIME dispatch faults, which means that they may remain uncorrected within an unlimited time frame. (f) Internal fault/external fault A unique fault may disturb several systems. In this case, it will lead to the generation of several maintenance messages (one per system). One of these messages may be more accurate than the others. Depending on the fault and its effect, it will be the one generated either by a computer which detects itself faulty (self monitoring) or by a system exchanging the greatest volume of information with a faulty LRU. Under these conditions this message is qualified by the unit generating it as having priority over all messages transmitted by the other systems for the same fault. It will be the one retained by the CMC (refer to the PFR). This message is called internal. The other maintenance messages related to the same fault are called external by the other systems. They have less accuracy, have not priority and are not recorded in this case by the CMC. Only their origins are memorized by the CMC as identifiers (refer to the PFR). Therefore, each system has in memory an information linked to every message transmitted to the CMC which defines its internal of external attribute so that the CMC can give priority to the most accurate one. In any cases priority is given to messages reporting aircraft electrical power supply. When no priority messages are received by the CMC for the same event it is considered that the accuracy is the same for all messages received. In this case the
Page 7 of 26
CMC 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. (6) Maintenance functions (a) First group: the PFR 1 Description of the PFR A maintenance report on the last flight is automatically printed as soon as all engines are stopped. This document is the Post Flight Report (PFR). The PFR is a result of the CMS automatic operating mode. This report is the main source of information used to initiate trouble shooting and to decide on the required maintenance actions. (Ref. Fig. POST FLIGHT REPORT SHEET 1) A backup of the printed PFR is available on the MCDU. It should only be used if the printed PFR is not available as the information is less complete and the presentation is not so user-friendly. Conditional maintenance operations are carried out in response to the observations made by the flight crew in the LOG BOOK. This information represents a cockpit effect as previously defined. The occurrence of a fault with effect on the system at operational level and on maintenance constitutes an EVENT. The EVENTs are recorded in the PFR as follows: COCKPIT EFFECTS Warning messages representing most cockpit effects are recorded in the PFR in the COCKPIT EFFECTS column. The warnings enable the flight crew to know the operational functions which are no longer available. These warning messages are associated with: . their ATA reference (aid for cross referencing with the maintenance message) . the warnings may be hidden (display inhibited) during certain flight phases. However, for a permanent fault, the warning is always displayed at one moment or another during the flight. Transitory faults which have appeared and which have disappeared during their display inhibition phase(s) will be indicated as NOT DISPLAYED. Warnings displayed at the beginning of the flight and cleared by the crew (CLR action on ECAM control panel), before start of PFR recording, will also be indicated as NOT DISPLAYED. Furthermore, as the CMC records events in real time (i.e at fault detection), certain events related to warnings initially inhibited will be recorded in the PFR with the initial detection phase whereas the crew will only report it when warning inhibition is eliminated, i.e. during a following phase. UTC - FLIGHT PHASE Flight operational phases (CLIMB, CRUISE, etc.) are indicated in plain language and in coded form in the PFR in front of the warning message and the maintenance message. The time (UTC) is also given.
Page 8 of 26
This information is especially useful when a maintenance message is not associated with a warning message. This information may be used for cross referencing between the maintenance message and the cockpit effect recorded in the LOG BOOK. FAULTS: Maintenance messages are listed in the PFR in the FAULT column. The maintenance messages and the fault trouble shooting procedures enable the maintenance technicians to know whether a component is defective and must be replaced. Additional information is associated with each message. 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. CLASS: Only class 1 and 2 maintenance messages are reported in the PFR. The maintenance class indication enables the maintenance teams to establish a priority in trouble shooting actions. HARD/INTERMITTENT: The computers are capable of announcing whether the faults detected are HARD (i.e.: consolidated) or INTERMITTENT (i.e.: transient). These indications are only recorded in the printed PFR. A HARD fault indicates that one of the LRUs incriminated has effectively a damaged part and that only the replacement of this LRU will restore system integrity. An INTERMITTENT fault is a fault detected by the operational monitoring systems but for which the BITE analysis has proven that no part is damaged. In fact, the operational constraints make it necessary to activate, and in certain cases very quickly, a warning when a function is no longer available or is downgraded. However, the BITE has the time to make a longer consolidated analysis based on the time the fault is present or its frequency, or in self tests, etc. If the fault is not consolidated it is INTERMITTENT. The LRU reported in the maintenance message does not have an effective fault, however this message provides information to the related ECAM Warning. Due to this, if warnings can be used as maintenance aids they cannot be considered as damaged component indicators. For example, when a circuit breaker is manually opened, warnings are generated whereas no computer is damaged. Remark: Certain faults initially declared INTERMITTENT during flight may be declared HARD on the PFR if they have been repeated a sufficient number of times during the flight for the BITE to finally declare them as being HARD. SOURCE: The source is the system (for system BITE) or the computer which generated the maintenance message retained by the CMC for this event and recorded in the PFR. A star '*' is shown facing the SOURCE name of the system if the associated maintenance message covers a CLASS 2 fault.
Page 9 of 26
-
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 CMC . cockpit effects. A star '*' is shown facing the IDENTIFIER name of the system if the correlated message is a CLASS 2 fault. Several data combinations may be displayed for a given event: NO ALARM - ONE MESSAGE ONE ALARM - NO MESSAGE ONE ALARM - ONE MESSAGE Remark: For an event, several warning messages associated with a single maintenance message may also be recorded in the PFR.
Case study (Ref. Fig. Basic System Architecture SHEET 1) The following case studies are based on a basic system architecture in which: A is a sensor sending a signal to computer B. B is a computer which uses and monitors the signal from A and which sends signals, dependent on A, to three computers C, D and E. C, D and E are computers using and monitoring the signals from B. This architecture justifies the management method used by the CMC for maintenance messages it receives from systems. The links between the systems are all based, to a varying degree, on this architecture. 1st case: A is defective. B reacts to the fault by generating a warning message and a maintenance message. Its output signals which depend on A are also affected. C, D and E use the signals from B therefore also react by generating warning messages and maintenance messages. In the PFR: -----------------------------------------------------------------------------! COCKPIT EFFECTS ! UTC ! FAULTS ! ! !FLIGHT PHASE! ! !--------------------!------------!------------------------------------------! ! ATA XX-XX ! XXXX ! ATA XX-XX-XX SOURCE: B ! ! ! ! CLASS: X ! ! ! ! HARD IDENTIFIERS: ! ! MESSAGE: !FLIGHT PHASE! MESSAGE: C D ! !"WARNING MESSAGE OF ! XXXX ! !
Page 10 of 26
! B ! ! A/B E ! -----------------------------------------------------------------------------Warning messages The warning message recorded in the PFR is the one displayed to the pilots on the EWD. This is a priority message and it corresponds to a primary warning. C, D and E generate independent warning messages which are not displayed on the EWD. Therefore, the CMC does not record these messages in the PFR. Maintenance messages B, C, D and E send maintenance messages to the CMC which applies the priority rule. The maintenance message which will be recorded in the PFR is the one corresponding to an internal message. Therefore, this is the message sent by B (source). In this case, the message may be: A/B (A or B). The other messages from C, D and E correspond to external message. These messages may be: for C: B/C (B or C) for D: B/D (B or D) for E: B/E (B or E). These messages are not recorded in the PFR. In this case they are not of any value as the B message has been received by the CMC. However, C, D and E are indicated as identifiers which makes it possible to evaluate the consequences of the fault. 2nd case: B is defective. As B is defective, it does not produce any warning message or maintenance messages. Its output signals are invalid. C, D and E use the signals from B and react by generating warning messages and maintenance messages. In the PFR: ------------------------------------------------------------------------------! COCKPIT EFFECTS ! UTC ! FAULTS ! ! !FLIGHT PHASE ! ! !--------------------!-------------!------------------------------------------! ! ATA XX-XX ! XXXX ! ATA XX-XX-XX SOURCE:C ! ! ! ! CLASS:X ! ! ! ! HARD IDENTIFIERS: ! ! MESSAGE: !FLIGHT PHASE ! MESSAGE: D E ! !"WARNING MESSAGE OF ! XXXXXXX ! ! ! C ! ! B/C ! !--------------------!-------------!------------------------------------------! ! ATA XX-XX ! ! !
Page 11 of 26
! ! ! ! ! MESSAGE: ! ! ! !"WARNING MESSAGE OF ! ! ! ! D ! ! ! !--------------------!-------------!------------------------------------------! ! ATA XX-XX ! ! ! ! ! ! ! ! MESSAGE: ! ! ! !"WARNING MESSAGE OF ! ! ! ! E ! ! ! ------------------------------------------------------------------------------Warning messages The warning messages recorded in the PFR are those which are displayed to the pilot on the EWD. B has not generated any warning therefore these are the warnings generated by C, D and E and are independent. Maintenance messages As B is defective it therefore does not generate any messages. However, C, D and E generate the same maintenance messages as those in the previous case. They correspond to external faults which now all have the same value. If there is no internal maintenance message, the message which will be recorded in the PFR will be the first external message that the CMC will have received. For example, the message sent by C which is then the source. The messages may be B/C (B or C). The other messages from D and E are not recorded in the PFR. They do not provide any additional information. Messages may be for D: B/D (B or D) for E: B/E (B or E). However, D and E are indicated as identifiers. Therefore, these cases enable to evidence that a simple and unique logic enables the CMC to always record the most precise maintenance message in the PFR whatever the fault and the warning effectively displayed to the crew might be. (b) 2nd group: manual test function The manual test function is the main function of the CMS manual operating mode. The purpose is to be able to test on the ground, the maximum number of components, i.e. the integrity of the computer managing the test, the system LRUs and the validity of the external signals used by the system with a single test, because a system offering too many test possibilities would require operator knowledge of the system that is not compatible with the goals. 1 Various types of tests (Ref. Fig. Example of Main MENU SHEET 1) Nonetheless, in order to optimize the test function and better satisfy operator requirements, certain adaptations have been introduced:
Page 12 of 26
To limit system complexity and their BITE, the test function does not always fully cover complete system integrity.
When the part not covered by the test is a major component of the system the limitation of the test is listed under the test title. Furthermore, in the TSM with each maintenance message, the test or the procedure will be indicated making it possible to recheck the component on the ground To better manage the effect of the test on the system and its ground handling the test function may be divided into three groups: . BASIC TEST (OR SYSTEM TEST) . COMPLEMENTARY TEST . ADDITIONAL TEST. This makes it possible to have at least one test available at the terminal gate (the basic test) which is quick to start-up by a single technician, the other tests (complementary and additional tests) making it possible to increase the global coverage level of the tests where useful and possible. All these tests are run on the ground from the MCDU using, first of all, the CMC menu (SYSTEM REPORT/TEST) then the system MENU. * Basic test or system test There is always one basic test (or system test) per system. This test has no effect on the aircraft and does not require that any long or complex actions be performed by the operator. Consequently, this test may be initiated from the cockpit by a single operator whenever required during stopovers. This test is as complete and exhaustive as possible. Amongst other things, it runs the power up test or the most equivalent test. All faults present on ground and actually detected by the system in automatic mode will be analyzed and reported by this test. Furthermore, it must be run before any other test to check the integrity of the computer housing the BITE. This test is only accessible via key 2R of the main menu of the system displayed on the MCDU. It is called TEST if it is unique for this system or SYSTEM TEST when other tests are available for this system. * Complementary tests (Ref. Fig. Example of Caution SHEET 1) These tests affect the aircraft (and may require actions by the operator). In fact these tests send stimuli to various components such as actuators, valves, etc. For this reason, CAUTIONS are displayed on the MCDU before activation and confirmation of test actuation. The wording of the cautions is in fact simply a reminder of the consequences on the aircraft following test activation. In fact, the safety procedures associated with these tests are in the AMM. Consequently, normally these tests are not performed during a short stopover. These tests are only available via key 3R of the main menu of the system displayed on the MCDU. Test names are related to the tested parts. * Additional tests These are menu guided tests. The actions to be taken are displayed in plain language on the MCDU. (Description of the initial configuration, description of the actions, wording of the questions to which the operator must respond). For this purpose, the operator uses YES or NO keys displayed on the screen.
Page 13 of 26
These tests are available via key 4R of the main menu of the system displayed on the MCDU. Test names are related to the tested parts. 2 Presentation of the test pages All test pages are displayed in accordance with the same rules: - The name of the test is given in the title - To better identify operator actions required on the aircraft they are preceded by a dash - Certain information may require several pages. Each page is then numbered and the MCDU up/down arrow keys are used to run through the test - In certain cases, the system waits until the operator has performed an action to continue the test. Then there is a limited time out so as not to stop in this configuration when the monitored signals are blocked. This implies that the operator action must be performed before this time out (approximately 30 seconds). Some rules for test pages also apply to all manual mode pages. - A dash may be shown when data is not available. This does not necessarily mean that an effective failure is present. Only maintenance messages indicate possible failures - The prompt < or > associated with a function key may be absent when exceptionally the function is not available. In this case the test procedure given in the AMM shall be applied. 3 Initial aircraft configuration for test activation The general configuration of the aircraft for test activation is basically as follows: - aircraft on ground - engines stopped - all systems power supplied (ADIRS, FADEC may be off) - pushbutton switches and switches in normal configuration. If a test calls for a different configuration, this configuration will be displayed on the MCDU as an initial condition or during the test. To limit BITE complexity and to provide greater coherence between all tests, all these conditions are assumed to be correctly applied by the operator. Consequently, if a difference is detected by a system it is considered as a fault and therefore generates a maintenance message in the test results. In all cases, it is recommended to restart the tests indicating faults in the results to eliminate any possible disturbances or wrong initial conditions. 4 TEST IN PROGRESS When a test is run without any operator action being requested the TEST IN PROGRESS xxS is displayed on the MCDU. In this case, the time xx is the approximate duration of the test. It is possible that automatic re-run of certain disturbed sequences of this test extend this duration. Consequently, this value must be considered as general information. Nonetheless, it may be considered that in any case a result should be displayed in a time equal to approximately twice this duration. For certain simple systems operating slowly, the TEST IN PROGRESS page may take up to 30 seconds before being displayed. 5 Test results The result of a test is one of the following:
Page 14 of 26
The mention TEST OK: The test has not detected any faults The display of maintenance messages on the MCDU:
The test has detected at least one fault. In certain multiple fault cases, the test may only indicate the first fault encountered. In fact, certain faults prevent to run the test more extensively. Test re-running after repair of the fault is therefore always necessary to check whether there is another fault or not. Only the mention TEST OK is proof that the test has not detected any other faults. No response from the system to the test request or no results displayed: In this case, the test has not been completed. Return to initial condition is obtained by pressing the MCDU MENU key then CMC key and selecting the system again. If the same sequence reoccurs then the computer managing the BITE of the system or the wiring from the CMC must be the cause.
Test stop The < RETURN key is the only key to be used to stop a test in progress. In certain system test cases (only) it is not possible to stop the test. In this case, the RETURN key is absent.
Configuration resetting after a test The operator may be requested to reconfigure after a test if the initial conditions required by the test have had a significant effect on the aircraft (instructions are then displayed on the MCDU). If the operator wants to repeat the test he is not obliged to apply these instructions on configuration resetting.
Ground handling of the tests As maintenance messages are stored in the PFR or the GROUND REPORT they will not be erased until the next beginning of flight. Therefore, a test is a means of checking whether a fault is still present and a means of isolating a failed LRU. Activation of a test will be requested in the TSM by the fault location procedure related to a maintenance message. It will be used to confirm the presence of a fault or to eliminate any ambiguity. As a general rule, the test of the system including the LRU incriminated by the maintenance message (message ATA) will be activated. By default, the test of the system which generated the message (SOURCE) may be activated. The activation of a test may also be part of the removal/installation procedure of an LRU given in the AMM.
Dual access It is possible to activate the test in two systems simultaneously using two MCDUs. In this case, the message DUAL ACCESS IN PROGRESS is displayed at the bottom of the screen. Two cases may occur: - Dual access is requested by a procedure displayed on the MCDU: in this case, the test results are reliable (no disturbance due to dual access as the procedure forecasted it) - Dual access is decided by the operator:
Page 15 of 26
In this case: * if the indication TEST OK is displayed on the MCDUs, the tests have not effectively detected a fault * if maintenance messages are displayed they must be confirmed by re-running the test in single access (possible disturbances in dual access not scheduled). (c) 3rd group 1 AVIONICS STATUS This function displays the identity of the systems detecting a class 1 or 2 internal or external fault when the function is called. The AVIONICS STATUS thus rapidly provides a global overview of the status of all systems. It is a simple to use monitoring device providing direct access to system menus which detect a fault (for example, flag displayed on the PFD). Also, after aircraft power up, it makes it possible to check that all computers have correctly satisfied the related power up tests. In order to know the reason for which a system is displayed in the AVIONICS STATUS it is recommended to get access to the system menu and to activate the system test (or test). NOTE: Certain systems are listed in the AVIONICS STATUS due to normal absence of a ground power supply. Therefore, it is recommended to supply all systems prior to gaining access to the AVIONICS STATUS. It shall be noted that when a computer is not supplied it is not directly displayed in the AVIONICS STATUS as it no longer detects, itself, this fault. Therefore, it is the systems which read the signals of this computer which will appear in the AVIONICS STATUS. 2 GROUND REPORT (LAST LEG/GROUND (GND) REPORT) This function displays on ground the class 1, 2 and 3 internal maintenance messages related to new faults detected on ground and which are therefore not recorded in the PFR. The faults detected during flight and which remain present on ground are in the PFR and not in the ground report. This function presents the history of these faults since the aircraft landed up to the next takeoff. Consequently, the ground report maintenance message of a fault which has been repaired will still be present in the ground report up to the next takeoff. Consequently, the ground report has the same usefulness as a PFR but concerns new faults detected on ground since the last flight (as defined by the CMC). The faults detected on ground prior to the last flight may be found in the PFR. However, it is necessary to confirm all faults of the ground report by activating a test or a procedure described in the TSM. NOTE: Case relating to Type 2 systems: This function is in the LAST LEG/GROUND REPORT section specific to type 2 systems. The messages in this section concern faults detected during flight and on ground, the wording GND preceding the list of messages related to the faults detected on the ground in accordance with the same ground report logic as for type 1 systems. Case relating to Type 3 systems: There is no ground report function for Type 3 systems. The test function shall be used in this case.
Page 16 of 26
3 SPECIFIC DATA (Optional)
(Ref. Fig. Example of SPECIFIC DATA SHEET 1) As an aid to trouble shooting, it may be advantageous for certain systems to display information specific to these systems. This information will be displayed in sections specific to each system. Access is possible via key 5L of the system main menu. Use of these sections is closely related to the system involved and is not a general rule. Furthermore, it is described in the TSM procedures. 4 GROUND SCANNING The GROUND SCANNING enables fault trouble shooting based on ground activation by the operator himself of functions normally performed during a flight. The advantage of this is that it is not restrictive as far as actions are concerned. In fact, the operator decides what type of actions to be performed on the system, which is in GROUND SCANNING, as a function of the problems to be processed. This action may include dynamic phases (for example: engine startup, flight control surface movement, etc.). This is also an aid in trouble shooting faults difficult to resolve. All maintenance messages (class 1, 2 and 3, internal and external) related to all faults detected in real time by the system will be displayed during the GROUND SCANNING. In order to indicate a transient fault source to the operator, the maintenance messages, automatically displayed in GROUND SCANNING, are only erased when exiting from the function. Furthermore, GROUND SCANNING must always be preceded by a system test in order to identify the possible static faults. The use of this function may also be requested by the TSM procedures. 5 LAST LEG REPORT This section presents a portion of the information given in the PFR. This is a simplified backup of the printed PFR or PFR displayed on the MCDU by the CMC. NOTE: For information purposes, the messages generated by the identifiers are accessible in the last leg report of these identifiers. The user who wants to use these messages must do so carefully as the information involved is non-correlated and non-priority information. (d) 4th group 1 PREVIOUS FLIGHT REPORT The purpose of the PREVIOUS FLIGHT REPORT section is to display, on ground, the maintenance and warning messages concerning all systems which occurred during the previous flight, with a limit of 64 flights. It is the memorization of the previous 64 PFRs. The PREVIOUS FLIGHT REPORT will be used when fault history is useful. For example, in the case of faults declared intermittently but repeatedly during several consecutive flights. 2 PREVIOUS LEGS REPORT The PREVIOUS LEGS REPORT function is the history of the LAST LEG REPORT limited to 64 flights. Therefore, it is displayed with the same restrictions.
Page 17 of 26
3 TROUBLE SHOOTING DATA
In most cases, this concerns primary and coded data. The purpose is to supply additional information on conditions prevailing when the maintenance message was generated. In general, these data are read in the case of events which do not result from effective part failure, already covered by the replacement of the failed part. Therefore, these are maintenance messages qualified as being intermittent in the PFR which may entail the reading of the TROUBLE SHOOTING DATA. Analysis of this data will be effectively useful in the study which may enable the identification of the cause of an event. If certain trouble shooting data are required for fault trouble shooting, data readout will be requested by a TSM procedure. Wherever possible, these data will be displayed decoded on the MCDU. 4 LRU IDENTIFICATION The purpose of this section is to display on ground the part numbers of computers of the selected system and possibly their serial numbers. This section may be consulted to check the interrogated computer standard. This is a configuration management aid. (e) 5th group 1 CLASS 3 REPORT On request from the operator the class 3 (internal and external) maintenance messages of all systems related to the CMC are displayed. These messages have been grouped in a single section. These messages do not appear in the PFR. When this section is used it is necessary to test the LRUs involved before replacing them. The detailed ground handling procedure related to this function is given in the AMM. 2 CLASS 3 FAULT All class 3 (internal and external) maintenance messages corresponding to the selected system are grouped under this section. This function enables a quick access to the class 3 messages of a given system. (f) Summary of the functions Summary of the functions available in ground menu mode (Manual Mode). ---------------------------------------------------------------------! HISTORY DATA ! REAL TIME ! ------------------------------------------------------------------------------! CMC ! - POST FLIGHT REPORT ! - AVIONICS STATUS (at activation) ! ! driven ! - PREVIOUS FLIGHT REPORT ! ! ! ! - CLASS 3 REPORT ! ! -------------------------------------------------------------------------------
Page 18 of 26
! ! - LAST LEG REPORT ! - TEST (all) ! ! SYSTEM ! - PREVIOUS LEGS REPORT ! - GROUND SCANNING ! ! driven ! - GROUND REPORT ! - SPECIFIC DATA (in some cases ! ! ! - CLASS 3 FAULT ! specific data are history data) ! ! ! - TROUBLE SHOOTING DATA ! - LRU IDENTIFICATION ! -------------------------------------------------------------------------------
Page 19 of 26
CMC
ARINC BUS
F_TS_000000_0_AEM0_01_00
** ON A/C ALL
Page 20 of 26
1st ENGINE START PLUS 3 MN PLUS FLIGHT PLAN INITIALISATION CAS: 80kts
TOUCH DOWN
ENGINES SHUT DOWN
80kts PLUS 30s
GND 1 AND 3
FLIGHT
GND
AUTOMATIC
GND
FLIGHT
GND
F_TS_000000_0_AGN0_01_00
** ON A/C ALL
Page 21 of 26
A/C IDENT FLT NBR FROM/TO START/END
F-WWCA JAN02 V00002 LFB0/CYYZ 0900/1500 UTC FLIGHT PHASE
MAINTENANCE POST FLIGHT REPORT LEG 00
CMC1 PRINTING DATE JAN02
03 COCKPIT EFFECTS
05 FAULTS ATA 212500 SOURCE AEVC
VENT PACK BAY VENT FAULT
ENGINE START
PRESS SW (2HR) PACK BAY VENT CIRCUIT/AEVC (2HQ) SOURCE FCMC1 FUEL CTR TK PUMP2 (600QL2) /FCMC1 (5QM1) ATA 313352 CLASS 2 SOURCE DFDRS
ATA 2826 FUEL CTR TO INNER FAULT
0935 CRUISE 06
MAINTENANCE STATUS
CRUISE 06
QAR TAPE LOW (3TU)
ATA 261600 CRUISE 06 LDCC SMK DET DISABLED
SOURCE SDCU
SOURCE SFCC-S2 ROLLOUT 08 INTERMITTENT SLT2 B HYD PRESS OFF
ATA 282754 ROLLOUT 08 INTERMITTENT FUEL AFT XFR VALVE1 (700Q N1)/FCMC2 (5QM2)
SOURCE FCMC2
END OF REPORT F_TS_000000_0_ALM0_01_00
** ON A/C ALL
Page 22 of 26
WARNING :INDEPENDENT MAINTENANCE MESSAGE :EXTERNAL
WARNING :PRIMARY MAINTENANCE MESSAGE :EXTERNAL
F_TS_000000_0_ANM0_01_00
** ON A/C ALL
Page 23 of 26
F_TS_000000_0_AQM0_01_00
** ON A/C ALL
Page 24 of 26
F_TS_000000_0_ASM0_01_00
** ON A/C ALL
Page 25 of 26
F_TS_000000_0_AUM0_01_00
** ON A/C ALL
Page 26 of 26

How To Use TSM

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

How To Use TSM

Caricato da

Copyright:

Formati disponibili

Customer : GFA Type : A330 Rev.

Date : Jul 01/11 How to Use the CMS

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

ENGINES SHUT DOWN

80kts PLUS 30s

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

A/C IDENT FLT NBR FROM/TO START/END

F-WWCA JAN02 V00002 LFB0/CYYZ 0900/1500 UTC FLIGHT PHASE

MAINTENANCE POST FLIGHT REPORT LEG 00

CMC1 PRINTING DATE JAN02

05 FAULTS ATA 212500 SOURCE AEVC

VENT PACK BAY VENT FAULT

ATA 2826 FUEL CTR TO INNER FAULT

QAR TAPE LOW (3TU)

ATA 261600 CRUISE 06 LDCC SMK DET DISABLED

SOURCE SFCC-S2 ROLLOUT 08 INTERMITTENT SLT2 B HYD PRESS OFF

END OF REPORT F_TS_000000_0_ALM0_01_00

Print Date: Nov 29/11 Local Time

Manual: TSM Selected effectivity: ALL

WARNING :INDEPENDENT MAINTENANCE MESSAGE :EXTERNAL

WARNING :INDEPENDENT MAINTENANCE MESSAGE :EXTERNAL

WARNING :PRIMARY MAINTENANCE MESSAGE :EXTERNAL