next up previous
Next: Decomposing ACS Models Up: Design Patterns for Avionics Previous: Structuring Avionics Control

Representing State


The heart of an ACS is a set of Models of the world; pulsating, active models with a purpose. Of course, an ACS need only model those properties of that small subset of the world that are useful for Effecting Flight, and/or are knowable from Sensors. Thus, the representational techniques used in an ACS are products of top-down and bottom-up forces:

However, there is not much need for reconciliation. All of these components intrinsically rely upon values represented on scales that are ultimately meaningful in terms of physical laws about bodies, motion, and change. These abstractions (relative position, velocity, etc.), usually termed state vectors, are required in order to arrive at guidance decisions, are the quantities that devices try to measure, and thus must serve as the basis for designing the representational, or attribute structure of models.

A state vector is a collection of physically meaningful values, representing measurements or settings of some sort; for example: Pitch, Roll, Position, Velocity, Acceleration, Attitude, Altitude, True Heading, Mach number, True Mean Sea Level Altitude, Indicated Airspeed, True Airspeed, Ground Track Angle, Magnetic Heading, Ground Speed, Angle Of Attack Bank, Angle Drift Angle.

The main reason that state vectors are used in guidance systems is that the abstractions themselves are so tractable mathematically. For example, so long as units of measurement are consistent, you can add two three-dimensional points together whether these represent Aircraft positions or Snail positions.

ACS model attributes are represented by state vectors, including vectors of vectors, and so on. State vector types are not restricted to descriptions of objects as they are in the world, but also include information about the future and past. For example, from position, heading, speed, and so on, they implicitly represent where an aircraft will be in the next instant. They may also represent historical values to help determine trends over time.

The second collection of design constraints on representational techniques rests on the kinds of algorithms used in an ACS. Most signal processing functions and their computational implementations do not differ in form across different units of measurement of their arguments and results. For example, a matrix of real numbers may be inverted in the same ways whether it represents a series of magnetic heading readings or a set of correlations. Nearly all Filtering and Transformation signal-processing algorithms are of this form. They accept structured collections of numbers, all represented using an arbitrary but common unit of measurement, and return others.

Finally, because most ACS models represent estimates of the state of the world, there are bottom-up, local, and top-down forces influencing the calculation and use of these representations with respect to their intrinsic accuracy, the computational limitations of estimation techniques, and/or system-wide control of the ACS.

An ACS must possess a lot of redundancy to achieve fault-tolerance. This redundancy cannot always be implemented simply by replicating components. For example, two identical radar-based sensors would tend to be equally adversely affected by extreme weather conditions, thus defeating much of the purpose of redundant support. Instead, most redundancy is accomplished through the use of multiple kinds of sensors, estimators, models, modes, and effectors. However, not all components are equally reliable or accurate. For example, Sensors, and/or communications channel connecting them can break. Even when not broken, they can occasionally report completely wrong values. Similarly, different Guidance Modes provide more accurate estimates of desired state than others. The act of Updating model attributes can introduce additional uncertainties. Different Filtering algorithms provide better model attribute estimates than others. Sometimes, a value cannot be computed at all due to computational limitations of filters that require input data to be of a certain minimum quality in order to produce transforms. Additionally, pilots and/or Supervisory components may disable (or ``disarm'') certain components or subsystems, for any reason.

Design Steps

Use multiple levels of representation of state in an ACS, varying in how values are ``tagged''. Different forms of representation serve as the basis for defining attributes of different kinds of Models, and are the data types used in Filter functions and Update operations:

Units and Types


Determine a set of measurement types via analysis of the physical properties that are represented and manipulated in the ACS [3]. Each type should be interpretable in terms of physically meaningful units:

  1. Create, name and organize a collection of basic value types in terms of their abstract physical meaning, not the entities that they represent. Assign generic, standardized names to types and fields.

  2. Define these types from the bottom. The primary dimensions for aviation quantities are Mass, Length, Time, and Temperature. Other derived types are composed as expressions on these primary units along with dimensionless values such as Angle. For example, velocity has the dimension Length / Time, and XYZ position is a 3-element vector of Length. Layer composite state vector types (e.g., position) as records and/or other composite types containing elements of these base types.

  3. Minimize and standardize the number of units of measurement. When possible, associate a single unit of measurement (e.g., cm, sec, radians) to each type. Assign consistent implementation types (integer, float, etc) to each unit.

Accuracy and Arming


For each representation subject to uncertainty or disabling, maintain associated ``qualifiers'' or subattributes:

A figure describing its degree of accuracy, confidence, quality and/or reliability. Ideally, all merit figures should be encoded in a common Unit of Measurement.

An on/off indication of whether it is enabled; that is, whether it can/should be used in other computations or be propagated to other components.

There are several variants and simplifications. For example, in some cases, these two qualifiers may be folded together as a single value. Also, merit and/or armedness values may sometimes apply to all attributes maintained by a given model component. And some values may always be known with the same degree of accuracy, in which case these figures may be statically or even implicitly represented.

Dimensionless Views


Creating a dimensionless view of one or more representations allows you to ignore units, attribute names, and model component types when applying generic signal processing algorithms, while still representing them for the sake of maintaining models.

For each kind of view, define a type. There are typically a relatively small number of these types, with very familiar names, for example, Pair, Vector and Matrix, specializations such as DiagonalMatrix, along with associated operations such as add, invert, etc.

There are two strategies for obtaining and using dimensionless views from model attributes, direct, and indirect. They differ in the same way that ``value-based'' and ``reference-based'' representational conventions differ in programming languages. Both strategies support minor simplifications in those cases where views are always ``readonly''; that is when values are used for computations but never fed back in a form suitable for updating their sources:

For each attribute of a model or collection of models, define a projection function that packs the desired value of the desired attribute into a view. These are special kinds of conversionless Converters. Unless the views will always be ``readonly'', define the corresponding inverse pack operation that converts back into original form.

Define each entry of the view to be some sort of reference to a particular attribute of a particular kind of representation object. Each value access must invoke the corresponding accessor, and unless they are readonly views, each modification must invoke the appropriate update operation.

Filter functions based on direct versions are simpler to compose, while those based on indirect versions are simpler to use in Model Updates. So neither is always best -- choices rest on Filter design, component Connections and Configuration matters.

next up previous
Next: Decomposing ACS Models Up: Design Patterns for Avionics Previous: Structuring Avionics Control

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