More on trustworthy data

You are flying a high tech airliner, at night, over the ocean. Your instruments become useless, airspeed and altitude randomly moving from off-scale-low to other, arbitrary values. Or are they true values? The computerized control system reacts to those with a series of warnings, some of which are contradictory: over-speed and stall, at the same time. Without any visual frame of reference, there's no way to tell even roughly how high or fast you are going. What do you do?

Ask for help.

Air traffic control has radars covering the area (it does for most places airliners fly, but not some of the deep ocean routes) so you call back and ask them to give you accurate information off their screens.

They can easily, if slowly and by voice, give bearing, direction of travel and speed.

Who knows what is wrong with this last data point?

Altitude is not derived from radar data, but is instead telemetry; the aircraft sends the information, along with those identifying codes at the top, to the radar as part of the transponder data. If flight instruments are inaccurate, its very likely -- and in this case, indeed true -- that the number on the ATC display screen is wrong also.

And as a result, you fly into the ocean.

Aeroperu 603 New York Times article Wikipedia article

There's plenty more to hate about this crash (and the similar Birginair one) from a human factors point of view, from providing static and pitot port blocking devices, to the difficulty the flight crew has of focusing on a problem with so many conflicting instruments and warnings.

But I think there's something to be said for the problem of displaying the trustworthiness of data in this one narrow context. ATC systems have worked like this forever, and will probably continue to do so. I was surprised no one seemed to be aware of their manner of operation. And remember, the ground controller does not have as many issues as the aircrew, so should have had a chance to think over the issue. I presume he was, deep down, aware of how the system works.

But I generally avoid anything that has training as its backbone. Would there be a way to denote how information works, or where it comes from? I have nothing now, but its worth considering. The big problem as I see it is that the information is of mixed sources, and therefore mixed reliability. When transponders fail, or are turned off (terrorists, smugglers), the data supplied by it simply disappears. But before that, its displayed in the exact same manner as the systematically, radar-derived data.

Note that just because air travel is a high-reliability system with lots of history, these systems are not bulletproof. Changes to the displays frequently are poorly implemented and cause confusion. I suspect much of the design is status quo, and is not that good were testing to be done on it. Problems are alleviated with training and procedure, leading to accidents that result from poor training, breakdowns in procedure, and poor communications of changes in either.

Another example...

...of desktop computer mentality causing short-circuits in design. A Predator B crashed in april of last year while flying for Customs & Border Protection in Arizona. The accident report is very interesting:

The condition lever, which is installed in both the PPO-1 and PPO-2 consoles, serves a different function depending on whether the station is being used by the payload operator or by the pilot. In the payload operator configuration, the lever is used to control the iris of the camera. Moving the lever forward increases the iris opening, moving the lever to the middle position locks the camera's iris setting, and moving the lever aft decreases the opening. In the pilot configuration, the lever is used to control the engine fuel valve and the propeller feather servo. When in the pilot configuration, the lever has a linear analog range from 0 to 100 percent, which is divided into thirds: "normal," "shutdown," and "feather/shutdown."

Without reading the report you can probably guess the accident is the result of switching consoles (due to some software issue with the first, I gather) and not following procedures correctly, so the engine was commanded to turn off. Here's another good example:

Warning Signals There is an audible warning when an engine failure occurs. However, the same tone is used for every warning... ...The avionics technician stated that he heard the warning, but thought it was activating because they lost the Iridium satellite.

And, apparently, there is no really useful visible signal of any sort. Naturally, FAA found the accident to be the pilot's fault, but I have to place a lot of the blame on the design of the system. I never buy poor training or poor procedure for such egregious design faults. Its not like 80 years of accident investigations have taught us nothing about aircraft control design and layout. This was totally predictable. Here's another one, about software design instead of human factors, but it proves the point as well. The aircraft is controlled mostly thru a C-band radio. If you loose signal (which happens if you are out of line-of-sight) an Iridium satellite comm channel can be used. When the engine power was lost, the aircraft dropped out of range of the primary radio.

However, when the fuel was cut off to the engine and the UA began shedding electrical equipment to conserve battery power, the Iridium system was one of the items that was shed. The UA is also equipped with an auto-ignition system, but this system will not work unless the Iridium system is operable.

Who decided that the only backup control channel should be turned off? This is like (on a manned aircraft) turning off the backup hydraulics. All of this, I think, is exactly inline with many of my rants about somehow forgetting good design principles just because its a computer, and everything is new.