As the level of functionality embodied in a system increases, the amount of communication needed should decrease. At all levels, however, the nature of communication between a human user and an autonomous system places constraints on how much information can be exchanged. It is advantageous to have a communication language that is unambiguous and carries as much information as it can in a small package. A representation language is also needed to allow behaviors to communicate with one another via their inputs and outputs. A behavior cannot truly be said to be generic unless its inputs and outputs are specified using a vocabulary that is generic and shared between all behaviors. This is important for communication between behaviors, since outputs of one will be connected to inputs of the other; in this case, the vocabulary provides a shared language, allowing the generic behaviors involved to understand one another.
In our approach, the communication language and the representation language are one and the same. In the case of communication with another AUV which is also using this generic behavior language, then the language allows communication (possibly directly between top-level layers) without the need for translation. In the case of communicating with a user, the language is a specification of how the user can communicate with the vehicle; the user can choose either to ``talk'' to the vehicle directly using the language, or an appropriate natural language or menu-driven interface can be built. A generic behavior language can also represent the behaviors to provide a way for one behavior, or a user, to cause the activation of others by specifying them by name along with any associated parameters. Using the language, a user can, possibly via the user interface, specify a mission directly in terms of the behaviors the AUV is capable of.
Such a language should be compact, yet expressive, and unambiguous. One
representation scheme that meets these criteria that we are beginning to
examine is conceptual dependency (CD) theory [\protect\citenameSchank &Abelson, 1977], which uses a
small set of primitives as a vocabulary. Figure 5 shows
the primitives originally developed for natural language processing to
represent actions. Each primitive has a well-defined semantics, with no
overlap with others' meaning. The semantics includes inferences that can be
drawn based on a CD conceptualization (i.e., instantiated primitive)
representing an action that has occurred. For example, the
conceptualization:
(ptrans (actor EAVE) (from BARGE) (to RENDEZVOUS1) (time T1))means that EAVE moved from a barge to a location denoted by RENDEZVOUS1 at time T1. Inferences that can be drawn based on this ptrans instance include that EAVE is at the rendezvous at time T1, EAVE is not at the barge at T1, etc.
In addition to well-defined semantics, CD theory offers a set of relationships between entities that allow primitive conceptualizations to be composed into larger, more useful structures, ranging from cause-and-effect chains to schemas such as scripts [\protect\citenameCullingford, 1981] and plans. The larger structures can then in turn be treated as new abstract "primitives" and linked to one another, composed into even larger structures, etc.
The idea of primitives and the relationships between them can be used to form the basis of a representation language for a generic behavior-based architecture. Several of the primitive actions (e.g., ptrans) apply equally well in the domain of autonomous systems, and others will need to be defined as part of our research. The existing relationships will likely be sufficient as a starting point.
To provide a representation for inputs to (and outputs from) behaviors, we will need to extend CD theory. Autonomous systems' behaviors will often need to refer to or describe objects in the world such as rocks, ships, and so forth-precisely the area in which the original CD theory work was weak. As a point of departure for this, however, we can turn to work done by others [\protect\citenameTurner, 1987][\protect\citenameLehnert, 1978] on the representation of physical objects in terms of primitives. For example, Turner ##1[][]turner:casTR defined several classes of functional objects, including consumer, producer, sink, source, container, supporter, filler, material, separator, connector, and tool. This set would need to be expanded for our purposes, for example, to capture such concepts as ocean currents. Representing physical objects as primitives has many of the advantages discussed above. An object primitive, for example, would have well-defined inferences associated with it that would be used to draw conclusions about the represented object and its relationship to others and to actions. The primitives would provide a rich descriptive representational language for use by the generic behaviors.
Ultimately, it may be useful to consider closely tying the action primitives to particular behaviors as a way to represent behaviors. This would allow the user interface, the architecture's software modules, and high-level behaviors (such as PLAN-MISSION) to easily describe and ``reason'' about the behaviors a system is capable of. A behavior might be directly described by a primitive (e.g., TRANSIT is very close to the CD primitive ptrans) or as an abstract representational object (script, schema, etc.) that is itself composed of primitives (e.g., RASTER-SEARCH). Additional work will be needed to define ways to parameterize such representations of actions: for example, ``transitting slowly'' versus ``transitting rapidly'', etc.