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:
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 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 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.