A module needs a way to determine the appropriate behaviors to activate in a given situation. There are many ways that a module's behavior repertoire could be organized to help the scheduler do this, ranging from a simple list of available behaviors to a content-addressable memory which indexes behaviors by features of the situation. The scheduler could also use existing contextual knowledge to help quickly select appropriate behaviors as the situation changes; another project at UNH focusing on context-sensitive reasoning [\protect\citenameTurner, 1989][\protect\citenameTurner, 1990] relates to this, and results from that project may be incorporated into this project as work progresses.
The scheduler must also manage the duration of a behavior activity. We can think of each behavior having a time course, or arc, over which it operates. Some behaviors, such as ones which turn on or off an effector, have well-defined time arcs. Others, such as TRANSIT, have slightly more fuzzy arcs: the behavior should remain active until the proper location is reached. Still others, such as AVOIDANCE and homeostatic behaviors, have ill-defined or indeterminate time arcs; these may remain active until explicitly deactivated. The length of time a behavior is active can also depend on other behaviors. For example, the OAS (obstacle avoidance sonar) behavior in the Data Assessment module may only be active due to AVOIDANCE being active in Guidance; when AVOIDANCE is deactivated, Data Assessment's behavior scheduler should deactivate OAS. This can be enforced by explicit activation links between behaviors within a module and similar bookkeeping measures between generic behaviors in different modules. Behaviors can also inhibit others; for example, DOCKING should inhibit AVOIDANCE. This could be handled by the behavior scheduler directly via establishing inhibitory links as necessary, but we prefer (in the manner of Brooks ##1[][]brooks86) to instead have the output arbiter handle this type of interaction, effectively blocking the inhibited behavior's output. Part of our research will focus on defining ways for the scheduler to ``reason'' about the estimated time arc of each behavior to determine when to deactivate them and on ways to maintain dependencies between behaviors within and between modules based on information associated with the behaviors themselves.