Spanair accident at Madrid

[PEI_3721]

Lessons (to be) learned

The main contributors to this accident appear to be a human element (resulting in error) - the lack of flap/slat; and a system failure - the configuration warning. This does not exclude the other combinations in the 2x2 matrix, e.g. mechanical flap failure or human error preventing the config warning, but as currently reported the first option is the most likely scenario.
The accident was the result of the combination of these ‘rare’ events, which can represented by the Swiss cheese model. The failure of the warning system was a latent factor and the human element the ‘unsafe act’.
Safety would be improved by either preventing the contributors (close the holes), or in the event of one or both being present, preventing their confluence – another slice of cheese – a new defensive barrier.

Improving the weaknesses in the human element is difficult. The industry accepts that errors will occur (1 to 3 errors/hour); only a few (5%) are undetected, of which only half might have any consequence.
However, the required standard of safety means that HF, CRM, TEM training, etc are still required to avoid, detect, or deal with the consequence of error in order to minimize the risk of a major accident, but this does not prevent the human element being a contributor to accidents.

The latent factor appears easier to deal with; in this instance, the reliability of the warning system could have been better. Previous accidents had identified a weakness (and as indicated by this thread, a continuing weakness), which in airworthiness terms could have warranted a system redesign, but it was judged that an additional check would be adequate. Note that this course of action has several paths where the human element might also be a safety factor. First, the human judgment that the additional check vs a system redesign would be enough, second that the check involves a human, and third, that the need for the check is both communicated and implemented as envisaged; all have opportunity for error.
In some instances, the certification process does allow ‘grandfather rights’, i.e. no need to meet a later standard of certification due to an earlier design/certification, MD-80 evolved from DC-9. This could have been an issue in the decision to use a check.
Thus, with humans involved in the system’s aspect too, it is not wholly possible to eliminate the system contributing to an accident.

The other option of preventing the combination might require identification that either of the contributors was present – use another crew member to monitor or a config-warning system failure detection.
In hindsight, and with concerns about human reliability, an improvement in the aircraft design by addiding config-warning system failure detection might be the better solution. The certification requirements (#2104), states that some aircraft already have ‘config warn inop’ or similar alerting. However, even this option is not totally error proof.
The EBR example in #2201 might have a weakness in that ‘Takeoff’ is announced by someone (thing) other than ATC – (Tenerife?). In other installations, the failure condition might be given during the test, which could be embedded in crew’s memory enabling a real event to be misinterpreted or ignored (Helios?).

There may not be a single safety solution – if there is, it might only prevent ‘this’ accident from happening again. In order to avoid similar, generic accidents, then a broad base of activities is probably required. The industry needs continued effort on HF training (CRM/TEM) and with management (certification) awareness of HF, but equally improvements in the certification and continued airworthiness processes would be required, and in a time scale matching those of operational training.

Ref: 1 to 3 errors/hour – Amalberti. ‘The paradoxes of almost totally safe transportation systems’. Also, see Helmreich et al. LOSA reports.

FAA Certification process study.