Aberystwyth University

Automated FMEA Based Diagnostic Symptom GenerationSnooke, Neal; Price, Christopher John

Published in:Advanced Engineering Informatics

DOI:10.1016/j.aei.2012.07.001

Publication date:2012

Citation for published version (APA):Snooke, N., & Price, C. J. (2012). Automated FMEA Based Diagnostic Symptom Generation. AdvancedEngineering Informatics, 26(4), 870-888. https://doi.org/10.1016/j.aei.2012.07.001

General rightsCopyright and moral rights for the publications made accessible in the Aberystwyth Research Portal (the Institutional Repository) areretained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by thelegal requirements associated with these rights.

• Users may download and print one copy of any publication from the Aberystwyth Research Portal for the purpose of private study orresearch. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the Aberystwyth Research Portal

Take down policyIf you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediatelyand investigate your claim.

tel: +44 1970 62 2400email: is@aber.ac.uk

Download date: 31. Mar. 2020

Automated FMEA based diagnostic symptom generation.

Neal Snooke1,∗, Chris Price

Department of Computer ScienceAberystwyth UniversityPenglais, Aberystwyth

Ceredigion, SY23 3DB, U.K.

Abstract

The comprehensive on-board diagnosis of faults in many aerospace and other engineered systems requiresreal time execution using limited computational resources, and must also provide verifiable behaviour. Thispaper shows how a diagnostic system satisfying these requirements can be automatically generated from themodel based simulation used to produce an automated Failure Modes and Effect Analysis (FMEA). Theresulting diagnostic system comprises a set of efficiently evaluated symptoms and their associated faults.The symptoms are complete in that they include all necessary observations required to determine applicablesystem operating states, unlike other work that finesses this problem by having models for each operatingstate and producing diagnostics for each operating state separately. The symptoms are also efficient becausethey abstract complex system behaviour based on observations available to the diagnostic system and onlypreserve sufficient symptom detail to isolate faults given these available observations.

This work has been done in the context of diagnosing autonomous aircraft, and is illustrated with examplesfrom that domain. The models used as a basis for automated generation of diagnostics were originallyproduced to automate the production of a FMEA report, and the paper also considers the relationshipbetween FMEA and diagnostics that provides verification of the failure effects predicted by the simulationand hence validation of the generated symptoms.

Keywords: Qualitative reasoning, Automated FMEA, Symptom generation, Diagnosability analysis

1. Introduction

1.1. ContextThis paper describes research carried out on

the ASTRAEA project, a pioneering £32 millionaerospace programme which is addressing key tech-nological and regulatory issues in order to open upnon-segregated airspace to unmanned autonomousaircraft [9]. In order to operate autonomous aircraftsafely in normal airspace, a high degree of confi-dence is needed in the capability of the aircraft toaccurately carry out prognosis and health manage-ment (PHM). A key part of the PHM task is theability to identify problems on board the aircraftand to diagnose those problems correctly.

∗Corresponding AuthorEmail addresses: nns@aber.ac.uk (Neal Snooke),

cjp@aber.ac.uk (Chris Price)1Tel: +44 (0)1970 621782

The on-board diagnosis of complex vehicle sys-tems is a challenging task, and qualitative modelbased diagnosis has been successfully applied toproduce on-board systems that assist in the detec-tion and isolation of faults [26, 4, 7]. The major-ity of these systems use executable models of thesystems (either with or without fault models) sim-ulated in parallel with the working system. Themodel is supplied with the actual inputs to the sys-tem and abductive reasoning is performed based ondiscrepancies between the predicted and observedsystem behaviour [8]. The reasoning approachesutilised to perform fault candidate generation fromthe discrepancy between predictions and observa-tions are categorised in [6].

A second approach that has been adopted is touse the same type of model-based analysis as above,with a defined set of possible component faults, togenerate a set of candidate component faults for ev-

Preprint submitted to Elsevier July 16, 2012

ery possible system failure. This information formsthe basis of an FMEA, for example earlier circuitbased work by the authors in[21]. Indeed, any sys-tem that is capable of the necessary nominal andfailure behavioural predictions can potentially beused to provide the data for symptom generation,for example the qualitative deviation model ap-proach of [24]. That approach does not howeverprovide any particular advantage with respect toefficiency of the FMEA production since the devi-ations do not replace the absolute model for theFMEA task[23].

There is some similarity to the ‘association based’category of reasoning described in [6] wherebydiscrepancies are matched with stored symptom-failure associations. The significant differences inthe present work are that possible discrepancies areprecomputed (optimised) and the symptom-failureassociations are generated automatically from thesystem description removing any maintenance is-sues. There are a number of advantages to the Au-tomated FMEA based approach:

• The diagnostic system’s capabilities can becharacterized before deployment. Specifically,the scope and accuracy of the diagnostics canbe checked and verified. This is important inour context, as stringent certification and reg-ulation approval requirements exist.

• The technical challenges associated with exe-cution of complex models and model accuracychecking is done off line, in advance, and onceonly and therefore the on board detection offaults is efficient allowing guaranteed responsetimes.

• Additional symptoms that do not come from amodel of the system can be used to augmentthe model-based diagnostics.

• The diagnostic weight of each symptom can becalculated to reflect reliability.

Component fault models and the identification ofthe operating states in which each component faultcan be detected are required in order to producegood results. It is not sufficient merely to test pres-sures or voltages in a system, as such symptomsare often state-dependent — problems can only beobserved when the system is in specific operatingmodes. Practical applications of this technologyoften link hand generated symptoms to component

faults in order to produce efficient on-board diag-nostic symptoms.

The research described in this paper improves theefficiency and consistency of this second approachin three ways. Firstly, it integrates the model-based diagnosis with model-based failure modesand effects analysis (FMEA): this means that allincluded component failures have been consideredand agreed by engineers using the existing designprocess. Secondly, it provides algorithms for pro-ducing state-based symptoms that comprehensivelycharacterise the observable failures in the system.Finally, it determines whether all system failurescan be observed with the existing sensors, and in-dicates which component failures can be isolatedwith existing sensors.

Section 2 describes the overall structure of theprocess of producing useful symptoms, and section3 explains the structure of the output of a model-based FMEA report.

Section 4 provides an efficient algorithm for theselection of symptomatic observations from a largeset of possible candidates.

Section 5 addresses the problem of generalisingobservations from a representative set of systemstates to all possible states.

Section 6 outlines how the generated symptom-fault sets can be used to create a diagnostic system,followed in the final section by the results of apply-ing the symptom generation technique to realisti-cally sized systems.

2. Background

Figure 1 illustrates the main steps in the processof producing detectable symptoms for the on-boarddiagnostic system. The shaded items represent pre-viously existing data and analysis.

Model-based generation of FMEA. This hasbeen well-documented in previous papers [16]and is in daily use in industry to produceFMEA reports on automotive electrical sys-tems. It simulates the qualitative system be-haviour for all potential component failures,and uses functional reasoning [14] to abstractthe high level consequences for each possiblefailure. The consequences of every failure arereported to the designers, and they can decidethe steps needed to improve the safety and re-liability of the system.

2

Model-basedgeneration of

FMEA

SymptomGeneration

On-boardBayesian diagnostic

system

FMEA results

Symptom/problem list

Hand generated symptoms

Model-basedsimulation of

system

Symptom coverage

CoverageAnalysis

Structure of system

Behaviour of components

Functions of system

Functional Anomalies

Nominal and Failure Behaviours

Nominal and Failure Behaviours

Figure 1: Model-based On-board Symptom Generation

Symptom generation. This is the main contri-bution of this paper. The FMEA results pro-vide a link between the system failures and thecomponent faults that caused them. For ser-vice bay diagnostics, these links can be used tofind the cause of a problem with the system.However, in on-board diagnosis, the known in-formation is limited to sensor values and sys-tem state, and it is necessary to decide howand when to use observable behaviour both todecide that there is a problem, and to deducethe root cause of that problem. Sections 4 and5 of this paper describe how to use automatedFMEA results to generate a set of character-istic symptoms to be monitored that will pro-vide the maximum information about the stateof the system.

On-board diagnostic system. One of the limi-tations of model-based reasoning is that it canonly deal with problems that are within thescope of the modelling. For example, if prob-lems are caused by cross-component interac-tions that are not modelled, then they wouldnot be included in the set of symptoms to mon-

itor [11]. The generated set of symptoms to bemonitored can be augmented by further symp-toms that compensate for the limitations of thechosen modelling. In our solution, all of thesymptoms are included in an existing propri-etary Bayesian network based diagnostic sys-tem developed by BAe Systems [19]. The pro-cess of using qualitative symptoms within thissystem is outside the scope of this paper, how-ever several key features are provided in section6 of this paper.

Coverage analysis. Ideally, the on-board diag-nostic system would be able to detect and iso-late every possible component fault that couldoccur. In practice, on-board systems have alimited set of sensors, and those sensors are of-ten decided before an on-board diagnostic sys-tem is planned. It is however easy to modifythe visibility of any model parameter or simu-lation variable in the system model. We havedeveloped a tool that exploits this to allow in-vestigation and analysis of the relationship be-tween measurement availability and diagnos-ability, presenting the information to the engi-

3

neer as a visual cluster matrix together withsummary information. These techniques andtools can be used during early design to quicklyassess the impact of different sensor selectionstrategies and are the subject of a separate pa-per [22].

There are several specific advantages of this pro-cess for the applications and case studies targetedby this work :

• The simulation effort need be carried out onceonly as part of existing design analysis require-ments, and does not need to be done on theon-board hardware. This means that the di-agnostic system requires relatively simple onboard processing.

• The ability to supplement the symptom setused for on-board diagnosis is valuable for sev-eral reasons. Symptoms can be included basedon specialist sensors outside of the modellingdomain of the system to be included, such as atemperature sensor measuring electrical com-ponent temperatures. In addition, outputs ofcomponents or subsystems that include theirown black box diagnostic capabilities that can-not be modelled can be included in the diag-nostic system. Fault prognosis tends to requirespecialist techniques and sensors to identifysystem degradation; if these exist then symp-toms can be included that convert these as-pects into a diagnostic output. In these casesthe fault is not a hard fault but a degradationor future failure prediction, and the measure-ments and observations may include outputsfrom the specialist sensors or software. Finally,further symptoms can be included (or possiblyexcluded) where for pragmatic reasons mod-elling simplifications exist in the models usedfor the design analysis.

• Existing experience can be included if aBayesian version of the on-board diagnosticsystem is used by allowing adjustment of theweighting of symptoms to reflect any uncer-tainty regarding the applicability of a symp-tom, for example where measurements mightbe considered less reliable.

• The diagnostic system’s capabilities can becharacterized in advance, and the sensing re-quirements and cost weighed against the di-agnostic and fault isolation capability of the

system. An engineer can experiment with sen-sor selection and assess the capability of theresulting diagnostic system [22].

3. Characterising FMEA Descriptions

The basis of the state-based symptom generationwork is the application of the simulation results ob-tained during the generation of an FMEA. Thesesimulations drive the system to explore a broadrange of nominal and failure operating states.

This section provides a formal description of theprocess of generating a model-based FMEA reportabstracted by function. This will then be used as abasis for the novel method of symptom generation.

A trivial electrical system comprising severallamps, switches and connecting wires are depictedin figure 2 will be used as a running examplethroughout the paper to illustrate the notation, al-gorithms and results. Only wire fracture faults willbe included, and the system will be instrumentedwith the current flow in each wire as a basis forsymptom generation. For reasons of space, resultsextracts will be used in the paper; the completeauto-generated results for the example are availableas supplementary material with the online versionof the paper.

3.1. FMEA generationAn FMEA report is produced by comparison of

system function and behaviour for nominal andfailure mode operation. The system is exercisedthrough a number of states using a scenario de-fined by an engineer that (in general) activates eachof the system functions and major functional oper-ating modes. The following paragraphs develop anotation for the FMEA results to be used for symp-tom generation.

OBS is defined as a finite set of first order sen-tences representing all measurements (outputs orinputs, or observable component states) availablefrom a target system. Some members of OBS maybe complex expressions, for example to create ‘vir-tual sensors’, however the term measurement isused to refer to a single sentence because the ma-jority contain a simple proposition that comparesthe value of a measurable quantity. Typical sen-tences in the qualitative representation of the sys-tem used in this work might be temperature = high

or switch.position = on although it could also be acomponent state, software variable or any other ob-servable.

4

+batt

sw_r

sw_glmp_g

lmp_r

sw_lmp w1w2

w5 w6

w7

s1

s3

w8

NEGPOST1T2P2 P1T1T2

T1 T2

T1 T2 T1 T2

T1 T2 P2P1

P2P1

T1 T2

T1 T2

T1

T2T3T1

T2 T3

w3

T1T2

lmp_w

T1T2

sw_w

P2 P1

w4

T1T2

Figure 2: Simple electrical system

A scenario, SCN , will provide an ordered se-quence of n input states for the system whereSCN n ⊂ OBS. That is, SCNn defines a set oftriggers. A simulation is performed for each SCNn,and for systems that reach a steady state2, an ob-servation is produced (containing all available mea-surements). The notation OBSn is used to indi-cate the subset of OBS produced (by simulation)for SCNn with no faults present.

A target system is comprised of a set of constantsCOMPS representing the components of the sys-tem. Each component has a set of mutually exclu-sive failure modes Modes(c) where c ∈ COMPS .Single faults are generally used for FMEA genera-tion, not only because of the effort involved in con-sidering the results of multiple faults, but also be-cause most design issues are highlighted from thesingle fault cases [18]. The complete set of compo-nent failure modes M for a system is thus:

M =⋃

∀c∈COMPS

Modes(c) (1)

The simulation can support any number of simul-taneous failures and on occasion an engineer maydecide to include specific categories of multiple fail-ure. Throughout this paper, M is used to representa (simultaneous set of) component failures consid-ered as a failure mode in an FMEA. M = ∅ isconsidered as the no failure case, and usually Mcontains a single component failure mode although

2Systems that do not achieve a steady state will produce asequence of observations, however we will not consider thosehere.

generally M ⊆ M ensuring only one failure modefrom each component:

(∀m,∀n ∈M, n 6= m,∀c ∈ COMPS )(m 6∈ Modes(c) ∨ n 6∈ Modes(c)) (2)

The notation OBSM is used to refer to the set ofobservations obtained by simulation of the systemfor SCN with faults M present and OBSM

n thusprovides concise notation for a failure mode ob-servation, a single set of measurements for SCNn.

An example scenario with 8 steps for the runningexample is shown in the top section of figure 33.The engineer has exercised the white, red and greenlamps (lmp w, lmp r, lmp g) individually by chang-ing switch settings. All other information presentedis derived automatically from the qualitative simu-lation combined with a functional model consideredin the next section. In the lower part of the figurethe first component fault (M = {w1− fracture})is shown for two scenario steps SCN5 and SCN8

because these were the only observations contain-ing abnormal measurements for this fault. For thepurposes of FMEA the state of the Failure Mode(abnormal function state) is the primary concernand the detailed behaviour is usually hidden.

The functional model provides interpretation ofthe simulation observations and also plays a rolein the symptom generation process and is thereforedescribed separately in the following section. Theelectrical activity in the circuit is specified as ac-tive or inactive as a direct result of the qualitative

3The complete FMEA for the example is available as sup-plementary information with the online version of this paper.

5

electrical simulation, and the risk factors (severity,detectability and occurrence) are derived from thefunctional and component models. For clarity, onlyabnormal measurements are shown on the humanreadable FMEA report however the nominal mea-surements are captured thus providing an observa-tion, for example OBS{w1−fracture}

5 . Further detailsof the FMEA generation are contained in [15, 14].

3.2. Function modelA functional interpretation model is used to al-

low the results of a component based qualitativesimulation to be abstracted into effects meaningfulto an engineer for the purpose of FMEA generation[14, 3]. The functional model also has a critical rolein the ability to generate diagnostics from the simu-lation results produced during the FMEA because itcan determine the relevance of measurements by op-erating state, thus allowing symptom generation us-ing only the representative system states providedby the FMEA.

An engineer describes the system functions, Fusing a Functional Interpretation Language (FIL)as detailed in [3], by defining the triggers requiredto activate the function and the effects required forthe function to be considered as achieved. The trig-gers and effects are linked to fragments of systembehaviour for any system that implements the func-tion. For the purpose of this paper it is only neces-sary to understand that each system function, fn ∈F , can be in one of four possible states provided bythe predicates Ac(fn), In(fn), Fa(fn), Un(fn), thatrepresent the function having been Achieved, In-operative, Failed or Unexpected. These functionstates are defined in terms of trigger (Tr) and ef-fect (Ef) propositions, grounded in a subset of thepossible system measurements within the FIL asfollows:

Ac(fn) ≡ Tr(fn) ∧ Ef(fn) (3)

In(fn) ≡ ¬Tr(fn) ∧ ¬Ef(fn) (4)

Fa(fn) ≡ Tr(fn) ∧ ¬Ef(fn) (5)

Un(fn) ≡ ¬Tr(fn) ∧ Ef(fn) (6)

Some intuition as to the type of knowledge cap-tured by the functional model can be seen in fig-ure 4 that defines the produce red light function forthe running example. The produce red light func-tion provides a purpose named red to its externalenvironment and requires a trigger activate red andeffect red illuminated. There are similar definitionsfor white and green functions for the system. Any

undefined identifiers are references to values pro-vided by an associated system simulation. For ex-ample the proposition sw lmp.Position == ‘on’ is as-sociated with a switch input position and providespart of the trigger for the function, and the obser-vation lmp r.R1 == ‘active’ evaluates current flow inthe resistance representing a lamp and is associatedwith the required effect (for pragmatic reasons, theFIL uses == as the equivalence operator and = forassignment).

Purpose information is not used in symptomgeneration but captures the teleological intent ofthe function within a deployment environment [5].Generally the functional model will be a relativelysimple identification of each system function, howit is activated and what effects are to be expected.The formal details of the FIL can be found in [3, 1].

FUNCTION produce_red_light {

ACHIEVES red

BY activate_red TRIGGERS red_illuminated}

PURPOSE red {

DESCRIPTION ‘provide red light to the user’

FAILURE_CONSEQUENCE ‘user does not see any red light’

SEVERITY 5 DETECTABILITY 2}

TRIGGER sw_lmp.Position == ‘on’ AND sw_r.Position ==‘on’

IMPLEMENTS activate_red

EFFECT lmp_r.R1 == ‘active’

IMPLEMENTS red_illuminated

UNEXPECTED_CONSEQUENCE ‘unwanted red light’

SEVERITY 3 DETECTABILITY 1

Figure 4: FIL illustration

3.3. FMEA AbstractionThe engineer-level FMEA report is generated by:

• simulating the system with a variety of failuremodes M1, M2, ..

• evaluating the state of system functions foreach element in OBSMi

• reporting failed and unexpected functions us-ing the definitions in equations 5 and 6.

The FMEA report for simulation step SCNn offault M will contain information relating to the fol-lowing set of abnormal functional results:

RfnAbMn = {fn | Fa(fn) evaluated for OBSM

n

∨Un(fn) evaluated for OBSMn }(7)

6

Figure 3: Automated FMEA fragment for circuit in figure 2

7

In addition, the related sets of failed and achievedfunctions are of interest for symptom generation:

RfnFaMn = {fn |Fa(fn) evaluated for OBSM

n } (8)

RfnAcMn = {fn |Ac(fn) evaluated for OBSM

n } (9)

The functional information provides adequate in-formation to generate a traditional FMEA, howeverspecific issues can also benefit from additional ex-planation with detailed behavioural abnormalitiesidentified by comparison of the nominal and failureobservations:

RobsAbMn = {o ∈ OBSM

n | o 6∈ OBSn} (10)

The example, in figure 3 reports the failure mode:

RfnFaw1−fracture5 = {produce red light}

and the behaviour comparison:

RobsAbw1−fracture5 = { w1.flow : inactive,

w2.flow : inactive,w5.flow : inactive,w6.flow : inactive}

Once the FMEA results are considered acceptableby an engineer, symptom generation can be carriedout. A prerequisite for FMEA production is thatthere should be no abnormal functions in the ab-sence of a failure:

(∀n)(RfnAb∅n ⇔ ∅) (11)

If proposition 11 is not satisfied for some OBSthen the system has failed to implement its func-tion description and this design verification issueshould be addressed before any meaningful FMEAor symptom generation can be produced. In figure3, RfnAb∅ (no fault) results are shown in the sce-nario section. Inoperative functions are not shownon the report for clarity, and there are no abnormalfunctions (Fa, Un) allowing symptom generation toproceed for the example.

4. Symptom generation

At first glance the FMEA appears to directlyprovide symptoms simply by associating abnormalbehaviour RobsAbn and failure modes M . Whilethis may sometimes provide a set of measurements,E , that form a usable symptom, the majority ofRobsAbn measurements remain within the range of

values encountered during nominal operation for atleast one other non failure state. Therefore mostsymptoms actually require one or more nominalmeasurements in addition to a subset of RobsAbn

to provide a symptom that does not spuriously in-dicate faults.

If engineers generate vehicle on-board diagnosticsby hand, they typically identify a sensor or set ofsensors to observe, and measurements that indicatean operating state of the system in which the ob-servations can be made. For example, in figure 2 ifthere is no current flow at lmp w and sw w==‘on’,then one possible fault is w3-fracture.

A fault may cause many abnormal observationsand since it is beneficial for |E| to be as small possi-ble for a given level of diagnosability and fault isola-tion, the abnormal observations in |E| may need tobe a subset of those available in a specific abnormalobservation. When manually creating symptomsfrom a hand generated FMEA, an engineer wouldmake these selections and create conditional symp-toms (discussed later) based on extensive systemknowledge. The work described here automates thisprocess and produces a consistent and comprehen-sive set of symptoms.

The automated symptom generation techniquedescribed in this paper does not require explicit ex-ternal knowledge concerning the relevance of mea-surements to either faults or functions to compen-sate for the missing state information inherent inthe FMEA. Rather, this information is extrapolatedfrom analysis of behavioural consistency coveringall of the faults and all of the system states en-countered during the entire FMEA. Given a reason-ably comprehensive FMEA that exercises all sys-tem functions and includes faults for the majorityof components, the aim is to produce symptomsthat are general enough to cover a great deal ofthe system state that is not explicitly included inthe FMEA without producing spurious symptoms.Failing to do this will mean that the diagnostic sys-tem will only have the ability to diagnose faults ina very limited set of operating modes of the device.A typical example might be that diagnosis is onlypossible when a single system function is operat-ing. The functional model (also used to interpretthe FMEA) is the enabling concept that indirectlyprovides abstract guiding knowledge facilitating ex-trapolation of symptoms to system states that werenot present in the FMEA.

The symptom generation therefore comprises twomain parts as follows:

8

• Logical expressions on sets of observationsmust be created that implicate faults. This isessentially a search task that involves selectingsets of observations that implicate the small-est set of faults that do not occur in nominaloperation. Sections 4.1-4.3 develop this task.

• Detailed behavioural information is only avail-able for a representative set of system statesand therefore some generalisations must bemade. Section 5 develops a method thatutilises functional information to produce gen-eralised symptoms.

4.1. Identification of symptomatic measurements

This section provides an efficient algorithm forthe selection of symptomatic observations from thecandidates obtained from the FMEA. The algo-rithm generates a complete symptom set for a sys-tem where every possible state was encountered inan FMEA.

A symptom is defined as a tuple S = (E,F )such that E is a first order sentence referred toas a symptom expression that when satisfiedindicates F = {M1, M2, ...} as symptom faults.A set of satisfied symptoms forms the diagnosiscandidates D ⊂ M. E(s) evaluates E on a spe-cific system state s ∈ OBS . The term simplersymptom is used to refer to a symptom that hasfewer measurements required to evaluate E. Amore complex symptom requires a greater num-ber of measurements than a simpler one. In thispaper E is always a simple conjunction of equiv-alence propositions that represent measurements,and we use E to represent these individual mea-surements and therefore the simplicity measure forany symptom is |E|. For example if E = (sw w ↔‘on’ ∧ lmp w.flow ↔ active) then E = {sw w ↔‘on’, lmp w.flow ↔ active} with |E| = 2. If |F | issmaller for symptom S1 than S2 then we refer toS1 as more specific than S2 and S2 as more gen-eral then S1.

The aim of the symptom generation is to producea symptom set S = {S1, S2, ...} that will provide adiagnosis as a set of possible faults D, such thatif M is a given failure mode, then M ∈ D whileavoiding spurious diagnoses M 6∈ D ∧ D 6= ∅. Inaddition the general principle used is to generatethe simplest symptoms that provide a given level offault detection/isolation to avoid redundant mea-surements forming part of a symptom. No diagnosis

of a fault D = ∅ is preferable to a spurious diagno-sis but given a fault M , the more operating time orstates that D 6= ∅ the more powerful the fault detec-tion, and the smaller |D| the better the diagnosticsystem fault isolation. These constraints define thebasic goals of the symptom generation technique.

Every component fault M considered by anFMEA results in several sets of measurementsOBSM

n as a response to the steps in the scenario.One or more measurements from OBSM

n may beconjoined to form a symptom, however they mustsatisfy two constraints. Firstly, a symptom shouldonly be present when the associated fault is present.Secondly, it is desirable to detect as many faultsas possible in as many operating states as possible.This implies symptoms should be general and there-fore contain the fewest measurements, such that thefirst constraint is satisfied.

Given a failure mode observation, s ∈ OBSM ,the aim is to find sets of measurements, E ⊆ s,where |E| is minimised, such that:

E = {R ⊆ s | @n : R ⊂ OBSn} (12)

For each fault observation OBSMx related to a fail-

ure mode M , a set N is defined that itself containssets of measurements that are abnormal with re-spect to each of the nominal observations. Eachfailure mode is considered individually so the faultmode superscript is omitted from the notation of Nin the following description.

Nx = { OBSMx \OBS 1, OBSM

x \OBS 2,

.. , OBSMx \OBS |SCN |}

(13)where |SCN | is the number of distinct steps in thescenario.

Any symptom must contain at least one measure-ment from every element of N to satisfy the re-quirement that the symptom does not contain onlymeasurements that exist during nominal operation.Definition 12 can thus be written:

Ex = {R ⊆ OBSMx | ∀N i ∈ N : ∃o ∈ N i ∪R} (14)

To efficiently select measurements, an index is as-signed to each member of OBSM according towhich members of N it appears in. N is consid-ered as an ordered set and each member is assignedan index value from a power 2 sequence. This facil-itates a tree structured search that locates simplesymptoms rapidly and allows the majority of longer

9

symptoms to be ignored. Each measurement o isassigned its index in the following way:

index(o) =∑

i=1..|N |

{2i−1, if o ∈ N i

0, otherwise(15)

Figure 5 illustrates the assignment of indices fora small example with 3 scenario states and 6 pos-sible measurements a-f. The nominal observationsare shown at the top of each column representing ascenario state and the possible failure observationsfor the failure are shown below.

N i for a specific failure observation is generatedby removing the nominal mode observations for sce-nario step i from the given failure observations.

The ordering of the measurements is depicted bya matrix using rows to represent measurements andcolumns to represent each element of N . The sumof the abnormal observation set indices for each rowprovides the order to search the measurements.

Since |N | = |SCN | and is related to the num-ber of system functions, the index values have beensmall enough to compute explicitly for the systemswe have applied the method to. A sorting algorithmthat performs a sequence of partial sorts of s basedon membership of each element in N would beequivalent for larger scenarios, however it is doubt-ful that an FMEA with such an excessive numberof scenario steps would be useful, and a better so-lution might be to divide the analysis into subsys-tems. The case where index(m) = index(n) for twomeasurements is considered in section 4.2.

The symptoms are now generated by traversingthe ordered list of measurements, including addi-tional measurements until a symptom is formedthat includes at least one measurement from eachset of N :

1. Initially set k = |N |2. Each measurement mp contained in Nk is con-

sidered as part of a new potential symptomexpression, Ep. Consider each Ep in turn:

3. Completed symptoms check. If Ep contains atleast one element from every set in N (i.e.∑

(∃m∈Ep)(m∈Ni)i = 2|N |−1 then Ep is a com-

pleted symptom. Ep is converted into a symp-tom expression by conjoining all the elementsE =

∧∀m∈Ep

m. Consider any remaining Eppossibilities.

4. An N index, j, is chosen for Ep such that 1 ≤j < k and (∀m ∈ Ep)(m 6∈ N j). In addition

if j < i < k, then (@i)(∀m ∈ Ep)(m 6∈ N i).That is, N j must be the next element in Nnot already represented by the symptom beingconstructed.

5. Dead end symptom check. If no j can be foundthat satisfies the constraints in step 4 then Epcannot form a symptom and is removed fromconsideration. Consider any other Ep possibil-ities.

6. If the |Ep| has not equaled any completedsymptom, it is used as the basis of a newsets of partial symptoms Ep′ , by adding an ad-ditional measurement, Ep′ = Ep ∪ mq wheremin(index(mq)) such that mq 6∈ Ep∧mq ∈ N j .That is, the lower ranking measurement not al-ready forming part of the partial symptom inN j . For each Ep′ , recursively apply from step3 setting Ep = Ep′ , and setting k = j.

Only the simplest symptoms are required andthe breadth-first strategy ensures all equally sim-ple symptoms are located first thus terminating thesearch. Also contributing to the efficient selection isthe characteristic that measurements contributingto the greatest number of remaining N elements arealways earlier in the sequence, and because theseare the measurements that distinguish the failurestate from the maximum number of nominal mea-surements, they are the best candidates to formcompleted symptoms using fewest measurements.

The ordering of the selection from the |N | setsmaking up N is arbitrary, but once an order is cho-sen, it determines the indices of the actual measure-ments, and must then be applied consistently. Thereason for ordering measurements and then select-ing sets of measurements in this way is to producesymptoms that are guaranteed to not be part of anyset of nominal observations.

The lower part of figure 5 illustrates the process.For OBSM

1 in the leftmost column, two symptomsare generated with two measurements required forboth. Two initial partial symptoms (b, {M}) and(d, {M}) are possible as the initial nodes in thesearch tree. The measurement with the highestrank of 6 is b, and provides two elements {N3, N2}from N , requiring only measurements from N1 tocomplete N and produce a symptom. The searchfrom b is continued by traversing further down themeasurements list for measurements involving N1.d is the next candidate and completes the set N .The completed symptom is therefore (b ∧ d, {M}).

For the second of the initial symptoms the next

10

a b c e f a c d e e f

nominal observations for three scenario steps

b d f observation 1 a b e a b d e

N1 = OBS1M \ OBS1= d

N2 = OBS1M \ OBS2 = bf

N3 = OBS1M \ OBS3 = bd

bd 1

2f

44

2

db

f

6

52

6

7

5 7

N1 = OBS3M \ OBS1 = d

N2 = OBS3M \ OBS2 = b

N3 = OBS3M \ OBS3 = abd

a

bd 1

44

256

d

4

6

N1 = OBS2M \ OBS1 = 0

N2 = OBS2M \ OBS2 = b

N3 = OBS2M \ OBS3 = ab

ab 4 2

46

No solutions(undetectable fault

-no abnormal behaviour)d

N3,N2 N3,N2,N1

N3,N1 N3,N2,N1

b7

N3,N2

d f

1,3

1

bresultOBS1

M : bdOBS1

M : dfOBS3

M : bd

N1N2N3 Index Index Index

N1,N2,N3

OBS1M OBS2

MOBS3

M

OBS1 OBS2 OBS3

a-f represent qualitative measurements

N1N2N3 N1N2N3

ordering measurements

selecting measurements

combining symptoms

observations for failure M

1,3

1

d

4 4

Figure 5: Symptom Search

element of N required is N2. Considering remain-ing measurements in N2, b, f are possibilities, andf also completes N for the symptom resulting inthe additional symptom (d ∧ f, {M}). The d thenb is abandoned without further searching since ifat all, it would provide complexity>2 and simplersymptoms have already been found for the obser-vation.

The second failure mode measurement OBSM2

produces N1 = ∅ and hence no symptoms are pos-sible because all of the measurements are seen inN1 and manifests as an empty matrix column forN1 in the figure. OBSM

3 produces a single symp-tom, because those starting d and a are abandonedat N2 on complexity measure. Finally, the symp-toms generated from each observation are added toan ordered tree of measurements to allow the com-plete set of faults related to each symptom to becaptured.

Using the running example we find that sce-

nario step 5 provides the first symptoms for faultw1.fracture as shown in figure 6. The 8 scenariosteps lead to N1−8 (this is notated ND0-ND7 bythe software implementation). Clearly sw r.Positionis only on in step 5 of the scenario (figure 3), andtherefore belongs to all groups except N5 (i.e ND4).w2.flow is abnormally inactive in step 5 but wouldnormally be active in step 7 and therefore belongsto ND4 and ND6. The symptom tree firstly selectsthe top ranking measurement containing ND0. Thisis the sw r measurement. Since this also includesND1-ND3 another measurement is sought from thelist that includes ND4. This is the w2 measurementand completes the full set ND0-ND7 and comprisesa complete symptom: S1 = (sw r.Position:on ∧w2.flow:inactive, {w1.fracture}). The process contin-ues until no more symptoms are found.

It is desirable that symptoms are complete sothat a valid symptom should indicate all detectablefaults. Therefore given S = (E,F ) is a symptom

11

ORDERED MEASUREMENTS:

sw_r.Position:onw2.flow:inactivew1.flow:inactivesw_g.Position:offw8.flow:inactivew7.flow:inactivelmp_g.illuminated:offw6.flow:inactivew5.flow:inactivelmp_r.illuminated:offsw_lmp.Position:onsw_w.Position:offw4.flow:inactivew3.flow:inactivelmp_w.illuminated:off

FAULT: w1-fracture step 5

LEVEL: 1 [ND0, ND1, ND2, ND3, ND5, ND6, ND7] sw_r.Position:on NOMINAL

LEVEL: 2 [ND4, ND6] w2.flow:inactive *LEAF* ABNORMAL w1.flow:inactive *LEAF* ABNORMAL

LEVEL: 2 [ND4] w6.flow:inactive *LEAF* ABNORMAL w5.flow:inactive *LEAF* ABNORMAL lmp_r.illuminated:off *LEAF* ABNORMAL

TOTAL SYMPTOMS FROM OBSERVATION: 5SHORTEST SYMPTOM: 2

Failure w1.fracture step 5RANK:

23980 80 64 64 64 64 16 16 16 7 2 2 2 2

N

[ND0, ND1, ND2, ND3, ND5, ND6, ND7][ND4, ND6][ND4, ND6][ND6][ND6][ND6][ND6][ND4][ND4][ND4][ND0, ND1, ND2][ND1][ND1][ND1][ND1]

SYMPTOM TREE

Figure 6: First w1-fracture observation producing symptoms

and E(OBS) is the result of evaluating E on a setof observations:

(∀OBSMn )((M ∈ F )⇔ E(OBSM

n )) (16)

This leads to an additional element in the symp-tom generation. Each completed symptom mustbe compared with the observations associated withall other failure mode observations and additionalfaults included in the symptom to ensure constraint16 is satisfied. In practice this is a case of mergingthe symptom trees produced from each observation.

4.2. Equivalent measurementsIt is common for several different measurements

to have equivalent diagnostic power within a symp-tom produced from a single fault observation. Asimple concrete example is provided by two wiresconnected in series; a lack of current flow in eitherone will indicate the same faults. The presence ofequivalent observations leads to more than one mea-surement with identical index(o) values in equation15. These symptoms can be handled in two ways.Either symptoms must contain disjunctive expres-sions that allow for any one of a number of mea-surements to be used, or several independent symp-toms are generated, one for each of the equivalentmeasurements. The symptom generation algorithmtherefore simultaneously includes all measurementswith the same index number as mp at step 2 and 6.

4.3. Fault exonerationThe diagnostic symptoms as generated in the pre-

vious sections should not be negated to performfault exoneration - a symptom expression evaluat-ing to false does not necessarily indicate fault ab-sence. For example consider a lamp with a plausiblesymptom:

S = (lamp↔ inactive ∧ switch↔ on,{lamp blown, switch corroded, wire fractured})

If the switch is off then switch↔ on is false resultingin a false symptom expression, but this does notimply the lamp is OK - it could be blown.

Manually crafted symptoms are often condi-tional so that ¬E will exonerate all of the faultsin F . This is because engineers consider the im-plication of not seeing the symptom as well as itspresence. The Bayesian net based diagnostic sys-tem for which the symptoms are being generatedrequires that symptoms can exonerate faults andtherefore (∀M ∈ F,∀n)(¬E(OBSM

n ) =⇒ M 6∈ D).This also allows better fault detection by allowingevidence from nominally operating parts of a sys-tem to contradict evidence from general symptoms,hence reducing the set of possible faults.

Assigning Ec ≡ switch ↔ on and Eo ≡ lamp ↔inactive, the earlier example can be reformed (Ec ∧Eo, {lamp blown, switch corroded, ...}) and (¬(Ec →Eo), {¬lamp blown,¬switch corroded, ...}). The sepa-rate conditional part Ec must be satisfied for thesymptom to be valid. Any valid symptom that isnot satisfied (i.e. Ec ∧ ¬Eo) can be used to exon-erate the associated faults. For the example if theswitch is on and the lamp is active then we can pre-dict that the lamp is not blown, the switch contactis not dirty, and the wire to the lamp is not frac-tured. A valid symptom that is satisfied implicatesthe associated faults. A symptom that is not validprovides no information.

To ensure negatable symptoms, E is partitionedto produce Ec and Eo to ensure the symptom is ei-ther satisfied or invalid for any observation OBSM

12

where M ∈ F . That is, a symptom expression mustnot exonerate a fault for an observation where thefault exists. Therefore if S = (Ec, Eo, F ) measure-ments must be included in Ec to ensure:

(∀M ∈ F,∀n, @OBSMn )(Ec ∧ ¬Eo) (17)

For symptoms formed as a conjunction of measure-ments, E = {m1, m2, ...} then ¬E = ¬m1 ∨ ¬m2...That is, if one of the measurements in the (pro-posed) symptom is not present in any of the obser-vations for the fault(s) indicated by the symptom,then the symptom cannot be negated to exoneratethe fault. To satisfy sentence 17 the symptom gen-erator therefore partitions E for each symptom byfinding candidate conditional measurements as fol-lows: Ec′ = {o ∈ E | ∀M ∈ F,∀n : o 6∈ OBSM

n }.Because |Ec′ | ≤ |E| and E is very small (section 4),a simple breadth first search rapidly finds all thesmallest subsets of Ec′ that satisfy proposition 17.Finally, Eo = E \ Ec is obtained.

Figure 7 contains the full set of symptoms gener-ated for the running example. These symptoms willcorrectly diagnose the system provided we only en-ter the states provided in the FMEA. To removethis restriction, the next section will modify thesymptom generation by restricting the measure-ments available based on function state.

Using all of these candidate conditional measure-ments is often over cautious, and may lead to theinability of some symptoms to exonerate faults, par-ticularly when nominal output measurements formpart of the symptoms. As a result an initial re-finement was made that restricts the measurementsavailable for symptom generation. s is thus rede-fined as a subset of OBSM

n to include only abnor-mal measurements plus triggers associated with thefailed functions (defined in equations 7-9).

s = {(RobsAbMn }∪{T(fn))|fn ∈ RfnFaM

n }∩OBSMn

(18)This was the measurement selection used for the

ASTRAEA project to generate symptoms for a twinengine aircraft fuel system. For that system thissimple approach worked well primarily because itwas relatively easy to exercise all of the functionpermutations that could be encountered during op-eration. For the running example it does not changethe symptoms generated, since no nominal mea-surements are selected by the generation algorithm.

Subsequent experiments for complex systemswhere operating modes combining multiple func-tions were restricted in the scenario, together with

experience from systems where it is infeasible toexercise all potential function permutations, identi-fied the need to be more selective than the simpleapproach in equation 18 and is the subject of thenext section.

5. Observation selection strategies

This section details the use of functional infor-mation to produce generalised symptoms from anFMEA analysis which does not exercise all systemstates, or even all permutations of possible systemfunctionality. Generalisation enables a set of symp-toms with good coverage to be produced.

The symptom generation presented in section 4 ineffect generalises symptoms because not all systemstates are available in the FMEA. However this gen-eralisation is somewhat arbitrary. Symptoms mayinclude measurements that are not causally relevantto a fault, simply because there was no state thatprovides a counter example. Such symptoms oftenare not applicable to states outside of those encoun-tered in the FMEA. To relieve this difficulty moresteps might be inserted in the scenario, howeverthis typically leads to less simple, equally limitedsymptoms. Thus, a simple search for symptomswill produce either very limited coverage of oper-ating modes or possibly artifactual symptoms forrealistic FMEA scenarios, due to incorrect assump-tions on unobserved state. To address these issuesthere are two possibilities:

• Ensure the necessary states are provided bythe FMEA. As noted previously, adding stepsto the scenario simply shifts the problem, andultimately a complete attainable envisionment[10] is required. In addition a great deal of in-sight is required to determine which additionalsteps are required. For these reasons this ap-proach is infeasible for most real systems.

• Constrain the search based on states relatedto structural and behavioural and functionalinteractions that have been encountered duringthe FMEA.

The second approach has produced the required re-sults and is based on extracting the association be-tween components and function from the FMEA,and is the focus of section 5.1.

The associations produced allow exclusion ofmeasurement m during the generation of symptomsfor a state OBSM

n for which there is no evidence

13

Figure 7: Symptoms generated for running example system

in the FMEA that m is related to the affectedfunctions RfnFaM

n and is the subject of section5.2. Where components implement several func-tions there are implications for the states requiredin the FMEA to ensure generated symptoms arenot too specific leading to symptoms that not ap-plicable for function combinations not available inthe FMEA. Essentially this means that the mea-surements associated with multiple functions placeadditional constraints on the functional states thatmust exist in the FMEA if they are to be used.

5.1. Avoiding over generalisation

There are two parts to the process of restrictingthe measurements available for symptom genera-tion based on the associated function states.

• Identify which measurements are behaviourallyassociated with each function. This is de-scribed in section 5.2.

• Select the available measurements for symp-tom generation based on the failure state offunctions for each observation. This is de-scribed in sections 5.2.1 and 5.2.2

Clearly measurements referred to in the functionalmodel trigger and effect expressions notated (T(fn)and E(fn)) are associated to the function, howevermost measurements that might be used for diagno-sis are not contained in these expressions. In ad-dition those measurements used in triggers and ef-fects are often not directly available to a diagnostic

system, particularly an on-board system, where in-direct measurements of the inputs and outputs arerequired.

The concept of a function associated mea-surement(FAM) is used to indicate a measure-ment has some behavioural or structural ‘causal’relationship to a function based on evidence fromthe FMEA. The measurements associated with fnare denoted by the relations Ab(fn) and Nom(fn)that provide respectively, the abnormal and nomi-nal measurements associated with a function. Of-ten these will simply be different value measure-ments from the same sensor however this is not as-sumed.

5.2. Associating measurements to functionsMeasurements are associated with system func-

tions based on the achievement and failure of func-tions across the entire FMEA. Given a comprehen-sive set of failures this provides a simulation de-rived description of which functions each compo-nent/measurement affects. This in turn allows anassessment of the relevance of measurements associ-ated with a fault; This technique ensures that irrel-evant measurements are not included in symptoms,and hence that symptoms are as general as possible.Conversely the decision as to which measurementsare relevant is derived from the entire set of fail-ure and non failure states encountered during theFMEA.

Given a comprehensive component fault list, al-most all diagnostically interesting measurements(with the exception of externally controlled trig-gers) will be affected by at least one of the failure

14

modes of the system. By associating these abnor-mal measurements with functions that simultane-ously fail we build up a FAM mapping. Even mea-surements structurally adjacent to external triggerswill be affected by faults in the connecting compo-nents. For example switch.position↔ on is a triggerhowever the current flow through the switch.contact

will be affected by faults such as the contact be-ing stuck or wiring faults in the switch circuit andcould be used as diagnostic measurements.

It is normal practice to exercise each function in-dividually4 during an FMEA and therefore abnor-mal measurements are available for each isolatedfunction. Computing Ab(fn) from an FMEA usingthe definition of RfnAb and RobsAb from equation7 and 10 is a matter of aggregating all of the theabnormal observations that occur during states inthe FMEA where single functions fail:

Ab(fn) =S

∀M,∀n≤|SCN|

(RobsAbM

n , if c

∅, otherwise

c = RfnFaMn ↔ {fn}

(19)Nom(fn) are the measurements in the nominal

state minus the nominal measurements from thefailure state.

Nom(fn) =S∀M,∀n≤|SCN|

(OBSn\(OBSM

n \RobsAbMn ), if c

∅, otherwise

(20)

Generally this produces a set of measurements thatagree with engineering expectation of the compo-nents used to implement each function. Howevereven if this is not clear, there must be a structural orbehavioural relationship between the function andthe measurement, as required for measurement se-lection.

Notice that m ∈ Ab(fn) specifies only that mcan be affected by a failure of fn in at least onestate and not that it will necessarily occur in allstates when fn fails. Therefore in general Ab(fn)∩Nom(fn) 6= ∅. Table 1 contains Ab(fn) and Ab(fn)for the running example.

Several variations of measurement selection arepossible that trade the simplicity of measurement

4It is not always possible to exercise each function in-dividually, however this also makes these operating modesimpossible during nominal operation, and therefore the asso-ciated measurements can simply be captured for the requiredgroups of functions

selection against the power of the symptom and thepossibility of spurious symptoms. All variations re-define the measurement selection s in equation 12to provide a restricted set of measurements.

5.2.1. Selection based on function associated mea-surements

Using the FAM to provide tighter selection of theabnormal measurements, s, gives better protectionagainst spurious symptom generation, when the fi-nal system will exercise function combinations notfound in the FMEA scenario:

s = {(Abn(fn) | fn ∈ RfnFaMn } ∪ T(fn)) ∩OBSM

n

(21)Allowing nominal observations in addition to

triggers will increase the range of symptoms thatcan be generated:

s = {(Abn(fn) ∪Nomn(fn)) | fn ∈ RfnFaMn }

∪ T(fn) ∩OBSMn

(22)In particular, for systems where a fault only causesartefacts in part of the affected function(s) be-haviour, it allows symptoms to be generated thatidentify the internal inconsistency in the function.For example if one branch of a parallel circuit (pro-viding a single function) fails then symptoms aregenerated that measure nominal flow in one branchand abnormal in another. It is thus important thatthe major sub-states of the function are exercised,such as any available control of the branches of aparallel circuit, particularly if ‘fully instrumented’systems are being investigated as a prelude to sen-sor selection.

Fully instrumented systems make large numbersof observations available for symptom generation,and many alternative symptoms can be generatedrepresenting alternative combinations of internalmeasurement inconsistencies. An engineer can thenuse external information and diagnosability tools[22] to select the most convenient measurements toachieve the required diagnosability, for example.

5.2.2. Selection based on shared function measure-ments

Measurements selected using equation 21 and 22can still lead to spurious diagnoses for novel func-tional combinations that share components due tofalse exoneration. To illustrate the issue, figure 8

15

Function, fn Function associated nominal measurements, Nom(fn)

produce red light lmp r.illuminated:on, w1.flow:active, w2.flow:active, w5.flow:active, w6.flow:activeproduce green light w1.flow:active, w2.flow:active, lmp g.illuminated:on, w7.flow:active, w8.flow:activeproduce white light lmp w.illuminated:on, w3.flow:active, w4.flow:active,

Function associated Abnormal Measurements, Ab(fn)

produce red light lmp r.illuminated:off, w1.flow:inactive, w2.flow:inactive, w5.flow:inactive, w6.flow:inactiveproduce green light lmp g.illuminated:off, w1.flow:inactive, w2.flow:inactive, w7.flow:inactive, w8.flow:inactiveproduce white light lmp w.illuminated:off, w3.flow:inactive, w4.flow:inactive

Table 1: FMEA derived function associated measurements for the running example

Vcc gnd

w1

w2 sw1

Symptom when sw1=closed: w1=inactive indicates w2.fracture

Function A: sw1=closed triggers l1=active

l1

sw2

Function B: sw2=closed triggers l2=active

Symptom generated if A and B not exercised concurrently in scenario. Will provide false

exoneration of w2 when both switches closed

l2

Figure 8: False exoneration caused by a limited FMEA scenario

depicts a simple circuit that implements two func-tions A and B that share some components in-cluding w1. Assume the functions A and B were(for reasons explained in section 5.2) not exer-cised simultaneously during the FMEA. The symp-tom shown in the diagram is generated becausein all scenario states where the fault exists andsw1=closed then w1 is inactive, and both measure-ments will clearly be associated with the failed func-tion. This symptom exonerates the fault whenboth functions are triggered because the symptomis valid (sw1=closed ) but w1 is active allowing thesymptom to evaluate false.

One solution is to exercise both of the functionssimultaneously in the scenario, thereby creating astate where w1 is active when sw1=closed (becausecurrent will flow for function B when A fails) forc-ing the symptom generation to include additionalmeasurements in the symptom, for example the po-sition of switch sw2. As described previously, forsome systems it is possible to activate all of thesystem functions simultaneously in the FMEA sce-nario, however complex systems often have limita-tions on the combinations of attainable functionsprecluding this approach, and in some cases spe-

cific combinations of functions may be required. A‘safe’ solution is therefore to disallow measurementsassociated with several functions if any of the func-tions is In or Un.

If ASh is defined as the abnormal measurementsthat are not shared with inactive function combina-tions and given fn ∈ RfnFaM

n and fs ∈ (RfnInMn ∪

RfnUnMn ), the measurement selection in 21 be-

comes:

ASh = {x | x ∈ Abn(fn) ∧ x 6∈ Abn(fs)}

s = ({x ∈ ASh | fn ∈ RfnFaMn } ∪ T(fn)) ∩OBSM

n

(23)Similarly for the nominal measurements NSh, themeasurement selection in 22 is modified to:

NSh = {x | x ∈ Nomn(fn) ∧ x 6∈ Nomn(fs)}

s = ({x ∈ (ASh ∪NSh) | fn ∈ RfnFaMn }

∪ T(fn)) ∩OBSMn

(24)This may prevent some faults being diagnosed,and a reduction in the number of operating stateswhere faults are diagnosable. If a significant dif-ference in the diagnosability of the system exists

16

between equations 24 and 22 the function combina-tions causing measurements to be abandoned basedon function sharing can be reported and the sce-nario can then be extended. Alternatively in somesituations, for example where functions are mutu-ally exclusive (activated by different positions of aswitch), they can be included in a list of allow-able unexercised function combinations for sharedmeasurements. There may be scope for determin-ing mutually exclusive functions from the functionmodel, but this has not been investigated becausein practice the issue has not arisen.

Neither of the measurement selection mecha-nisms above make any use of unexpected functionachievement to produce symptoms. This is for tworeasons.

• Symptoms based on unexpected functionswould require the absence of trigger measure-ments in an observation to be included as partof the symptom expression making it necessaryto identify the sets of mutually exclusive mea-surements that form ¬T(fn) to allow suitablemeasurements to be selected that represent thetrigger absence.

• Since Nom(fn) are required for Un(fn), it isnecessary to ensure that all abnormal (failedand unexpected) functions present in an ob-servation also exist in their achieved form inthe nominal observations. Failing to do thiswould allow symptoms based on nominal mea-surements of function combinations that havenot been observed in the nominal state.

To complete the running example, we can see fromtable 1 that w1 and w2 have measurements sharedbetween the red and green functions. The effect ofthis on symptoms generated using measurement se-lection in equation 24 is to remove symptoms 4-7from those in figure 7. In addition no w1 and w2faults are diagnosed by the remaining symptoms.This is because these components are shared be-tween two functions that were never exercised si-multaneously in the scenario. To allow these com-ponents to be diagnosed, and also for their mea-surements to be usable, the scenario is extended toinclude the state where both red and green func-tions are activated (the symptom generator can ad-vise which shared measurements are unusable andwhich function combinations are required to allowthem). The functional model also indicates thereis a dependency between these functions because

they share the sw lmp.Position on trigger, thereforethe state where sw lmp.Position on, sw r.Position off,sw g.Position off is also included in the scenario.

The resulting symptom set in figure 9 providesno spurious diagnoses in any system state. An ex-haustive analysis of the evaluation of the symptomset for all of the 16 possible states of the systemreveals that these symptoms place the actual faultin the top rank set for each fault as shown in fig-ure 10. The two numbers a/b in each cell of thetable indicate that the inserted fault was in the topranking set of faults (a=1) and the how many otherfaults b, were contained in the top ranking diag-nosis. The ranking used is simply a count of thesymptoms indicating the fault minus symptoms ex-onerating the fault. For example, the state repre-senting all switches on (rightmost column) shows1/2 for the w1.fracture fault the because the diag-nosis included this fault in the top ranking faults,of which there were two. The additional informa-tion F6 S10 for this entry indicates that there werea total of six positively ranked faults and ten symp-toms that were valid (either for fault indication orexoneration).

6. Diagnosis framework

The symptom set can be used to analyse diag-nosability and fault isolation for a given set of mea-surements. The symptoms are qualitative in natureand an engineer must determine thresholds or ap-ply additional techniques for these values if they areto be used for an on board diagnostic system. Oneapplication where the symptoms are used as themeasurement-fault mapping of a Bayesian networkcould adjust the symptom weights based on a fuzzydescription of the qualitative values for example.

For systems with a well defined set of sensor out-puts, the diagnosable components and states canbe determined by simple analysis of the symptomsgenerated. In another application the task is to de-termine the best n measurements that can diagnosethe maximum number of faults. Since it is trivialto generate symptoms based on any set of systemvariables it is possible to use the symptoms to assistin the selection of potential sensors. One tool to dothis was described in [22].

The ASTRAEA target application uses the gen-erated symptoms in a Bayesian network to producefinal diagnoses by adding probabilities to the symp-tom elements;

17

Figure 9: Enhanced Symptoms generated for running example system

• The component fault prior probability de-scribes component reliability.

• The symptom leak probability captures theprobability that the symptom is observed eventhough there is actually no fault.

• Fault symptom conditional probability cap-tures the probability that when the symptom isobserved it is due to the fault indicated ratherthan any other fault. This can be useful fornoisy signals for example.

The probabilities allow for intermittent or unreli-able measurements to be used. They also allow thecharacteristics of the mapping between quantita-tive measurements and qualitative values (e.g. nu-merical thresholding) to be taken into account asa certainty measure on the symptom for numericalmeasurement ranges that cannot be clearly mappedto the qualitative values used.

For the purposes of investigating the diagnosabil-ity properties of a system and validating symptomsat the qualitative level, another tool (figure 11) al-lows the system to be exercised interactively, andany combination of faults inserted. The figure usesthe symptoms from figure 9. The system can be

exercised in the top section of the tool interface,measurement visibility selected in the center leftsection. The diagnosis is presented in the lowersection, with the valid symptoms that implicate orexonerate faults. The ‘I/E’ column is shown tickedif the symptom indicates its associated faults andnot ticked if it exonerates them. The faults impli-cated by any symptom can be shown by selectingit (S12 in the figure), and finally a fault ranking isgiven based on number of satisfied and exoneratedfaults.

6.1. Multiple faultsThe diagnostic system can only explicitly diag-

nose multiple faults if a multiple fault FMEA isperformed. Previous work has described how a mul-tiple fault FMEA can be efficiently performed usingthis technology [18, 17, 14], and so there is no con-ceptual barrier to diagnosing multiple faults. Mul-tiple fault FMEA analysis can by run for exampleby selecting only combinations of faults with highercombined component failure likelihoods. The mul-tiple faults are then considered as a single com-pound fault within symptoms. If f12 represents si-multaneous occurrence of two failures f1 ∈ M andf2 ∈ M, the symptom set could be modified by

18

Elements are shown as fault-group rank/equivalent-rank-faultsF indicates total number of positively implicated faults S indicates total number of activated and satisfied symptomsSETTING:sw_w.Position 'off' 'on' 'on' 'on' 'on' 'on' 'on' 'on' 'on'sw_lmp.Position 'off' 'on' 'on' 'on' 'on' 'on' 'on' 'on' 'on'sw_g.Position 'off' 'on' 'on' 'on' 'on' 'on' 'on' 'on' 'on'sw_r.Position 'off' 'on' 'on' 'on' 'on' 'on' 'on' 'on' 'on' Nominal w1.fracture 1/4 F4 S5 1/4 F4 S5 1/4 F4 S5 1/4 F4 S5 1/2 F6 S10 1/2 F6 S10 w2.fracture 1/4 F4 S5 1/4 F4 S5 1/4 F4 S5 1/4 F4 S5 1/2 F6 S10 1/2 F6 S10 w3.fracture 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 w4.fracture 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 1/2 F2 S3 w5.fracture 1/4 F4 S5 1/4 F4 S5 1/2 F2 S9 1/2 F2 S9 w6.fracture 1/4 F4 S5 1/4 F4 S5 1/2 F2 S9 1/2 F2 S9 w7.fracture 1/4 F4 S5 1/4 F4 S5 1/2 F2 S9 1/2 F2 S9 w8.fracture 1/4 F4 S5 1/4 F4 S5 1/2 F2 S9 1/2 F2 S9

Figure 10: Exhaustive validation of symptoms for running example

multiple fault FMEA in one or more of the follow-ing ways:

1. A unique symptom, SNEW = (E, {f12}) is pro-duced that would allow the multiple fault to beisolated.

2. A symptom, Sn = (E, {f3, f12}), is producedthat is identical to the symptom for a differentfault.

3. Symptoms are produced that are the same assome or all of the individual faults. Sn =(E, {f1, f12}) or Sn = (E, {f2, f12}) or Sn =(E, {f1, f2, f12}) .

4. The multiple fault case produces no symptoms.

Without using multiple fault FMEA, we find em-pirically for the systems tested, the most commoneffect of multiple faults is that all or some of theindividual faults appear in the highest rank of pos-sible faults (case 3 above). For case 1 and 4 abovethe multiple fault is not diagnosed. If only case 4occurs then the multiple fault is not diagnosable,this could be two faults that negate each other andprovide no overall effect on the system.

Case 2 is the only one where the multiple faultcould lead to a spurious diagnosis; f3 would be diag-nosed if f1 and f2 occurred simultaneously. Empir-ically we have found that the most likely situationis a case of fault masking where all the faults areassociated to the same function and f3 masks themultiple fault. Parsimonious principles dictate thatthe diagnosis f3 would be a preferred initial diag-nosis, and is the result provided by the symptomsproduced without multiple faults. Once f3 is ex-onerated, by exercising additional faults or includ-ing additional measurements, without the multiplefault simulation the fault could not be diagnosed.For example, if two lamps wired in parallel bothfail: the effect is the same as the main supply fail-ing, and given that it is impossible to distinguish

these faults the single fault is more likely unless thesupply can be exonerated.

7. Example systems

We present the results of the symptom generationfor two case studies.

The Aircraft Fuel system was a test system usedas a technology demonstrator, and had the advan-tage of a laboratory based physical model that in-cluded all of the relevant tanks, pumps and valvesincluding various fault injection mechanisms, allow-ing a physical validation of the diagnosis. For thissystem, the sensors were already defined and there-fore there was a relatively small number of mea-surements to be made available for symptom gen-eration. The task was to produce symptoms thatindicated faults, rather than perform sensor selec-tion based on likely diagnosability.

The Automotive example was an electrical exte-rior day time running lighting system (DTRL). Weuse this example to illustrate the ability to generatediagnostics from an FMEA that did not exercise allfunction combinations, and indeed did not exerciseone entire function, demonstrating that the result-ing diagnosis is able to diagnose all faults exceptthose related to the implementation of the disre-garded function. This example was also used toillustrate symptom generation based on ‘high ob-servability’ by allowing the current flow in everywire component to be used to generate symptoms.

For both systems the symptom generation pro-cess takes a tiny fraction of the processing time thatthe FMEA generation takes. The simulation andsymptom generation is coded in Java and has notbeen optimised in any sense. A 2.4Ghz Core 2 lap-top completes FMEA generation for either systemin around 2-30s per fault for a sensible scenario re-quiring of the order of an hour in total. The symp-

19

Figure 11: Tool interface used to manually investigate diagnosability of the example system

tom generation takes less than a minute in total foreither system. Evaluating the symptom set for aspecific set of observations requires evaluation of asmall number of simple logical and arithmetic ex-pressions and is extremely fast (milliseconds), re-quires only a few hundred lines of code, and hasminimal memory requirements. The running exam-ple system takes around 5s to produce the FMEAand 2s to produce the symptoms, but most of thistime is initialising the Java virtual machine.

From an engineers perspective the major inputsto the system are a system schematic (componentsand connections) and a set of qualitative componentmodels that define the structure and behaviour ofthe components. Component models may comprisea resistance network connecting component termi-nals, and state machines that describe higher levelbehaviour or non linear behaviour aspects. Suchmodels are usually obtained from a library, and thequalitative nature of the modelling allows gener-alised modelling of component classes. One possi-ble modelling approach for electrical systems [20]has been extended to allow modelling of systems

from other domains such as hydraulic, fluid flow andthermodynamic by utilising generalised power andenergy flow models using a qualitative approach re-lated to the well known Bond graph theory.

For non switching systems qualitative distinc-tions may appear too coarse to capture the requiredbehaviour, however this is not necessarily the case.Additional techniques such as exaggeration reason-ing [25] may be used to define faults. For example ina fluid flow system a leak in a pipe may not producea qualitatively significant change in flow, however ifwe treat the extreme case of the leak as a fracturethen the flow in the system will have changed qual-itatively. The FMEA (and subsequent symptoms)can therefore report that a potential symptom forthe leak may be high or low flow in the relevantparts of the system.

The qualitative modelling and resulting symp-toms provide comprehensive analysis of the systemcovering all qualitatively distinct regions of nominaland failure behaviour. The main requirement forsuccessful FMEA and symptom generation is thatthe qualitative values utilised in the system simula-

20

tion description are able to represent the significantsystem states and failure effects.

The second task for the engineer is to capturethe system functions in the functional model out-lined in section 3.2. These models identify the trig-gers and effects that relate to each system func-tion and can usually be defined with a set of rel-atively simple logical expressions relating systeminputs to expected outputs. Where necessary, thefunctional model can be sophisticated, involving hi-erarchical functional structures with propositionallogical (and temporal logic) expressions to definethe required behaviour [2].

A scenario is provided by exercising the systemfunctions, allowing an FMEA is automatically gen-erated and considered by engineers as per usualpractices. No further input is required to producethe symptoms which are generated for any abnor-mal behaviour that has qualitatively significant be-havioural deviations. The simulation and FMEAtechniques have been widely used for electrical sys-tems with switching behaviour [13] where a quali-tative order of magnitude approach [21, 12] allowsdistinctions between power circuit and signal circuitbehaviour to be made for example. Recently, fluidflow systems have also been successfully modelled,and the energy flow based structural modelling pro-vides an expectation that the methods will be ap-plicable to other domains also.

7.1. Aircraft fuel system technology demonstratorThe system in figure 12 comprised approximately

98 components with failure modes, including 4tanks, 8 multiway valves and 7 pumps. Therewere 239 faults considered in the FMEA includ-ing full and partial blockages, leaks, valve stuckfailures, tank leaks, and pump failures. Measure-ments included values from several pressure andflow sensors, valve position actuator request andmicroswitch tell-back values, and tank level mea-surements. The difference between the number ofsymptoms using abnormal measurements only (64)and the symptoms generated using both abnormaland nominal measurements (104) is not so markedwith this system, due to the relatively small quan-tity of measurements available. An example of partof the symptom expression set is shown in figure13. PT refers to pressure transducer measurements,TVL are multiway valves, and CP are pumps. Thissystem required no more than two measurementsto form any symptom and each symptom is asso-ciated with between 1 and 40 faults (not shown).

The colon symbol is used to separate the symptomcondition from the main observations. The symp-toms containing only a condition are effectively notnegatable and cannot exonerate faults, since it isvalid and considered satisfied when all of the mea-surements are observed, and can never be valid andunsatisfied.

Figure 14 shows a breakdown of the number offaults that can be diagnosed in 17 of the main op-erating states of the system. These are 6 majorfunctions available based on various valve config-urations, and it is clear that there is one majoroperating state for each function that allows themajority of the faults for that function to be diag-nosed. The other operating states for each func-tion are where valves have been configured but thepumps are not activated, and as expected manyfaults cannot be detected in these states. Thecolumns representing the number of faults in eachstate are subdivided according to the number ofother faults that ranked equal top in the diagnosis.Given the limited amount of sensing available forthe system, there are inevitably significant num-bers of faults that are indistinguishable from themeasurable observations; the diagram however onlyconsiders individual states, some faults can be iso-lated by switching states, for example componentsthat contribute to several functions can be isolatedthis way. Finally the symmetrical structure of thesystem is revealed by the symptom set; the systemhas left and right halves and the ability to feed ei-ther engine from either wing tank. It is no surprisethat the diagnosability of left and right, normal andcross fuel feed is similar.

7.2. Daytime running lights systemThis system was supplied by Sumitomo Electri-

cal Wiring Systems Europe Ltd and comprised 166electrical components, including several multiplecontact switches, lamp clusters and splices. 63 com-ponent faults were considered for the analysis com-prising mostly of wire fractures since these providegood coverage of the circuit topology. The currentflow in all wires was made available as a measure-ment, together with the components that normallyproduce an input or output such as switches andlamps. The system is designed such that the highbeam can be activated if the main switch is in theany position, the sidelights are activated if the mainswitch is in the sidelights position, and the dip andmain beam are both available when the main switchis in the mainlights position dependent on the dip

21

switch position. The FMEA activated the fol-lowing function states: off-dipbeam, off-highbeam,sidelights-dipbeam, mainlights-dipbeam. The day-time running function was not activated for the pur-poses of illustration. The number of symptoms gen-erated depends on the measurement selection strat-egy and is shown in table 2.

The diagnostics were verified by running the sim-ulation for each fault for a set of operational states.These states included the two major operationalstates that were missing from the original scenario:sidelights-highbeam, mainlights-highbeam. Theseare highlighted in table 2 which summarises theresults of testing the diagnostic system for eachof the symptom generation strategies from selec-tion strategies in equations 18-24. The table showsthe number of correctly detected faults (insertedfault was in the top or equal top ranking predictedfaults), with the number of incorrectly identifiedfaults (higher ranking than the actual fault) insquare brackets. For this system the real fault wasnever worse than second ranking, with between 25and 2 higher equal ranking predicted faults.

It is clear in column 18 that simply using ab-normal measurements and triggers leads to incor-rect fault identification when the system enters newstates that were not exercised in the FMEA sce-nario, as expected. Allowing FAM associated withfailure of the function significantly reduces the num-ber of symptoms and also reduces the number ofmis-identification of faults (column 21). AllowingFAM associated with nominal operation maintainsthe reduction in mis-diagnoses, however it increasesthe number of symptoms by allowing abnormal re-lationships within function activity to be used assymptoms. This will provide more flexibility in thechoice of measurements that might be used (sincethe final diagnostic system will not have the abil-ity to monitor every wire). A tool to display themeasurement-symptom-fault relationships visuallyis described in [22]. The final two columns showthe effect of excluding all measurements associatedwith shared functions that have not been activatedsimultaneously for the same setup as 21 and 22 re-spectively. The two faults that were mis-detecteddue to spurious fault exoneration no longer exist,however the total number of faults that can be di-agnosed is also reduced. The diagnosis generatorreports that some measurements were unable to beused because the scenario found no instances wherethe sidelights function and highbeam function werefailed or achieved together. This then would pro-

vide a direct indication to the engineer that this op-erating mode could be added to the scenario to im-prove the symptom set, since the failure behaviourof the system shows that they share components/orbehaviour and could therefore interact.

Some of the faults could not be detected at allbecause part of the circuit functionality was notexercised in the FMEA. This is to be expected forany fault in the FMEA that has the report“No ex-ternal behaviour or functional effects”. There were15 such faults in the FMEA and therefore the max-imum number of faults that could be expected tobe detected based on the FMEA information is 48.Figure 15 shows a breakdown of the number offaults that can be diagnosed in the 6 main operatingstates of the system using measurement selectionmethods in equation 23 (or 24) and full measure-ment visibility. State 4 and 6 were not exercised inthe scenario but clearly produce good fault detec-tion. The columns are subdivided according to thenumber faults that ranked equal top with the actualfault in the diagnosis. In this system the maximumnumber of faults that cannot be distinguished is 9.A selection of these were analysed in detail and aregenerally wire failures in series circuit elements thatcould not be isolated further without external inter-vention. There were no faults in the first operatingstate because activating the dipbeam function withthe ignition off results in no electrical change in thecircuit and merely a change to the switch position.

8. Conclusion and future enhancements

The initial concept for this work was to replacethe use of manual FMEA as the input to a Bayesiannetwork based diagnostic system with an auto-mated FMEA. It rapidly became clear that thecomprehensive nature of an automated FMEA ac-tually makes the identification of general symptomsmore time consuming - although the resulting diag-nostic system is more powerful. Automation of thegeneration of the symptoms was an obvious nextstep, although emulating the selectivity and addi-tional knowledge imparted by an engineer provedto be a challenge, and was finally addressed by theuse of the functional model that already plays therole of interpreting detailed behaviour into a moremeaningful abstracted description.

An unexpected - and for the ASTRAEA projectan exciting possibility - was the ability to gener-ate symptoms based on all potentially measurablequantities in a system. The resulting large set of

22

Measurement selection strategy18 21 22 23 24

Symptoms Generated 1014 72 968 52 828Total diagnosable faults 48 48 48 46 46

Operational State

dipbeam 0 0 0 0 0highbeam 13 13 13 11 11sidelights-dipbeam 31 31 31 29 29sidelights-highbeam 13[25] 36[2] 36[2] 36 36mainlights-dipbeam 17 17 17 15 15mainlights-highbeam 20[4] 22[2] 22[2] 22 22

Table 2: Fault detection for DTRL system (63 faults available in the FMEA)

symptoms (1000+ for typical automotive systemexamples) paves the way for a sensor selection toolthat allows an engineer to quickly analyse whichmeasurements may be most useful for a given setof ‘diagnosability’ criteria. The potential diagnos-ability of a system can therefore be investigated inbroad qualitative terms early in the design, possiblyleading to alternative solutions that build diagnosisinto preliminary design rather than as a retrofit ac-tivity. An early version of this tool is documentedin [22].

Currently, symptoms are based on qualitativesystem states and do not include sequences of statesin the description of behaviour that may indicate afault; however, fault isolation may be carried outby considering symptoms related to multiple sys-tem states. Systems that include internal (hidden)state that affects fault behaviour will result in nosymptom being generated for affected faults in therelevant operating modes due to a lack of observa-tions able to distinguish the faults. These can thenbe highlighted to the engineer and if necessary somemechanism for providing the additional state to thediagnostic system can be included.

The technique is applicable to any system forwhich the automated FMEA can be generated[14, 15, 24]. Applicable systems have behavioursand faults of interest that can be represented qual-itatively and these types of systems tend to betopologically complex with component behavioursrepresented by a relatively small number of lin-ear behaviour regions. This allows the symptomsproduced to cover qualitative regions of behaviour.Systems where the behaviour is highly nonlinear atthe level of abstraction required or where the mea-surements required for diagnosis are not qualita-tively significant, will not be amenable to the anal-

ysis because the system behaviour does not form areasonable finite state description.

The functional model had not yet been utilised toits full potential in symptom generation. For sys-tems with complex functional dependencies such aswarning, fault mitigating, interlocking, rechargingfunctions that may be described in the FIL, as wellas functions that share triggers and effects we be-lieve the functional model can provide additionalinformation to ensure the FMEA scenario includesthe worst case faults and effects, and also ensure therelevant states are included that allow a compre-hensive set of symptoms to be generated. Furtherinvestigation is planned in this area.

In summary, this paper demonstrates the gener-ation of a diagnostic system from the results of anautomated FMEA. We have deployed software us-ing the algorithms described here on several realsystems including an aircraft fuel system that wasthe main diagnostic case study for one of the AS-TRAEA [9] project. The focus of this work wason single component failure modes, however manymultiple failure modes are completely or partiallydiagnosed and possibilities are available to extendthe analysis into multiple failure modes if requiredat the computational expense associated with ad-ditional simulation.

8.1. Acknowledgements

This work was supported by Aberystwyth Uni-versity, the Welsh Assembly Government, BAE Sys-tems and the DTI ASTRAEA Programme. We arealso grateful to the anonymous AEI reviewers fortheir valuable comments.

23

References

[1] Bell, J., 2006. Interpretation of simulation for modelbased design analysis of engineered systems. Phdthesis, University of Wales Aberystwyth, email:jpb@aber.ac.uk.

[2] Bell, J., Snooke, N. A., 2004. Describing system func-tions that depend on intermittent and sequential be-havior. In: Proceedings 18th International Workshopon Qualitative Reasoning, QR2004. pp. 51–57.

[3] Bell, J., Snooke, N. A., Price, C. J., Oct 2007. A lan-guage for functional interpretation of model based sim-ulation. Advanced Engineering Informatics 21 (4), 398–409.

[4] Cascio, F., Console, L., Guagliumi, M., anda. Panati,M. O., Sottano, S., Theseider-Dupre, D., 1999. Strate-gies for on-board diagnostics of dynamic automotivesystems usingqualitative models. AI Communications.

[5] Chandrasekaran, B., Josephson, J. R., 2000. Functionin device representation. Engineering with Computers16 (3–4), 162–177.

[6] Chantler, M. J., Coghill, G. M., Shen, Q., Leitch, R. R.,1998. Selecting tools and techniques for model baseddiagnosis. Artificial Intelligence in Engineering 12, 81–98.

[7] Coghill, G. M., 2009. Incremental state based diagnosis.Advanced Engineering Informatics 23, 309–322.

[8] de Kleer, J., 1987. Diagnosing multiple faults. ArtificialIntelligence 32 (1), 97–130.

[9] Downes, C., November 2007. ASTRAEA T7 – an ar-chitectural outline for system health management oncivil UAVs. In: 2nd Autonomous Systems Conference.Institution of Engineering and Technology.

[10] Forbus, K., 1990. The qualitative process engine. In:Weld, D., de Kleer, J. (Eds.), Readings in QualitativeReasoning about Physical Systems. Morgan Kaufmann,pp. 220–235.

[11] Genesereth, M., 1984. The use of design descriptionsin automated diagnosis. Artificial Intelligence 24 (1-3),411–436.

[12] Lee, M. H., 2000. Many-valued logic and qualitativemodelling of electrical circuits. In: Proceedings 14th In-ternational Workshop on Qualitative Reasoning, (QR-2000).

[13] Mentor Graphics, July 2012. Capital harness product.URL http://www.mentor.com/products/electrical-design-software/capital/harness-classic

[14] Price, C. J., 1998. Function-directed electrical designanalysis. Artificial Intelligence in Engineering 12 (4),445–456.

[15] Price, C. J., Pugh, D. R., Snooke, N. A., Hunt, J. E.,Wilson, M. S., 1997. Combining functional and struc-tural reasoning for safety analysis of electrical designs.Knowledge Engineering Review 12 (3), 271–287.

[16] Price, C. J., Snooke, N. A., Lewis, S. D., 2006. A layeredapproach to automated electrical safety analysis in au-tomotive environments. Computers in Industry 57 (5),451–461.

[17] Price, C. J., Taylor, N. S., 1997. Multiple fault diag-nosis from FMEA. In: Proc. The Ninth Conference onInnovative Applications of Artificial Intelligence (IAAI97). AAAI, pp. 1052–1057.

[18] Price, C. J., Taylor, N. S., 2002. Automated multi-ple failure FMEA. Reliability Engineering and SystemSafety 76 (1), 1–10.

[19] Snooke, N., Price, C., Downes, C., d Aspey, C., April

2008. Automated failure effect analysis for PHM ofUAVs. In: International System Safety and ReliabilityConference, (ISSRC 2008). Singapore.

[20] Snooke, N. A., 1999. Simulating electrical devices withcomplex behaviour. AI Communications 12 (1,2), 45–58.

[21] Snooke, N. A., 2007. M2CIRQ: Qualitative fluid flowmodelling for aerospace fmea applications. In: Proceed-ings 21st international workshop on qualitative reason-ing. pp. 161–169.

[22] Snooke, N. A., 2009. An automated failure modesand effects analysis based visual matrix approachto sensor selection and diagnosability assess-ment. In: online proc. Prognostics and HealthManagement Conference (PHM09). PHM Society,http://www.phmsociety.org/references/proceedings.

[23] Struss, P., 2004. Models of behaviour deviations inmodel-based systems. In: R.Lopez, Saitta, I. (Eds.),16th European Conference on Artificial Intelligence.ECAI, IOS Press, pp. 883–887.

[24] Struss, P., Fraracci, A., 2011. FMEA of a braking sys-tem - a kingdom for a qualitative valve model. In: 25thInternational Workshop on Qualitative Reasoning.

[25] Weld, D. S., 1990. Exaggeration. Artificial Intelligence43 (3), 311 – 368.

[26] Williams, B., Nayak, P., 1996. A model-based approachto reactive self-configuring systems. In: Proceedings ofAAAI-96. pp. 971–978.

24

Generic fuel system schematic Figure 12: Fuel system schematic

25

Figure 13: Example of symptom expressions generated for fuel system

!"

#"

$!"

$#"

%!"

%#"

&!"

$" %" &" '" #" (" )" *" +" $!" $$" $%" $&" $'" $#" $(" $)"

!"#

$%&'()'*+,-.(/,$

0%'),

"01/'

23%&,4.-'/1,1%'

$",-"#"./0.12/34.156789":648,1" (",-"$!" $$",-"%!" %$",-"'!" '$;"

engine_supply_left

engine_supply_right

auxiliary_transfer_left

auxiliary_transfer_right

engine_crossfeed_to_left

engine_crossfeed_to_right

Figure 14: Quantity of faults diagnosable for major operating fuel system states

!"

#"

$"

%"

&"

'!"

'#"

'$"

'%"

'&"

#!"

'" #" (" $" )" %"

!"#

$%&'()'*+,-.(/,$

0%'),

"01/'

23%&,4.-'/1,1%'

'"*+,-."

#"/01/2304,/25+6-7"*+,-.2"

(".8")"

%".8"'!"

dipbeam

highbeam

sidelights-dipbeam

sidelights-highbeam

mainlights-dipbeam

mainlights-highbeam

Figure 15: Quantity of faults diagnosable for major DTRL operating states

26