In post-mortems involving pilot error, what strikes me is that airliner cockpit design sounds so convoluted, unintuitive, and just plain bad. The burden of disentangling this bad design is always placed on the pilots - through extensive training and rote memorization - which inevitably fails under stress.
In this particular example, consider:
- the opposing pilot inputs being signaled only by a pair of little green lights
- the cacophony of warning lights and alarms which, together, say little more than "something is wrong"
- instruments that direct a pilot to pull up during a full stall
- sensor failures with no clear indicator
- computer safeguards suddenly removed without a stated reason
Etc. And the expectation towards the crew is to quickly and corrently reason about this stream of conflicting signals, while embroiled in a sudden emergency.
It smacks of pure engineer-driven design, assembled with serious attention to the technical issues, but with near-zero empathy for the humans who will be operating the contraption.
Reminds me of internal web tools at so many companies. They present giant messy forms, with checkboxes and dropdowns for every conceivable edge case, which have to be manipulated just so or the system explodes. And when something breaks, of course it's the user's fault every time.
The ECAM is where one needs to look and start debugging. The pilots here didn't really do that. Audible warnings are only really used if they're extremely time sensitive (GPWS, Stalling, Dual Input).
There is no "cacophony of warning lights". The overhead panel is a designed to have all buttons not be illuminated, so if you're checking what's wrong, you can immediately tell by there being a light indicator on it. Here this was limited to two ADIRs indicating FAULT. Nothing more.
Not relevant in this example, but another terrible user interface in the cockpit is the FMC. That thing with the '70s era green screen, where pilots program routes with cryptic codes, seemingly inherited from the Apollo guidance computer.
So many accidents seem to happen when pilots receive a route change and have to hastily re-program the FMC.
There should be a calm AI voice stating what they should be doing based on some heuristics. Based on angle of attack, engine power and the last recorded reliable speed, I feel a simple system should be able to make projection of the current speed and throw some warning when pilot input are becoming real stupid.
It exists, and it'a called the ECAM. Last recorded reliable airspeed is usually never used, because an upset condition can change it very drastically fast. These systems help resolve upsets way more often then they miss and these engineers did their homework.
Hearing is also the first sense to go when people panic; this flight had the stall warning blaring for over a minute straight and it didn't occur to the pilots that they may not be in overspeed, but stall.
(It is of course not perfect, sometimes conditions become dependent on one another and their order is not always great - see this simulated simultaneous engine fire and engine failure right after takeoff, where flying on your burning engine might be better than turning into a 1000ft glider: https://www.youtube.com/watch?v=ZRbLLO385_c)
I also wonder why airspeed is derived by some formula applied to the measurement of flow along a tube that can be blocked by ice and become useless. Why not use GPS primarily and fall back to that if needed? Or the other way around even.
If you expect an instrument to routinely fail, it just seems logical to at least have a backup.
In this particular example, consider:
- the opposing pilot inputs being signaled only by a pair of little green lights
- the cacophony of warning lights and alarms which, together, say little more than "something is wrong"
- instruments that direct a pilot to pull up during a full stall
- sensor failures with no clear indicator
- computer safeguards suddenly removed without a stated reason
Etc. And the expectation towards the crew is to quickly and corrently reason about this stream of conflicting signals, while embroiled in a sudden emergency.
It smacks of pure engineer-driven design, assembled with serious attention to the technical issues, but with near-zero empathy for the humans who will be operating the contraption.
Reminds me of internal web tools at so many companies. They present giant messy forms, with checkboxes and dropdowns for every conceivable edge case, which have to be manipulated just so or the system explodes. And when something breaks, of course it's the user's fault every time.