Not a pilot problem...
Why this case is a design concept problem and not a pilot problem?
Answer:
If only 1% of qualified pilots get a wrong picture of what is going on in this scenario then it's not a pilot or training problems but a design problem in the way of data presentation to the pilots.
Additional point: If all systems are okay but only one input data (air speed) is invalid then there is no reason to disable the autopilot because the pilot don't have a better speed value.
Following this thread since two years as silent reader I have the advantage not to be a pilot but many years of IT design experience. This helps to identify problems from another point of view.
I am a graduated physicist and have been working as software developer for 25 years with industry quality data IT-systems including data input screens, automatic machine date interfaces and graphical presentation.
During all the thousands of IT-duty calls I got at day and night helped me to develop a good feeling what can go wrong between hardware, software and the user - and how to avoid this.
Main problem in the system design phase:
The programmer speaks with the wrong persons (not the end user) or got a system specification written by people not knowing all cases. Especially big companies avoid direct contact between the programmer and the end user.
The resulting produced software is working well for standard cases but in case of problems the error handling will be poor.
Only the end user knows all special cases and possible combination with other systems. The programmer has the task to find out what the user really needs and only he knows which additional help data the system can give to the user.
Note: A good written program often has more than 50% code for error handling.
Example: >>> The user wants to print a sheet with quality data but nothing happens.
Bad written software will show nothing or display some cryptic error codes.
A smart program collects all errors, adds a priority to each error and does some additional plausibility checks to eliminate errors that are results of other errors.
In our sample the problem can be missing data, database server, network switches, network connection, print server, wrong printer, printer defect, paper missing,...
A good program also checks the printer queue for errors, tries network pings to check the connection and so on.
Then the error codes are checked for logical relations and finally an easy to read, short message for the user is generated.
This message should show what action was requested, what went wrong, the assumed reason and how to fix it:
Sample: "Cannot print because network connection to printer lost -> check network cable (main reason for cable problems: cleaning lady). "
This message box also has a "Help" which will show a picture where the PC network port is located. So the user is able to fix the problem without calling me at night...
Another important rule: A good system should never surprise the user - it should always let you know what happens next.
So when the problem is fixed the program should inform the user "Connection to printer OK - print again?"
Back to AF447:
=============
The pilot seems to have wrong picture of the situation (never see the changing stall messages as valid) which results in wrong actions.
So the question is: which presentation of the available flight data will create a correct picture for the pilot?
The current cockpit instrument are looking old fashioned to me, similiar to old Comodore64 text adventure games I played 25 years ago:
A lot of numbers displays, cryptic messages give the brain a difficult task to generate the matching picture.
So just some thoughts:
1. Present a graphical 3D-Model of the plain that show the xyz-orientation as well as air-speed, GPS ground speed and attitude arrows (unreliable or
dangerous data marked by colors)
=> so that even a non-pilot can see in seconds what is going on.
2. imagine an IPAD-like touch screen device showing this 3D flight model that you can turn and zoom with your fingers.
3. put all manuals/checklists into this device - in case of a problem the matching checklist is shown automatically. The pilot has confirm the suggested actions (Trim/Thrust settings) just with a tip of his
finger to automatically executed them.
4. show detailed logs what the system is doing in case of unusual data.
Also use text to speech computer voice (see 100$ car navigation devices) to speak the messages.
Sample messages:
- unexpected speed lost => Thrust changed to 90%
- cannot hold speed with 100% thrust
- speed unreliable, possible cause: pitot icing (because of temperature, all 4 tubes)
- change to emergency mode:
using GPS ground speed before unexpected speed lost as reference
Then show check list for unreliable speed and ask for execution.
Hope this helps for the discussion...