
Let’s talk about the Trident accident near Staines Reservoir. I want to walk you through the human factors questions that this accident raises — questions that are central to how we investigate incidents and design safer systems.
The Trident fell out of the sky in a flat spin and crashed next to the A30 near Staines Reservoir. All 118 passengers and crew on board were killed. The aircraft entered a deep stall — a condition where the aircraft is uncontrollable and irrecoverable. That’s a critical distinction: a deep stall is not just a stall you can recover from; it is a state from which there is no recovery.
Now, the text asks us to think about several layers of system design and human factors. First: was the system designed for minimum risk? It can be argued that the Trident was a fundamentally unsafe design because it had an inbuilt capacity to lapse naturally into a dangerous, irrecoverable situation — the deep stall. That’s a design-level failure.
Second: were appropriate automatic safety features installed and implemented correctly? The text mentions the stick push — that’s a system that pushes the control column forward to prevent a stall. But the question is whether it was implemented properly. The text also points out that a speed lock on the droops should have been present. The droops are leading-edge devices that extend at low speeds to improve lift. A speed lock would have prevented them from retracting at the wrong time. The text warns: there is nothing worse than an unreliable safety device that gives out false warnings. Why? Because that leads operators to mistrust these systems and potentially be inclined to ignore or override them. That’s a critical human factors point — false warnings degrade the pilot’s trust in the automation.
Third: were the warning systems implemented in an appropriate way? The text asks us to consider the position of warning lights on the stick push system and the ‘droops out of position’ warning. And then there’s the cacophony of warnings and alerts when the aircraft began to stall. Should these have been better prioritized? In a high-stress situation, too many simultaneous warnings can overwhelm the crew — that’s a classic human factors issue.
Fourth: were there appropriate procedures in place? The text says this is the lowest level of system fix — you only rely on procedures when the design and automation can’t solve the problem. It asks: were there appropriate procedures for the selection and training of aircrew? Was the procedure to circumvent the industrial dispute one which promoted safety? Was it appropriate to use an inexperienced P2 and P3 — that’s the co-pilot and second officer — on this flight? Should Keighley have been ‘selected out’ during training? Should Key have been selected as a Training Captain? And what about the inspection procedures in the maintenance hangar?
Finally, the text introduces a key distinction: if possible, each factor in the accident should be assessed as either causative or contributory. A causative factor is an item in the accident chain which, if it were removed, would have stopped the accident from happening. A contributory factor is one which, from knowledge of the human operator, ‘would not have helped’. That’s not an easy thing to do, but it can be informative if you need to prioritize actions.
So the core lesson here is that accident investigation isn’t just about finding one cause — it’s about examining the whole system: design, automation, warnings, procedures, training, selection, and maintenance. And we classify each factor as causative or contributory to help us decide where to act first.
This is one saved preview. Continue from this exact book or paper with BlueFlash voice AI.
Continue in BlueFlash