Updates

Avionics Control Systems are in constant flux. New data values become available to Model components on a continuous basis, allowing them to compute fresh estimates. To maintain required system-wide information Flow, each update from the level of Sensors to Effectors should take the same general form.

Design Steps

In a Staged design, each stage of estimation should have the same essential form and characteristics. The version used in any given ``host'' component may omit steps and considerations that do not apply given a particular set of Flow control and Configuration decisions.

Protocols

Ensure that each update procedure contains all relevant steps of the following sequence:

1. Determine if the host attribute(s) to be updated are Armed. If not, skip all other steps.

2. Determine one or more Armed, Connected data sources for the estimate.

3. Obtain data from each source. This may involve, for example, pull-style interactions with a Sensor Controller or another model component; or a timed wait for a ``push'' of the data, giving up on time-out; or in a periodic indirect transfer strategy, checking any validity indicators for values that should be present on each update cycle.

4. Determine the assessed Quality of obtained data.

5. Determine one or more Filters that may be used to transform all obtained source data into a new estimate of a given quality. Special filters and/or internal actions may be chosen when the set of sources changes across updates, so as to ensure a smooth transition in estimates.

6. Invoke the Filter with available source data, typically in the form of Dimensionless Views of values after scaling to common units.

7. Update attributes from the results of the Filter. If appropriate and possible, first check estimates according to statically encoded rules to determine whether they fall within known acceptable ranges or relations with other values.

8. Update Accuracy estimates. The ``bottom-up'' flow of merit figures parallels that of attribute values. At the bottommost level, Sensors and/or their direct consumers must maintain independently or inherently known accuracy figures. These may be propagated along update paths, when necessary and possible through extra parameters of Filter functions that both compute transforms and their quality.

9. For all Connected data consumers of the new estimate, if any action must be taken to propagate values to them, do so. A host may be one of its own consumers, for example when ``derived'' attributes must be computed on the basis of updates to primary values.

Failures. Arrange evasive action upon failure in any of the above steps; i.e., lack of sources, inability to obtain data, insufficient source data quality, lack of an appropriate filter, failure of a filter component, inconsistent or poor quality filter results, or propagation failures. Normally, the most appropriate action is to control Arming of the host component and/or its data sources. This may involve interactions with Monitoring and Control components that alert them when input values are of insufficient quality to form new estimates (as determined, for example, by comparison to fixed thresholds). Local and/or centralized operations may then disarm, recalibrate, or mechanically shut down Sensors, and propagate top-down disarming control to other data sources.

Connections

Uniform update strategies work so long as each ``host'' stage can determine the set of dependent data sources and associated data types, the kinds of Filters to form new estimates, and the set of dependent consumers for which action is required by the host upon each update.

The first step in establishing connections is to determine the set of dependencies; that is, cases where any change in one attribute must propagate to another that depends on it. Every set of connections must reflect Compatibility constraints among filters and representations. However, compatibility constraints operate at the level of types. Connections are at the level of individual components. Each host must deal with the particular data sources and consumers required to fulfill its role in the system.

A range of options for representing connections apply to both source-to-host or host-to-consumer connections. Each impacts different aspects of Update mechanics, and so must be considered in tandem with update protocols. Feasible choices depend upon Flow and Configuration strategies.

Anonymous Connections.

No explicit representation of source connections is required if the host always waits for ``push'' style data of certain forms to arrive, or for indirect data in pre-established storage locations to fall into place, without knowing or caring where it came from. When all the right data are obtained, it proceeds with an update. Similarly, there is no need to explicitly represent consumer connections if, upon update, the host either broadcasts data to all possible consumers or places state vectors in pre-established storage locations for use by consumers.

Fixed Connections.

The host invokes (or waits for) a fixed set of data-gathering operations before each update, and invokes a different fixed set of operations after update. Sources may include current or previous attribute values of the host itself, perhaps to be averaged with new readings. They may even include higher quality data from ``upstream'' models fed back to be used at this level.

Dynamic Connections.

The host contains operations that accept new handles (object references, ``callback'' function pointers, etc [4]) to source and/or consumer operations to be used on each update. These handles are supplied (by either the sources themselves or Monitors) when new sources become available, and may be discarded by the host upon noticing connectivity or data Quality problems.

Brokered Connections.

Each update is mediated by a relay or broker that maintains association lists between each desired data type and available suppliers.

Consistency

Multiple or interdependent representations are often essential in Avionics Control Systems in order to apply Filtering and Transformation algorithms. For example, position may need to be represented both ENU form and XYZ form for purposes of a particular set of algorithms. But whenever interdependent representations are used, consistency problems are all but inevitable. Any two state vectors that represent or derive from the same physical phenomenon must be consistent. Changes in one must be reflected in the other.

No approach can or even should guarantee that all representations in any system are always instantaneously consistent. This is especially so in ACS systems, where updates to values continuously stream in, and where it is sometimes better to use an old value rather than undergo the overhead or delays associated with obtaining a new or consistent one. Further, if differences are somehow known to always lie within an acceptable fixed tolerance and they are either never directly compared or are only compared within this tolerance, then you can ignore the entire problem.

Otherwise, update strategies must be modified to deal with sets of interdependent representations; that is, cases where two different state vectors contain the same or interconvertable values representing the same physical phenomena. Two overlapping representations, A and B, form a cycle of dependencies. There is no single technique that applies, but most instances in practice fall under one or more of the following special cases.

• If representation A can be treated as ``primary'', values of representation B may be obtained as ``readonly'' Views, where changes are never propagated back to A.

• Representations that are obtained from different sources may be treated as different estimates and combined via special Filters into a new intermediate Stage maintaining an estimate that is better than either of the two.

• Components maintaining these representations may contain internal propagation protocols to each other that are somehow guaranteed not to loop forever[4]. For example, if A receives an update request from anyone other than B, it notifies B, but if it receives one from B, then it silently performs an update without calling back B, under the assumption that such messages are only consistency propagations. (Note that this assumption is not necessarily always correct in general.)