Jump to the AIS Overview page.
Jump to the Architectural Details Menu page.
Jump to the Home page.

Architectural Details

Dynamic Control Architecture

The dynamic control architecture is implemented as a BB1 (i.e. blackboard) system. It is further subdivided into four sections. The global database stores all the knowledge of the system. It uses a BB* conceptual network representation for this purpose. The network provides predefined entities such as actions, events, control plans, and cognitive skills. To these the programmer can add application-specific subnetworks, that might represent new strategies, knowledge or cognitive skills (see Asynchronous I/O Subsystem

This subsystem consists of a communications interface (CI) and logical I/O buffers. The CI continously monitors both the input sensor buffers and the logical output buffers. Any input from the sensors is relayed to the system when it asks for it. Similaryly, actions requested by the system are performed as soon as possible. We sould also point out that the buffers have fixed capacity with FIFO overflow. This means that inputs that the system does not ask for will, eventually, be discarded. Similarly, if the system requests that actions be performed faster than possible, the CI will, eventually, start ignoring some of these task instead of constantly running behind.

Dynamic I/O Channels

Each channel is set up to mediate the communications between the sensors or effectors and the AIS's reasoning mechanisim. They perform some amount of preprocessing so that the reasoning mechanism is not burdened by the need to analyze raw input data, or trasform higher level actions into their mechanical components. They accomplish this by the use of perceptual and performance filters. Perceptual filters are designed to only relay task-relevant or otherwise important data to the system. Drivers user the performance filters to determine which actions should be performed, according to their urgency, and to handle the details of performing the actions. The specificity of the filters is determined by the system as it executes. If the systems sees that the locgical I/O buffers are being overflowed then it will use more specific filters. Similarly, if the system wants more detail it will use more general filters.

Satisfycing Reasoning Cycle

The satisficying reasoning cycle was developed to provide the guaranteed latencies required for real-time performance. It is an expansion of the agenda manager, scheduler, executor cycle. It modifies their behavior as follows: The agenda manager, instead of exhaustively identifying all possible operations on each cycle, it finds as many as possible, best-first, until any of its dynamic interrupt conditions occur. The scheduler, instead of choosing the optimal operation from a complete agenda, it does the best it can with an incomple one. The executor, instead of executing an action to completion, it partially executes the next action until any of its dynamic interrupt conditions occur. When interrupted, it save the sate of the operation so that it can be continued later. The rate and importance of interrupts is determined by a set of cycle parameters which are determined by the reasoning operations. By appropiately setting these parameter the reasoning cycle can modify the effectivenss of the satisfycing cylcle by utilizing different reasoning policies such as:

• Perform any operation that is "good enough" as soon as possible.
• Perform any urgent operation immediately.
• Perform the "best available" operation whenever necessary.
• Perform only operations that are "good enough".
• Perform the best possible operation regardless of the time required.