Finally, there must be a way to arbitrate between plan elements or goals. There must be a way to determine the current focus of action-selection attention -- to deal with context changes (whether environmental or internal) which require changing between plans, rather than within them. Some hybrid architectures consider this problem the domain of `deliberation' or `introspection' -- the highest level of a three-layered architecture. But BOD treats this problem as continuous with the general problem of action selection, both in terms of constraints, such as the need for reactiveness, and of solution.
BOD uses a third element type, the drive collection for this kind of attention. A drive collection is very similar to a competence. However, it is designed never to terminate -- there is no goal condition. The drive collection is the root of the BOD plan hierarchy, and the only element that executes on every program cycle (from hundreds to thousands of times a second, depending on the implementation). The highest priority drive-collection element that triggers passes activation to whatever competence, sequence or action primitive it is currently attending to. Or, if the agent has just been initialized or the element's last attendee has terminated, the element sets its attention to the apex of its plan hierarchy.
 |
Drive-collection elements have another feature not shown in the above diagram: they also allow for scheduling, so that a high priority element does not necessarily monopolize program cycles. This increases the parallelism and reactivity of BOD agents.
For working, non-toy examples of plans for complete BOD agents, see (9,8,7); for comparisons to other systems, see (8,7). This chapter emphasizes instead the engineering of BOD agents. The next sections return to the question of revising BOD specifications.