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.
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:
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:
For each representation subject to uncertainty or disabling, maintain associated ``qualifiers'' or subattributes:
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.
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:
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.