Decomposing ACS Models

The role of an ACS model component is to:

• Maintain a consistent representation of an aspect of the world.
• Update this representation in response to new information from ``source'' components.
• Alert other ``consumer'' components about changes.
• Alter behavior in response to system-wide control components.

Many sets of physically meaningful Values (e.g., heading versus position) used in an ACS are nearly independent of each other, both physically and computationally. There are several reasons that corresponding models of ``macro'' objects such as the Aircraft itself need not, and should not be constructed as single components: Most updates and queries are localized to particular, known, independent aspects of state. The associated mechanics are simpler to arrange for small, independent submodels than a monolithic component maintaining all possible attributes. Many attributes must be represented in multiple ways. Different ACS systems radically differ with respect to parts, so there is no single, generic compositional model. New attributes reflecting new sensor capabilities, guidance modes, or effectors may need to be added across successive versions of the system. And small, localized components are simpler to Configure in accord with the special physical, resource, and performance demands of any particular instance of an ACS.

Design Steps

Decentralize models. While they may possess aggregate conceptual interfaces[9], each kind of ACS model should be implemented as a loosely connected bundle of submodels, each responsible for maintaining a small independent set of attributes representing related, physically meaningful abstractions.

The resulting collection of attributes and operations for each kind of model or submodel describes a set of interfaces that may be implemented in many ways. Many kinds of models will share many aspects of common interfaces, which can be factored via interface inheritance[4] to arrive at more compact and useful designs.

However, the following steps do not themselves generate interfaces, only sets of attributes, connections, operations, and protocols that must be arranged into common interfaces according to roles and usage. In fact, because ACS model interfaces are uncomfortably sensitive to policies surrounding control Flow, Monitoring, and Configuration, it is a good idea to design attribute structure early, but to return to operation interfaces only after considering these issues.

1. Represent attributes in terms of State Vectors using common Measurement units.

2. Ensure that attributes represent information that is estimable from source components and useful to consumer components. Try to maintain the same (or a common subset of) attributes, in the same way, across different stages.

3. When attributes must be multiply represented or are otherwise interdependent, either within or across models, ensure Consistency among them.

4. Maintain static knowledge (e.g., constraints on possible attribute values, defaults, fixed properties of the entity being modeled, physical constants and laws) in a form usable in the course of updates and access. Different components should represent the same static knowledge in the same ways. One way to ensure this is to pool static knowledge into common database-style components with access operations that are invoked in a uniform manner across various models.

5. Maintain and evaluate the degree of Accuracy surrounding each attribute that is subject to uncertainties in estimation.

6. Maintain an indication of whether the information represented by an attribute is Enabled for use by other components, as Controlled and Monitored by system-wide components.

7. Maintain those Connections needed to communicate with sources and consumers.

8. Construct an Update strategy for each attribute in accord with protocols established by Information Flow policies.

9. Enable construction of Dimensionless Views of values for generic Filter and signal processing functions when needed to perform updates.

These steps and concerns are applied in different ways across the different kinds of models found in an ACS: Navigation Models, Objective Models, Error Models, Action Models, and Intermediate Models.