An integrated diagnostic architecture for autonomous underwater vehicles

An Integrated DiagnosticArchitecture for Autonomous

Underwater Vehicles

K. HamiltonSeeByte LtdOrchard Brae HouseEdinburgh EH4 2HS Scotlande-mail: [email protected]

D. M. Lane and K. E. BrownOcean Systems LaboratoryHeriot-Watt UniversityEdinburgh EH14 4AS Scotlande-mail: [email protected],[email protected]

J. EvansSeeByte LtdOrchard Brae HouseEdinburgh EH4 2HS Scotlande-mail: [email protected]

N. K. TaylorDept Computer ScienceHeriot-Watt UniversityEdinburgh EH14 4AS Scotlande-mail: [email protected]

Received 15 May 2006; accepted 10 May 2007

The architecture of an advanced fault detection and diagnosis �FDD� system is describedand applied with an Autonomous Underwater Vehicle �AUV�. The architecture aims toprovide a more capable system that does not require dedicated sensors for each fault, candiagnose previously unforeseen failures and failures with cause-effect patterns across dif-ferent subsystems. It also lays the foundations for incipient fault detection and condition-based maintenance schemes. A model of relationships is used as an ontology to describethe connected set of electrical, mechanical, hydraulic, and computing components that

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Journal of Field Robotics 24(6), 497–526 (2007) © 2007 Wiley Periodicals, Inc.Published online in Wiley InterScience (www.interscience.wiley.com). • DOI: 10.1002/rob.20202

make up the vehicle, down to the level of least replaceable unit in the field. The archi-tecture uses a variety of domain dependent diagnostic tools �rulebase, model-based meth-ods� and domain independent tools �correlator, topology analyzer, watcher� to first detectand then diagnose the location of faults. Tools nominate components, so that a rank orderof most likely candidates can be generated. This modular approach allows existingproven FDD methods �e.g., vibration analysis, FMEA� to be incorporated and to add con-fidence to the conclusions. Illustrative performance is provided working in real time dur-ing deployments with the RAUVER hover capable AUV as an example of the class ofautomated system to which this approach is applicable. © 2007 Wiley Periodicals, Inc.

1. INTRODUCTION

Autonomous Underwater Vehicles �AUVs� have be-come essential tools in offshore, oceanographic, andmilitary organizations because of the convenience ofocean access and high quality of in situ data they areable to provide. Survey, inspection, and latterly inter-vention missions are typical. These systems are nowcommercial reality routinely working on a daily ba-sis.

Like most robotic systems, a significant limitationof current generation AUVs is frailty in the face of un-foreseen events, such as component failure on the ve-hicle or unexpected interactions with the surround-ing environment. These result in large amounts ofwasted time, loss of data, and overruns in cost.

The current generation of AUVs are generally un-able to respond well to such unexpected failures be-cause their mission management algorithms are de-terministic, using scripts, finite state machines, orsimilar. For them to be effective, the mission pro-grammer must, therefore, predict all such situations,which is clearly impractical.

Embedded planners can provide the capability toreplan a mission on the fly in response to events, buttheir effectiveness varies with the quality and scopeof the information they have available �Albus et al.,1994�. Coping with unforeseen faults and adaptingmission plans appropriately therefore requires thataccurate information is available to recognize a faulthas occurred and that the electrical or mechanicalcomponent which has failed is determined.

The fault detection and diagnosis �FDD� systemsinstalled operationally on AUVs are generally simplein nature, using rules in combination, and also buriedin the flight code of subsystems, hard to find, modify,or extend. Their simplicity is such that they often donot detect the presence of a fault, or provide correctdiagnosis of failure to the mission manager. Withoutthis, robust AUV behavior will not be realized.

For pragmatic reasons, we ultimately seek to re-

alize a fault detection and diagnosis �FDD� systemwith more generally applicable properties that repre-sents a significant step change from the current stan-dard. Specifically, we seek to develop an architecturewhere

• dedicated sensors are not required to detect/diagnose every fault condition,

• previously unforeseen faults can be detected,• faults can be handled that have cause and ef-

fect behaviors across separate subsystems,• a framework is created for detection of faults

before they happen �incipient fault detec-tion�,

• what-if analysis �prognostics� can beimplemented.

In this paper, we introduce a more advanced de-sign of fault detection and diagnosis system that runsonboard the vehicle as a distinct process, with real-time access to status information and sensor data. Theapproach uses data fusion of multiple concurrentstrategies to detect failures and nominate compo-nents that might be at fault. The strategies are

• Model Based Diagnosis—a semantic modelof the vehicle and its subsystems is main-tained down to the level of the least replace-able unit. The model is used to identify cor-rect behavior according to the mission and,therefore, the presence of failures. Data nor-mally left in filing cabinets is built into themodel and actively employed in the diagnos-tic task. Dynamic models characteristic offault tolerant control can be incorporated.

• Heuristics—rules of thumb used by opera-tors on a regular basis that can provide ashort cut to the presence and cause of a fault.

• Coincidence—co-location in time of twoevents often implies they are related, andthere is an underlying un-modelled causal re-lationship that links them.

498 • Journal of Field Robotics—2007

Journal of Field Robotics DOI 10.1002/rob

This nomination approach is modular, whichmeans that traditional diagnosis methods �e.g., vibra-tion monitoring, FMEA—failure modes effects analy-sis� from third party sources are not lost, but can beintegrated and utilized to increase confidence in FDDconclusions.

Here we demonstrate that the power of modelbased diagnosis in conjunction with other diagnosticmethods can successfully operate on a real AUV �seeFigure 1� in real time and provide useful and accurateinformation to an onboard mission controller. Section2 presents some introductory background on diag-nostic methods, and Sec. 3 reviews earlier implemen-tations for AUV applications. Having reviewed somedesign principles for fault tolerance and modularityin Sec. 4, Sec. 5 presents the architecture of a proto-type system, RECOVERY, which has been imple-mented to evaluate this more advanced approach.Section 6 illustrates the system in operation, and Sec.7 presents results from practical in water AUV trials.Section 8 concludes.

2. APPROACHES TO ADVANCED FAULTDETECTION AND DIAGNOSIS

Once a fault has occurred there are three parts to thefault diagnosis cycle: detection, diagnosis, and ac-commodation. Detection recognizes that a fault hasoccurred, diagnosis identifies what is causing the

fault, and accommodation tries to cope with the fault.This work concentrates on detection and diagnosis asthe accommodation is to be performed by a separatemission controller.

There are two main types of faults: static and dy-namic. A dynamic fault is one that can only be diag-nosed by observing system performance over time; astatic fault may be diagnosed with a simple snapshotof the system. Static faults are generally easier to di-agnose than dynamic faults, for instance a blown fuseis generally easier to diagnose than an intermittentfault such as a loose wire. Dynamic faults can alsotake a great deal of time to diagnose due to the largeamount of information involved, particularly in along mission.

The range of possible faults that can occur on anAUV, when taken together with the unpredictable na-ture of the environment, can be very large. It is prac-tically impossible to predict �and plan for� all possiblefaults. This is borne out by practical experience ofAUV operations and mirrors experience in mostbranches of engineering.

Typically, approaches to developing more ad-vanced FDD solutions use methods such as the fol-lowing:

2.1. Rulebases

Rulebases are a common, first attempt solution,where heuristic expertise from a human expert is ex-pressed in a machine useable format. This usuallycomprises rules, in the form of if-then statements,and commonly embraces fuzzy logic to give somedegree of generalization. These rules use knowledgegained by outside observation of the system ratherthan a representation of any internal mechanismsand, as such, are termed shallow knowledge. The useof shallow knowledge produces some limitations:

• There is no knowledge about why somethinghappens, but only a relationship betweensymptoms and failures. For this reason a rulebased diagnosis system cannot provide a co-herent explanation of the failure; it can onlyshow what rules were fired.

• Multiple faults are not easy to isolate. Whentwo faults appear, it is not always the casethat the union of the symptoms of the two in-dividual faults is equal to the symptoms ofthe device �Hansen, 1988�.

• Lack of flexibility—only faults that have been

Figure 1. RAUVER hover-capable AUV demonstratingautonomous riser inspection.

Hamilton et al.: Diagnostic Architecture for Autonomous Underwater Vehicles • 499


explicitly described can be diagnosed. Somefaults are difficult to describe in rule baseform and so need a deeper method of repre-sentation.

• The set of conditions that describes a particu-lar fault must match the observed conditionsclosely. The use of fuzzy logic, or other quali-tative approaches, can reduce this need by in-troducing some generalization but at the ex-pense of some processing overhead.

The main advantage of a rulebase is that execu-tion time is generally much faster than other meth-ods using more sophisticated models. Processoroverheads are usually extremely low, although theaddition of fuzzy logic methods will increase it.

2.2. Model Based Diagnosis

Model based diagnosis systems use a model con-structed from detailed in-depth knowledge �prefer-ably from first principles� of the system. The result isknown as deep knowledge, said to be gained fromconsidering the systems mode of operation from theinside.

Numerous types of models are available for usein diagnosis including mathematical, functional, andabstract �Chantler et al., 1998�. Generally, an explicitmodel of the device is created from knowledge ofthe system’s structure and the physical �or other�laws that govern its behavior. As an example, mo-tion models tend to be equation based, with the levelof detail determined by the need for accuracy com-pared with the real system, and the available designeffort that can be applied to the modelling process.

The fault detection and isolation �FDI�, whichhas grown out of the control engineering commu-nity, tackles the main diagnostic task by comparingthe observed and the predicted system responses,generated using mathematical models. The compari-son can be achieved quantitatively and qualitatively.The main approach used in the FDI community isanalytical redundancy, which uses numeric analyti-cal models �Sampath, 1995; Staroswiecki, 2001�. Thenumerical models are based on behavior �they arenot based on structure or functions� of the system.The task of analytical redundancy can be dividedinto two major steps �for detectable and isolatablefaults�:

1. Fault detection: generating residual signalsby comparing those predicted from the math-

ematical modelling with the actual observedvalues. The signals are near to zero whenthere is no fault. Different approaches areused in generating the residual, specificallyparameter estimation �monitoring param-eters�, observer-based approach �estimatingunknown variables� and parity space ap-proach �eliminating unknown variables�.

2. Fault isolation: Examining the residuals forlikelihood faults �making decision�. Two ap-proaches for isolation, on structured residu-als and directional residuals, are used. Instructured residuals a residual is sensitive toa subset of faults and insensitive to the otherfaults. It uses a signature matrix and isolationproperties. In directional residuals the re-sidual vector is oriented along a particular di-rection for each fault �Staroswiecki, 2001;Massuyes, 2003�.

The major advantage of the analytical redun-dancy approach is the ability to detect abrupt andincipient faults. However, modelling errors, distur-bance, and noise can affect the robustness in failuredetection. Also, there is no mechanism to detect mul-tiple faults and it requires expensive computation.Decoupling techniques and noise filtering techniqueare proposed to increase the robustness of the failuredetection �Sampath, 1995�.

Currently, there is an increasing move awayfrom FDD model-based to structured and data-driven methods based on AI and learning controlstrategies such as RECOVERY. This is because com-plex dynamic systems are difficult to model, basedon analytical redundancy alone. Uppal and Patton,2002, argue that the interesting combination of cer-tain aspects of qualitative and quantitative model-ling strategies can be made. They further state thatqualitative methods alone should be used, if faultscause qualitative changes in system performanceand when qualitative information is sufficient for di-agnosis. Qualitative methods are essential if mea-surements are rough or if the system cannot be de-scribed by differential equations with knownparameters. The FDD community uses numericalmodels to describe physical system. It is a compli-cated task to model large interconnected systems us-ing analytical numerical model which require expen-sive computation and are not always able to detectall types of faults.



2.2.1. Model Based Diagnosis System Operation

By using appropriate combinations of models, thebehavior of a component, sub-system, or system canbe predicted and then compared to the actual mea-sured behavior. Any discrepancies are likely to indi-cate a fault, which the diagnosis system can then tryto replicate by changing model parameters. If themodel can match, or at least approximate, the faultysystem’s behavior, then the altered variables, whichare likely to represent components or subsystems,are candidates for the fault.

2.2.2. Multidimensionality

Model based diagnosis capability may be extendedby using multidimensional models. A dimension is apoint of view from which a fault is apparent. Forinstance, a vehicle that is diving instead of surfacingwill show a fault in the movement dimension.

A model that covers one aspect of a vehicle, inthis case movement, is known as a monodimen-sional model. Most robotic vehicles have a variety ofsensors on board, enabling monitoring of a numberof dimensions simultaneously. Using these multipleviewpoints it is possible to greatly enhance the diag-nosis capability. For instance, as well as looking atvehicle movement, the power consumed may alsobe monitored providing additional information usedto aid diagnosis.

By extending this information through time, it ispossible to access the temporal dimension, enablingthe diagnosis of dynamic faults using a system suchas Shen and Leitch, 1995. Commonly available di-mensions are time, power, and movement.

2.2.3. Model Generation and Selection

Ideally, it would be possible to create an effectivelyperfect model of the vehicle, correct in every detail,so that any possible faults could be tracked down byoperating on the model. Clearly this level of model-ling is not realistic due to complexity and changesinvoked by maintenance during the vehicle’s life-time. Even if such a model could be constructed, theamount of time needed to operate with such a largevolume of variables would be prohibitive.

An alternative approach to perfect model build-ing is realistic model building. The most commonmodel available to AUV engineers is a vehicle-movement model, often generated at the prototypestage by using towed scale-model techniques.

Available on-vehicle computing platforms re-quire the depth of the model �in a hierarchical sense�be limited so that time available for diagnosis can bemanaged, as in the approach of Aldea, 1994. In thiscase the simplistic model might have a term thatlumped together several of the hydrodynamic ef-fects, thus reducing the number of variables and therun time, at the expense of accuracy.

Caccia et al., 2000, have studied the generationof such models using the vehicle’s own sensor suite,which substantially reduces the cost of generatingmodels available for diagnosis. Chantler et al., 1998,provide a thorough examination of the suitability ofvarious types of models to differing applications.

Model based diagnosis has a far higher over-head than a RuleBase System but is the essentialmechanism by which we can provide much morepowerful diagnostic capability, such as the ability todiagnose:

– multiple faults,– unforeseen faults,– the same fault repeatedly, without having ex-

actly the same observed conditions each time.

2.3. RuleBases vs Model Based Diagnosis

In summary, RuleBases are fast and easy to make buthave extremely limited capabilities, particularlywhen confronted with unforeseen circumstances.Model based diagnosis systems are far more power-ful but require more time and processing power.When dynamic fault diagnosis is included, the timeneeded by a model based system increases even fur-ther.

2.4. Using Heterogeneous Knowledge

A great deal of vehicle design knowledge is oftenavailable, much of it generated as part of the vehicledesign process. For instance, circuit diagrams, me-chanical drawings, data flow diagrams, systemsschematics, fault log-books, and software class dia-grams are all useful. This information is usuallystored and may be utilized by field personnel tryingto manually diagnose a fault. Other knowledge,such as sensor data, is generated whilst the vehicle isperforming its mission.

For convenience, we categorize the available ve-hicle knowledge into five main areas: design, sensor,historical, mission and fault. A suggested breakdownis shown in Figure 2:



Where foreseen means designed a priori, synchro-nous means in lockstep with the real time clock, asyn-chronous means previously collected and archiveddata, dynamic means changing over time, systemicmeans internal to the vehicle, and environmentalmeans external not part of the vehicle

Of these, design knowledge is one of the mostvital types of knowledge for in-vehicle fault diagno-sis since it describes the vehicle’s logical architecturethrough the use of ontology �Sowa, 1999�. Researchinto this area is ongoing, but at present ontology re-search consists mainly of relationships between com-ponents, parameters, and sensors.

Another useful form of knowledge is general-ized fault diagnosis knowledge, such as the proce-dural knowledge that technicians use to track downfaults. For instance, if the brakes are applied on yourcar and there is a loud bang followed by a great dealof shuddering, a fair assumption is that there isbrake problem. This is because the braking systemwas activated just before an overall system fault�with the car� became apparent. This sort of general

knowledge can be applied across many types of sys-tems not just motorcar brakes. Of course, the prob-lem may lie elsewhere, but there is a good chancethat the problem is with the brakes.

There is also a growing movement towards Fail-ure Modes and Effects Analysis �FMEA� to be incor-porated into the design cycle. If this is so, then agreat deal of extra knowledge in the form of failuremodels will become available for diagnosis. Work onautomating the generation of FMEA knowledge hasbeen performed by Price and Taylor, 1997.

3. PRIOR ART

Apart from simple rule-bases there are many ap-proaches to automated diagnosis applied acrossmany different but related applications including air-craft, spacecraft, automobiles, AUVs, and industrialplant. We here provide a representative survey of dif-ferent approaches to implementing diagnostic sys-tems, with the focus on autonomous vehicles.

Synthesis of redundant actuators—Yang et al., 1998focus on thruster failure. A thruster control matrix isused for controlling vehicle movement with thethrusters. If a thruster’s speed does not match the de-manded speed, then the thruster is assumed faultyand the thruster control matrix reconfigured to makeuse of the vehicle’s redundant degrees of freedom.

Perrault and Nahon, 1998, have adopted a similarapproach using an algorithmic model of the vehicle’sdynamics for control. This allows them to use a syn-thesis of actuated and non-actuated degrees of free-dom to allow continued vehicle operation with faultythrusters.

Alessandri et al., 1998, use a dynamic model ofthe vehicle combined with a bank of Extended Kal-man Filter Estimators for fault isolation. The empha-sis is on accurate fault detection and diagnosis ofthruster failure.

Hybrid rulebase/model/neural network—Again fo-cussing on thruster failure, Deuker et al., 1998 uses ahybrid rulebase/model/neural network system.Fault detection is achieved with a movement modelto detect discrepancies between modelled and sensedmovement. A set of foreseen faults is generated beforethe mission using the rulebase, which is then com-piled into a neural network. This limits the system tothe diagnosis of foreseen faults only.

Neural network movement model with look-up table—Takai and Ura, 1999, concentrate on actuator failure.

Figure 2. Types of vehicle knowledge.



A neural network is used as a dynamic model of thevehicle’s movement. Diagnosis is achieved with pre-set “diagnosis motion sequences” during which thevehicle performs a standard series of manoeuvres. Alook-up table is then used to relate defective move-ment to defective components. This system has theability to use the dynamic model for dead-reckoningcontrol of the vehicle if a sensor fault is diagnosed.

Failure mode and effects analysis—Price and Taylor,1997, propose the use of models generated at designtime using the Failure Mode and Effects Analysis�FMEA� design discipline. The FMEA models areused to generate sets of possible faults at design time�offline generation�. This combines some of thestrengths of model based diagnosis with reduced on-line run time but sacrifices the ability to diagnose un-foreseen faults.

Hierarchical Model Based Diagnosis—Aldea, 1994,uses hierarchies of models to provide “anytime diag-nosis,” where the level of diagnosis performed ismatched to system deadlines using a tree of modelsof varying degrees of detail. This is a powerful ap-proach, well suited to deadline orientated real-timesystems as found in most AUVs. This system cur-rently concentrates on the diagnosis of static faults.

Dynamic model based diagnosis—Shen and Leitch,1995, concentrate on diagnosing dynamic systems us-ing dynamic models coupled with a synchronoustracking mechanism. System behavior is observedover time and compared to the modelled behavior.This is a lengthy process if used with multiple modelsand they recognize the need for a refinement ofsearch techniques.

Mosterman and Biswas, 2000, use bond graphs toconstrain dynamic models as much as possible and solimit the amount of computation involved. This di-agnosis system depends on analyzing the transientsgenerated by faults and so cannot analyze steady-state, or static, faults.

Unified geometric approach—Dunia and Qin,1998a, use a geometric approach based on PrincipalComponent Analysis. A model is created of the nor-mal operation of the system, under fault conditions avector is defined from faulty to normal operation.This system is limited to single dimensional, steadystate faults. Dunia and Qin, 1998b then extend theirgeometric approach to multidimensional faults.

NASA’s “remote agent” spacecraft missioncontroller—NASA’s remote agent experiment, as de-tailed by Bernard et al., 1998, is deployed on the DeepSpace 1 probe. The spacecraft has a goal orientated

mission controller �rather than a list of actions� whichincorporates a model based fault diagnosis module.Under fault conditions, the diagnosis module is re-sponsible for presenting detailed fault information tothe mission controller. With the aid of this fault data,the mission controller has an enhanced ability to planaround the fault. Washington, 2000, continued workin this vein.

An interesting aspect of the remote agent ap-proach is the focus on integration of mission controland explicit diagnosis. The model based diagnosissystem is conventional, static, and monodimensionalbut, when combined with the onboard planner, theability of the spacecraft to cope with unforeseen faultswas increased �Bernard et al., 1998�. The melding ofmission controllers and explicit diagnosis is sure tohave a significant effect on the autonomy of roboticvehicles.

Dearden et al., 2004, report the results from astudy done as part of NASA’s Mars Technology Pro-gram, where the use of particle filters for real-timefault detection is considered. This paper shows thatthere is potential in the use of these techniques fortackling some aspects of fault diagnosis, but does notlook at the integration of mission control and explicitdiagnosis illustrated by the remote agent approach.

Summary—From the above, the open literaturehas not reported any existing unifying architecture,nor is there any evidence of the development of anunderlying architecture capable of utilizing differingdiagnostic systems. There is generally no integrationof design information. Although Failure Modes andEffects Analysis examines the system design for pos-sible errors and effects, it is fundamentally limitedwhen faced with unforeseen events. There is no em-phasis on modularity and scalability, which is an es-sential ingredient of many complex system includingAUVs. Finally, little use is made of domain-independent knowledge and, with the exception ofNASA’s Remote Agent Experiment, there is no realholistic approach to mission control and diagnosis.

4. DESIGNING FOR FAULT TOLERANCE ANDMODULARITY

Before considering our FDD architecture in more de-tail, we introduce some key design concepts that willbe used later.

Fault Spaces—Fault diagnosis depends on theability to observe AUV operational parameters using



sensors, with the complete set of observations beingthe observation space. The complete set of diagnos-able vehicle components �thrusters, sensors, etc.� thata diagnosis system can identify as faulty using the ob-servation space is known as the diagnosis space. Thecomplete set of possible faults �the fault space� forany given vehicle and situation is very large. A fur-ther explanation is given in Hamilton, 2001b.

The ratio between the diagnosis space and the ob-servation space, that is, how many components canbe diagnosed with the set of sensor observations, isgenerally low on current generation AUVs. This is be-cause most AUV sensor suites concentrate on navi-gation and environmental sensors. Although naviga-tion sensors observe the vehicle they are currently oflittle use for diagnosis. Environmental sensors arealso of limited diagnosis suitability at present.

Sensors—The systems of the vehicle usually havea few systemic sensors monitoring battery tempera-ture, vehicle attitude, battery charge, etc. Systemicsensors are generally far cheaper than environmentalsensors as the latter usually need to be waterproof tomaximum operational depth, which can sometimesbe measured in kilometers.

An overlooked area of fault tolerance is increas-ing the observation of vehicle systems. Because sys-temic sensors are relatively inexpensive, it is possibleto substantially increase the amount of observationsby scattering cheap sensors at key locations withoutnoticeably increasing overall vehicle cost. Even witha simple rulebase, this makes it possible to directlyprogram for more events.

Increasing the observation space makes possiblean increase in the diagnosis space, which can be fur-ther increased with the use of multidimensional andintegrated knowledge techniques. In general, themore observed dimensions the greater the diagnosisspace.

Modularity Concerns—An increasing feature ofmodern design is modularity. Modularity providesthe means to scale to higher levels of complexity andto make systems multi-functional through ease of re-configuration. The move towards modularity is evi-dent in the designs of AUVs and their subsystemsdue to the wide range of mission types they are re-quired to perform. An information-based fault diag-nosis system must encompass modularity or its use-fulness will decline as the vehicle changes from itsinitial configuration.

Two popular methods of implementing modular-

ity are the distributed and centralized approaches, ofwhich the latter is the most common.

A distributed diagnosis system has each majorcomponent capable of diagnosing itself and provid-ing this information to the overall diagnosis system.In principle, it would be able to send and receive di-agnostic information to other modules, so that causeand effect in different subsystems can be detected.This is a robust approach, as it would provide grace-ful degradation and maximum survivability in caseof damage. Although there is a move towards such“smart” components, it is not yet common enough tomerit developing fully-distributed diagnosis sys-tems.

With the centralized approach various modulescan be “plugged” into a central core. Most currentgeneration AUVs favor a centralized approach withvehicles consisting of a core onto which other sensorsor other devices may be added. At present, the cen-tralized modular approach is the most practical so-lution, although it can lead to the loss of graceful deg-radation.

5. RECOVERY: SYSTEM CONCEPT

In this section we introduce the architecture of anFDD system developed to realize the attributes in Sec.1 and, hence, provide more useable and robust sys-tems. The aim, therefore, is to develop a system thatprovides an underlying information-based, modulararchitecture suitable for integrating various types ofknowledge, and diagnostic systems, including rulebased, model based, static, dynamic, and multidi-mensional approaches. We term our prototype “RE-COVERY.”

RECOVERY is designed to work as a standalonemodule in conjunction with an enveloping missioncontroller �Figure 3�, preferably a goal-orientatedplanner. In this case, the script or finite state machinemission controllers used by most AUVs would act asa state generator.

5.1. Architecture

Figure 4 illustrates the architecture that has beenused to guide implementation of the early RECOV-ERY prototypes. Central to the architecture is aModel of Relationships �MOR� that captures the keycomponents of the target system and the relation-ships between them, modelled to the level of the



least replaceable unit �LRU� that maintenance teamscan attend to in the field. The MOR is initially con-structed using available design information aboutthe system, and any available models defininginput/output relationships �e.g., dynamics, motortorque/current curves�. Import filters are intendedto help with the information capture, from variousCAD packages routinely used. During system opera-tion, real-time sensor data is input to the MOR and

used as part of the fault detection and diagnosiscycle. Domain specific diagnostic tools using model-based, rule-based, or other approaches can be in-cluded and operate on the MOR to detect and local-ize faults. Plug-ins forming domain independentdiagnostic tools similarly interact with the MOR.Typically, these look for coincident events or seekparameter values that are out of specification. Theymay also use trending information to perform incipi-ent fault detection, as a basis for a condition basedmaintenance regime. Following fault detection �gen-erally executed by the Watcher—see below� both thedomain-dependent and domain-independent diag-nostic tools work on the MOR and nominate compo-nents as possible causes. The more nominations arereceived, the greater the confidence that a particularcomponent is at fault. From this, a rank order list ofcandidate causes is prepared, and either passed tothe operator for maintenance action, or the missionmanager for mission replanning. In a future releaseof the system, it is intended to incorporate time man-agement into the MOR, so that diagnosis can workto deadlines—best available solutions are madeavailable early, with refinement as time progresses.

With this approach, the system aims to providemethods for integrating heterogonous knowledge,from performance evaluation curves to the manufac-turers own common faults. Such information is com-monly known and used but not usually integratedinto the vehicle’s mission control software, which inturn limits the diagnostic capability.

Figure 3. Fault detection and diagnosis approach.

Figure 4. Architecture of the initial RECOVERYprototypes.



5.2. Model of Relationships

The Model of Relationships expresses the designknowledge that captures the structure of the systemfrom an ontology of its components and any modelsthat can be used for prediction. It also records livesensor data as it is made available. It thus providesthe focal database that is used by the various typesof domain dependent and independent diagnosistools to detect and diagnose faulty operation. It isconstructed using a dynamically modifiable seman-tic network comprising links and nodes of varioustypes. Semantic networks are known to be modularand easy to understand at the expense of expressive-ness �Finlay and Dix, 1996; Russell and Norvig,1995�.

Figure 5 illustrates a simplified model of rela-tionships for a particular target system. Nodes rep-resenting real items that can be diagnosed as faultyare connected by semantic links which are givenmeaning.

Figure 6 illustrates an exemplar componentnode and the associated design information it holdsthat can assist FDD.

In the early releases of RECOVERY, the follow-ing nodes and links have been supported:

Nodes:Operational Models: e.g., dynamic motionmodels, torque/current curves in a motorComponents: Items that make up the vehicle

model defined at the least replaceable unit�LRU� level, e.g., electronics board, hydraulicvalve, electric motor, etc.Parameters: e.g., data from sensors.

Links:Sensor OverlapSensor to ParameterComponent to ParameterModelled to Sensed ParameterPower Supply to Component

Research into the types of nodes and links bestneeded to represent a simplified model of the ve-hicle �i.e., its ontology� are ongoing. In addition, theMOR design allows semantic networks to be hierar-chically partitioned such that each component andvehicle sub-system forms a complete, heterogeneousdescription tied together at a higher level also usinga semantic network. These components and sub-

Figure 5. Graphical representation of a target system and its model of relationships.

Figure 6. Exemplar component node and associated de-sign information.



system networks are, therefore, joined together toform the complete vehicle MOR.

Figure 7 shows a section of the MOR for an AUVthat details the relationships between some commonparameters and components. Sensor-to-parameter,differential-to-differentiated parameter, and power-supply-to-component links are illustrated.

5.3. Domain Dependent Diagnostic Tools

Domain dependent diagnostic tools implement tech-niques that operate on and with the MOR and arespecific to the particular FDD application. Two arecurrently provided—rulebase and model based di-agnosis.

Rulebase—Rulebase captures expert heuristicsabout the nature of faults. Certain combinations ofevents may be known to be attributable to a particu-lar cause. The level of modelling detail in the MORmay not capture the causal nature of such relation-ships and, therefore, it would not be caught as partof normal operation. Expressing it as an ad hoc rule,or set of rules, ensures it is available and can con-tribute to the nomination of faulty components. Inprinciple, although not implemented here, such arulebase could be set up with a learning mode,where event and consequence relationships are cap-tured and stored by observation or manual inputfrom an operator.

Model based diagnostics—Following fault detec-

tion, model based diagnostic tools identify candidatecomponents that may be faulty using standardobserve/perturb/match techniques. Currently, thesystem supports the use of analytic models, such ascommon movement models or input-output rela-tionships that have been graphed a priori �e.g.,current-torque motor relationships�.

There are two types of model diagnosis tool,static and dynamic, currently used with RECOVERY.Static tools are only capable of finding faults that canbe diagnosed with a single snapshot of the system.Dynamic fault tools can find faults that are only ap-parent from studying the system behavior over time.Due to the large amount of information involved indynamic diagnosis, it can take far longer than staticdiagnosis.

Both types of tool are capable of diagnosingsome multiple faults, that is, faults where more thanone component has failed simultaneously.

Other—Other industry standard diagnosticmethods can be implemented as domain dependentplug-ins to the model of relationships using a stan-dard API. This, therefore, allows the wealth of expe-rience and expertise captured in traditional tech-niques, such as vibration monitoring/spectralanalysis to be incorporated, and nominate compo-nents. This gives the modular architecture realpower, as much expertise is captured in these exist-ing approaches.

5.4. Domain Independent Diagnostic Tools

Domain independent tools implement generic tech-niques to help detect and/or localize faulty compo-nents in the target system. These techniques do notutilize any specific expertise, which is particular tothe domain. Rather, they work within the model ofrelationships looking for specific conditions treatingit as a generic database.

Correlation detection—Correlations between vari-ous system events may be detected using the Cor-relator module. The Correlator uses domain-independent fault finding knowledge to highlightpossibly relevant components. At present, this mod-ule traverses the nodes and links in the MOR look-ing for the following:

„1… Parameters whose values change in sympa-thy with changes in faulty parameters val-ues are likely to be related to the fault.

„2… Faults that occur at similar times are likelyto be related to each other, and perhaps

Figure 7. Excerpt from an AUV model of relationships.



faults which have occurred immediatelypreviously.

„3… Components that become active �after a pe-riod of inactivity� just before the occurrenceof a fault are likely to be related.

„4… Components that are being used at the timeof a fault are more likely to be related to thefault than inactive components.

Topology Analyzer—Like the Correlator, the To-pology Analyzer traverses the MOR, this time seek-ing components that have common connection withmultiple other components that have been nomi-nated as faulty. If such a common connection exists,the component in common is likely to be the under-lying cause and is nominated. This is typically ap-parent with power supplies. If all the active thrusters“fail”, then it is likely to be the Navigation PowerSupply that is actually at fault. Power supply con-nections are numerous and one of the most commonforms of component information. It is readily avail-able on AUV circuit diagrams and so forms one ofthe most numerous types of link in the Model ofRelationships.

Watchers—The Watcher is the key tool that de-tects the possible presence of a fault and, thus, acti-vates other diagnostic tools to nominate possiblecomponents as the cause. It has three parts. Thealarm watcher scans alarm parameter nodes in theMOR to see if they have become active �these arenodes that are hardwired in to indicate an alarmwhen a particular condition exceeds a threshold�.The constraint watcher scans parameter nodes tocheck their constraints are within range �i.e., a powersupply providing 12 amps when the maximum al-lowable is 10 amps�. The residual watcher scans mod-elled parameters and compares them to the relevantsensed parameter. A difference in values is called a“residual” and can be used to indicate a fault if itbecomes too large.

Incipient and condition based maintenance—Plug-ins are under development to use trending informa-tion from the model of relationships to detect theonset of fault conditions before they occur. This of-fers the potential for maintenance action or missionreplanning before it is too late. Using this capability,maintenance regimes for target systems can be mademore effective by replacing components when theyneed replacing, rather than according to some statis-tical norm �condition based maintenance�. Extend-ing their lifetime thus saves on replacement costs.

Similarly, catching premature failure before it hap-pens can save the mission. This capability is not re-ported or demonstrated here, and so a full descrip-tion left for future publication.

5.5. Modularity

RECOVERY uses a centralized approach to modular-ity. The RECOVERY kernel will accept informationfiles containing descriptions of the various vehiclecomponents together with specific fault knowledgeof that component. In this way, the knowledge filerepresents each significant vehicle component. Theseknowledge files are similar to the Component Infor-mation Files used in Windows Plug and Play sys-tems.

Domain independent, domain specific, vehiclelevel, and component level information can beadded to the system using a dedicated compiler andknowledge files. In the future, support for other de-sign knowledge commonly discarded for automateddiagnosis purposes will be added to the system.

5.6. Architecture Potential

Use of the MOR and diagnostic tools such as theTopology Analyzer mean that the RECOVERY archi-tecture does not require a sensor for every fault, andis able to detect previously unforeseen faults, unlikestandard diagnostic methods such as fault trees. Fur-ther, by linking MORs associated with intercon-nected subsystems, it can deal with cause-effect pat-terns between each, forming the basis of a modularplug and play diagnostic engine. Finally, as dis-cussed, by incorporating trending information onsensor and predicted parameter values within MORnodes, the architecture has the potential to detect in-cipient faults and, therefore, can form the basis of acondition based maintenance system. Exploration ofthis potential is left for future publication.

6. RECOVERY: SYSTEM OPERATION

RECOVERY follows the classic pattern of fault detec-tion followed by diagnosis �Figure 8�. Detection isperformed by several methods encompassed in theWatcher, ranging from simple rule triggering throughmodel-sensor comparison to mission goal violation.Diagnosis is in two stages: component and subcom-



ponent levels. When diagnosis is complete, the infor-mation is presented to the enveloping mission con-troller and/or operator as appropriate.

6.1. Detection of Symptoms

The RECOVERY module is invoked at every vehicle“heartbeat” to perform FDD. To initiate each cycle,the Watcher �Sec. 5� runs over the MOR to determineif a fault may have occurred triggering the diagnos-tic tools within RECOVERY to be initiated. Informa-tion on which parameters have sufficient discrep-ancy for an alert, together with any other detectioninformation, is then passed to the diagnosis modulesto aid their operation. Alternatively, the systemsleeps until the next heartbeat.

6.2. Fault Diagnosis

Diagnosis is performed in two stages: componentand sub-component. During component diagnosisthe search is narrowed down to a short list of highlysuspect components, after which sub-component di-

agnosis runs the component-specific information at-tached to each component to try to identify the faultin greater detail.

By highlighting components that have been pro-posed as fault candidates, the number of models tobe run is reduced compared with simply runningthrough the entire model set.

Component-level diagnosis—The detection infor-mation passed to the diagnosis module is used toidentify which models are to be run. For instance,only models attached to faulty parameters in theModel of Relationships are passed to the diagnosistools, so saving time and processor energy.

RECOVERY currently uses rule-bases and modelbased diagnostic engines capable of dealing withmultiple faults simultaneously. Multiple fault candi-dates may be generated by these tools. Other typesof diagnostic tool such as Bayesian Belief Networksor Neural Networks may also be supported in thefuture.

The outputs from the various diagnostic toolsare fault candidates, or components, which exist asnodes in the communal Model of Relationships. Inthis way multiple, heterogeneous diagnostic enginesmay be used together.

Domain-independent diagnostic information isthen processed by the correlator, which searches forpossibly relevant events and similarities as de-scribed in Sec. 5. The Correlator also produces can-didates held in the Model of Relationships.

Suspicion index—Every time a diagnosis module,such as a diagnostic engine, nominates a componentthen that component’s Suspicion Index rises. TheSuspicion Index is one of the attributes of that com-ponent’s node in the Model of Relationships and isused to determine which components should havetheir component-specific diagnostic knowledgeevaluated in the sub-component diagnosis stage.

Because faults may show in different dimen-sions at different times, the Component-Level Diag-nosis is run through several iterations over severalseconds. For instance, in the Results section, it is ap-parent that, whereas a fault may be instantaneouslyapparent in the power dimension, it may take sev-eral seconds to show in the movement dimension.This is due to the relatively slow dynamics of AUVs.By running component-level diagnostics for severalseconds, the fault is given a chance to show up in allrelevant dimensions, so increasing the knowledgeavailable to the diagnostic system.

Once the final iteration is reached or a particular

Figure 8. RECOVERY operation.



component’s Suspicion Index reaches a certainthreshold, then the Topology Module is invoked.This may find connections between some of the sus-picious components and so alter the focus of thesearch.

Sub-component-level diagnosis—After component-level diagnostics are complete, the focus moves tosub-components, where the component-specific in-formation attached to each component is analyzed.Links to the various types of information are part ofthe component node’s attributes in the Model of Re-lationships. For these results, rules and equationalmodels have been used as initial component-specificinformation,

The component with the highest Suspicion In-dex is analyzed first. If no exact matches are found,then the next highest component is processed. Ifthere are still no matches, then the faulty componentis assumed to be the one with the highest SuspicionIndex and a confidence is generated. This informa-tion is then passed to the mission controller.

6.3. Adding Components

The modular implementation of adding a new com-ponent is illustrated in Figure 9 for the case of adigital compass. The implementation is similar inconcept to the edge-connector method often used inindustrial electronics.

The knowledge file is compiled and linked toother knowledge files using RECOVERY’s own com-piler and linker. The output from the linker is themultidimensional semantic model of the vehicleforming the Model of Relationships.

7. RESULTS

We present practical results from a real testbed thatillustrate the main aspects of architecture, operation,and benefit. We provide results from a typical missionin detail for illustration �Secs. 7.1–7.8� and some fur-ther exemplars in summary that both occurred dur-ing operations and illustrated aspects of the RECOV-ERY architecture that provided benefits �Sec. 7.9�.

7.1. Testbed approach

RECOVERY has been developed and evaluated onthe Ocean Systems Laboratory’s own vehicle, RAU-VER; a 2 m, however capable AUV shown in Figure1. The following results were generated during amission in which one of the Lift Thrusters was dis-abled mid-mission.

RECOVERY runs on a fully embedded PC104+Pentium 266 MHz with 32 MB RAM consuming ap-proximately 8 W. RECOVERY is currently invokedat 200 ms intervals, a graphical user interface is pro-vided.

For these results decoupled axis movementmodels were used as they are simple to generate andsuitable for use at the low speeds used here �Cacciaet al., 2000�. The simplicity of the models also meansthat they are crude and so a worst-case test for theRECOVERY system.

7.2. Evaluation Mission

The mission segment detailed in this section is takenfrom a realistic scenario based on a survey andsample mission �see Figure 10�. The AUV’s missionis to follow a waypoint sequence at a depth of a fewmeters in order to stay out of the splash zone. Ateach waypoint, the vehicle surfaces for a GPS fix be-fore diving and then proceeding to the next way-point. At the last waypoint, a final GPS fix and statustransmission is performed before the vehicle dives toundertake the survey.

In this mission it is necessary to sample the wa-ter column with various sensors, often using a “ver-Figure 9. Change edge connector implementation.



tical lawnmower” pattern, where the vehicle starts asample at the surface and dives continuously sam-pling. An ambient sample is then taken with the ve-hicle in standby mode. The AUV then repeats thewater column sample whilst returning to the surfacefor a position fix, then moves to the next samplepoint before repeating the process. This mission seg-ment details a single leg of this survey method: Goal0: Surface and hover for GPS fix. Goal 1: Submergeto fully flood instruments. Goal 2: Dive vertically tosurvey-end depth. Goal 3: Standby �drift� while am-bient readings taken. Goal 4: Ascend vertically tosurface. Goal 5: Hover at surface until standby.

During the vertical sample process, the vehicleattitude must be kept within certain pitch, roll, andheading constraints in order for the environmentalsensors to work properly.

7.3. The Fault

At the beginning of Goal 4 �return to surface� a “portlift-thruster” fault is forced which drops the Port LiftThrust to zero. This causes a severe roll as the Star-board Lift Thruster is still operating normally. Theresultant roll does not match modelled normal op-eration behavior, so invoking the RECOVERY diag-nostic system.

This fault is equivalent to a catastrophic failureof the Port Lift Thrust Motor Control Sub-Component, which is part of the overall Port LiftThruster Component. These results only show op-eration up to the end of the Component Level Diag-nostics and so an overall diagnosis of Port LiftThruster is the desired goal.

7.4. Vehicle Behavior

The above set of mission parameter graphs �Figures11–15� show key parameters during the evaluationmission. The left, or �a�, graphs show normal opera-tion whilst the right, or �b�, graphs show faulty op-eration. The time scale is the same for all graphs, thedifferences in mission times between the �a� and �b�missions are due to the vehicle being powered upfor different lengths of time before the missions. Thefault is readily apparent in some dimensions, nota-bly Figure 13 �Roll� and Figure 14 �Port NavigationPower Consumption�. Other dimensions, such asFigures 11, 12, and 15 �depth, pitch, and stbd. nav.power�, hardly show the fault.

By comparing Figure 14 �port nav. power� andFigure 15 �stbd. nav. power� it can be seen that the

Figure 10. RAUVER descending towards the seabed dur-ing the mission.

Figure 11. Vehicle depth: �a� normal mission, �b� faulty mission.



loss of the Port Lift Thruster is apparent by the lackof power consumed by this thruster during verticalmovement.

The discrepant parameters in this mission areFigure 13 �Roll� and Figure 14 �Port Nav. Power�—the simplistic, operational models are too crude to

Figure 12. Vehicle pitch: �a� normal mission, �b� faulty mission.

Figure 13. Vehicle roll: �a� normal mission, �b� faulty mission.

Figure 14. Port Navigation Power Consumption: �a� normal mission, �b� faulty mission.



pick up the Pitch and Depth discrepancies. Thisshows some of the advantages of multidimensionaldetection, as even crude models can be extremelyuseful.

Because of the slow physical movement of thevehicle, the fault becomes apparent in the Power Di-mension approximately 2 s before the Movement Di-mension.

7.5. Fault Detection

As described in Sec. 6, the Model of Relationshipsdetails links between sensed parameters, modelledparameters, and the models that produce them. Thisinformation is passed to the model diagnosis engineso that it knows which variables represent specificcomponents �see Figure 16�.

The Port Nav. Power parameter is modelled bythe Port Nav. Power Model, this information is heldas a link in the Model of Relationships. The nomina-tions from the various Model Based Diagnosis En-gines are shown in Figure 17.

Note that the Starboard Power Model is not runbecause no power discrepancy was detected withthe starboard power measurement—it is the port

vertical thruster that is faulty. At this stage the faultis only apparent in the Power Dimension due to theslow physical movement of the vehicle and so theRoll Model is not run either. When the Port Nav.Power model was analyzed, it was found that thefaulty behavior could be matched by perturbing PortLift Thruster and Port Lamp Control variables, eachof which represent specific components as describedin Sec. 2.

Each of the components nominated above willhave their Suspicion Index incremented.

Figure 15. Starboard Navigation Power Consumption: �a� normal mission, �b� faulty mission.

Figure 16. Fault detection information.Figure 17. Model based diagnosis engine results, firstinvocation.



7.6. Correlation Detection

The output of the Correlator is below in Figure 18.First, all components active at the time of the faultare nominated �not shown here�. Next, a search ismade for parameters that track the faulty parameter�Tracking�Parameter�, then for alarms that havetripped recently �Similar�Alarms�. Finally, a search ismade for components that have been inactive for10 seconds before becoming active within the last2 seconds �Recent�Components�.

Note that the Correlator has found both relevantand irrelevant fault information:

Tracking Parameters: The port and starboardlamps nominated are irrelevant. They coincidentallytrack the Port Navigation Power but are not relatedto the fault. The Port Diode Temperature nominationtracks the Port Navigation Power as the temperatureis directly related to the amount of current drawn,but it is, again, irrelevant to the fault.

Recent Components: The Correlator has foundthat both the port and starboard lift thrusters wereactivated shortly before the fault became apparent.

This is highly relevant because it is the port liftthruster that is actually faulty.

Each of the components nominated by the Cor-relator will have their Suspicion Index incremented.

7.7. Suspicion Highlighting

Shown below in Figure 19 are the Suspicion Indicesfor components nominated so far.

Note that the combination of model based diag-nosis engines and correlation searches have resultedin the focus of suspicion falling on the port liftthruster and the port lamp control. At this stage thefault is only apparent in the power dimension and,so, it is difficult to narrow the search further—it istrue that either the thruster or the lamp could havecaused the discrepancy in power consumption.

7.8. Final Iteration

The tenth and final Component-Level Diagnostic It-eration is performed just over 2 seconds after thefault was first detected. At the time of the first itera-tion the fault was only apparent in the Power Di-mension, but it is now visible in the Movement Di-mension due to the thrust imbalance caused by theloss of the port lift thruster. The two-second delay isdue to the slow physical dynamics of the vehicle.

This causes two models to be analysed: PortNav. Power and Vehicle Roll, see Figures 20 and 21.The fault is not apparent in the Starboard Nav.Power dimension and, so, that model is not ana-lyzed to save time and processing power.

As before, the power model cannot distinguishwhether the observed power consumption is caused

Figure 18. Correlation results, first invocation.

Figure 19. Suspicion highlighting, first invocation.



by a fault in the lift thruster or the lamp controller.The Roll model cannot determine whether the ve-hicle movement discrepancy is caused by a faultyport or starboard lift thruster—it could be either.

The Correlator is now invoked, exactly as in thefirst iteration. This time it has two faulty parametersto find tracking parameters for, but the SimilarAlarms and Recent Component searches are un-changed �see Figure 22�.

This time, almost entirely irrelevant informationhas been found as the Recent Components are no

longer present. This is because the final iteration isso long after the initial detection that the recentlyactivated components can no longer be said to berecent. This is offset by the extra information avail-able to the Model Based Diagnosis engines.

Shown above in Figure 23 are the Suspicion In-

Figure 22. Correlation results, last �tenth� invocation.

Figure 20. Fault detection information.

Figure 21. Model based diagnosis engine results, last�tenth� invocation.

Figure 23. Suspicion highlighting, last �tenth� invocation.



dices for the various nominated components, someof which were nominated in the middle iterations. Itcan be seen that, despite some totally irrelevant in-formation being produced by the Correlator, the PortLift Thruster �actually faulty� and Port Lamp Con-trol are clearly the most suspicious components. ThePort Lift Thruster is identified as the most suspi-cious, but the Port Lamp Control should also bechecked by maintenance.

At this stage the Topology Module will be in-voked to search for common connections betweenfaulty components. If none are found, the Sub-Component Diagnostics will proceed to analyze thedetailed component-specific information attached tothe most suspicious components.

The component-specific information analysiscan take a great deal of time, particularly if dynamicmodels are involved. By using the Model of Rela-tionships to highlight the components with the high-est fault probability, the total diagnostic time can begreatly reduced in comparison to simply evaluatingall available data.

It can be seen how the method of combining het-erogeneous knowledge with various types of diag-nosis can reduce the search space. If all the modelsand rules were simply run in turn, then there is avery high probability that there would be a severetime delay between detection and final diagnosis.This is particularly true when the lengthy needs ofthe dynamic models are taken into account.

7.9. Further Exemplars

For further illustration, we overview some othertypical results observed during operations, and theresponses from the system.

7.9.1. 5 v DC power supply fault

The 5 Vc power supply component supplies powerto the eight digital alarms, the AOSI Compass/Attitude sensor, and the three rate gyros. During tri-als when the 5 Vc supply failed, all the alarms,which are active low, appear to trip and the outputof the rate gyros drop to zero. Existing FDD systemswould incorrectly diagnose a plethora of failures,overloading either an operator or an automated mis-sion replanner.

The roll, pitch, and yaw rate gyros do not haveany detection information or models associated withthem and so RECOVERY only detects the alarms:

Alarm detected: ALARM�WATER at MissionTime: 211.615

Alarm detected: ALARM�PDH at Mission Time:211.615

Alarm detected: ALARM�SDH at Mission Time:211.615

Alarm detected: ALARM�PDW at Mission Time:211.615

Alarm detected: ALARM�SDW at Mission Time:211.615

Alarm detected: ALARM�PLH at Mission Time:211.615

Alarm detected: ALARM�SLH at Mission Time:211.615

Alarm detected: ALARM�SPARE at MissionTime: 211.615

Alarms detected thus automatically have theirassociated sensor component �specified in the MOR�nominated as a possible cause of the fault, and so atdetection the Suspicion Index looks like

Suspicion Index at Mission Time: 211.615Component Level Diagnostic Iteration: 0PORT�DIODE�50�SENSOR: 1STBD�DIODE�50�SENSOR: 1PORT�DIODE�60�SENSOR: 1STBD�DIODE�60�SENSOR: 1PORT�NAVSUPPLY�HOT�SENSOR: 1STBD�NAVSUPPLY�HOT�SENSOR: 1WATER�SENSOR: 1SPARE�DIGITAL�SENSOR: 1

Following invocation of the Topology Module,the common power supply component is identifiedand the following component nominations aremade:

Topology Analyzer �post iterations�Nodal Power Supply Diagnosis:PORT�BATTERY Fault Rating: 0.STBD�BATTERY Fault Rating: 0.PORT�NAV�POWER Fault Rating: 0.STBD�NAV�POWER Fault Rating: 0.TWELVE�PCONTROL Fault Rating: 0.TWENTYFOUR�PCONTROL Fault Rating: 0.COMMS�POWER Fault Rating: 0.FIVE�PCONTROL Fault Rating: 0.7 �nominated�FIFTEEN�PCONTROL Fault Rating: 0.MINUSFIFTEEN�PCONTROL Fault Rating: 0.

The 5 Vc �FIVE PCONTROL� supply has ex-ceeded the threshold of faulty supplied componentsand so, has been nominated. The suspicion indicesthen become

Suspicion Index at Mission Time: 211.615



Component Level Diagnostic Iteration: 0FIVE�PCONTROL: 1

The topology module correctly found that acommon component is faulty despite the power sup-ply having no direct measurement sensor, and with-out the use of any fault-specific information builtinto the system.

7.9.2. 12 v DC Power Supply Fault

The 12 Vc power supply component supplies powerto the depth sensor, the AOSI compass module, andthe port and starboard analogue temperature sen-sors �see Figure 24�.

On failure of the 12 Vc power supply, the depthsensor output drops to zero, as do the port and star-board analogue temperature sensors. The implemen-tation of the AOSI compass module, which commu-nicates data via an RS232 Serial Communicationslink to the onboard computer, means that, when itfails, no more data is received from it. In this eventthe onboard computer simply retains the latest val-ues, which does not change until another update isreceived from the AOSI compass module. The onlydetection associated with components supplied bythe 12 Vc power supply is the modelling of the AOSIRoll parameter. This narrow spread of detection in-

Figure 24. The 12 Vc MOR segment.



formation means that the fault can only be detectedwhen the vehicle is rolling, as the observed roll willnot match the sensed roll, which will be the samevalue as when the 12 Vc power supply failed. Whenthe vehicle is sitting flat in the water, whether it bemotionless, ascending, descending, or turning, therewill be no detection. Without detection the diagnosislevel is not, therefore, invoked.

When the 12 v power supply fails when the ve-hicle was rolling, the RECOVERY detection modulepicks up the discrepancy between the vehicle’s mod-elled roll and the frozen sensed roll parameter

Residual detected between Modelled Node:ROLL�MODEL

and Sensed Node: AOSI�ROLL at Mission Time:253.88

The associated sensor is nominated, so at detec-tion the Suspicion Index is

Suspicion Index at Mission Time: 253.88Component Level Diagnostic Iteration: 0AOSI�EZ3�COMPASS�SENSOR: 1

The Topology Analyzer is now invoked, givingthe output

Topology Analyzer �post iterations�Nodal Power Supply Diagnosis:PORT�BATTERY Fault Rating: 0.STBD�BATTERY Fault Rating: 0.PORT�NAV�POWER Fault Rating: 0.STBD�NAV�POWER Fault Rating: 0.TWELVE�PCONTROL Fault Rating: 0.25TWENTYFOUR�PCONTROL Fault Rating: 0.COMMS�POWER Fault Rating: 0.FIVE�PCONTROL Fault Rating: 0.FIFTEEN�PCONTROL Fault Rating: 0.MINUSFIFTEEN�PCONTROL Fault Rating: 0.

Because of the lack of detection information, theonly component that shows a fault, out of the fourattached to the 12 Vc supply, is the AOSI compassmodule. The fault rating of 0.25 is not enough toexceed the nomination threshold and, so, the 12 Vcpower supply is not nominated, giving a final Sus-picion Index of


This shows the benefit of having rich fault detec-tion event data. The Residual Watcher has correctlyfound that the modelled output does not match thesensed parameter, but a wider spread of simple fault

detections �from dedicated sensors or model residu-als� would have enabled the Topology Analyzer tohave correctly determined the fault was the powersupply rather than the compass.

7.9.3. 15 v DC Power Supply Fault

The ±15 Vc power supply is a dual power supply,i.e., it is a single component that provides two powerrails. It is represented in the MOR as two separatecomponents because it is possible for one power railto fail while the other remains working. This hastypically been caused by a loose wire or blown fuse�Figure 25�

The port and starboard navigation power sup-ply current �amperage� sensors, commonly knownas ‘Lems,’ require a dual supply and, so, are con-nected to both the plus and minus 15 Vc. At thistime no other components use these power rails.

When the entire power supply unit fails, boththe plus and minus fifteen volt power rails drop tozero. When this happens, the output of both Lemsalso drop to zero. Both the Lems have detection in-formation attached in the form of the port and star-board power models �modelling electric current�.When the current drawn from the navigation powersupplies is zero the output from the Lems is alsozero. If the ±15 Vc power supply fails, forcing theLem outputs to zero, when no current is beingdrawn from the navigation power supplies therewill be no detection. This is because the modelledoutput is zero, the correct output is zero, and theLem output is zero.

If the ±15 Vc power supply fails when the ve-hicle is moving, then the fault will be detected.There are two conditions: one navigation power sup-ply being used, or both. In the former case the±15 Vc power supply has failed when the starboardnavigation power supply is active because the ve-hicle is rolling to port using the starboard liftthruster.

The discrepancy between modeled and sensedstarboard navigation power supply current is de-tected:

Residual detected between Modelled Node:STBD�NAV�POWER�MODELand Sensed Node: STBD�LEM at Mission Time:

252.33



The “faulty” parameter has its attached sensorcomponent nominated automatically, so at detectionthe Suspicion Index is

Suspicion Index at Mission Time: 253.33Component Level Diagnostic Iteration: 0STBD�LEM�SENSOR: 1

The Topology Analyzer Module is invoked, pro-viding the output

Topology Analyser �post iterations�Nodal Power Supply Diagnosis:PORT�BATTERY Fault Rating: 0.STBD�BATTERY Fault Rating: 0.PORT�NAV�POWER Fault Rating: 0.STBD�NAV�POWER Fault Rating: 0.TWELVE�PCONTROL Fault Rating: 0.TWENTYFOUR�PCONTROL Fault Rating: 0.COMMS�POWER Fault Rating: 0.FIVE�PCONTROL Fault Rating: 0.FIFTEEN�PCONTROL Fault Rating: 0.5MINUSFIFTEEN�PCONTROL Fault Rating: 0.5

Both the plus and minus fifteen volt power railshave a fault rating, reflecting the dual-supply re-quirements of the Lems, but neither of them havereached the nomination threshold. This is because

with only one navigation power supply active onlyone of the Lem outputs is incorrect, the other is still“correctly” stuck at zero. The final Suspicion Index isthen

Suspicion Index at Mission Time: 253.33Component Level Diagnostic Iteration: 0STBD�LEM�SENSOR: 1

Again, a simple increase in the scope of faultdetection would have caused a fully correct diagno-sis, showing the usefulness of RECOVERY’s MOR.

With both navigation power supplies active thefault is detected, showing up in the MOR as bothport and starboard navigation power parameters notmatching their related model parameters.

The detection information is

Residual detected betweenModelled Node: PORT�NAV�POWER�MODELand Sensed Node: PORT�LEM at Mission Time:

31.48Residual detected betweenModelled Node: STBD�NAV�POWER�MODELand Sensed Node: STBD�LEM at Mission

Time:31.48

Figure 25. The ±15 Vc MOR segment.



Associated sensors components are automati-cally nominated, giving a Suspicion Index at detec-tion of

Suspicion Index at Mission Time: 31.48Component Level Diagnostic Iteration: 0PORT�LEM�SENSOR: 1STBD�LEM�SENSOR: 1

The Domain Independent Hierarchy Module isinvoked:

Domain Independent Diagnostics �post iterations�Nodal Power Supply Diagnosis:PORT�BATTERY Fault Rating: 0.STBD�BATTERY Fault Rating: 0.PORT�NAV�POWER Fault Rating: 0.STBD�NAV�POWER Fault Rating: 0.TWELVE�PCONTROL Fault Rating: 0.TWENTYFOUR�PCONTROL Fault Rating: 0.COMMS�POWER Fault Rating: 0.FIVE�PCONTROL Fault Rating: 0.FIFTEEN�PCONTROL Fault Rating: 1. �nomi-

nated�MINUSFIFTEEN�PCONTROL Fault Rating: 0.

Note that only the plus fifteen supply has a faultrating, which is high enough to exceed the nomina-tion threshold, but the MINUSFIFTEEN PCON-TROL �−15 Vc power rail� should also have a faultrating.

The Hierarchy Module automatically denomi-nates supplied components as soon as the powersupply is nominated. The final Suspicion Index is

Suspicion Index at Mission Time: 31.48Component Level Diagnostic Iteration: 0FIFTEEN�PCONTROL: 1

This is a fully correct diagnosis as the correct�dual� power supply has been nominated, eventhough it is not directly sensed and no fault-specificinformation was used. The novel Domain-Independent Hierarchy Module has worked well,using the structured MOR to find common connec-tions between supposedly faulty components. A spe-cific fault has been found using general diagnosticinformation.

7.9.4. Thermal Drift

During a hovering mission, RAUVER was posi-tioned so that it was within 1° of being absolutely

flat then left recording data whilst motionless whilsta mission log file was generated. When the data wasevaluated, the magnetic heading was found to driftupwards by approximately 1° every 10 min. On fur-ther inspection of the data, it was found that thetemperature of the compass module also drifted upduring the mission. The conclusion was that themagnetic heading variation was a thermal drift. Thistype of correlation between two parameters is ex-actly what the Correlator is designed to look for us-ing the “parameters that track a faulty parameter arelikely to be related to the fault” item of domain in-dependent diagnostic information.

The residual between predicted and observedheading was detected once a threshold value wasreached:

Residual detected betweenModelled Node: HEADING�MODELand Sensed Node: AOSI�HEADING

The faulty parameter’s related sensor was auto-matically nominated, giving a Suspicion Index at de-tection of


The Correlator was then invoked, producing theoutput

Correlator Invoked at Mission Time: 689.5Delta�Correlations:Bad�Node: AOSI�HEADINGDelta�Matches:GYRO�YAW

The final Suspicion Index was

Component Level Diagnostic Iteration: 0YAW�GYRO�SENSOR: 1AOSI�EZ3�COMPASS�SENSOR: 1

The Correlator thus failed to notice the “obvi-ous” correlation between magnetic heading drift andtemperature increase. Figure 26 shows the magneticheading, which can be seen to drift upwards overthe length of the mission. It also shows the compasssensor’s temperature superimposed. The tempera-ture information is sampled at a lower frequencythan the heading, the temperature seems to be in-creasing in a near-linear manner but the heading is



non-linear, and the heading is far more noisy thanthe temperature. However, the overall trend of bothparameters is upward.

For a more robust approach, a Delta Index wasgenerated for each parameter and then compared tothe faulty parameter’s Delta Index. The Delta Indexstarts at zero. At each time interval it is incrementedby one if the parameter has increased, decrementedif the parameter has decreased, and not modified ifthe parameter has not changed. If a parameter hasincreased at every sample during the mission, thenthe Delta Index will also have climbed constantly.The Delta Indices are then compared to the faultyparameter, and any that are close in value are nomi-nated as a “tracking parameter.” This is a very crudesearch that takes no account of different rates ofchange, delayed tracking, or different waveformshapes. At the time of detection, the Delta Indices forthe relevant parameters were

AOSI HEADING: 12.0AOSI TEMP: 18.0GYRO YAW: 14.0

The nomination threshold at this time was 2.0,which had been set during development to a valuewhich generally limited the number of parametersnominated to about 3 to prevent flooding the systemwith irrelevant data. This time the Correlator outputwas

Correlator Invoked at Mission Time: 689.5Delta�Correlations:Bad�Node: AOSI�HEADINGDelta�Matches:

AOSI�PITCHAOSI�TEMPGYRO�YAWGYRO�PITCH

The widening of the nomination window hasenabled the nomination of the temperature param-eter, but has also included other parameters. The fi-nal Suspicion Index was

Suspicion Index at Mission Time: 689.5Component Level Diagnostic Iteration: 0AOSI�EZ3�COMPASS�SENSOR: 3YAW�GYRO�SENSOR: 1PITCH�GYRO�SENSOR: 1

The AOSI compass sensor has been nominatedthree times: once at detection for sensing the faultyparameter and twice by the Correlator for being at-tached to the AOSI pitch and temperature param-eters. The two gyros have only been nominated onceeach by the Correlator for sensing their respectivenominated parameters. The Correlator is shown tobe capable of automatically picking up extremelyuseful correlations using its general diagnostic infor-mation. For a human to have extracted these corre-lations out of a large mission file would have re-quired quite some work, but the Correlator hasautomatically detected them.

7.9.5. Component Failure at Startup

Occasionally components are noticed to fail duringthe transient conditions at startup. In this example,the lift-thrusters have been inactive for several sec-onds before being activated, at which point the Star-board Lift-Thruster fails. The lack of power con-sumption is detected by comparing the StarboardNavigation Power Model with the observed power.The detection information is

Residual detected between Modelled Node:STBD�NAV�POWER�MODEL

and Sensed Node: STBD�LEM at Mission Time:439.735

The Correlator is invoked, producing the output

Correlator Invoked at Mission Time: 439.735Delta�Correlations:Bad�Node: STBD�LEMDelta�Matches:PORT�LIFTSTBD�LIFT

Figure 26. Magnetic heading and sensor temperatureduring null movement.



AOSI�MAGXRecent�Comp�Correlations:PORT�LIFT�THRUSTERSTBD�LIFT�THRUSTER

The Correlator’s Delta Index search has deter-mined that the lift thrusters have a similar Delta In-dex to the current drawn by the Starboard Naviga-tion Power Supply �sensed by the Starboard Lem�.At the time of the failure, the lift thrusters were runat matching thrusts and they were the only compo-nents drawing power from the navigation supplies.The Correlator has correctly noticed a relevant linkbetween components.

The AOSI MAGX parameter has also been nomi-nated during the Delta Index search. It is probablethat this is a coincidence as it should not be affectedby operation of the lift thrusters. During the searchfor “components that were activated shortly beforethe fault” both lift thrusters were again nominated.In this experiment this means that they were inactivefor at least 5 seconds before being activated, whichmust, in turn, have been within 3 seconds of the

fault being detected. These nominations are highlyrelevant, as it is one of the lift thrusters that hasfailed on activation.

The final Suspicion Index for this fault was

Suspicion Index at Mission Time: 439.735Component Level Diagnostic Iteration: 0PORT�LIFT�THRUSTER: 2STBD�LIFT�THRUSTER: 2STBD�LEM�SENSOR: 1AOSI�EZ3�COMPASS�SENSOR: 1

Thus, during this failure the Correlator againprovided accurate nominations.

7.9.6. Disturbance by an Environmental Event

During hovering, unexpected environmental eventssuch as a large wave or collision with a moving ob-ject �mammal, other UUV, diver� took place. Figure27 shows a full mission when a gentle collision inci-dent occurred, with the time of failure marked. RE-COVERY finishes its detection and diagnostic opera-

Figure 27. Depth, roll, pitch, and yaw �heading� during a collision.



tion within approximately 2 seconds of these failurepoints, acting as a mute watcher with no controlover the vehicle, and so the mission �and, therefore,the graphs� carry on until mission end.

RAUVER can be seen to be gently rocking �dueto surface wave action� before the environmentalevent is initiated at approximately 286 seconds �Mis-sion Time�. The event forces a considerable changein pitch, roll, and heading, with a minor change indepth.

Initially, RECOVERY correctly detects the eventat Mission Time 286.985 due to the residual betweenmodelled and sensed roll parameters. The scantmodel coverage means that the discrepancies inpitch, heading, and depth are undetected:

Residual detected betweenModelled Node: ROLL�MODELand Sensed Node: AOSI�ROLLSuspicion Index at Mission Time: 286.985Component Level Diagnostic Iteration: 0AOSI�EZ3�COMPASS�SENSOR: 1

As usual, the sensor providing the residual isautomatically nominated.

The Correlator is invoked, producing the output

Correlator Invoked at Mission Time: 286.985Delta�Correlations:Bad�Node: AOSI�ROLLDelta�Matches:AOSI�MAGZRecent�Comp�Correlations:�none�

It has found a coincidental delta match with theAOSI MAGZ parameter. The Model-Based Diagno-sis Engine is then invoked. As the residual was onlydetected with the roll model, this is the only one tobe evaluated:

Model-Based Diagnosis Engines invoked at:286.985

Roll Engine Proposes:PORT�LIFT�THRUSTERSTBD�LIFT�THRUSTERPort Power Engine Proposes:�none�Stbd Power Engine Proposes:�none�

It has found that the level of roll could be pro-duced by either of the lift thrusters malfunctioning.After ten iterations, the Suspicion Index becomes

Suspicion Index at Mission Time: 288.955Component Level Diagnostic Iteration: 10AOSI�EZ3�COMPASS�SENSOR: 16PORT�LIFT�THRUSTER: 8STBD�LIFT�THRUSTER: 8

At each iteration the lift thrusters have beennominated by the Model-Based Diagnosis Enginewhilst the AOSI compass has two nominations, oncefor generating the discrepant parameter and once forthe coincidental delta match between the roll andmagnetic x parameters.

As part of these iterations, the contribution fromthe Topology Analyzer Module was typically

Topology Analyzer �post iterations�Nodal Power Supply Diagnosis:PORT�BATTERY Fault Rating: 0.STBD�BATTERY Fault Rating: 0.PORT�NAV�POWER Fault Rating: 0.5STBD�NAV�POWER Fault Rating: 0.5TWELVE�PCONTROL Fault Rating: 0.25TWENTYFOUR�PCONTROL Fault Rating: 0.COMMS�POWER Fault Rating: 0.FIVE�PCONTROL Fault Rating: 0.FIFTEEN�PCONTROL Fault Rating: 0.MINUSFIFTEEN�PCONTROL Fault Rating: 0.

The Port and Starboard Navigation power sup-plies have the highest Fault Rating as they only sup-ply two thrusters, lift and main. As in both cases, thelift thruster has been nominated; this leads to theFault Rating of 0.5. The TWELVE PCONTROL�12 Vc� power supply has the next highest rating asit supplies the AOSI compass. None of the powersupplies have been nominated, as they do not haveenough active supplied components diagnosed asfaulty. This is a correct diagnosis. However, as nopower supplies were nominated, the Suspicion In-dex is unchanged from that detailed previously.

RECOVERY now enters component-specific di-agnostics, where the component-specific informationattached to each component via the MOR is evalu-ated. Before this the Suspicion Index must have thesub-components �components that may only be di-agnosed using component-specific information�added. In this case the port and starboard lift-thrusters have five sub-components and, so, theseare inserted after the relevant component

Component-Specific Diagnostic Level Entered



Adding Related Sub-Components to Suspicion In-dex:

Final Suspicion Index at Mission Time: 288.955Sub-Component Diagnostics LevelAOSI�EZ3�COMPASS�SENSOR: 16PORT�LIFT�THRUSTER: 8PORT�LIFT�THRUST�CONTROL: 0PORT�LIFT�MOTOR: 0PORT�LIFT�THRUSTER�BRUSH: 0PORT�LIFT�GBOX: 0PORT�LIFT�PROPELLER: 0STBD�LIFT�THRUSTER: 8STBD�LIFT�THRUST�CONTROL: 0STBD�LIFT�MOTOR: 0STBD�LIFT�THRUSTER�BRUSH: 0STBD�LIFT�GBOX: 0STBD�LIFT�PROPELLER: 0

The sub-components were not within the scopeof the component-level diagnostics and, so, theyhave no nominations. The sub-component diagnos-tic stage steps through the list from the top to thebottom and, so, the zero rating of the sub-components does not matter. The information at-tached to each suspicious component is now evalu-ated. In this implementation, the only informationattached to the components consists of dynamicrules, or rules that specify system behavior overtime:

Dynamic Rule Testing of Component:AOSI�EZ3�COMPASS�SENSORPORT�LIFT�THRUSTER StartedPORT�LIFT�THRUST�CONTROL StartedPORT�LIFT�MOTOR StartedPORT�LIFT�THRUSTER�BRUSH StartedPORT�LIFT�GBOX StartedPORT�LIFT�PROPELLER StartedSTBD�LIFT�THRUSTER StartedSTBD�LIFT�THRUST�CONTROL StartedSTBD�LIFT�MOTOR StartedSTBD�LIFT�THRUSTER�BRUSH StartedSTBD�LIFT�GBOX StartedSTBD�LIFT�PROPELLER StartedScan finished �no match found�Exiting diagnostics

In this case there is no information relevant to anenvironmental effect and, so, no relevant diagnosisis found. The final diagnosis is the final SuspicionIndex �given above� in which the AOSI Compasssensor had the highest Suspicion Index due to re-

peatedly sensing the event. This is a reasonable re-sult as the system has no knowledge of objects out-side the vehicle or collisions and can only nominatecomponents in its MOR. The disturbance observedthrough the AOSI compass is, therefore, interpretedas a fault.

8. CONCLUSIONS AND FURTHER WORK

8.1. Conclusions

A system for increasing the diagnostic capability ofan autonomous underwater vehicle has been pre-sented. Such vehicles are a typical exemplar of theclass of advanced, automated, and/or remote ro-botic systems for which RECOVERY is applicable.Some key conclusions are

• Much useful heterogeneous information isgenerated as part of the usual AUV designprocess, most of which is not generally usedfor automated diagnosis. We have used thisusefully in the development of a more pow-erful and generic diagnostic approach.

• Any system that tries to make use of this in-formation should be modular to cope withthe variety of configurations available toAUVs. Scalability to avoid the need for a dif-ferent system for each configuration of AUVare important. RECOVERY with its architec-ture meets this requirement.

• Improved fault detection and diagnosis canbe attained using different types of diagnosisand multi-dimensional viewpoints togetherwith a mixture of domain-specific anddomain-independent information. Withthese methods it is possible to diagnose spe-cific faults using general information ratherthan detailed fault knowledge �e.g., faulttrees�.

• The use of a Focus of Suspicion method cansignificantly reduce the amount of informa-tion to be analyzed.

• In water results of the RECOVERY systemhave illustrated typical operations and im-proved diagnostic performance over thatachievable by fault trees, rule bases, or faultsensors alone.

• The need for a minimum amount of sensor



data has been established, so that the systemhas sufficient information to make a correctdiagnosis.

• The diagnostic capability �and so mission ro-bustness� of an AUV can be increased by add-ing cheap, internal sensors to provide addi-tional viewpoints that support theRECOVERY approach and improved diag-nostic capabilities.

• Misdiagnoses can occur when unmodelledparts of the system are involved. Collisionwith an unmodeled object in the environ-ment is one such case, diagnosed as a tran-sient sensor fault.

Note that nowhere in this system is there a rulestating “IF ROLL is TOO�HIGH and PORT�POWER isTOO�LOW THEN PORT�LIFT�THRUSTER isFAULTY.” The models, correlator, and generalizeddiagnostic methods have highlighted this correctcomponent without any specific pointers—in effect,this fault was diagnosed without being foreseen.This is a clear advantage over a standard rulebase,traded for increased processing overhead.

It has been shown that domain independentknowledge can be used with this system but at thecost of some irrelevant fault information being pro-duced. The system can also use heterogeneous de-sign knowledge in the form of nodes and links in themodel of relationships. Other methods may beadded at the development stage. The potential forcombining different types of diagnostic tools is alsoshown.

8.2. Further work

Differing types of domain dependent diagnostictools such as Bayesian Belief Networks or NeuralNetworks could be added to study how the systemis enhanced with these powerful methods. The sys-tem must be tuned to reduce processor overheads,memory requirements, and run-time still further. Re-search is also needed on types of nodes and linkssuitable for the Model of Relationships, and the useof weighting of the Suspicion Indices should be in-vestigated. Current efforts are addressing broaderdefinitions of the MOR as an ontology that definesand integrates with maintenance processes, whichthemselves can be the cause of failure. Applicationsbeyond UUVs are also underway.

ACKNOWLEDGMENTS

The UK Engineering and Physical Sciences ResearchCouncil �EPSRC� funded this research �Award No.98315473�. East of Scotland Water has been ex-tremely helpful in making available their large selec-tion of reservoirs and lochs for testing. The UnitedStates Office of Naval Research financed visits toseveral U.S. institutions, during which many usefuldiscussions took place.

Ian Chalmers, Ron Lynch, and Dave Haldaneconstructed the mechanical components of the RAU-VER vehicle, whilst Len MacLean built and main-tains RAUVER. Without their high level of skill andeffort this research would be purely theoretical.Thanks also to the whole of the Ocean SystemsLaboratory for invaluable contributions and sugges-tions.

REFERENCES

Albus, J.S., Quintero, R., & Lumia, R. �1994�. Overview ofNASREM: The NASA/NBS standard reference modelfor telerobot control system architecture. NASA STI/Recon Technical Report, 1994, Vol. 95.

Aldea, A. �1994�. The use of scheduling and hierarchicalmodelling techniques for time-limited model-baseddiagnosis. Ph.D. thesis, 1994, Heriot-Watt University,Edinburgh, Scotland.

Alessandri, A., Caccia, M., & Veruggio, G. �1998�. A modelbased approach to fault diagnosis in unmanned un-derwater vehicles. OCEANS ’98 Conference Proceed-ings, Vol. 2, pp. 825–829.

Bernard, D.E., Dorais, G.A., Fry, C., Gamble, E.B., Kanef-sky, B., Kurien, J., Millar, W., Muscettola, N., Nayak,P.P., Pell, B., Rajan, K., Rouquette, N., Smith, B., &Williams, B.C. �1998�. Design of the remote agent ex-periment for spacecraft autonomy. Proc. IEEE Aero-space Conference, Vol. 2, pp. 259–328.

Caccia, M., Indiveri, G., & Veruggio, G. �2000�. Modellingand identification of open-frame variable configura-tion unmanned underwater vehicles. 2000, IEEE Jour-nal of Oceanic Engineering, 25, 227–240.

Chantler, M., Coghill, G., Shen, Q., & Leitch, R. �1998�.Selecting tools and techniques for model based diag-nosis. Artificial Intelligence in Engineering �12�, 1998,81–98.

Dearden, R., Willeke, T., Hutter, F., Simmons, R., & Verma,V., �2004�. Real-time fault detection and situationalawareness for rovers: Report on the Mars TechnologyProgram Task. Proceedings of IEEE Aerospace Confer-ence, pp. 826–840.

Deuker, B., Perrier, M., & Amy, B. �1998�. Fault diagnosisof subsea robots using neuro-symbolic hybrid sys-tems. OCEANS ’98 Conference Proceedings, Vol. 2,830–834.



Dunia, R., & Qin, S.J. �1998a�. A unified geometric ap-proach to process and sensor fault identification andreconstruction: The unidimensional fault case. Com-puters & Chemical Engineering, Vol. 22, No. 7–8, 927–943.

Dunia, R., & Qin, S.J. �1998b�. A subspace approach tomultidimensional fault identification and reconstruc-tion. American Institute of Chemical Engineers�AlChE� Journal, 44, 1813–1831.

Finlay, J., & Dix, A. �1996�. An Introduction to ArtificialIntelligence. UCI Press, ISBN 1-85728-399-6.

Hamilton, K., Lane, D., Taylor, N., & Brown, K. �2001a�.Fault diagnosis on autonomous robotic vehicles withRECOVERY: An integrated heterogeneous-knowledgeapproach. International Conference on Robotics andAutomation ICRA 2001, 4, 3232–3237.

Hamilton, K. �2001b�. An integrated diagnostic architec-ture for autonomous robots. Ph.D. thesis. Ocean Sys-tems Laboratory, Heriot-Watt University, Edinburgh,Scotland, U.K.

Hansen, T. �1988�. Diagnosing multiple faults usingknowledge about malfunctioning behavior. Proceed-ings of the first international conference on Industrialand engineering applications of artificial intelligenceand expert systems, June 1988, pp. 29–36.

Massuyes, L.T. �2003�. Bridging AI and control engineeringmodel-based diagnosis approaches. Presentation, Mo-net Summer School, Crete, Greece.

Mosterman, P., & Biswas, G. �2000�. A comprehensivemethodology for building hybrid models of physicalsystems. Artificial Intelligence, 2000, 1–39.

Perrault, D., & Nahon, M. �1998�. Fault-tolerant control ofan autonomous underwater vehicle. OCEANS ’98Conference Proceedings, Vol. 2, 820–824.

Price, C., & Taylor, N. �1997�. Multiple fault diagnosis fromFMEA. Proceedings AAAI-97, 1052–1057.

Russell, S., & Norvig, P. �1995�. Artificial Intelligence, AModern Approach. �1995�. Englewood Cliffs, New Jer-sey, Prentice Hall International.

Sampath, M. �1995�. A discrete event based approach tofailure diagnosis. Ph.D. thesis, University of Michi-gan.

Shen, Q., & Leitch, R. �1995�. Diagnosing continuous sys-tems with qualitative dynamic models. IntelligentSystems Laboratory, Heriot-Watt Univesity, U.K.,1995, Artificial Intelligence in Engineering �9�, 107–125.

Sowa, J.F. �1999�. Knowledge Representation: Logical,Philosophical, and Computational Foundations, �NewYork, Brooks Cole�.

Staroswiecki, M. �2001�. Tutorial on FDI approaches. Pre-sentation, International Workshop on Principles of Di-agnosis �DX’ 01�.

Takai, M., & Ura, T. �1999�. Development of a system todiagnose autonomous underwater vehicles. Univer-sity of Tokyo, Japan, 1999 International Journal of Sys-tems Science, 981–988.

Uppal, F.J., & Patton, R.J. �2002�. Fault diagnosis of anelectro-pneumatic valve actuator using neural net-works with fuzzy capabilities. in Proceedings of Eu-ropean Symposium on Artificial Neural Networks,ESANN’02.

Washington, R. �2000�. On-board real-time state and faultidentification for Rovers. in Proceedings IEEE Interna-tional Conference on Robotics and Automation, April2000.

Yang, K., Yuh, J., & Choi, S.K. �1998�. Experimental studyof fault-tolerant system design for underwater robots.Autonomous Systems Laboratory, University of Ha-waii, Honolulu, IEEE Int Conf Robotics and Automa-tion ICRA1998, 1051–1056.



An integrated diagnostic architecture for autonomous underwater vehicles

Documents

Transcript of An integrated diagnostic architecture for autonomous underwater vehicles