Sensors

A sensor is any component that feeds raw data values into the ACS for purposes of model estimation. There are multiple ways of sensing and estimating just about every physical attribute of the earth, atmosphere, and aircraft. Physical sensors that provide the raw data vary in quality, reliability, and the extent to which their values must be filtered and combined with others to obtain useful estimates. Survivability and fault-tolerance constraints require that the system use whatever data is actually available; the ACS cannot shut down just because a sensor goes out of service.

Sensors form the bottommost elements of Staged model Updates. A sensor might be as simple as a software switch recording the fact that a pilot turned on an instrument or as complex as an Air Data Computer that reports a number of atmospheric measurements. Some user inputs to the system (e.g., manually entered position coordinates) also play the role of sensor data. Sensors may even be simulated by software during development and testing. A detector is a special kind or role of sensor. While a normal sensor provides updates for stable models, a detector initiates the process of classifying and describing a new Transient Model Object.

Design Steps

To separate the ``physical'' control of sensors from the use of their information, for each kind of sensor device, associate a Sensor Controller that handles the special control features of the device and its interactions with the environment. Standardize operations across devices as much as possible, to avoid coupling device-dependent actions to components that deal with their data as estimate sources:

1. Standardize upon common interfaces for Sensor Controller operations. These may include operations to initialize, to shut down, to self-test, to begin a reading, to supply correction data, to enable internal pre-filtering (which may lead to further interactions with models and filters), and so on. For the sake of uniform client interaction, it is worth the trade-off to pad these interfaces with operations that are only sensible for certain subtypes of devices, so long as they can be implemented as no-ops for others. Despite such attempts to standardize behavior, sensor devices remain notoriously idiosyncratic. It is most likely that some Controllers will need special care and treatment, requiring special code that may infiltrate even far-removed components that somehow rely on their data values. Positions midway between full standardization and full chaos are also available. For example, it may be the case that all Inertial Navigation Sensors (INS) or all Radio Navigation Subsystems can share the same or subtyped interfaces.

2. Because there may be multiple consumers of data, unrelated components may need to discover the state caused by the actions of others. To enable this, device control state must be exposed and standardized into a common set of attributes and accessors. Data clients then may determine whether and how data values may be obtained.

3. Specialize general Update protocols for sensors by ignoring aspects dealing with data sources except in those cases where the devices do in fact need data from other sources in order to obtain readings.

4. Adopt Monitoring and Control policies, components, and operations to deal with device control; for example recalibrating when Accuracy estimates fall below thresholds. In order to avoid contention, inconsistency, protocol failures and non-determinism in control state, implement the associated operations to be insensitive to redundant calls by unrelated clients, and contain rules for dealing with inconsistent commands. Alternatively, or in addition, define a secondary controller layer that performs this layer of bullet-proofing, weeding out commands, locking access, and caching consistent sets of data values. Such mechanics avoid the need to synchronize the actions of otherwise independent data clients with respect to each other.