Intelligent Control of Auxiliary Ship Systems

David Scheidt, Christopher McCubbin, Michael Pekala, Shon Vick and David AlgerThe Johns Hopkins University Applied Physics Laboratory

11100 Johns Hopkins RoadLaurel Maryland 20723-6099

Abstract

The Open Autonomy Kernel (OAK) is an architecture for au-tonomous distributed control. OAK addresses control as athree-step process: diagnosis, planning and execution. OAKis specifically designed to support “hard” control problems inwhich the system is complex, sensor coverage is incomplete,and distribution of control is desired. A unique combinationof model-based reasoning and autonomous agents are used.Model-based reasoning is used to perform diagnosis. Obser-vations and execution are distributed using autonomous in-telligent agents. Planning is performed with simple script orgraph-spanning planners. A prototype OAK system designedto control the chilled water distribution system of a Navy sur-face ship has been developed and is described.

IntroductionNext generation ship engineering plant designs must in-corporate a variety of increasingly sophisticated propul-sion and auxiliary subsystems while reducing the overallrequirement for human monitoring, maintenance and con-trol. In order to meet these objectives, new levels of subsys-tem interoperability and autonomy must be achieved. TheOpen Autonomy Kernel (OAK) addresses critical infrastruc-ture requirements for next generation autonomous and semi-autonomous systems, including fault detection and recovery,and goal-directed control. OAK brings together the Arti-ficial Intelligent (AI) technologies of agent-based systems,and qualitative model-based reasoning to enable a new gen-eration of integrated auxiliary subsystem autonomy.

Efforts to automate the control of engineering plantsaboard naval vessels have emphasized the infrastructure anddiagnostic aspects of plant management, i.e. monitoringvessel subsystems via sensors and presenting sensor datato human operators. Interpretation of and response to thedata remain largely manual tasks. This interpretation and re-sponse function, especially in damage control scenarios, is asignificant factor in determining ship-manning levels. If theincident assessment and response loop can be closed witha reliable autonomous reasoning process, significant reliefin overall manning levels can be realized. Successful au-tomation efforts to date have been based on expert diagnos-tic knowledge in the form of coded rules or procedures that

Copyright c© 2002, American Association for Artificial Intelli-gence (www.aaai.org). All rights reserved.

are interpreted by the system at runtime to detect, predict, ordiagnose fault conditions. The OAK architecture and work-ing prototype extend this automated reasoning paradigm ina number of important ways. First, OAK uses goal-directedcommanding at the system component level. This shifts thecontrol paradigm from one of sending commands to sub-systems, to that of sending goals and resources to intelli-gent subsystem management agents that require no directoperator interaction. Secondly, OAK’s subsystem manage-ment agents are loosely coupled and distributed across a net-worked infrastructure. This results in a dynamic and adapt-able coordination capability. Finally, OAK uses qualita-tive model-based reasoning as an extension to current rule-and procedure-based formalisms in the agent control loop.Model-based reasoning is used to perform real-time detec-tion and identification of unanticipated fault conditions.

Motivating ExampleThe motivating example used for the existing prototypeis the control of auxiliary systems on capital ships. Thespecific target domain is the electrical, chilled water, low-pressure air and fire main systems on US Navy ArleighBurke class Aegis destroyers. These systems are complex,inter-dependent, distributed, redundant, embedded, and con-tain numerous components that are unobservable. Currentlyhigh level control is the primary responsibility of dozens ofsailors on each ship. Effective automation of these systemswill allow the Navy to significantly reduce its manning re-quirements.

The auxiliary systems on the Arleigh Burke contain thou-sands of interdependent controllable nodes. One of the aux-iliary systems, the chilled water distribution system, consistsof a dozen complex machines, such as pumps and chillerplants, approximately four hundred valves, and twenty-threeservice loads. Behavior of components within an auxiliarysystem is dependent upon the components to which they areconnected, often recursively. The auxiliary systems them-selves are inter-dependent; for example, the chilled watersystem runs on electrical power provided by the electricalsystem while the electrical system is kept cool by the chilledwater system. Behavior of the auxiliary systems is also de-pendent upon other ship systems such as the HVAC, com-bat, and fire support systems. These dependencies combineto generate a complex super-system; no portion of which

IAAI-02 913

From: IAAI-02 Proceedings. Copyright © 2002, AAAI (www.aaai.org). All rights reserved.

may be controlled in isolation. The size of the auxiliary sys-tems, combined with their interdependency, prevents the ef-fective use of traditional control system software. The auxil-iary systems are designed with redundant supply and distri-bution mechanisms for critical resources. This redundancypresents the possibility of multiple valid configurations fora goal system-state pair, introducing control optimization inaddition to control satisfaction.

Survivability, the justification for redundancy within aux-iliary systems, demands that auxiliary control mechanismsavoid single points of failure. Therefore, the control mecha-nism must be fault tolerant.

The auxiliary Arleigh Burke control systems are onlysparsely instrumented. The vast majority of system com-ponents do not have sensors that provide direct feedback onthe behavior of the component. Comprehensive sensor cov-erage incurs additional cost, resource utilization and intro-duces additional points of failure. Without the availabilityof complete sensor coverage system states must be inferredfrom indirectly observable behavior.

Model-Based ReasoningModel-Based Reasoning is an overloaded term. The Model-based reasoning used in OAK refers to a “reasoning fromfirst principles” approach to diagnosis (Kuipers 1994).The theoretical basis for model-based reasoning is Dis-crete Event System theory, specifically Partially ObservableMarkov Decision Processes (POMDP).

Discrete Event System theory shows that systemsmay be modeled discretely using the automaton G =(X, E, f,Γ, xo, Xm) (Cassandras & Lafortune 1999) inwhich X is the discrete state space; E is the finite set ofevents associated with the transitions in Γ; f is the transi-tion function; Γ is the active event function; xo is the initialstate; and Xm is the set of marked states. Control of Γ isprovided by a control policy S that includes a set of controlactions S(s).

Automata that are memoryless (i.e. all past state infor-mation, and how long the process has been in the currentstate, is irrelevant), are considered Markov Processes. Asso-ciation of control actions for state transitions, cost for suchtransitions, and transition probabilities, allows us to deriveMarkov Decision Processes (MDP). MDP are defined by thetuple (XS , EA, fT , R) in which: XS is the finite set of statesof the system being tracked; A is the set of commands; EA

is a finite set of actions; and fT is a state transition model ofthe environment which is a function mapping XS ×EA intodiscrete probability distributions over XS . The actions arenon-deterministic, so we write fT (x, e) for the probabilitythat transition e will occur given the state x. R is the costof action. Our use of model-based reasoning is limited todiagnosis; therefore we are not concerned with R.

POMDP are MDP that have been extended to include afinite set of observations. POMDP are represented by thetuple M = (XS , EA, O, fT , R) in which O is the observationfunction that maps the finite set of observations into XS .The probability of making an observation o from state x isdenoted as O(o, x).

The tuple M is capable of representing the behavior ofsystems that are composed of independent subsystems. Thismay be generated by creating a supermodel MS whosestates, events and function are the cross product of the sub-system models; MS = M1×M2×. . .×MN . This approachto modeling complex systems is impractical for two reasons:first, the state space quickly becomes unwieldy; second,the majority of complex systems of interest are composedof dependent subsystems. Model-based Control solves thisdilemma by modeling the system as concurrent constraintautomata, separately enumerated component models that areconstrained by shared attributes (Williams & Nayak 1996).

This representation scheme is beneficial when construct-ing large complex systems. By encapsulating componentbehavior within a single logical model and by constrain-ing components through context independent attributes thecomponents themselves become context independent mod-els. This provides for model replication and reuse.

Model-based reasoning is a three-step process: (1) Prop-agation of control action effects through a system. Prop-agation generates a predicted state for the system, includ-ing controlled and uncontrolled components. Observationsof system behavior are compared to the predicted state; ifobservations match predictions then the system is assumedto be behaving nominally. The existence of conflicts be-tween observed and predicted states indicate the existenceof one of more failures within the system. (2) Identificationof candidate failure scenarios that most effectively resolvethe conflicts. The strategy used to resolving these conflictsis Conflict-directed best first search (CBFS), loosely basedon De Kleer and Williams’ General Diagnostic Engine (deKleer & Williams 1987) and described in detail by Kurien(Kurien 2001). (3) Selection of the most probable scenariofrom the identified candidates. The fitness criteria used byCBFS to select the most probable solution is a system-widecandidate probability based upon the probabilities of indi-vidual component states fT (Xi, Ei)∀M ; by using a gen-eral diagnostic algorithm, implementation effort is limitedto the model upon which the algorithm operates. Systemdesign and maintenance do not require software modifica-tions. In addition, because of the encapsulation of the com-ponent models, model maintenance is limited to those com-ponents modified in the controlled system and their immedi-ate neighbors.

Autonomous AgentsWithin the context of OAK, an agent is a software processthat can reason about and act upon its environment. Foursets of characteristics that may be used to describe agentsand agent systems are: Intrinsic Agent Characteristics; Ex-trinsic Agent Characteristics; System Characteristics; andAgent and Environment-Agent characteristics. OAK agentsare intrinsically permanent, stationary, exhibit both reactiveand deliberative behavior, and are declaratively constructed.Agents are reactive in their ability to reconfigure the sys-tems within their control in the context of an existing plan.Agents are deliberative in their ability to create a plan in re-sponse to observed states and defined goals. OAK agent’sextrinsic characteristics include proximity to the controlled

914 IAAI-02

system, social independence, and both awareness of and co-operativeness with goals and states of other agents. Systemsof OAK agents consist of nearly homogeneous agents, andare independently executed yet contain unique models of thesystem for which the agent is responsible. OAK agents areenvironmentally aware and behavior of the environment ispredictable through each agent’s model.

Application DescriptionOAK is a distributed, multiagent system. The system canhave varying topology based on the application. OAK hastwo major use-cases that almost fully describe the opera-tion of the system: OAK’s reaction to user-input goals; andOAK’s reaction to system state change. The primary intelli-gent components that enable OAK to accomplish these use-cases are the model-based reasoning engine and the planner.In the sections that follow, the OAK application is describedin detail.

The Multiagent SystemTo perform the diagnostic phase of the control cycle, OAKagents continually update their states using the model-basedreasoning engine, and pass these state updates to otheragents that are interested so that these agents may updatetheir states. In response to these states, or to the system’s en-vironment, an external actor or an OAK agent will providegoals to the OAK system, which are distributed for furtherprocessing. A hierarchical agent topology was used for test-ing. However, the OAK architecture does not preclude othertopologies.

Agent Communication Framework and LanguageEach agent has an associated Agent Communication Broker(ACB), which is responsible for handling all of the agent’scommunication with the Agent Communication Framework(ACF). The ACB maintains a queue of messages cominginto the agent. Additionally, each agent that has directcommunication with hardware has a control mediator (CM)to handle the hardware level goals that are generated bythese agents for the hardware associated with it, and toreceive updates about this hardware. These messages arenot handled by the ACF.

The ACF of OAK is built using the Control of AgentBased Systems (CoABS) Grid, a “flexible information in-frastructure” built by Global InfoTek, Incorporated. CoABSallows OAK to have a dynamic, heterogeneous agent mem-bership, facilitates agent replication to remove single pointsof failure, and supplies utilities for ACF visualization.

The Agent Communication Language (ACL) of OAKprovides several message templates, including messages forqueries, state updates, subscription requests, goals, excep-tions, and agent coordination. The ACF allows any agentto communicate directly with any other agent. Thus, com-munication between agents is not restricted to any particularlogical framework.

User-determined Goals One of the major use-cases ofOAK is to react to goals entered by an external actor. Theseare system-level goals which have the potential of transition-

ing the entire multiagent system from one state to another.Goals that are entered from an external actor, such as a

human operator, through this interface are sent directly to theroot level agent using a goal message. This agent develops aplan with goals that apply to the domains of its child agents.Goals have a priority associated with them, which is usedfor goal preemption.

After the root node develops a plan and directs a goalto one of its child agents, the goal is received by the childagent’s ACB, sorted into its queue, and eventually acceptedby the agent for processing. This agent develops a plan toimplement the goal. Since this agent is a root of its own tree,the goals developed by the planner are passed to its childagents. This propagation continues until leaf agents receivegoals for their specific domains.

Once goals are received at the leaf level, a similar pro-cess occurs, in that a plan is developed and goals are passedout of the agent. The only difference is that the goals arenow passed to the agent’s CM, which translates the goal intocommands that a hardware driver can understand. Since theCM is the only component that has direct interaction withthe hardware drivers, it is the only component that has to beupdated when hardware itself is changed or when hardwaredrivers are updated.

Successful goal implementation implies a state change, soan agent does not have to set up callbacks with the hardwareto confirm that a command was successful. Leaf agents arealready required to monitor the hardware they control forchanges in order to accomplish the second major use-caseof OAK. Therefore, the leaf agents wait for reactions fromhardware monitors to indicate that the command has beensuccessful. The agent is then free to pass out goals that wereorder dependent on the goal just implemented. Since statechanges are propagated up the hierarchy, agents at higherlevels are also informed that their goals were implementedand they can then pass out goals that had to be put in a waitstate. To an implementer of OAK, this means that the in-coming goal use case and the state change use case, whichcomprise the two major functions of OAK, are decoupled.

Reacting to State Changes To appropriately handlechanges in the state of the system, OAK uses a model-basedreasoning engine (MBRE)(Kurien & Nayak 2000). In thissection, we follow the sequence of events that are impliedby a state change in OAK.

State change events are transmitted through the use ofa fact message. This message contains a representation ofthe knowledge contained in an agent. When states change,all subscribed agents are informed, and propagation of statechanges begins. Note that since many agents may subscribeto an event, state changes may be propagating in several sub-trees at any given time.

One of OAK’s strengths is an agent’s ability to determinethe state of its model, compare that state to a knowledgebase, and reactively plan. Thus, an agent can autonomouslycontrol its domain until an agent that is higher in the hier-archy (or in the case of the root agent, the external actor’sagent) preempts its control. The component of OAK thatcontrols reactive planning is called the reactive manager.

IAAI-02 915

There are two types of information in the reactive manager:persistent goals and emergency conditions.

Persistent goals are simply goals that are desired true forthe duration of the agent.

We define an emergency condition as a state that cannotbe reversed and requires OAK to act immediately to protectthe resident system. When OAK detects an emergency, itwill preempt the external actor’s goal and go to a predeter-mined goal that will minimize damage to the system beingmodeled. From this point on, goals from the user are im-plemented as completely as possible based on the damage tothe system.

PlanningOAK agents must be able to plan in order to achieve speci-fied goals. The plan format is an ordered sequence of frag-ments. Each fragment consists of one or more subgoals. Theidea is that, within a fragment, each subgoal may be accom-plished in parallel, while subgoals in a prior fragment mustbe completed before the current fragment may be attempted.OAK executes a plan once it has been developed by trans-mitting each subgoal at the appropriate time to the appropri-ate agent or piece of hardware and waiting until those sub-goals are accomplished or fail.

Different planners may be appropriate for different agentsdepending on the domain being planned. Therefore, theplanner is instantiated at run-time differently for each agentfrom a group of developed planners. So far, two plan-ners have been developed. The deployed planners are theScripted Planner and the highly specialized Graph-BasedPlanner.

The scripted planner is extremely simple but useful forsimple agents, such as leaf agents. The scripted plannermatches on the incoming goal and a propositional logicexpression about the current world-state, producing a pre-defined response. Different propositional expressions, andtherefore plans, may be associated with each incoming goal.Also, since the scripts are checked in a specific predefinedorder, a simple priority of plans can be imposed.

The graph-based planner was written specifically for thetest domain described below. Planning consisted of deter-mining how to move flow from a source to several sinksthrough a dynamic pipe network, with many operationalconstraints. The problem representation was a digraph, withweights on each edge according to the constraints. The plan-ner operated by performing Prim’s Minimum Spanning Tree(Prim 1957) algorithm on the graph to determine how to getflow to as many of the desired sinks as possible. The plannerdetermined the actions that each agent would need to takeand would generate a plan based on the actions determined.

ImplementationOAK has been implemented on the Chilled Water ReducedScale Advanced Demonstrator (RSAD) at the Naval SurfaceWarfare Center (NSWC) Philadelphia. The RSAD, seen inFigure 1, is a reduced scale model of the Arleigh BurkeChilled Water system. The RSAD is a physical implementa-tion of two Arleigh Burke chilled water zones using reduced

Figure 1: Reduced Scale Advanced Demonstrator (RSAD)

scale equipment. The RSAD contains four pumps, twochiller plants, two expansion tanks and approximately onehundred controllable valves. In-line tanks containing con-trollable heaters simulate equipment that is directly cooledby the chilled water system. The units of equipment cooledby the chilled water system are known as loads. The RSADincludes sixteen simulated loads.

The RSAD control prototype uses twenty OAK agents tocontrol the RSAD’s pumps, plants and valves. Each agentcontains its own diagnostic engine, planning engine(s), ex-ecution managers, and the ability to receive and propagategoals and facts. The agents are organized hierarchically withagents controlling individual hardware components, smallaggregations of components, system level abstractions, andthe ship.

The L2 inference engine was used within the OAK agentsas the diagnostic engine. L2 is NASA AMES ResearchCenter’s second generation model-based reasoning engine.L2, and its predecessor Livingstone, are based on Williams’model-based reasoning approach.(Williams & Nayak 1996)Livingstone was demonstrated as a diagnostic tool for faultanalysis of satellites in a 1998 experiment on NASA’s DeepSpace One(Muscettola et al. 1998). Models processed byL2 are written in the Java-Based Model Programming Lan-guage (JMPL). L2 provides multiple candidate identificationand resolution strategies. The strategy used for the RSADprototype is CBFS(Kurien 2001). The L2 CBFS implemen-tation uses constraint satisfaction to identify candidate sys-tem states. The candidate states are then maintained as hy-pothetical belief states over time. Each successive observa-tion is used to update the stored belief states and to gener-ate new hypothetical belief states. L2 provides a likelihoodrank associated with each belief state. OAK reconfigures theRSAD based upon the current most likely belief state whilemaintaining other trajectories. The reasoning system is non-monotonic, as active belief states will be abandoned if futureobservations provide support to other previously less likelypossible belief states.

Each OAK agent contains a JMPL model of the real-worldsystem or subsystem for which it is responsible. The modelincludes POMDP representations of components within theagent’s system or subsystem.

916 IAAI-02

The ship agent’s planner accepts high-level goals fromthe ship’s Command Center. The ship agent also acceptsinferred facts from the intermediate agents that express thebelieved state of the ship systems. The ship agent plannergenerates goals for the intermediate agents.

The Chilled Water agent is the only intermediate levelagent currently implemented in the RSAD prototype. Themodel used for diagnosis in the chilled water agent consistsof twenty-one components. Each component represents asmall cluster of machinery within the RSAD. The ChilledWater Agent directly controls eleven of these components.

Beneath the Chilled water agent in the hierarchy are eigh-teen low-level agents. These agents manage the two coolingunits with their supporting valves and regional valve-pipeaggregate components within the chilled water system.

ResultsThree test sets were performed for the RSAD implemen-tation of OAK. The first round of testing was performedfor and by the development team. The second round oftesting was performed with control systems engineers fromthe Naval Surface Warfare Center Carderock Division Ad-vanced Auxiliary Controls and Automation Group (NSWC-CD Code 825) who are familiar with the Arleigh Burke aux-iliary systems. The third round of testing was performed forrepresentatives of the ship construction industry. All threesets of testing followed the same format. All tests were per-formed with the RSAD hardware. Four types of test sce-narios were performed during each test set. The first threescenarios were designed to provide basic coverage of the pri-mary OAK capabilities. The final portion of testing was adhoc, and provided the testers an opportunity to game the sys-tem. During the second and third test sets, hardware faultswere instigated by either physically disconnecting a compo-nent from its power supply or by physically disconnecting acomponent from the control network.

The first test scenario was used to demonstrate OAK’sability to reconfigure the RSAD based on high level oper-ator goals. During this test scenario the RSAD was givenconsecutive commands from a Command and Control simu-lator to move from one “ship state” to another. The four shipstates each have a unique combination of desired states andfitness criteria.

The second test scenario consisted of inducing a series ofsequential component failures that initially force OAK to re-configure the system in order to satisfy the high-level goalsand eventually degrade the RSAD so that the RSAD’s statedgoals are no longer achievable. The second scenario wasalso specifically designed to test the non-monotonic capabil-ity of the reasoning engine. An improbable component fail-ure that was observationally indistinguishable from a prob-able failure was generated resulting in a misdiagnosis. Sub-sequent failures generated observations that re-enforced thecorrect belief state and caused a change of hypothesis withinthe inference engine.

The third scenario consisted of inducing simultaneousfailures to multiple components within the RSAD.

Throughout the testing OAK consistently demonstratedthe ability to plan, execute, and propagate facts and goals

between agents. During the first test set, the test team foundin OAK the propensity to select a legitimate yet unlikelycandidate from a set of possible candidate diagnosis. Thisproblem was addressed by modifying the agent topology forthe RSAD implementation. After modifications were made,all three test sets were successfully completed. In total, four-teen separate multi-stage tests were conducted. During thesefourteen tests, OAK performed thirty-four diagnose-plan-execute cycles. OAK was able to identify the most proba-ble failure scenario when insufficient observables presentedmultiple indistinguishable situations: also, OAK demon-strated the ability to retroactively update its belief state whenevidence was provided to support what had been a less prob-able candidate solution.

In some cases, equivalent “best fit” reconfigurations wereavailable. In these cases the observing mechanical engi-neers noted that OAK’s reconfiguration was occasionally“unusual” or “not what I would have selected”. However,upon inspection, the selected reconfiguration was alwaysconsistent with the reconfiguration goals and fitness criteria,and considered reasonable by the observing engineers.

In addition to planned testing, twice during the third testset the RSAD experienced unexpected hardware failures.One failure consisted of a chiller plant unexpectedly failingto the OFF state. Another failure consisted of a valve un-expectedly failing to STUCK SHUT. During both of theseunexpected failures, OAK correctly diagnosed the failuresand successfully reconfigured the RSAD.

OAK’s planning and execution capabilities succeeded inperforming a successful reconfiguration of the RSAD in alltest cases. In all cases where a complete solution was avail-able, a solution was found. In cases where multiple solu-tions were available, OAK was able to determine and selectthe solution deemed optimal in accordance with the fitnesscriteria expressed in the script-planner rule base. When nocomplete solution was available, the “best fit” partial solu-tion was identified and executed.

Difficulties Distributing Diagnosis in StronglyCoupled SystemsEach OAK agent maintains the ability to obtain observationsand perform diagnostics on components that the agent con-trols. Individual agents use observations to infer componentstates within the agent’s sphere of influence. Information oncomponent states are propagated throughout the agent com-munity by disseminating facts that represent the belief stateof the agent-modeled subsystem. The model and diagnosticengines within individual agents are independent and, by de-sign, capable of performing diagnosis in isolation from otheragents. When an observation is made that conflicts with themodel’s current belief state (indicating a fault within the sys-tem), the reasoning engine attempts to resolve the conflictinternally. When the observation and faulty component(s)are both contained within the same agent/model, OAK wasfound to correctly diagnose component failures. However,when a conflicting observation is observed by one agent andthe failed component is within the sphere of influence ofanother agent, and a candidate failure within the observingagent’s model exists, the observing agent will attempt to re-

IAAI-02 917

solve the conflict prior to disseminating observations. Sincea candidate solution does exist, the observing agent will re-solve that its internal solution is correct and disseminate thebelief that its internal component is faulty. This can resultin OAK selecting a less likely candidate state for the systemover a more likely candidate.

The potential to select unlikely candidate failure stateswas mitigated by removing the diagnostic portion of thecontrol loop from those agents that did not have access toobservables either directly or through subordinate agents.Diagnostic responsibility for components that did not haveaccess to observables was the undertaken by the lowest par-ent agent in the hierarchy that did have access to the nec-essary observations. In the RSAD implementation, this in-volved moving the diagnostic responsibility for the chillerplant agents into the Chilled Water agent. All agents re-tained the ability to make observations, plans and executecommands. Thus modified, OAK was able to successfulcomplete all three sets of tests.

Future WorkWhile the principle of OAK has been demonstrated in a realworld setting, additional non-AI related steps are necessaryfor OAK’s acceptance into ship construction. A partial listof future non-AI activities include the creation of a matureset of modeling tools, development tools, and testing uponactual ships.

Future AI related activities involve the extension of themodeling capability (and corresponding model-based rea-soning) to include more diverse and sophisticated represen-tations. The most straightforward modeling extension in-volves the detailed modeling of the other auxiliary ship sys-tems; namely the electrical and low pressure air distributionsystems. Slightly more sophisticated is the ability to incor-porate a model of the control system itself into the ship sys-tems model. By modeling the control network and the com-puting infrastructure, the control system becomes capable ofreasoning with an inability to command otherwise functionalcomponents. Particularly interesting is the possibility thatoperating agents could jointly control a system through ob-serving each other’s behavior should their communicationsbecome severed.

In addition to extending the modeling capabilities later-ally, more comprehensive control may be found by extend-ing the modeling vertically as well. In the RSAD imple-mentation, the ship model above the chilled water systemwas limited to a simple finite-state model of the basic shipoperating modes. Complex models of ship operating prac-tices and policies have been developed. Extending OAK’smodeling capability upward to incorporate both fluid controland operational models within a common reasoning systemwould further improve OAK’s effectiveness. OAK may beimproved by extending modeling downward as well. JMPLlacks the sophistication to represent detailed fluid systemsnormally modeled by ordinary differential equations. Hy-brid modeling involving discrete and continuous models is alarge vibrant community.

Finally, distributed non-monotonic reasoning should beinvestigated. Recall that while facts and goals are shared

between agents, reasoning is performed in isolation. The in-ability to send out tentative facts limits diagnosis to encapsu-lated systems that have co-located components and observ-ables.

ConclusionsOAK has successfully demonstrated the ability to au-tonomously control complex, sparsely observable systemswith social distributed agents that use model-based rea-soning for system diagnosis. Specifically OAK has beendemonstrated on a reduced scale version of a US Navy de-stroyer’s chilled water distribution system. The design ofOAK is not ship system specific, and OAK has the potentialto improve the autonomous control of real-world systemsthat exhibit similar traits. Systems OAK should be effectivein controlling include electrical utilities, water utilities andcommunications systems.

AcknowledgmentsWe conducted this work as part of the Office of NavalResearch “Machinery Systems and Automation to ReduceManning” program under contract N00014-00-C-0050. TheRSAD and low-level control software was developed andprovided by the Naval Surface Warfare Center CarderockDivision Advanced Auxiliary Controls and AutomationGroup. Don Dalessandro, Brian Callahan, Richard Avilaand William Basil provided substantial insight into the Ar-leigh Burke auxiliary control system design and Naval doc-trine. John Bracy contributed to the editing of this paper.

ReferencesCassandras, C., and Lafortune, S. 1999. Introduction toDiscrete Event Systems. Kluwer Academic Publishers.de Kleer, J., and Williams, B. 1987. Diagnosing multiplefaults. Artificial Intelligence 32:97–130.Kuipers, B. 1994. Qualitative Reasoning. The MIT Press,Cambridge MA.Kurien, J., and Nayak, P. 2000. Back to the future forconsistency-based trajectory tracking. In Proceedings ofAAAI-2000.Kurien, J. 2001. Model-Based Monitoring, Diagnosis andControl. Ph.D. Dissertation, Brown University Dept. ofComputer Science.Muscettola, N.; Nayak, P.; Pell, B.; and Williams, B. 1998.Remote agent: to boldly go where no AI system has gonebefore. Artificial Intelligence 103:5–47.Prim, R. 1957. Shortest connection networks and somegeneralizations. Bell System Technical Journal 36:1389–1401.Williams, B., and Nayak, P. 1996. A model-based ap-proach to reactive self-configuring systems. In Proceedingsof AAAI-1996.

918 IAAI-02