Flow

Information of various sorts in an ACS is carried ``upward'' from Sensors, through Navigation Models, to Error Models to Action Models and Direction. However, the control of this flow can be assigned in several ways among sources, intermediaries, and consumers.

For any pair of source and consumer components in a system, there are three basic strategies (plus countless combinations and variants) available for moving transformed information between the source and consumer[10]:

Pull (Functional)

The consumer requests information via a procedure call to the source that returns the values as results. This operation may be implemented via an arbitrarily complex sequential protocol, may be multithreaded with other requests on either side, and may perform ``in-place'' updates rather than returning results.

Push (Event Driven)

The source issues an message with data values as arguments whenever new values are available. Push-style models may be implemented as resultless procedure calls containing new data as arguments, as non-returning point-to-point messages or broadcasts, as prioritized interrupts, or even as continuation-style program jumps.

Indirect (Shared Resources)

The source periodically makes data available in known locations for the consumer to read. This is often implemented via transfers to shared memory occurring at a fixed known periodicity, or via polling of synchronization signals. It may also be implemented in a more active ``blackboard'' style, where data producers asynchronously push information to a managed, synchronized common resource, and data consumers pull it.

Because these matters affect every pair of communicating components in the system, because nearly all mechanisms must preserve the overall system flow requirements in a consistent fashion, and because mismatches in modes are difficult and overhead-consuming to patch together, control conventions must be established by policy.

Sets of flow policies help generate the overall architectural style of a system. Different policies lead to substantial differences in interfaces and protocols of staged components, which in turn affects their use and reuse across systems. For example, in most pull protocols, navigation models need to record and invoke Connections to sources, each of which requires data-access operations. In most pull protocols, sources must record connections, and consumers must support operations triggering updates.

The style of interaction of certain components is often beyond the control of system developers. For example, some Sensors can only operate in indirect mode, via periodic direct memory access (DMA) transfers. Similarly, components that will be Configured to reside on different processors may be subject to communications infrastructure constraints that make push protocols the only reasonable choice. And although signal processing Filter functions may be invoked by components otherwise obeying any of these protocols, the filter procedures themselves almost always take a functional, pull-driven form. Finally, system Monitoring and Control operations often work in the reverse direction of primary information flow, and must use reverse protocol styles.

Thus, no single option is always best or even attainable. Moreover, each can pose problems. For example, pull protocols cannot deal with unexpected or prioritized events. Push protocols cannot always be buffered effectively, and require the existence or development of scheduling policies and algorithms. Shared memory requires the overhead of synchronization to avoid storage inconsistencies.

Design Steps

For the sake of minimizing design complexity and maximizing configurability and performance, adopt the smallest possible number of global default policies, each perhaps with a hand-full of special-case exceptions. Map out where each policy applies.

Center information flow policies on Navigation Models, the components that maintain snapshots of the world. These components are at the point of maximum stress, and bear most responsibility for ensuring that the right values are correctly Updated and propagated.

When they are not prespecified, develop the infrastructure components, subsystems, and hardware necessary to support policies. These may include schedulers, priority queues, and event handlers for managing push-style communication, remote procedure calls and thread libraries for pull-style communication across processes, and memory management mechanisms and synchronization primitives for indirect-style interaction.

Examine existing similar systems and existing reusable components for guidance in establishing policies. For example, in several ACS systems, data are obtained using hardware-assisted periodic shared-memory input from external sensors. Every N time units, processing stops while sensors transfer readings. After a suitable settling period, other components use this data. On the other side, most updates are pull-driven from guidance. This global synchronization technique avoids difficult local synchronization problems that would otherwise occur with shared memory, as well as those that would be encountered when trying to integrate, for example, readings from one push-style sensor with that of a pull-style one. However, there are still exceptional push-driven flow paths, for example to deal with high-priority matters such as obstacle avoidance.