Enhancing off-line and on-line condition monitoring and fault diagnosis

Pergamon

0967-0661 (95)00162-X

ControlEng. Practice, Vol. 3, No. t l , pp. 1515-1528, 1995 Copyright © 1995 Elsevier Science Ltd

Printed in Great Britain. All fights reserved 0967-0661/95 $9.50 + 0.00

ENHANCING OFF-LINE AND ON-LINE CONDITION MONITORING AND FAULT DIAGNOSIS

R.A. Vingerhoeds*, P. Janssens**, B.D. Netten* and M. Aznar Ferndndez-Montesinos*

*Delft University of Technology, Faculty of Technical Mathematics and lnformatics, Julianalaan 132, 2628 BL Delft, The Netherlands

**Performance Engineering Department, Sabena, Brussels National Airport, 1930 Zaventem, Belgium

(Received March 1995; in final form September 1995)

Abstract: This paper describes the use of artificial intelligence technology to enhance off- line and on-line condition monitoring and fault diagnosis and to integrate these two developments into a closed-loop diagnostic tool for complex systems in modem transportation. Two developments are presented here, which were verified in industrial diagnostic problems; on-line fault diagnosis for trains, and off-line aircraft Engine Condition Monitoring (ECM). Case-based reasoning (CBR) is used to incorporate the knowledge and experience of both train manufacturers and railway companies for on-line train fault diagnosis. The size of the diagnostic problem is such that explicit formulation of fault-trees is almost impossible. CBR facilitates the automatic generation, consistency checking and maintenance of the fault-trees. Additional measures have been taken to meet the real-time requirements for on-line use of a CBR-based diagnostic system. A balanced combination of neural networks and expert-system techniques is used to ensure more consistent off-line ECM. The information, such as trends from in-flight measured aircraft and engine parameters, crew trouble reports, maintenance and findings from accessory repair shops, can be incorporated to assess the engine's state of health, and to deduce appropriate preventative or corrective actions.

Keywords: condition monitoring, fault diagnosis, neural networks, expert systems, case- based reasoning.

1. INTRODUCTION

Operating a modern technical system, such as a train or aircraft, calls for good organised engineering, operation and maintenance to keep the system in an optimal operational condition (see Fig. 1). Preventative maintenance is preferred over corrective maintenance. After all, an aircraft that encounters technical problems in service leads to delays or even flight cancellations, as extensive repair actions, such as the replacement of

components, keep the aircraft on the ground and out of service. The importance of preventative and well- timed corrective maintenance, of course, applies to all technical systems, and in this paper two application areas will be described: electronic train systems and aircraft engines.

The safe and efficient operation and maintenance of such modem technical systems involve several on- line and off-line diagnostic tasks. The operational diagnostic tasks could involve alarm handling,

1515

1516 R.A. Vingerhoeds et al.

trouble-shooting for corrective actions, dispatching or traffic control. These tasks have to be performed on-line by crews, respecting strict real-time requirements. Off-line diagnostic tasks involve the handling of recorded data, condition monitoring, and organised corrective and preventative maintenance. The information gathered during operation, such as that from crew reports and data recordings, are vital sources of input for off-line diagnostic tasks. The information about both operation and maintenance is then used by the engineering departments for the software maintenance of both the off- and on-line diagnostic systems.

procedural reasoning about and explanation of witnessed events and examples, and the generation of reports and warnings.

Rule-based reasoning expert systems are already being applied in many tasks whenever the domain knowledge can be explicitly specified, such as for rules of thumb (e.g. see (Vingerhoeds, et al., 1992)). If domain knowledge is too complex or extensive to declare explicitly, or is not known at all, other techniques have to be applied. Typically, the implicit domain knowledge can be obtained from historical examples and experience by pattern recognition or classification.

)" f Maintenance 1 Operation )- q~

Fig. 1. Three important aspects for safe operation.

In reai-life diagnostic systems, the complex explicit relations between detectable conditions and possible causes can be avoided by using case-based reasoning in the development of diagnostic systems. However, case-based reasoning systems tend to be very slow. In the first application, special measures are described to build on-line train-diagnostic systems automatically for different diagnostic tasks from a unique knowledge base.

Each diagnostic task has specific goals, decision strategy, input and output information, but all concern the same technical (sub)system and should therefore comprise similar domain knowledge. Ideally, the knowledge in each task is consistent with every other task, but as systems are usually developed separately, tremendous additional efforts are required to obtain and maintain some degree of consistency. The lack of consistency and integration between operational and maintenance diagnostic systems is a major reason for inefficiency in exploitation. In the two applications presented here, the aim was to develop software tools for which the initial domain knowledge and the knowledge gathered during operation can be used directly for multiple-diagnosis tasks.

Condition monitoring provides a vital source of information for maintaining a healthy operational status. The main objective is to recognise patterns in time series of monitored data and to classify these patterns as known conditions. This process requires great skill and experience from the expert, which are almost impossible to declare explicitly. Whenever the condition of a technical system is identified, consequences and further actions can be explicitly specified. In the second application, an artificial neural network surrounded by an expert-system structure is used for the off-line aircraft engine condition monitoring. Future use of this neural network based condition-monitoring system, in combination with a case-based diagnosis system in an integrated environment, will be outlined.

In the technical world, many still see artificial intelligence (AI) as a variety of techniques used for a wide range of academic or smaller practical applications, without any apparent coherence between the application domain' and the techniques used. It is almost impossible to model any real-life application by using only one single technique, and it is only recently that hybrid artificial intelligence systems have been receiving more attention. As each artificial intelligence technique has its own characteristic advantages concerning the availability of knowledge, knowledge representation, learning capabilities, etc., a technique should be selected to best fit a given task. No AI technique, however, can be expected to replace a human expert entirely, and they should always be used as a supporting tool, handling the more routine tasks more consistently than the expert. Typical routine tasks are non-

It should be noted that artificial intelligence will not be used to perform the monitoring tasks autonomously, but as a supporting tool handling the more routine tasks of the monitoring process on a fully consistent basis, such as non-procedural reasoning about witnessed patterns, reasoning about examples, generating reports and advice.

In this paper the off-line and on-line condition monitoring and fault diagnostic systems developed will be discussed. The design considerations will be explained, as well as the working principles of the systems. Illustrations using some initial results show that both approaches are well-founded and promising. Incorporating artificial-intelligence techniques for monitoring and fault-diagnostic activities will lead in the near future to an important diagnostic tool.

Off-Line and On-Line Condition Monitoring 1517

2. ON-LINE FAULT DIAGNOSIS FOR MODERN TRAINS

A major problem in maintaining regular train services concerns on-line reaction to failure messages. These failures do not only give rise to a technical problem to be solved, but can cause an operational problem as well. A balanced time-schedule must be maintained as closely as possible. The problems which occur may necessitate the quick repair of faults, moving scheduled maintenance to an earlier date, or even to replacing a train in more severe cases.

On modem trains, electronic failure-detection devices are installed to generate symptom-codes whenever a component or subsystem failure is detected. These symptoms are presented to the driver, monitoring systems and data recorders via an electronic on-board network. The problem is such that a failure may be caused by more than one actual fault, while a fault can also be identified using many symptoms and test results (see Fig. 2). The actual fault(s) which occur can only be detected by deduction from other symptoms and the results of additional tests.

may result in

if detected then generate

(symptom 1} ~ymptom 2} (symptom 3} i

Fig. 2. Relations between faults, failures, symptoms and tests

The relations between symptoms and test results on one hand and the actual faults on the other hand can be very difficult to understand for the users, the manufacturers and even the diagnostic experts. These relations are, however, very important for safe and efficient operation and maintenance, since from the generated symptom codes an intervention, such as a repair action, must be determined. The first aim is to maintain the operational schedule as closely as possible. The second aim is to infer changes in the maintenance schedules as a result of the faults which have occurred. As such, four main diagnostic tasks can be identified: off- and on-board trouble-shooting for immediate repair actions, dispatching and detailed (scheduled) maintenance.

On-line trouble-shooting. The key issue for the driver, when a symptom occurs, is to know what effect this symptom can have on the safety and functionality of the train. The diagnostic system for on-line trouble-shooting should enable quick and reliable fault diagnosis for the symptoms which occur. The highest alarm level for the current status of diagnosis should always be signalled to the driver. In time-critical situations only the most relevant tests can be performed to further determine the alarm level and the actions to be taken. The actions that can be taken during operation are limited, and may be different from maintenance tests. Therefore, it is not strictly necessary to identify the exact fault uniquely, but only the actions that can be taken during operation.

Dispatching. Whenever a symptom cannot be identified explicitly during operation, and the safety or functionality of normal operation is severely affected, the dispatching centre should be informed. In the first instance, the dispatcher has to decide on the severity of the incoming error message, the implications for the schedule and the actions to be taken for dispatching, such as re-routing. To make a decision on maintaining a train schedule, based on the functionality and safety requirements and the intensity of the traffic flow, only knowledge about the actual functionality and safety of the train is needed.

Off-board trouble-shooting. The information resulting from trouble-shooting during operation can be used to direct maintenance personnel, as well as to allocate spare parts. At the next stop, mechanics will continue fault diagnosis to further identify the faults and determine repair actions. Therefore, it is important that all information is recorded during operation for further off-line diagnosis.

Maintenance. Information from operation and trouble- shooting forms an essential input for the extensive diagnosis of unresolved problems. More detailed tests can be performed than during operation, and other tests can be simulated that can normally be performed only during operation (Johnson, 1994). During maintenance, the history of a certain train or system can also be consulted. Solving the remaining unresolved problems should lead to updates for the off- and on-board diagnostic systems. When replacing a subsystem or component, the historical database can be simultaneously updated.

The typical size of the technical diagnostic problem, in terms of the number of symptoms, faults and possible interventions in all diagnostic systems, increases rapidly with the number and complexity of on-board systems. For modem aircraft, this can be in the order of about 11,000 faults (Johnson, 1994). Diagnostic systems of this size ask for a special- purpose approach to allow for a quick interaction time between diagnostic system and user.


Usually, separate diagnostic systems are developed for each of the above mentioned tasks, and although the goals and requirements for each task are different, they all concern the same technical system. All these diagnostic systems should contain similar domain knowledge in any form of knowledge representation, such as historical examples, explicit relations and fault descriptions. It is preferable to construct all diagnostic systems from the same input files, using the same knowledge representation. If all the knowledge for all the diagnostic systems is contained in a unique knowledge base, the level of detail for each system determines the subset of this knowledge base. In this section, a generic approach for building different diagnostic systems for the same technical system will be described. An initial implementation of this work for trouble-shooting and maintenance in modern trains was reported by Raaphorst, et al. (1995). Similar diagnostic problems can be found for modern civil aircraft (see, for example (Johnson, 1994; Virilli, 1994; Magaldi, 1994)).

2.1 Current Fault-Diagnosis Systems.

For modern fault-diagnosis systems, faults have to be specified explicitly in terms of their resulting symptoms and test results (facts) as well as the relations between those facts. These facts can be explicitly arranged accx~ding to the specified relations in the form of a fault-tree. Usually, a fault-tree is constructed from individual sub-trees for symptoms and sub-systems. During the diagnostic task itself, use is made of tree- search methods.

Due to the complexity of modern technical systems, together with the number of on-board systems they include, the typical size of their diagnostic problems is increased to such an extent that for fault-tree-based diagnostic systems the following problems can be identified:

Different diagnostic tasks. The objectives, the series of tests that can be performed, and the actions that can be taken may be different for every diagnostic task. In practice, for each diagnostic task a separate system has to be developed. For each diagnostic system, a dedicated strategy should be deduced, from which a specific fault- tree should be derived.

Diagnostic strategy. When a fault occurs, several symptoms may arise over a short period of time. The driver tends to focus on the symptom with the highest possible alarm level, and follows the sequential order of tests as specified by the corresponding sub-tree. The efficiency of diagnosis depends on the ordering of the tests in the fault-tree. The more decisive tests should be placed higher up in the tree. For each diagnostic task, only tests that can be performed in the given situation should be invoked.

Known information remains unused. The other symptoms and test results in a classic fault-tree that are already known and are related to a particular fault, remain unused until they appear in a node in the fault-tree being evaluated. Much valuable time is lost because not all the available information is directly used to evaluate parts of sub-trees.

Induction. If, in a certain situation, the information required for a node is not known, all other subsequent branches of the fault-tree have to be evaluated to determine the actual fault. This requires advanced tree-search techniques and search time.

UncertainW in fault descriptions. The behaviour and reliability of system components cannot always be precisely specified for large real-world applications. The occurrence of symptoms and the outcome of tests cannot be assigned with 100 % probability for each fault. In practice, these probabilities should be estimated by a human expert (Raaphorst, et al., 1995).

Explicit definition of all facts and relations. It is almost impossible for human experts to explicitly define all facts and their relations consistently. The exact definition of tests and actions is very important, to be able to dearly distinguish individual faults.

Generation, verification and maintenance of the fault- tree. It is also almost impossible for human experts to generate, verify and maintain a complete and consistent fault-tree of this size. With visualisation tools, sub-trees may be presented per symptom, sub-system and per diagnosis task. Within a sub-tree, nodes with multiple faults or missing branches may indicate the necessity for additional tests, or that faults are incorrectly specified. Due to the inherent structure of a fault-tree, duplications of parts of branches are very difficult to detect, while any modification has to be specified explicitly in every related sub-tree.

2.2. Motivations for Using Expert Systems for On- Line Diagnosis

Artificial intelligence techniques have been applied successfully in several technical applications, such as operator assistance, fault monitoring and diagnosis. Rule-based expert-system techniques are applied most frequently, and make use of explicit relations between symptoms, test results and faults. These relations should be declared explicitly in the form of "if-then" rules, and each rule can be regarded as a node in the fault-tree. The input relations of a node in a fault-tree can be declared by the antecedent part of the rule, and the output of the node results from the consequent part of the rule. The antecedent evaluates the presence of symptoms or test results. The consequent part holds the conclusion on the state of the symptoms, test results and actions to be taken.


To define a fault-tree, human experts are forced to reason in a top-down manner, i.e. from a symptom down to each related fault. The strategy for diagnosis has to be specified for each symptom by the order in which the tests are to be performed to identify a fault. In this approach, the human expert has to perfom~ the most difficult reasoning process: explicit declaration of all faults satisfying some set of conditions. Reasoning top-down from symptoms to faults is complicated, as a fault may affect many sub-systems and components. The human expert has to maintain the overview of the complexity of the technical systems. The facts in the form of symptoms and test results are well defined, while the relations between these facts and the faults are not well known. Using top-down reasoning, the human expert is forced to define these poorly known relations explicitly, starting from the well-known facts. Using rule-based reasoning has the advantage that the relations can be declared individually, and the positioning of the relations with respect to each other is achieved automatically in a network. Most rule-based reasoning shells use the Rete algorithm (Forgy, 1982) to position the rules in a network. The Rete network performs the function of a fault-tree, but has an essentially different structure from that of a tree (see later).

Bottom-up reasoning offers an interesting alternative to top-down reasoning, as it requires the problem specification from the opposite side. The facts are well defined during the development of the technical systems. The human expert has only to specify the faults in terms of the probability of occurrence of these well- defined facts. The relations between facts and faults are implicitly specified in these fault descriptions. These relations are not very complicated, but follow strict rules:

1. Each fault is related to each of its symptoms and test results (with a specified probability).

2. The ordering of these relations is determined by a general diagnostic strategy, which can be specified generically for each diagnostic task.

These relations can be derived by a generic and automated procedure. From the view point of software development and maintenance, the required problem specification is unique and easily interpretable by the human expert. The relations do not have to be specified and the known faults can be regarded as individual cases.

2.3. Case-Based Reasoning Approach for Diagnosis System Design

Case-Based Reasoning (CBR) (e.g. see (Riesbeck and Schank, 1992; Aarnodt and Plaza, 1994)) is an artificial intelligence technique that uses implicit knowledge

from previous experience to guide the problem solving. In contrast to rule-based reasoning, CBR can be used when the relations between facts cannot be declared explicitly. The inherent relations that describe the derivation of a solution for a given problem definition are not specified. Each known fault can be described as a historical fault case in terms of probable symptoms and test results as its characteristic features, and is collected in the so-called case-base. During fault diagnosis, all symptoms and test results which have occurred are matched against the features of the known faults in the case-base. The best matching faults are selected, and their interventions retrieved.

The approach presented here for fault-tree generation and on-line fault diagnosis makes use of case-based reasoning techniques, tailored in such a way that the response time for each diagnostic system is minimised. Matching and retrieving the cases from a database would be computationally too time-consuming for on- line diagnosis. To avoid extensive database queries, a fault-network is first built off-line from the cases, and only this network is used during the on-line diagnosis process itself (see Fig. 3).

Fig. 3. Off-line generation of a fault network.

A textual case description of the symptoms, tests and results is only necessary to inform the user during development or diagnosis. This information should therefore be contained in databases for the man- machine interfaces. Within the actual on-line diagnostic systems, the cases, symptoms, test results and actions are only referenced by indices. The fault network developed resembles the Rete network (see (Raaphorst, et al., 1995)). Some additional node-types are added to this structure to account for uncertain information of fault descriptions. The top layer of the network consists of all input nodes for the symptoms and tests. In the next layers, nodes are built for each combination of symptoms and results, in such a way that each combination is built only once in the network. The bottom layer consists of nodes with reference to the individual faults. Building such a fault network has several major advantages over other diagnostic systems:

The structure of the network is smaller. Each test result and each symptom appear only once in the network as input nodes. Combinations of test results and/or symptoms are searched for in the case-base, and each combination is also represented by only one node. As described in (Raaphorst, et al., 1995), the resulting network is very wide but shallow, and smaller than a fault-tree.


Efficiency of the data-driven network. A high efficiency is realised by making optimal use of the fact that the results of a new test only lead to limited modifications in the network. As in the Rete network, values are propagated from the input node downwards through the entire network. In every cycle, the current status of all nodes is maintained, and only modifications of the inputs are propagated through the network. Matches that have changed and that are no longer valid, are made inactive for further inference.

Simultaneous diagnosis of multiple symptoms. The relations of sub-trees for specific symptoms in the former fault-trees are now merged into one network, allowing for the simultaneous treatment of multiple symptoms. In fact, all initially available information about symptoms and test results should be presented at the initialisation of a network. This information will immediately be propagated through the network, and the actual state of the fault diagnosis is immediately obtained.

Diagnostic strategy inhibited in the network. As the objective of each diagnostic task is different, the order in which tests should be executed and actions taken is different as well. From these objectives, general rules for the diagnostic strategy can be derived, and should be applied during diagnosis. As functions of activated symptoms, results of previously performed tests and probabilities of test results, intermediate conclusions can be drawn for the faults that might have occurred, and a next step can be initiated. As with fault-trees, the strategy should be used to determine the inference process, which in turn is determined by the network structure and the node indices. In an off-line procedure, these indices can be assigned for each diagnostic task separately, according to the rules of the specific strategy. For on-line diagnosis, the appropriate strategy is maintained by simply following the threads through the activated nodes.

Non-procedural order. In contrast to fault-trees, the nodes on the threads are not addressed in a procedural order. As any input is immediately propagated to any node in the network, the remaining nodes in the active threads with unknown inputs are detected, and the related tests are suggested to the user.

Computer memory can be reduced. For on-line diagnosis, only the network structure is loaded into memory as a set of pointers between the nodes. During diagnosis, limited node information is added to the memory. A Boolean specifies the validity of a node, and an integer-array is maintained to count the number of executed tests within each probability level (Raaphorst, et al., 1995).

Reduced search time. The response time for diagnosis is reduced in several ways with respect to fault-trees:

• The structure to be searched is smaller. • All cases satisfying a relation are treated in one

operation within one node. • The diagnostic strategy is inhibited in the network

structure to avoid large additional computations or queries to determine the next step.

• The diagnostic process itself is not hindered by time-consuming string operations. The network itself contains no textual information, only pointers, integers and Booleans.

Consistency checking. Faults with identical descriptions are found in the same end-nodes of the network and can be easily detected. To make a distinction between these faults, an expert can be prompted to specify additional questions. Input nodes that have no further links downwards either represent default answers to questions, or indicate that faults are not completely specified in the case- base (or have not been defined at all).

Incorporation of new experience. New experiences of operators and the train manufacturers can be incorporated as new faults in the case-base as they become available. This information is then immediately available for all diagnostic systems.

2.4. Building Off-Line Diagnostic Systems

As was explained earlier, for each different diagnostic task a different network has to be constructed. Using the approach presented here, this can be done automatically from one single case-base. The unique fault descriptions in the case-base include all the information for all individual diagnostic tasks.

For each case the mode of operation in which the fault may occur has to be specified, together with the corresponding alarm level. All features must be specified with a level expressing the probability that the symptom or test result will occur whenever the fault arises. In a separate file, tests have to be specified, together with a description of all possible results. The test specification further includes a description of how a test should be performed, what tools are required, during which modes of operation these tests can be performed, and when these tests can be suggested by the system. In a second file, actions are specified that can be taken during operation, traffic control, trouble-shooting and scheduled maintenance. In a third file, a textual description has to be given for each symptom code and the technical sub-system it belongs to.


The diagnosis systems can be extended in a modular manner. A new on-board (sub-)system can be included as a set of new cases. After re-generation of a network, the new (sub-)system is automatically included and the diagnostic system immediately has access to the new knowledge.

2.5. Performance results of the fault network

The measurements were performed on a PC-486 using a 33 MHz clock. In Fig. 4, the highest measured response times from the test case-bases are depicted as a solid line. The dotted line indicates that the response time increases less than linearly with the number of faults, while the number of facts for the faults remains equal. Extrapolation indicates a response time less than 1.6 seconds per 1000 faults in these case-bases.

An indication of the performance of the fault network for on-line diagnosis can be derived from response-time measurements during the development of several test case-bases. The size of the case-bases increased during these tests and ranged from 50 to 800 fault cases. Each fault case consisted of a number of symptoms and one additional test result• The number of symptoms varies with each fault, ranging from 1 to 10, while the average number of facts in a fault case remained about 6.5. The total number of symptoms rose up to 100. The constant average number of facts implies that the number of node levels in the fault network remained about constant for all case-bases, while the total number of faults and symptoms rose•

2.6. Future Expansion for On-Line Fault Diagnosis

Future developments are foreseen in four different areas"

Handling unknown faults• When a fault occurs that has not been specified in the case-base, several similar cases will partially match. General rules can be specified to deduce appropriate actions from the actions as specified for the partially matched cases. These rules provide the modification function as described in case-based reasoning literature. At this moment, the user may deduce the proper actions, or leave the cases unresolved until maintenance.

After the generation and loading of the network in internal computer memory, the response time was measured between the manual input of an initial symptom and the prompting for the occurrence of a next symptom or to perform a test. During this time, the diagnostic system:

Improving software maintenance. The first aim of this work has been to facilitate the representation of diagnostic problems, thereby avoiding the explicit creation of a fault tree by a human expert. It is planned to further improve maintenance tools for the case-base and operation of the system.

1. propagates the initial symptom through the fault network,

2. determines the relevance of the input to fault cases ,

3. determines the most relevant test or symptom to be prompted to the user next, according to the search strategy, and

4. retrieves the text string to be prompted.

max. response time [sec]

. ° .

15 '"

1 .0- ~ "

0 .5 -

! ! | 0 200 400 600 8~0 1 0 ~

number of faults in the case-base

Fig. 4 Maximum response times for the fault network

Speed-Up. For both the off-line generation of the fault network and the on-line reasoning, drastic speed-ups are investigated• The on-line reasoning process can be accelerated by incorporating explicit and well-known relations (rules) between symptoms and faults if they exist. The rules can be included in the network as short-cuts and can by-pass the network generated for the case-base. If the solution in the rule appears incorrect, the remainder of the network can be evaluated normally for other cases. The availability of explicitly known rules can be very useful during the off-line generation of the network as well.

Learning new cases. In the case-based reasoning concept, several techniques for automated learning can be implemented such as automatically adding new cases when they are found during operation. Once knowledge becomes available to modify actions, a new fault-case can be automatically included in the network. Before modification of the case-base or network, confirmation should be asked from human experts.


3. ENHANCING AIRCRAFT ENGINE CONDITION MONITORING

Operating a modern airline calls for good organised maintenance to keep the fleet of aircraft in an optimal operational condition. A very important aspect of maintenance concerns the aircraft engines. To have a regular overview of the proper functioning of the engines, Engine Condition Monitoring (ECM) is applied.

Engine condition monitoring is the process of assessing the state of health of aircraft engines off- line. Modern ECM is performed with the aid of an ECM system, using in-flight measured aircraft and engine parameters to determine the performance of the engines. Performance trend analysis software products form the backbone of modem ECM. They visualise the evolution in time or so-called trends of the most important engine parameters, and maintain a database of the engine parameters during its on- wing life.

Deterioration of engine modules, failure, malfunctions of engine control systems or of aircraft systems which affect the engine's operation, are announced by parameter trend evolutions, prior to the occurrence of incidents. Trend analysis allows one to anticipate incidents by determining the need for maintenance, and detecting the components or systems where maintenance is required (Janssens, 1994).

This kind of support for on-condition maintenance has an enormous impact on the profit of a fleet of aircraft, and as such plays an important role in the day-to-day business of a modem airline. Performance trend analysis programs assist the performance engineers in engineering departments in detecting problems, but leave them to interpret the data and to deduce conclusions, including possible preventative or corrective actions. This task consists, amongst others, of a pattern evaluation and recognition process of the performance trend, and requires extensive knowledge and experience.

Here, a first step to enhance current aircraft off-line ECM is presented, thereby making extensive use of artificial intelligence techniques. A neural network will be used to determine whether the engine is in good state of health or not, and will indicate a possible problem. Expert systems will operate in conjunction, as a surrounding system to control the network, to interpret its output and to generate reports for the performance engineer so he can give well-motivated advice. The general goal of the work is:

Ensuring more consistent engine condition monitoring.

3.1 Aircraft Engine Condition Monitoring.

Engine condition monitoring consists of a wide range of activities where the health of the aircraft engines is assessed and followed up in time from the moment the engine is put on-wing until its removal. This allows one either to anticipate incidents and to avoid them, or to evaluate the effects of incidents by stipulating maintenance verifications and actions or, in normal engine operation, to provide a guarantee that there is no indication or announcement for problems with an engine during the next few flights. Finally, when an engine gets to a state where its performance level has deteriorated to the point where it can no longer be operated within the regulatory limits, ECM allows precise planning of its removal.

ECM also aims at maximising the engine's operational life through determining and predicting malfunctions and/or deterioration of engine systems or aircraft-related systems which affect the engine's operation. Through well-directed maintenance actions, the engine is not only kept in its optimum operational condition, within close limits, but is also corrected at an early stage if changes are detected. In this way, ECM supports effective on-condition maintenance and offers a way of reducing fuel consumption, enhancing safety and increasing operational punctuality.

Turbofan Engines. In this work the engine studied was the CFM56-3 engine, used to power the Boeing 737-300's, -400's and -500's operated by Sabena. The prime task of an aircraft engine is to produce thrust to propel the aircraft, by accelerating a mass flow in the opposite direction to the direction of the aircraft. In a CFMI turbofan engine, this is accomplished by means of a dual rotor assembly. The CFM56-3 low-pressure spool runs with fan speed (N1), and has a single-stage fan and a three- stage booster driven by a four-stage low-pressure turbine. The core or high-pressure spool runs with speed (N2), and has a nine-stage high-pressure compressor driven by a single-stage high-pressure turbine. The rotors and their shafts spin at very high speeds to limit the size and weight of the engine. A more in-depth discussion on the working of turbofan engines is given by Kerrebrock (1992).

Assessing the Engine's State of Health. A great variety of techniques and information are used by the performance engineer to evaluate the condition of the aircraft's engines. The major source of information is of course the in-flight behaviour of the aircraft. Data analysis by bnilt-in devices provides a good means of assessing the condition of the aircraft and its systems. Engine vibration monitoring, limit exceedance data, event history recording and engine performance monitoring fall


into this category. Crew trouble reports are also invaluable in the assessment, together with feedback from line maintenance, and results from repair shops on removed and tested components.

Engine performance monitoring has proved to be a very effective technique for providing warning information of ongoing or imminent problems prior to serious malfunction. The effects of incidents, like for example bird strikes, can also be evaluated and followed up. Changes in the engine's prime parameters are in fact associated with a change in the performance level. The ADEPT-program (Aircraft Data Engine Performance Trending), developed by CFMI and General Electrics for their engines, is based on this technique and calculates and trends engine performance in time from the cruise parameters (CFM International, 1991).

On-board Sabena's Boeing 737-300, -400 and -500 series, aircraft systems generate among others cruise reports during each flight when aircraft and engine conditions are stabilised. Next to the typical aircraft and environmental parameters, engine-related data such as exhaust gas temperature, rotor speeds and fuel flow are recorded. These reports are processed, stored and interpreted by the airline's Performance Engineering department.

Prime engine parameters. The following parameters can be identified as prime indicators for the engine's state of health.

• Low-pressure rotor speed or fan speed (N1). Fan speed is the parameter used by the engine manufacturers to establish engine thrust or power setting. The analysis of the other prime engine parameters (such as exhaust gas temperature, fuel flow, and high-pressure rotor speed) is done as a function of N1.

• High-pressure rotor speed or core speed (N2). N2 represents the actual RPM of the high- pressure compressor and the high-pressure turbine (gas generator) to deliver the actual thrust (N1) under the given circumstances, i.e. given altitude, Mach number and Total Air Temperature.

• Exhaust gas temperature (EGT). EGT represents, likewise, the thermal conditions in the turbines.

• Fuel f low (FF). Fuel flow represents the fuel needed by the engine in its actual performance state. It is also one of the main parameters from which cost benefit can be monitored by trend performance monitoring.

• Throttle position. The throttle provides the means of power control during all normal conditions of operations. The throttle positions of both engines are recorded in order to compare them to each other.

Engine trend build-up. It must be noted that no two flights are performed in equivalent circumstances. Even during one flight, the same flight parameters change continuously due to fuel consumption and weather condition changes. This calls for a consistent procedure to obtain from the recorded data a relevant time evolution of the engine's health parameters. The ADEPT computer program compares the cruise behaviour of the actual engine with the performance of the so-called baseline engine defined by the manufacturer. This results in percentage differences for each corrected parameter in time. This trend generation is discussed in detail by CFMI (1994).

Trend analysis. Since the temperature, core speed and fuel flow are the most indicative of the cruise performance level of an engine, the delta EGT, delta N2 and delta FF are plotted by ADEPT, either smoothed or as raw data. By eliminating natural scatter in the raw data, smoothed delta-values permit a trend analysis (e.g., see Fig. 5). Most recent raw data is also visualised at the bottom of the graphs, to cover rapid changes in the engine's state of health that would only have become apparent later, as a result of the smoothing algorithm. The trend report also incorporates the evolution of the take-off EGT- margin expressed in so-called SL-OATL (Sea level Outside Air Temperature Limit). This value indicates the potential on-wing life and is obtained from an assessment of take-off reports containing data taken during take-off at about 300 ft above the runway.

Each engine has its own characteristic, referred to as a signature. The engine trends are thoroughly analysed in terms of the differences between current and past behaviour.

The performance engineer looks at both the smoothed data and the raw data and searches for shifts in the most recent trends in terms of the evolution of delta's in EGT, FF, N2 and the throttle position. Thereby all the engines of the aircraft are compared. If no shift is noted, then there is no evidence of a problem for the aircraft. If both engines show similar trend shifts, then the problem may be induced by an aircraft-related system or instrumentation problem; otherwise the detected shift indicates a change in engine behaviour (CFMI, 1992). Tied to the engine type and the aircraft it powers, typical shift patterns are known, identified by combined evolutions in EGT, FF and N2, both in magnitude and sense (up or down). They allow the problem to be localised within the engine's modules. It is difficult, however, to quantify the exact parameter shifts for each degradation type. There are, however, some general patterns that are supplied by the manufacturer, the so-called fingerprints. The performance engineer uses these


DA'E V I ~ . . J . . . . ~ . . . . ~ . . . . . . . . . r . . : e . . . : , . . , . . . . * . 2 . b . . -~ , .~ /F .F~ . :±~.~ii,~o~ -~ .... .. -2 ..... ~.ii[~ii~ .

7 ~ 4 a . * " 2

6 ~ 6 C . U ' / 6 2 2 ¢ , ~ v 6 2 9 ¢ . R v 7 ~ 4 C . R v 7 c o R v

' 7 0 9 p v 7 0 9 Rk 7 } ~ pV

7 1 1 711 * 7 ~ 2 ~ v 7 1 2 RV 723 RV

7 1 4 ~V 7 1 4 ~V 7 ] S RV 7 1 5 RV 7~6 ~v 7 1 6 RV 7 1 7 u v 7 1 7 RV 7 1 8 RV / 1 8 .R V 7 1 9 ,R v 7 1 9 . ~v ? : , e ,~ v 7 ~ 0 .R v

72$ . ~ 7 2 2 .R v

B (,

G G

%

e, g

%

g

OATL TIT up 3 4 , 8 3 7 . 7 3 r , 4

x . 2 3 3 . 1 x . z 4 0 . 2 x . 2 4 0 . 2 g. ~ T . ~ 9 . 2 1 0 3 47 X. 2 T . 3 9 . 2 1 0 7 4B x . 2 ~ , 4 0 . 3 1 0 7 43 Y . ~ 1 . 3 3 . 5 94 ~2 x , ' 4 0 . 3 1 0 6 4 ~

z. z T . a O , 3 1 0 5 4~ x. 2 T 3 8 . 3 9S ~9 x . 2 T , 3 9 . 4 1o~ SO x . ~ T . 3 9 . 5 l e e ~2

x , P ~ . ~8,~ * T . x . ~ 7 , 6 1 0 6 48

x . ~ T . 3 O . O 37 ~o x . ; T . 3 6 . 4 1 0 7 47

. T 3 3 . 3 1 0 6 $1 2 T . 4 0 . 3 lOB 49

r . ~ . 2 4 2 . 3 1 0 4 49 • 2 ~ T:T" 4 2 . 3 1 0 3 46

x . ~ 3 . ~ 1 1 1 so x . ~ T 4 3 . $ 1 1 2 48 x , ~ T . 4 1 . 9 1 0 6 47 x . 2 r . 4 3 . 1 111 be X , ~ T . 4 1 . | 1 0 6 47

T 4 1 . 1 1 0 ; 4B x . x . 2 r . 3 9 . 9 1 0 6 a9 x , 2 T . 3 P . 8 l e o 48 x . 7 2 2 .R v r~ ,

7 ? 3 .R v G F 7 2 3 .R v

724 . Fv 6 F 7~'~ u v G 7."~ .R v G 7 ~ 6 . l~v B . F F

7 2 7 729~,

O . . . ~ , , T . , ; ~ . . , ~ X } . ;, G F3 - : ~ . . - ~ . . . . . . . . ~,'- - : . . . . ~ . . . . ~ . . . . x . .

b h ' i E V ] ~ . . I . . . . . . . . . . . . , - - 4 . . . . ~. - ~ . . . - 4 . . . - ~ ' . . . r / r . L . ; ' . . . , 4 . . . . 6 - 2 . . . - 1 . . 723 .R v 6 . F

7 2 4 . RV 'Gi -- z 7 . ' 3 * 3 6 % G 2 , 8 Z e F 7 2 5 . R V G, G" 7 2 5 . * F 7 2 6 ,RV .G F

G.

2 3 8 . e l l 0 ~3 X. 2 T . 3 3 . 4 1C8 ~9 x . 2 t . 3 8 . 4 1 0 9 47 X. 2 1 3 8 . 4 9 9 T.0 x . 2 X . 3 7 . 6 . 1 0 4 bO x . 2 - ~ 4 , 5 )OS 49

l r 3 1 . 3 1 0 7 47 L 2 x . 2 T 27.8 98 ~,g

x . 2 T . 2 4 . S 1 0 6 X, ~ & T . 2 4 . 3 ) Q 4 49 ~ . j ~ . 7 , ~ . 29.4 l i e 4S

• .1~3 . ' . . ~ . . . . 1 . . . . x . . . . 2 , E R R , . . ) . . . . ; ' . . . . 3 . . . . 4 . . . . ~ . . . . 6 f i A I N I . COOTS

X.

x , ~ , 0 . 8 2 x . x . 2

• 2

7 ~ 9 . . R V G . ~ . __ __ __ .,--_ ._7 .~ - -new engine OOSOld -2 U $ 1 N 6 0 A T L I~E'f l ,OOl 5 6 - 3 B Z R U l l O~TE 7 / 3 @ ] 9 2

Fig. 5. Example of graphically represented trends - bird strike incident see 3.4.

fingerprints as a starting point in the closer interpretation of the problems, and relies further on his skills built up from previous experience.

The daily evaluation of the trends produced by ADEPT, together with all the other known information about the engine behaviour in operation, provides the framework towards:

• effective condition monitoring • anticipation of engine 'events' • help in engine problem diagnosis

Close co-operation between the engineering, operation and line maintenance departments of an airline is therefore essential.

COuE

Through regular involvement and feedback from engine behaviour, operational and maintenance reporting, the performance engineer's knowledge is continuously refined. He develops the skill to sift facts for relevance and knows when to discard them. By experience he also knows how to focus on problems rather than analysing all data extensively. In many situations, information is incomplete or conflicting, so past experience is often used to warn successfully about impending problems.

With the current mature state of artificial intelligence techniques, the next step can be taken in which computers will assist engineers in the actual monitoring tasks. The advantage of this development can be found in more consistent monitoring decisions, even under pressure during busy periods.

3.2. Motivations for using an Artificial Intelligence Approach

As was indicated earlier, modelling of real-life applications is almost impossible using one single technique. Implementation and maintenance of the knowledge then become complicated. A solution can be found in using a hybrid artificial intelligence approach. Recognising certain patterns in time- series of data and reasoning over the results are two separate issues. A performance engineer recalls previous situations and uses rules-of-the-thumb to evaluate and interpret problems. The knowledge required can be obtained from different sources, all of which offer information from a particular point of view. Due to the diversity in which knowledge is available, no unique form of representation can be used.

3.3. A General Framework For Enhanced Engine Condition Monitoring

Several artificial intelligence techniques are incorporated in this issue. The proposed concept allows the incremental development of an AI system on top of available analysis tools. Three main steps for the development of the system can be identified:

• recognition of a pattern indicating a possible problem

• interpretation and further analysis of a detected problem

• intelligent ECM diagnostic tool

The proposed solution does not imply the use of one artificial intelligence technique for the whole


process, but rather the use of specific techniques, namely neural networks and expert systems, for the tasks they are most suited for.

Recognition of a pattern indicating a possible problem. For the recognition of patterns, the Kohonen self-organising feature map was chosen, which has favourable characteristics for such tasks (Vercauteren, et al., 1990). The self-organising properties were especially important in this selection. As opposed to other algorithms, this type of neural network allows for an incremental extension of the domain of the patterns. For the actual study, it is expected that the list of typical patterns will extend over time. In Fig. 6, a general scheme is depicted of the signals which are fed into the neural network. The output is a so-called symptom code, specifying whether the module has recognised a possible problem.

performance engineer to obtain a solution. Automation of this phase of the condition monitoring therefore requires an expert-system approach rather than a neural-network approach.

As explained above, short-, mid- and long-term effects have to be recognised by the system. Short- term effects are evaluated by comparing the most recent flight with the moving average. Since some faults are gradual degradations, they only become apparent after a slow process. Mid-term evolution can be evaluated by comparing the most recent flight(s) to several previous averages. Long-term evolution can be evaluated by comparing monthly averages since the engine's installation date. This is to assess the global deterioration of the engine. As the shifts themselves are known to be similar for short-, mid- and long-term effects, the same network can be used for this diagnostic task. In this way the three-fold time-span is covered.

A (AN2)

A (AF_.o-rr)

A (AThrottle)

Symptom Code

Fig. 6. Schematic overview of the neural-network module

Kohonen self-organising feature maps are known to be static associative memories, which means that for a specific engine only one set of ADEPT delta parameters can be evaluated. However, it is not the actual performance state of an engine that is important, but its evolution. As an example, an engine that is warmer and consumes more fuel than another, may be in a good state, while the other one may be deteriorating. Therefore the difference between two successive [AEGT, AFF, AN2, AThrottle] sets is presented as input to the network. This will allow the module to be used for interpreting delta sets on short- (flight after flight), mid- and long-term intervals.

The CFMI-GE set of fingerprints for CFM56-3 engines was used as a starting point for a training set of patterns for the network. Since these fingerprints do not offer a complete overview of all possible problems, additional data will be generated in the near future, based both on more than three years' experience of a fleet of more than 30 Boeing 737's at Sabena, and from engine events experienced world- wide. Nevertheless, the network trained with only the fingerprints has shown very promising results, as will be shown later.

Interpretation and further analysis of a detected problem. Interpretation and further analysis of a detected problem require active reasoning by the

A special situation arises when a component or even a complete engine is replaced. Then no relevant historic data is available. As the system is not aware of this when presented new information, it will immediately discover a shift. The ECM engineers have to order the system to reset historic data for the engine. The (moving) averaging functions will then start from scratch. No further actions are required, as the system will automatically start to rebuild its database for this specific engine, and will use the information collected for the trend monitoring.

The Intelligent ECM Diagnosis Tool. In Fig. 7, a schematic overview of the developed ECM module is given. The neural network described above uses data supplied by a data preparation module, where all data handling is done, and where the data are presented to the neural network per engine in several sets of data, to cover the multiple time-spans. Furthermore, data can be invoked from APM (Aircraft Performance Monitoring) programs. These programs, written in Fortran 77 and developed by Sabena, calculate the degradation of the aircraft's structure and its engines over time compared to the Boeing baseline aircraft. As such, APM has a complementary function to ADEPT. The evaluation module also interprets the error identifications specified by the neural network and performs a comparison with the error identifications found for the other engines of the aircraft. The intelligent user interface allows the user to communicate with the system and all sub-systems.

The Intelligent ECMframework as shown in Fig. 7 consists of the neural-network module, surrounded by an expert-system structure. At several places, complementary information is included in the framework. Engine condition monitoring is not only based on relations that can be expressed explicitly in


ADEPT

APM

Data Base

Fig. 7. The Intelligent ECM framework

rules. The performance engineer also makes use of knowledge in the form of historical cases describing previous engine failure events. In the integrated off- line intelligent ECM diagnostic tool, a combination of rule-based and case-based reasoning will be used to assist the performance engineer. The incorporation of the case-based reasoning concept described earlier will be used to speed-up the diagnostic process.

An on-line ECM diagnostic tool may be developed in the future, using the same philosophy and structure as in this off-line ECM diagnostic tool. However, two major problems concerning safe engine operation have to be solved prior to making such a system operational: firstly, the consequences of incorrect in-flight advice for aircraft crew can be disastrous, and secondly, the real-time requirements for such a system will play a major role.

3.4. Preliminary Results

Training the network with only the fingerprints resulted in a converged topological map, where the different types of engine failures could clearly be identified. The Kohonen network classifies the data in such a way that similar problem patterns are placed near to each other. In the converged map, engine failures with a similar effect on its trends are located next to each other. As an example, a similar cluster is made for both 5th- and 9th-stage compressor customer bleed losses. Air is tapped from those high pressure compressor stages for air- conditioning purposes.

For verification of the proper functioning of the map, real flight data as processed by the ADEPT program were presented to the network. This led to the proper identification of the correct problems. Presented in Figs. 8 to 10 is an example where a bird-strike damaged the engine (during flight 19). Visual inspection after landing led to a replacement of two fan blades, while a borescope test took place without revealing visual internal damage. The plane was dispatched for its next flights. Nevertheless, ECM- trends showed a strong positive shift of 36°C in AEGT, 2.8% in AFF and a negative shift of 0.8% in AN2, indicating that due to vibrations, internal rubbing had occurred. This degraded the efficiency of the high-pressure turbine so as to lose 30°C of the EGT-margin on take-off (see the trends in Fig. 5 and Figs. 8 to 10). At this stage the engine was immediately replaced (after flight 28).

The evolution of this event can be followed nicely in the network (Fig. 11). Previous to the event, the network maps the engine data on the area representing good conditions. When the bird-strike event occurs, the data is immediately mapped onto the location that represents a decrease in the high- pressure turbine efficiency. Also, it can be seen that the new engine baseline again falls into the class of good states of the network.

More examples of failures were presented to the network, all resulting in a proper identification of the problem which had occurred. A more in-depth discussion of the results can be found in (Aznar Fern~ndez-Montesinos, 1994).


4. CONCLUSIONS

2

1.5

1

0,5

0

Delta N2

, i , i ~ 1

i0 20 30 40 50 60

F l i g h t s

Fig. 8. Shifts in N2 for a bird-strike

Delta FF

6 effect b i rd- l t r lke

Fig. 9.

10 20 30 40 50 60 F l i g h t s

Shifts in FF for a bird-strike

To make the operation and maintenance of modern technical systems more efficient, an integrated development is necessary of the software tools for, amongst others, all monitoring and diagnostic tasks. To investigate possible approaches to this goal, two key applications in this field have been developed and tested. An integrated system development approach is described, based on the experiences of these applications.

A new approach to on-line fault diagnosis is presented, which has several major advantages over other existing systems. To enable the integrated development of different diagnostic systems, the concept of case-based reasoning is applied to automatically build up the different diagnosis systems from one unique knowledge base of the technical application. This approach maintains the consistency between the diagnostic systems for different diagnostic tasks, greatly eases the declaration of the diagnostic problem and allows for a simple and consistent maintenance of the different diagnostic systems during operational life. To enable on-line diagnosis to take place, the response time of the case-based reasoning system is strongly reduced by development of a Rete-like network that also facilitates the specification of probability factors in the knowledge base.

DelLa EGT

2 . . . . . . . . . . . . .

i i i ..................... i ............ - 0 10 20 30 40 ,50

F l i g h t s

60

Fig. 10. Shifts in EGT for a bird-strike

Engine Condition Monitoring encompasses knowledge of the performance engineer from several sources and of different natures. Neural networks are used here to identify possible problems in the engine trends, while expert-system techniques are used for interpretation, further analysis and solution advice. Initial results show the validity of the approach by successfully recognising certain engine failure modes from trend data supplied by existing engine analysis software. To obtain a complete off-line diagnosis and monitoring tool, an expert-system structure will be developed around the neural- network module.

1 i i !

4 • . . . . .

i , .......... ........... ......... 0 2 4 6 8 10

Fig. 11 Mapping of bird-strike data on the Kohonen map

REFERENCES

Aamodt, A., and E. Plaza (1994). Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches. AI Communications, 7, nr. 1, pp. 39-52, March.

Aznar Fermindez-Montesinos M. (1994). Intelligent Aircraft Engine Condition Monitoring. MSc- thesis, Delft University of Technology.

CFM International (1991). Trend monitoring interpretation guide.

CFM International (1992). ADEPT Trend Monitoring Conference, Paris, 15-17 April.


CFM International (1994). ADEPT Trend Monitoring Conference, Paris, 28-29 April.

Forgy, C.L. (1982). Rete: A fast Algorithm for the Many pattern/Many Object Pattern Match Problem. Artificial Intelligence, 19, pp. 17-37.

Janssens, P. (1994). Sabena ECM Activities. ADEPT Trend Monitoring Conference, Paris, 28-29 April.

Johnson, K (1994). Evolution of the Trouble Shooting Manual for the A319/A320/A321/ A330/A340 Central Maintenance System. FAST Airbus Technical Digest, nr. 16, pp. 10-15.

Kerrebrock, J.L. (1992). Aircraft engines and gas turbines, The MIT Press.

Magaldi, R.V. (1994). Maintaining Aeroplanes in Time-Constrained Operational Situations using Case-Based Reasoning. In: 2 na European Workshop on Case-Based Reasoning EWCBR- 94, M. Keane, J.P. Haton, M. Manago (eds.), AcknoSoft Press, Paris, pp. 1-12.

Raaphorst, A.G.T., B.D. Netten and R.A. Vingcthoeds (1995). Automated Fault-Tree Generation For Operational Fault Diagnosis. Proc. RAILink'95, 27-30 March.

Riesbeck, C.K. and R.C. Schank (1989). Inside Case-Based Reasoning. Lawrence Erlbaum Associates, New Jersey.

Vercauteren, L., R.A. Vingerhoeds and L. Boullart (1990). Intelligent Dimensional Data-reduction by a Topological Map. In Parallel Processing in Neural Systems and Computers, Eckmiller, R., G. Hartmann and G. Hauske (eds), North- Holland, Amsterdam.

Virilli, M. (1994). A330/A340 Central Maintenance System. FAST Airbus Technical Digest, hr. 16, pp. 2-9.

Vingerboeds, R.A., B.D. Netten and L. Boullart (1992). Artificial Intelligence in Process Control Applications. Communications and Cognition in Artificial Intelligence, 9, pp. 161-173.

Documents

Enhancing off-line and on-line condition monitoring and fault diagnosis