Avionics Commonality

A LinkedIn discussion centered on the Future Airborne Capability Environment (FACE) standard contained an important observation concerning certification.  Granted — requirements for validation, with acceptance by governing agencies, definitely are essential for safety. What follows here is advocacy for a proposed way to realize the common avionics benefits offered by FACE while retaining (and in fact, improving) the process of certification. Reasoning is based on three major items:

* CHANGE. In many respects this has necessitated improved standards. 

* HISTORY. Spectacular failures in what we have now are widely documented.

* COST. The status quo is (and, for a long time, has been) unaffordable.

In regard to the first item: the pace of change in so many areas (hardware, software, operating systems, data communication, etc., etc., etc.) — and the effects on procurement cycles — are well known. How can certification remain unchanged when nothing else does? That argument would be undercut if the process had a rock solid track record — but that theme would not be supported by the second item — history:

Myriad shortcomings of existing operational systems are so pervasive that no one is considered a “loose cannon” for openly discussing them. Any of my horror stories — too strange and too numerous to be revisited here — would be trumped anyway by a document from the government itself. GAO-08-467SP, in 2008, described outlandish cost overruns, schedule delays, and deficient technical performance in the defense industry. That 3-way combination speaks for itself. Now a significant addition: the certification process has not been at all immune to serious flaws. The first-ever certified GPS receiver is now well known to have failed spectacularly in multiple facets of integrity testing by another manufacturer. It is readily acknowledged that correction of those early problems is quite credible, but one issue is inescapable: Historical proof of flightworthiness improperly bestowed — with proprietary rights accepted for algorithms and tests –- happened,  and that was not widely known until much later.

There is still more, including integrity failure probability limits missed by orders-of-magnitude in certified GPS receivers, severe limitations of GO/NO-GO testing, and failed attempts to gain approval to set requirements for correcting those plus other deficiencies. For brevity here, those issues are covered by citing the fifth page from another related reference.

The final item is, after years of fruitless talk about cost reduction, being acknowledged — we can’t do what we’ve been doing any more.  With dollars being the ultimate driver of so many decisions, we might finally see the necessary break from ingrained habits. FACE already addresses the issues and the requisite justifications. To make it all happen, two essential ingredients are

* raw-data-across-the-board, and

* nonproprietary software, with standardization under government control.
Flight-validated algorithms already in existence can be converted (e.g., from proof-of-concept to in-flight real-time form) according to government specification, by small groups more interested in engineering than in dollars (yes, that does exist). The payoff in cost savings can be huge.

Significant momentum is evolving toward a role for Open System Architecture (OSA) applied to radar. My observations in connection with that, voiced in a short LinkedIn discussion, seem worth repeating here.

One step could add major impact to this development: Rather than position (or relative position) outputs, provide measured range, azimuth, elevation (doppler could optionally be added if applicable) on the output interface. That simple step would vastly improve effectiveness of track file maintenance. Before attempting to describe all reasons for improved performance, two obvious benefits can be identified first:
* ability to use partial information (e.g., range-only or, for passive operation, angle-only)
* proper weighting of data for updating track state estimates.
The first item is self-evident. The second arises from common-sense attachment of greater value to the most accurate information. An explanation:

One-sigma error ellipsoids for individual radar fixes are not spherical (not a beachball shape but more like a flattened beachball), even at close range. At longer distances the shape progresses from a frisbee to a pancake to a DVD. Kalman filtering has enabled us to capitalize on that feature for over a half-century. Without exploiting it, we effectively treat separate radar-derived “coordinates” by intersecting volumes in space that are common to overlapping spheres. Resulting uncertainty volume is enormously larger than it should be.

The feature just noted shows up dramatically when mixing data among multiple platforms. Consider cooperative engagement whereby participants, all tracking each other via network-transmitted GPS observations, share radar observations from an unknown non-participant. Share measurements or coordinates? No contest; multiple lines crossing from different directions can offer best (i.e., along-range) accuracies applicable in 3-D.

That fact (i.e., combining data from different sensors and different platforms further dramatizes available improvements) doesn’t diminish the basic issue; even with a time history of data from only one radar, a designer with direct measurements available — instead of, not in addition to, coordinates — can provide incomparably superior performance.

“Send Measurements not Coordinates” (1999; #66 from the “Published Articles” panel, opening with eight rock-solid reasons) was aimed at GPS rather than radar. Many of the principles are the same when mixing data with information from other platforms — and from other sensors such as GPS. There is no reason, in fact, why data from satellite navigation and radar can’t be combined in the same estimation algorithm. That practice hasn’t evolved but the historical separation of operations (e.g., navigation and surveillance), arising from old equipment limitations, should no longer be a constraint. Moreover, with focus shifted from tracking to navigation, integration with additional (e.g., inertial) data offers still more reasons for using direct measurements. Rather than loose integration, superior benefits are widely known to result as the sophistication progresses forward (tight. ultratight, and deep integration).

Further elaborations on “casting off our old habits” appear from different perspectives in various blogs, one-pagers, and a few manuscripts available at this site. If your library has a copy of GNSS Aided Navigation & Tracking  pages 203-4 show a way to implement the cooperative sharing of radar data obtained from a non-participant, among participants tracking each other via the mutual surveillance and tracking approach defined earlier in that same chapter.

Because so many operational systems (in fact, a vast majority) use reports in the form of coordinates, reiteration is warranted. The central issue is the content, not the amount, of data. Rather than coordinates, provide accurately time-stamped direct measurements with links connected to whichever platform observed the data (e.g., for satnav — pseudoranges; for radar — range, azimuth, elevation). Those links are automatically attached when Mode-S extended squiter (e.g., chosen for ADSB) is the means for conveying the data.  For message content, strictly disallow “massaging the data beyond the light of day” (e.g., by unknown processes, with uncertain timing, … ) which invariably results in enormous loss of performance in common occurrence today.