next up previous
Next: Guidance Modes Up: Design Patterns for Avionics Previous: Effectors

Filters

 

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

  1. Organize filters as an extensible set of free-standing procedures and/or classes.

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

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

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

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

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

  7. 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 up previous
Next: Guidance Modes Up: Design Patterns for Avionics Previous: Effectors



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