ii. ariane-4 veb assembling tests

A multi-model-based approach to diagnostic

assistance: application to Ariane-4 VEB

(Vehicle Equipment Bay)

D. Macchion & D.P. Vo

ARAMIIHS laboratory, 31 Rue des Cosmonautes,

ZI du Palays, 31077 Toulouse Cedex, France

Abstract

This paper presents a fault diagnostic assistance approach which buildsin Model-Based, Case-Based and Rule-Based reasoning techniques. TheModel-Based Reasoning layer retains the description of the equipment to bediagnosed and some basic resolution capabilities. The Cased-Based Reasoninglayer stores the past incident solutions so that they can be reused for similarfuture cases. The Rule-Based Reasoning layer synthesizes the most frequentincidents under powerful expert rules. Combining these techniques in a globalresolution strategy improves the efficiency of the target Knowledge BasedSystem and increases the scope of its initial competences.

I. Introduction

Our works take place in the ARAMIIHS (Action Recherche etApplication Matra IRIT en Interface Homme Systeme) laboratory whichconnects the activities of MMSF (Matra Marconi Space France) engineers andIRIT (Institut de Recherche en Informatique de Toulouse) researchers. Thepurpose of this lab is to investigate and derive advanced computer sciencetechnologies to provide solutions for space industry needs.

The long term challenge of our works consists in designing andimplementing a Knowledge Based System dedicated to technical diagnosis.

Transactions on Information and Communications Technologies vol 1, © 1993 WIT Press, www.witpress.com, ISSN 1743-3517

714 Artificial Intelligence in Engineering

We put our emphasis on three main points : the KBS must take into account thedifferent types of knowledge available in the expertise domain; the KBS mustbe able to learn in the course of being used; the KBS resolution process shouldreflect the expert diagnostic knowledge. After studying the pro&cons of variousexisting techniques, we are currently adapting some of their concepts to a realworld diagnostic application. A first implementation of those reflexions is in the

progress of being developed.

II. Ariane-4 VEB assembling tests

The MMS-F center based in Toulouse is in charge of the assemblingof the Ariane-4 launcher VEB. These VEBs must take charge of the scheduleof the launcher flight by computing guidance actions, telemetry emissions,order diffusions... Teams of specialists and technicians devote themselves to theassembling of the VEBs which are composed of various equipments : On-Board Computer, Electronic Sequencing Unit... (see figure 1). Exhaustive testprocedures are finally run out to ensure that they globally work. Any incidentdetected by the multiple and redundant measure units must be strictly resolved.

These assembling teams have been acquiring a strong andcumbersome know-how for about seven years. So they can quickly diagnosemost of the incidents that occur during the course of the VEB tests. They havenow noticed the opportunity to have at their disposal of a system which wouldcapitalize the collective set of these experiences. We are convinced that Case-Based Reasoning technology is appropriate to perform this task.

III. Study of CBR systems

It is ten years since R.Schank published "Dynamic Memory" [16]which put forward a theory of human reasoning radically opposed to the one"Human Problem Solving" [12] had expounded ten years before. Schank assertsthat our natural way of reasoning is based on the intensive use of a collectionof past experiences which persists in some self evolutive structures inside ourmemory. Thus, when solving a problem (the target case), we would not chaintogether a set of rules; we would rather try to adapt the solution of an oldexperience (the source case) we think similar to the problem we face.

In 1983 at Yale University, J Kolodner validated some basic ideas ofthe Schank's theory in her Cyrus program [9] which memorized Cyrus Vance'strips in the Near East: the Case-Based Reasoning technology had just comeinto the world. Since then, many AI researchers have been developing CBRsystems in various applications : Casey [10] deals with heart failures; Chef [6]is a cooking planner, Prows [4] diagnoses ear disorders; Mud-Creek [1] is usedin off-shore drilling; Persuaders [18] solves labor disputes; MOLTKE [21] is aworkbench for technical diagnostic applications.


Artificial Intelligence in Engineering 715

On-BoarCompute

flightsoftware

d;r

Address.Bus

(Order)

DataBus

InterfaceUnit

,

i

1

I

r

i

)eco

i

y

^' p

dei

q

legister

602wi

(

irdre

ElectroiSequencinj

Telemei

Relay

fcf~~i*l_l

-».

Redund;equip rru

lie?Un

tryLQC— ILJ

ant>nt

it

digacqui

— 1 — IHM 1Fuse

analoacqui

italsition

r°

MUgicalsition

T\>o«-

Vehicle Equipment Bay Bench

Figure 1: The equipments involved in the sequencing order function.

The On-Board Computer creates an order; the Interface Unit sets the corre-sponding normal and redundant registers; the produced current sticks a relay;the Test Bench checks the order arrival. If an anomaly is detected, a fault mes-sage is written down on a listing.

IV. Current trends in technical diagnosis

Papers about diagnostic problems treated by AI techniques are ratherabundant. It is yet possible to classify them into two main approaches.

The Model-Based Reasoning (MBR1 approach

Model-Based diagnosis is supported by a detailed description of thesystem to be diagnosed. Every involved equipment can be described underdifferent points of view : functional (use), structural (decomposition),topological (connections)...[8]. Some flow propagation, alibi [13] orincrimination principles can operate on this representation to propose, cancel orvalidate hypotheses.

Most of these models are based on predicative languages [14] [5].Theypropose to use some dedicated diagnostic concepts such as minimal or kerneldiagnoses which are useful in multiple fault contexts. Anyway, they cannot beeasily transported into real world applications. Furthermore their resolutioncapabilities do not often reflect any human natural process.



The Rule-Based Reasoning (RBR) approach

Rule-Based Systems (RBS) have been widely used since the beginningof the Eighties. They have been applied to assistance or tutoring [11] needs.Basically, a RBS architecture runs around an inference engine which explores arule base to produce a solution. To simulate the RBS resolution process,information associated to the fired rules can be systematically displayed. Mostoften this is not enough to understand what the system is doing.

Furthermore, the construction of a fully satisfying rule base for aparticular domain is not a trivial activity. Domain know-how may be difficult totranslate into a rule formalism; maintenance on the rule base is tricky; the scopeof the RBS competence is fixed; rule base consistency is hard to establish... Allthese questions are moreover the concern of a well-studied domain of AI :Knowledge Acquisition [3].

V. A weak disfunctioning theory domain

While studying our application domain, we first discover that variousknowledge sources were available that is technical documentations, incidentforms, more or less general diagnostic principles and a large amount of domainknowledge. However, information about the VEB disfunctioning is not easy toformalize and no absolutely strict resolution method can be followed. We aretypically in presence of a weak disfunctioning theory domain. In this context,existing trends in technical diagnosis do not propose any suitable answer. Theirdiagnostic processes and representation formalisms are too rigid and clear cut tocorrectly run on this complex domain.

VI. Combining Rules, Cases and a technical Model

Considering the above problems, we propose to combine differenttechniques, namely Rule-Based, Cased-Based and Model-Based reasonings.Their respective formalism permits to take into account both technicalinformation, past encountered incident resolutions and expert rules.Furthermore, we are convinced that they can globally supplement one anotherin order to find a reliable and quick solution for a larger set of incidents.Including Case-Based Reasoning technique then facilitates the automaticacquisition of future incidents.

On the resolution process side, we decided to implement ratherstraightforward and human knowledge sources instead of developing abstractand artificial methods. Out of our expert's general diagnostic behavior [20], wenotice that he resorts on three different reasoning modes depending on theincident he faces. If the problem keeps recurring, the expert is able to recognizeautomatically its situation. If the problem already occurred, maybe he canrecall of its past global or partial resolution. Otherwise, he must activate aheavier process based on his VEB knowledge.



The different sources of knowledge involved in our expertise and thereasoning modes our expert uses led us to propose an architecture (see figure 2)that groups different knowledge layers as also described in [1], [7], [19].General domain principles as well as expert's automatisms are both formalizedinto triggered rules exploited by a reflex type reasoning. A past incident isattached to a case which details its complete resolution path and is exploitedwith an analogical type reasoning. Finally, the VEB functioning is kept in atechnical model which is exploited by a dedicated Model-Based Reasoning. Thestrategy we adopt to get a diagnosis consists in calling first the RBR module. Ifno rule is available, we address the problem to the CBR model. Otherwise weactivate the MBR solver.

AUTOMATISM MODEL

{ rules }Reflex typeReasoning

CASE MODEL

case : symptoms, process, diagnosis

Analogical typeReasoning

FUNCTIONAL MODEL

{ technical vocabulary } ( functions

{ equipments } { fault message{ flow } { functioning informations

VEB dedicatedModel-BasedReasoning

Figure 2 : The three knowledge levels of our architecture.The set of rules is the most efficient knowledge model of our architecture.At a lower level, we keep track of the encountered incidents in the case base.At the base of our architecture, we specify the technical vocabulary and thefunctioning of the VEB. Each model is exploited by a dedicated reasoning.

VII. LOIR (Lisp Objet Inference Reflexe)

We have decided to develop our KBS with an hybrid language realizedby a team of researchers [2] at the IRIT laboratory. It provides variouscapabilities such as a Common Lisp interpreter, a reflex inference engine, aframe-based formalism, pattern matching mechanisms and for coming needs adialogue and action model. The frame concept is used to formalize the technicalvocabulary of the VEB. Our cases are implemented in a special frame accessedby typically CBR methods : retrevial, indexing, adaptation... Our automatismsare kept in rules which are parsed by the reflex engine. All the methodsmanaging these objects are Lisp written.



VIII. The VEB technical model

The first layer of our system consists in the VEB model. Its main part isto define and characterize the domain concepts : equipments, connections,electric flows... We describe the equipments under functional, causal andtopoiogical aspects [8], based on SADT methodology concepts [15]. We alsouse a prototype notion to make easier the modeling of a huge amount ofequipments. The resolution abilities of this model are implemented with graphtracking algorithms

The technical vocabulary

The technical vocabulary organizes in a taxonomy of classes the set ofdomain concepts such as flows (orders, voltages, currents, telemetries, anomalymessages...), equipments (relays, Sensing Unit, QC...), connections (wires,bus...). Furthermore, it provides a set of methods to verify fault messagedependencies, to give functioning information, or to test equipments.

The functional knowldege

Functional knowledge is used to organize the equipment functions innetworks of spreading flows. A function then reflects IO dependencies within anequipment (see figure 3). If the complexity of the function is reduced, goodfunctioning rules are available to define the expected value of its outputaccording to its associated inputs.

We distinguish five function types. Control functions are in charge ofacquiring flow parameters (current, voltage, presence...). Out of thoseacquisitions, anomaly messages can be produced by the ground computer. Anemission function describes an equipment (e.g. On-Board Computer) whichgenerates a flow whereas a reception function is attached to a receivingequipment (e.g. acquisitions). A transformation function converts inputs intooutputs (e.g. QC). A transmission function only conducts a flow (fuse). Thismean of classification allows to dynamically delimit the propagation of a flowwithin the VEB.

The causal knowledge

Causal knowledge relates anomaly messages to search space context.In our initial KB, causality is directly extracted from the functional descriptionof the VEB according to an obvious principle : a function which causes ananomaly message is related to downstream message emissions. As those causalrelationships are not always satisfied and can be modified by real incident cases.

The topoiogical knowledge

Topoiogical knowledge regroups link and proximity informationbetween equipments. For each IO of a function, subsequent and followingequipments related to it are mentioned. This type of knowlegde allows toprecisely retrieve a flow path and is useful for CBR adaptation mechanism.



The prototypical instances

One of the main issues of our VEB moderation comes from the hugeamount of concepts (equipments, functions, flows) : we can find about 200relays, 100 sensings, 200 analogical and digital acquisitions... A manualinstanciation of such classes is not viewable. Declaring all the individualconnections of all the VEB equipments is neither acceptable. So in order tolighten the instanciation process of those excessive classes, we create the notionof "prototypical instance". The creation of this instance then automaticallyfires the creation of the effective concepts (e.g., the VEB equipments). Thisinstance is also used to describe the prototypical functioning : we can noweasily notify the relay / fuse connections by relating the prototypical relay to theprototypical fuse. When deeper precisions are needed, the resolution processwill look for the effective relays or fuses.

How to generate the diagnosis

The resolution capabilities of our Model-Based layer are based on astraightforward principle : the guilty equipment function must be located in thefunctions which intersect each detective function dependencies. So ourdiagnostic process consists in two main steps : looking for the minimal space ofplausible faulty functions; then comparing each function expected and receivedlOs to find out the guilty one.

(classe FUNCTIONattsinstance* inputs type (an IO) multivalue* precedents type (a function) multivalue* ascendants type (a function) multivalue

if_needed (fasc nil (list self))* equipment type (an equipment))* cleared type (a boolean)...)(classe INPUT/OUTPUTattsinstance* expected type (fixp)* effective type (fixp)* flow type (a flux)* subsequents type (an equipment) multivalue* functions type (a function) multivalue...)(for input new I_TMU_1NaddlNHlNtoflow...)(for function new THEJNHIBITION_TMadd (list I_TMU_1N...) to inputs add TheJTMJJnit to equipment...)

Figure 3 : the representation formalism of the VEB model



IX. The case model

On our technical model of the VEB, we place the Case-BasedReasoning layer. Its purpose is to keep the complete resolution of encounteredincidents. This model is supported by a diagnostic oriented case structure, anautomatic classification algorithm and some adaptation capabilities. We willshortly add dynamic learning functionalities by collecting the resolution ourexpert will interactively practice on unusual or hypothetical incidents. We willtherefore improve the system knowledge with the VEB disfunctioning behavior.

The case structure

No studies have defined a standardized structure of a case : everydesigner of a CBR system has to describe his cases according to his applicationneeds. For our diagnostic requirements, we have characterized an incident casewith various attributes : its description, its situation, its search space, itsdiagnostis process and its diagnosis and repairing (see figure 4). We now detaileach of those attributes.

• The description of a case is a list of anomaly messages. Any messagesignals that a measure device has detected an anomaly at one cycle of the testprocedure excecution. As soon as the user enters this description under the CBRmode, the system searches in its case memory for a source case which wouldhave a similar situation i.e. set of anomaly messages.

• As soon as an old similar situation has been retrieved, its associatedsearch space is transfered to the target case. Interactions with an expert user canstart to modify this focused space. Causal relations between anomaly messagesmay be updated. At the end of this step, a sequential resolution process on eachsuspected functions can be applied.

• The old case resolution process gathers a set of attribute / value pairswhich are specific to a case. They represent the list of intermediate results(dependencies between messages, comparison between expected and acquiredflow parameters...) that have been useful to end up at the diagnosis.

• Finally, the diagnosis and repairing represent the solution of theincident. The diagnosis memorizes the guilty function and the repairing keepsthe actions which have been done to repair the faulty equipment function. Suchactions can propose to repair it on the site or to send it back to its constructor.

The case memory

We keep our past cases in a hierarchy [18], which classifies the casesaccording to the values of their attributes. At the root of this hierarchy (seefigure 5), the symptom index distinguishes the lower cases according to theirassociated situation. This classification level constitutes the study of the casesearch space. At lower levels, we put prototypical cases described by their ownattributes. Sub-cases are themselves classified according to the values they takefor those attributes. These successive levels represent the resolution process. Wecan finally find real cases which contain the diagnosis and repairing.



(classe CASEattsinstance* description type (a message) multivalue* situation type (a situation)* space type (a function) multivalue* { the own attribue / value pairs of the case resolution process )* diagnosis type (a function)* repairing type (an action))* failure type (a case) multivalue

Figure 4 :The case class

Case retrieval

The retrieval method we use to select a case similar to the target isinspired by an automatic classification algorithm discussed in [17]. Its main stepsystematically compares the index / value pairs of the cases in memory and theattribute / value pairs of the target. At the end of this process, the target istheoretically put down to a leaf of the hierarchy. The source case is thusmaterialized by the path followed from the root case to this leaf. Here are someprecisions about the calculation of this solution path :

• The first level of the hierarchy puts in correspondence the symptomattribute of the past cases with the target case. This will activate a local searchwithin the case memory out of the anomaly message presence / absence. Thereturned value is then a similar past encountered situation which is attached tothe target. The classification can carry on under the prototypical case with asame situation.

• As the target is put down to the hierarchy, the index it successfullycrosses will form the resolution process. The calcul of their value must beautomatically computed by methods and deduction written in our VEB model.Therefore the system only asks the user for the results of a test or a measure.

• As soon as the algorithm reaches a leaf of the hierarchy, we are inpresence of a concrete source case. We pick up the associated values of thediagnosis and repairing to produce the target solution.

Case adaptation

It is not assumed that the solution founded can always resolve thetarget case : the old faulty equipment may not be the cause of the currentincident. To take this fact into account, many CBR systems [4] [6] proposemutiple adaptation mechanisms in order to converge on a satisfying solution. Inour domain context, our adaptation possibilities are to be constrained. Indeed,our expert finds unreliable to try to adapt a past diagnosis to a current problembecause the adjonction and/or suppression of any message can definitively



/AnalogicalI digital &.^acquisitions^

Legend

real-case

f Aft ttgkfcL) f single 1 (Multiplet message / V ° V V__j_

entry_deplugged

Figure 5 : The case hierarchy.

The cases are installed in a hierarchy. A leaf is associated to a concrete casewhich memorizes the resolution of a real past incident. Its resolution proc-ess is fixed by the resolution path that the classification method follows.

changes the diagnosis. In these conditions, we have looked for a mean toprovide another realistic diagnosis : we just "branch" the resolution process to acase which has got a diagnosis in the neighborhood of the wrong one. Forinstance, when the fuse function diagnosis is not the right one, we can proposethe "Test bench entry deplugged" because the entry of the test bench is justdowstream the fuse. The failure attribute of the fuse case can catch suchinformation if it has already been encountered. If not, we can rely on our VEBtopological model to determine the selectable case.

Case storage

It is easy to install the target case in the hierarchy as soon as it isalready present. We adopt the Protos approach [4] which merges the two casesand increases a successful! rating which can be useful to decide between equalcases. The installation is much more complex when the case is absent. In the



most favourable situation, the process we followed to end up at the wrongdiagnosis is just incomplete : we can then add the steps that finish up thisprocess and ask the expert for the right diagnosis. In worst case, the system isnot able to provide a diagnosis and consequently the case cannot be placedunder a leaf : the cause of this non-classification may be that we have not yetconsidered an important category of symptoms or a significant index or one ofits possible value. We can then add the missing type of information and ask theuser to propose a new resolution process. In the most complex situation, thesteps imposed by the hierarchy are wrong or inappropriate. This can lead us toreconsider the whole hierarchy structure.

X. The Automatism model

The highest layer of our KBS consists in a set of expert rules whichrepresent the solution of very frequent incidents called automatisms. As nomore deep knowledge is invoked to treat these well mastered incidents, thislayer can efficiently reduce the reponse time by shorcutting the activation oflower models. Each automatism is supported by a rule (see figure 6) whosepremises sum up the case description and some specific constraints whereas itsconclusion indicates the plausible faulty function.

For the moment, we propose that a knowledge engineer manuallysupplies these efficient rules and tests their consistency. For futureinvestigations, we claim that their dynamic production out of very frequentcases and generalization mechanisms would be a better option.

(rule VEB_TB_connectionif messages of incident = ^digitalmessages of *incident = * analogicalemitter of digital = *HP_deviceemitter of analogical = *DIC_deviceorder of *HP_device = Borderorder of *DIC_device = Bordermessage_number of incident = 2thenfunction of diagnosis < The_VEB_TB_connectionfound of diagnosis < true trigger

Figure 6 : The automatism for suspecting the VEB-TB connection.

If we are in presence of two acquisition fault messages from the same order,the bus connection between the VEB and the Test Bench can be suspected.



XL Conclusion and perspectives

We propose to dispatch the competences of our KBS among threemodules : a technical model, a memory of cases and a set of expert rules.Although this integration improves the scope of the initial KBS and reduces theresponse time, its main drawback is to maintain a global consistency of thewhole KBS so that an efficient Rule-Based solution and a heavier Model orCase-Based one should not contradict each other. Before proposing morecooperative interactions between the KBS layers, we claim that their relativeindependence allows an incremental development. The "Sequencing function"of the VEB is in the progress of being modelized while some of its mostfrequent incidents are coded into expert rules. Appropriate Case-basedReasoning mechanisms are currently being designed.

To limit the inconsistency risks, our future works will concentrate onan appealing solution which would consist in merging MBR diagnostic process,rule and case formalisms into a single and unified one : Case. Based on adomain concept knowledge only, cases would then mean either systematic rulesor more or less frequently encountered situations or very hesitant processeswhich are respectively called Ossified cases, Paradigmatic cases and stories inthe Schank's terminology [16]. We could then make the maturity of oneparticular incident resolution evolve from an hesitant process up to a case thento a rule. The system should play the part of a novice growing up to the expertlevel along the resolution it learns under the expert guidance [9].

XII. References

[1] AAamodt, «A Knowledge-Intensive, Integrated Approach to ProblemSolving and Sustained Learning*, Ph.D Thesis of the Trondheim University,Norway, 1991.

[2] UArronategui & FMieulet, «Le langage LOIR : objets, regies et actionspour la modelisation*, Ph.D Thesis of the Paul Sabatier University, Toulouse,1992.

[3] NAussenac, Conception d'une methodologie et d'un outild'acquisition de connaissances expertes», Ph.D Thesis of the Paul SabatierUniversity, Toulouse, 1989.

[4] R.Bareiss, «Exemplar-based knowledge acquisition : A UnifiedApproach to Concept Representation, Classification, and Learning»,Academic Press, 1989.

[5] M.O.Cordier, Model-Based Reasoning*, MBR tutorial of the PRC-IAConference, October 1992, Marseille.

[6] KJ.Hammond, Case-Based Planning : Viewing Planning as aMemory Task», Academic Press, 1989.

[7] A.Golding & P.SJtosenbloom, «Improving Rule-Based Systems through



Case-Based Reasoning*, Proceedings of the AAAI Conference, pp. 22-27,1991.

[8] AXeuneke, Machine Understanding of Devices: Causal Explanationof Diagnostic Conclusions*, Ph.D Thesis of the Colombus Univeristy, Ohio,!989.

[9] JXolodner, Towards an understanding of the role of experience in theevolution from novice to expert*, International Journal of Man-Machine StudiesNo 19, pp. 497-518, Academic Press, 1983.

[10] PA. Koton, «Using Experience in Learning and Problem Solving*,Ph.D Thesis of the Massachusetts Institute of Technology, 1988.

[11] JMoustafiad£Sj "Formation au diagnostic technique : I'apport deVIA*, Editions Masson, 1990.

[12] A.Newell & Simon, «Human Problem Solving*, Prentice-Hall, 1972.

[13] ORaiman, "Diagnosis as a Trial: the Alibi Principle*, Proceedings ofthe IBM Workshop on Model-Based Diagnosis, pp. 1-10, Paris, 1989.

[14] R.Reiter, «A Theory of Diagnosis from First Principles*, ArtificialIntelligence 32, pp. 57-95, 1987.

[15] IGL Technology, «SADT : un langage pour communiques, Eyrolles,1989.

[16] R.Schank, Dynamic Memory : A theory of Reminding and Learning inComputers and People*, Cambridge University Press, 1982.

[17] R.Schank & CJliesbeck, «Inside Case-Based Reasoning , LawrenceErlbaum Associated, 1989.

[18] PSycara, Case-Based Reasoning , CBR tutorial of the EM2SLConference, July 1991.

[19] FSchmalhofer &. JThoben, «The Model-Based Construction of a Case-Oriented Expert System*, AICOM Vol 5 No 1, pp. 3-18, Mai 1992.

[20] D.P.V6, NAussenac, C.Soler, DMacchion, «A Cross-DisciplinaryResponse To Improve Test Activities: The Corporate Memory Capitalization inAriane-4 Test Domain*, Second International Symposium on Ground DataSystems For Space Mission Operations, Pasadena, November 1992.

[21] SWess, K.DAlthoff, FMaurer, «Case-Based Reasoning and AdaptiveLearning in the MOLTKE3 workbench for technical diagnosis*, SEKIReport SR-91-05, University of Kaiserslautern, 1991.


ii. ariane-4 veb assembling tests

Documents