Next: Guidance Modes
Up: Design Patterns for Avionics
Previous: Effectors
Filters, or more accurately, ``Transformers'' form the functional glue
between Sensors,
Models and other intermediate
Stages, and
Effectors. But the
algorithmic properties of most filter functions are independent of the
entities using them. Filter functions do not model the world; they
are instead methods for transforming data. The same function may be
used in Updating several
independent Models. Thus, most
filter functions cannot be designed in ways that are intrinsically
coupled to any particular source or destination components.
Classically, a filter is a pure function that accepts one or more main
inputs, and returns an output of the same form as the main inputs, but
with different values. However, in practice, filters take a number of
functional forms, including those that also perform transformations
and conversions, and those that include control or parameterization
arguments in addition to their main inputs. And while filters are
conceptually defined as pure stateless functions, they may be
implemented as operations of statefull components that maintain values
across different operations to cache recurring computations, and
maintain static data, policies, and/or rule sets guiding
transformation. Categories include:
- Null.
- Null filters are convenient ways to represent the lack of
transformation when updates consist only of simple operations that
do not require invocation of an external filter. For example, in
the case of single source faultless data (e.g., from a sensor that
records a Pilot choice on an instrument) updates may collapse to a
single value assignment.
- Reducers.
- Collect and combine a series of values to a single
estimate. Reducers may apply weights to various inputs,
average multiple estimates, merge redundant readings, and so
on.
- Selectors.
- Select and output the best of multiple inputs according
to certain rules or criteria.
- Weighted.
- Weight and combine multiple inputs based on their
Accuracy and Quality.
- Sequential Filters.
- Accept a series of inputs representing values
observed over time, and smooth them, average out transient noise,
etc., to generate a single best current estimate.
- Differencers.
- Transform two main inputs to a single value
representing differences between them. Sequential versions
detect rates of changes of inputs.
- Converters.
- Scale or transform Units or types of representation. Converters are
required in cases where the same information is represented in
multiple formats. For example, there are many ways of
representing Earth Geometry, and clever algorithms best suited
to each. Even the simple notion of Position can be represented
in many ways, relative to different coordinate systems, so
values must ultimately pass through converters when unified
with other representations.
- Sequentially Composed.
- One filter may further coordinate the
effects of others by sequentially connecting the outputs of
one or more function as inputs of others.
- Conditionally Composed.
- Invoke best available function
depending on Accuracy and Quality estimates of source data, and
the preconditions or accuracy profiles of possible transforms.
- Dynamically Composed.
- The filter is an operation of a component
that contains an updatable invocation plan consisting of
handles to available subfilters and rules for how and when to
invoke them on its main input.
- Guidance Comparator.
- A special kind of differencer
comparing desired state represented by Objective
models and actual
state represented by navigation models, and using them to help produce an
Error Model
representing these differences in a form allowing computation
of Action Models.
Comparator components mainly perform data categorization and
reduction. There are numerous ways in which actual and desired
state may differ. These differences must be reduced to an
Error Model containing small number of attributes that are
meaningful to flight director components. Current algorithms
for computing these quantities each specialize on only one
error dimension (e.g., speed). Thus the Error model and
guidance comparator system cannot be designed as a single
monolithic entity. Comparators must be constructed as a small
collection of problem-solving specialists, each reducing
actual versus desired state differences to one, or perhaps a
few Error Model attributes. The inner workings of comparators
are dictated by algorithmic concerns, and oftem employ
specially crafted algorithms.
- Action Control.
- An Action Control Function ``converts''
differences between actual and desired state as represented in
Error Models into
values representing actions that will minimize these
differences. Algorithms are based on ``control laws'' that
are usually specialized along a single control dimension; for
example those that map heading error into a set of effector
values that cause the aircraft to roll. Different action
functions, or different parameters of the same functions may
be constructed to reflect control and availability
information. For example, a special function may be needed to
compute the best course of action if an engine fails.
In Avionics Control Systems, such functions are used extensively to
derive attribute estimates from raw sensor data and to combine
multiple estimates. The algorithms must be derived from analytic study
of device and value characteristics, which are not addressed in this
set of patterns. However, even assuming that the best signal
processing algorithms are available, there is still the question of
how to build ACS systems using them. Usually, for theoretical,
empirical and/or and operational reasons, only certain combinations of
source types, filter types, and destination types can be used
together. This set of compatibilities constrains the ways in which
components can be connected, so must be collected to guide
Update mechanics.
Design Steps
- Organize filters as an extensible set of free-standing
procedures and/or classes.
- Minimize the number and dependencies of filter function
types by expressing arguments and results as
Dimensionless View Types whenever possible, and standardizing on
their order and meaning. Some filters, especially Guidance
comparators and Control filters are usually too specialized
and quirky to standardize upon. However their internal
structure may be composed of parts with more uniform
characteristics.
- Standardize on a common method for each filter function for
which output quality is a nontrivial function of input
quality, to produce in addition to its main output, a means of
indicating the assessed Quality and
Accuracy of this
result, typically as a function of the quality of inputs.
Similarly, standardize on a method for callers to determine
value or quality preconditions for using any filter that
requires inputs be of a certain quality even to be invoked.
- Ensure that filters may be combined; that their outputs are
usable as inputs for other filters. When a specific
composition of filtering is needed in
Update operations, define
a new filter function that provides this transformation by
invoking others. For the sake of uniformity, it is useful
(but not always essential) to encapsulate those composite
filters that are actually used in a system as separate
free-standing components.
- Organize large-granularity filter components such as guidance
comparators and action control filters as networks of simple
filters Connecting
an arbitrary number of intermediate Stages.
- To allow the use of mixed representations, construct a matrix
of feasible converters that accept measurements, state
vectors, and/or model types, and produce others that are
equivalent at the desired unit of measure, that may then be
used in a dimensionless manner in a filter function. This
matrix may even be directly represented and used as a key into
available converters.
- Statically represent (perhaps only as a design-time tool) a
set of feasible connections between sources, destinations, and
filters, at the level of types (interfaces, state
vectors, function types), not individual instances. Because
they are based ultimately on the characteristics of available
representations, sensors and filters, compatibility
constraints are nearly always fixed at design time. When
types form an inheritance hierarchy, this set of constraints
may be represented more economically. For example, if the kind
of positional data from any Inertial Sensor may be used
with a particular kind of filter type to produce a better
positional estimate, then special versions representing special
kinds of Inertial Sensors need not be listed.
Next: Guidance Modes
Up: Design Patterns for Avionics
Previous: Effectors
Doug Lea
Tue Mar 28 08:50:41 EST 1995