Orca is designed to meet the requirements listed above. It will be only one part of the software controlling the LRAUV. Current plans are to use the existing MSEL software architecture [\protect\citenameBlidberg &Chappell, 1986] as the basis for the LRAUV's control software. It is a hierarchical, layered set of modules (see Figure 2) arranged by functionality and time requirements. Orca will comprise the topmost, or mission, layer. It will receive as input symbolic, subjective (with respect to specified parameters) data from the Situation Assessment module (e.g., ``too deep'') and will give commands (e.g., ``move to (x,y,z)'') to the Navigator module.
A benefit of this approach is that Orca will not have to deal with the minutiae of sensor, motion, and effector management. Instead, it will be presented with a ``virtual AUV,'' complete with abstract (virtual) sensors and operators it can use to carry out its missions. This will allow Orca to be much more broadly applicable to other autonomous vehicles than if it had to incorporate a detailed knowledge of the underlying vehicle. Another benefit is that Orca need only be a ``soft'' real-time system-the underlying software will handle those events requiring very rapid response based on how Orca has configured it in advance.
Orca has several modules, as shown by the rounded boxes in Figure 3. All of the modules share a working memory, which is a central repository for information about the state of the vehicle and mission. All input to Orca comes in via Event Handler, and all output leaves via Schema Applier.
Event Handler (EH) is responsible for noticing and handling all events, both those anticipated by the program and those that are unanticipated. The former is recognized based on predictions present in the working memory (WM), placed there by Schema Applier(SA), while the latter are recognized using,in the current version of Orca, a rule-based reasoner. Anticipated events are handled by notifying Agenda Manager (AM) of their occurrence. Unanticipated events are diagnosed to determine their cause, then their importance is estimated and an appropriate response is selected. Each of these activities is also done in the current version by a rule-based system. The response-usually a new goal to be activated (e.g., ``photograph object'' if an ``interesting'' object is seen)-is sent to AM, which activates it by placing it on the agenda.
Messages to the LRAUV from outside are also handled by EH; the rational for this is that messages are just a special kind of event. They, too, may be anticipated or unanticipated, and they are handled in much the same way as any other event, at least as far as EH is concerned. Failures are similarly treated as events. Failures can come either from the lower-level architecture (LLA) or from SA. In either case, EH treats a failure as an event by diagnosing its cause, estimating its importance, and selecting a response.
Agenda Manager (AM) is responsible for activating and deactivating goals and for selecting the current focus of attention-that is, the goal that is currently being worked on. Currently, it, too, uses a rule-based system to focus attention. As the focus changes, it can command Schema Applier to stop what it is doing and to switch to working on another goal.
Schema Applier (SA) is the part of Orca that actually takes action. Its knowledge structures are procedural schemas [\protect\citenameTurner, 1994] (p-schemas),hierarchical plan-like objects that SA expands to determine what to do. P-schemas are selected from Orca's schema memory based on the goal to be achieved and the current context. They are expanded into steps, each of which is either a goal, a p-schema, an executable action, or a ``special'' step type (which can include conditional branches, requests for suspension of the current schema pending some state, and loops).
A step is selected and applied. If the action specified is an executable action, it is directly carried out, for example by sending a command to LLA. If it is a p-schema, then that becomes a sub-schema of the current p-schema, and is expanded recursively. If the step is a goal, then SA looks in the schema memory for an appropriate p-schema with which to achieve the (sub-)goal; this is very much like usual hierarchical plan expansion.
Communication actions are treated the same as any other action by Orca's SA. They can be part of regular p-schemas, or they can be grouped into their own discourse schemas to control the course of conversations with others [\protect\citenameTurner &Cullingford, 1989].
A p-schema is not completely expanded by SA before actions are taken. The current schema is expanded only until an executable action is found, then that action is taken. In future, we will look at alternate ways of p-schema expansion that partially expand future portions of schemas to guide current actions.
Novel situations are handled by general-purpose p-schemas. These represent general-purpose problem-solving methods (e.g., case-based reasoning, means-ends analysis, etc.) that can be used when no special-purpose methods are known to the agent.
Context Manager (CM) indirectly affects all other modules. It is responsible for watching the evolving problem-solving situation and making decisions about what the current context is. It then supplies information to the other modules based on its contextual knowledge that help them tailor their actions to the current context.
CM uses knowledge structures called contextual schemas (c-schemas) that were first used in AI in medicine [\protect\citenameTurner, 1989][\protect\citenameTurner, 1994]. They represent important contexts the agent is likely to be in-that is, those that have implications for its survival or for its mission. For example, an AUV might have c-schemas representing: being in a harbor, being in the open ocean, operating under ice, operating near crush depth, performing an exploration mission. Each c-schema contains contextual knowledge about how the agent should behave in that situation. CM merges this information into the current c-schema, a knowledge structure that is then used by the other modules as they go about their tasks.
Orca's architecture allows the it to make commitments to future actions, both as entries on its agenda as well as steps in its p-schemas. However, Orca does not overcommit to details of actions. It expands its p-schemas only as needed-changes in the world do not force replanning, but are rather taken into account automatically as the schemas are expanded in the future. In addition, Orca always remains ready to respond to unanticipated events occurring in the world or in the vehicle it is controlling. Its responses can range from modifications of ongoing actions, new actions for old goals, or new goals (including the goal to abort the mission). Orca's Agenda Manager can switch between tasks as the situation demands, interrupting work on one goal to work on another, perhaps later to come back to the first. Finally, Orca is a context-sensitive reasoner. Its Context Manager constantly watches the environment, the vehicle, and the mission and advises the other modules about how they should behave to conform to the context.