terpster and SR71 have raised the issue of nav data base integrity (paper or electronic, issues are similar). It's a lot more complicated than just a couple of places where things can go wrong.
I don't recall either terpster or SR71 being on the bluecoat list. The Bluecoat 2001 annual meeting was held at LHR just a month after 9/11. It wasn't super-well attended because of that, but there were some very informative talks indeed. One was from Lee Carlsen, of Smiths, in Grand Rapids, Michigan, who talked about the issues of nav data base integrity. I wrote up a conference report. Here are my notes on Lee's talk. I apologise for the length.
I am also concerned about thread creep. Over the time I've been on PPRuNe I think I have tried to start three threads. Each one has silently disappeared within minutes of my starting it. However, my contributions to existing threads don't disappear. JohnT moderates transparently and I'm sure he will make the necessary structural changes if this is too much creep.
[begin Bluecoat 2001 notes on Lee Carlsen's talk]
Lee Carlsen told us about Nav database integrity, lavishly illustrated with some unnerving photos from
Unusual Aviation Pictures . He succeeded in persuading me, at least, of the significance of this problem of heterogeneous engineering. The chain is as follows.
1. Survey;
2. Compilation of survey data by the state or official agencies;
3. Data given to DB providers (Jeppesen, Thales, etc) for processing;
4. Data processed by DB providers;
5. Formatted data given to Navionics providers for formatting and compactification for their products;
6. Product-adapted data returned to DB provider for distribution to customers;
7. Distribution to customers;
8. Installation in airplane;
(9. Pilot's fingers......).
During any of these processes, data could become corrupted. Surveyors make mistakes (or, in some cases, require and provide half their data as WGS-84 and another half using traditional measures, as in Mexico), and at any other point in processes 2 through 6 finger trouble at data entry or lack of correctness of programs processing the data can cause corruption. Customers may not necessarily install new data correctly. And all that before it gets to the pilot. Lee gave us a quick survey of the methods that can be reasonably applied to assure high integrity: tools can be provided to the DB producers to check output against input for steps 4 and 5, and to check output to step 6 against output to step 4 (and thus against input to step 4 for those with a tool for this also). Output can be assured wrt input for steps 3 and 7 by including error detection (or even error-correcting encoding) on the distribution medium. Such methods could also be used to prevent successful installation if there is any data corruption on the medium.
However, while all this is technically trivial, it is a significantly large if not gargantuan task of heterogeneous engineering involving many actors, some of whom (such as the states) are not necessarily motivated by any externalities such as a threat of getting sued over mistakes.
In my own work I encounter data integrity problems, and their significance for safety-related systems cannot be underestimated. But the problem of assuring integrity seems to be much more difficult than I had heretofore thought it.
[end Bluecoat 2001 notes]
PBL