next up previous
Next: References Up: Design Patterns for Avionics Previous: Updates

Configuration

 

While it is profitable to design Avionics Control Systems in an open, extensible fashion, ultimately an ACS must be configured into a closed, self-contained system, due to the following constraints:

Design Steps

Establish ``wiring'' schemes for composing large-grained subsystems in which most internal connections and protocols are ``frozen'', and in a way that the subsystems themselves are suitable for static configuration. Integration into subsystems is by nature an opportunistic task, exploiting relationships among components that lend themselves to tighter coupling. Different strategies have the effect of collapsing overall ACS designs into different-looking concrete architectures, each with different consequences in terms of performance, static structure, and independence. Given a set of components and a configuration strategy, it is possible to build generator tools that can instantiate different versions of a system (see [3]).

There are two nearly independent dimensions to collapsing components. The first is the ``direction'' of integration:

Vertical.
Integrate components that deal with an isolated set of model attributes along a subset of a functional Flow path, even all the way from input Sensors to Effectors. This kind of vertical collapse applies whenever it is possible to decompose an aspect of functionality into a loosely-coupled, mostly-independent subsystem.

Horizontal.
Collect submodels and stages of the same kind of model (Navigation, Objective, Error, and Action) into larger-grained subsystems. This re-centralizes independently designed model components that operate on independent attributes at the same level of processing.

Vertical integration is more common and usually more desirable. The representations and algorithms used for estimating, for example, positional values based on Radar sensor inputs are separable from those for estimating atmospheric values from Air Data Computers, so may be split off into different subsystems, integrated only at their common meeting point in overall system flow. Similarly, Guidance Comparators and associated Error Models normally work off only a single control dimension that is matched to a corresponding set of Action Functions and associated Action Models. All components dealing with values along any single dimension can be integrated into a single larger-grained subsystem.

Horizontal collapse can be used to exploit common control Flow mechanics. For example, all Navigation Models that work off periodic memory transfer from Sensors can be collected into a common subsystem with its own scheduler and policies.

The second dimension deals with the ``focus'' of integration:

Model-based.
Directly incorporate functional Filtering algorithms into Model Update procedures. This eliminates the overhead associated with separate construction, normalization of data, and invocation.

Transformation-based.
Directly incorporate Model representations and Update protocols into Filters. This eliminates the need to maintain representations, and may lead to the collapse of several model Stages by directly feeding the results of one computation into another without ever explicitly representing the intermediate values.

Model-based and transformation-based strategies are duals (often stemming from object-oriented versus structured-design approaches), that tend to result in about the same final configuration, but expressed in different ways. They most readily apply when representations, algorithms, and/or control are already somewhat coupled, so that this coupling can be accentuated and hard-wired into larger-grained entities. For example, when there is already a one-to-one correspondence between individual Guidance Comparators and Error Models, it is simple and effective to merge Transformation, Updates, and Representation of a primary error attribute.



next up previous
Next: References Up: Design Patterns for Avionics Previous: Updates



Doug Lea
Tue Mar 28 08:50:41 EST 1995