next up previous
Next: Representing State Up: Design Patterns for Avionics Previous: Introduction

Structuring Avionics Control Systems

 

The top-level functional requirements and structural constraints on aircraft control systems can be categorized into two types of concerns: Flow and Models:

Flow. An ACS continuously collects a large number of inputs, including positional and environmental data from external sensors, state data about aircraft components and controls, and desired flight objectives and other control information. It ``converts'' these into a small number of outputs, primarily displays alerting Pilots about suggested control actions, and direct manipulations of aircraft effectors.

Nearly all system-wide top-level information flow in an ACS is inherently upward, from sensors to displays and effectors. Overall flow resembles that maintained, for example, in neural network designs. Even most ``feedback'' flow falls under this pattern. For example the state of a wing is obtained from sensors, not just assumed to be what its last effector command requested.

The functional form of flow in an ACS is transformational. Information continually changes form across paths from input to output. To be useful, nearly every representation across the overall flow of an ACS must be transformed according to some kind of filtering or conversion algorithm. For example, sensor data must be transformed from often-messy device-dependent readings into estimates of where the aircraft is. Filter functions represent the ``gates'' that connect stable representations.

Models. To carry out its functionality, an ACS must maintain coherent, accurate models of the world.

From a structural perspective, an ACS may be seen as an instance of a Model-View-Controller (MVC) design[7]. An ACS maintains a ``reactive'' model of the world that is controlled via updates in response to new data sources, and is viewed ultimately by displays and manipulators. MVC frameworks (along with numerous minor variants) split the roles of model-maintenance, input ``sources'', and output ``sinks'' across different components in order to isolate variation in how each of the associated responsibilities may be accomplished. In an ACS, there is scarcely even an alternative to this structure. Modeled aircraft properties may rely upon any or all of a number of different sensors, controls, estimation rules, guidance modes, and/or policies. These properties may be used to generate outputs in any of several ways. It would be inconceivable to construct a set of components that merge all possible combinations. Instead, components of each type are linked together to serve particular purposes.

Because of the transformational nature of ACS systems, the linkage between models and other components is almost never a simple matter of arranging connectivity to propagate value updates. Instead updates must be performed via invocation of suitable filtering functions. These transformations may take any number of functional forms. It is even possible to transform sensor data in multiple ways to obtain multiple estimates. This leads to a second kind of separation principle in ACS design: Data transformation functions must be independent of the components that use them in the course of updating representations.

Algorithmic concerns also govern the top-level categorization of different kinds of models. The ``topmost'' model in an ACS is an Action model, representing desired effector and display settings. Essentially all known algorithms for computing these representations employ variants of a standard strategy. Estimated properties of the actual world are compared with ideal or desired properties that may be further transformed into changes in effector and/or display settings that reduce these differences. Thus, Error models representing differences between actual and desired state play a central role in ACS systems. Because error models are used to effect particular changes in the aircraft, they must take a very simple form, typically representing only a few summary attributes. To support the comparator algorithm, other ACS models are subdivided into two similar yet mostly independent categories, Navigation models, that represent the actual state of the world, and Objective models, that represent desired state.

Design Steps

  1. Construct components maintaining Models, each Representing the state of the aircraft and significant aspects of its environment:

  2. Construct components serving as Sources and Sinks for models:

  3. Construct computational signal-processing components:

  4. Construct policies, algorithms, and components that tie components together:



next up previous
Next: Representing State Up: Design Patterns for Avionics Previous: Introduction



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