Part 3
Continuing the Threat and Error Management discussion..... If you are joining midway through, I highly recommend that you go back to the beginning (Part 1) starting with the post with the TEM graphic.
The TEM model posits that there will always be
threats, that there will always be
errors, but that by intelligently designing and employing sufficient
barriers, threats can be identified and mitigated, and errors can be trapped before they lead to an undesired aircraft state, incident, or accident.
Threats and errors were covered in the previous post, and a list of potential barriers were identified. I left off with what I thought were two germane questions:
Why did the existing barriers fail?
What happens when a barrier actually becomes a threat?
Once again, traditional aviation barriers that apply to flight deck operations include policies and procedures (SOP's), checklists, crew resource management (CRM), knowledge and aircraft handling skills, as well as external resources (ATC, maintenance, etc). CRM procedures would include briefings, communication, active monitoring, deviation callouts, assignment and execution of pilot flying/non-flying pilot (PF/NFP) duties. Knowledge and aircraft handling skills would determined by the particular training and experience of each pilot.
Which of these barriers failed? (easier question) Why did they fail? (harder question)
Unfortunately, not enough is known of the specific Ethiopian SOP's, crew discussions prior to takeoff, or specific training and experience to definitively address some of these questions. However, we can still make some (hopefully) useful observations. The data that has been released to date suggests that the ET302 Captain did not fully process the nature of the malfunction (perception error). Having not perceived the true nature of the malfunction, he proceeded to apply inappropriate procedures (attempting to engage A/P, retracting the flaps before the AOA/UAS malfunction was resolved). The repeated attempts to inappropriately engage the autopilot and subsequent aircraft handling (particularly the lack of aggressive trimming against the MCAS input) suggest a lack of comfort with hand-flying. At this point, it is impossible to say how much of the Captains actions were driven by a particular lack of knowledge or skill, or rather, the inability to draw upon that knowledge or skill under pressure. However, I think it is a reasonable observation that, to the degree that any barriers resided within the mind of the Captain (perception, SOP's, knowledge, aircraft skills), these barriers were ineffective. In short, the Captain could not trap his own errors. When errors are not properly trapped, they can convert to new threats.
Or to put it another way, what should have been barriers actually became threats.
How did these barriers become threats? There are signs that the Captain was experiencing cognitive overload. Contributing issues could include fatigue, distraction, pressure to meet schedule, inadequate training, and/or perception that he was effectively single pilot (more on that in a moment). Whatever the reason, the TEM model does suggest an appropriate response when barriers become threats.
Before that discussion, I need to touch on one other aspect of this accident. Based upon some of the previous feedback, I suspect some of you are not going to like this part, but I feel this is a necessary exercise. There was another potentially useful barrier on the flight deck that day -
the First Officer. This is an interesting case in that I have already identified a low-time FO and the possible existence of a steep authority gradient on the flight deck as potential threats. So was the FO a
threat or a
barrier? Or a little of both?
One piece of information we do not have is whether any steps were taken to mitigate the FO as threat. How well did the Captain know the FO and how did he perceive the FO's competency? Did he enquire as to his recent experience or if he had any particular questions? How thoroughly did the Captain brief his FO? Did the Captain perceive that there was a potentially hazardous authority gradient, and if so, did he attempt to mitigate it with clear guidance to the FO that he was expected to speak up as necessary?
Now let's discuss the FO as a potential
barrier. In a two-pilot crew operation, each pilot is expected to back up the other and help identify and mitigate threats as well as trap errors. They are also expected to work together to resolve any non-normal procedure.
One of the remarkable aspects of the CVR discussions that have been released so far are not so much what was said, but what was
not. There is very little discussion of the ongoing malfunction or the state of the aircraft. There is no discussion of airspeeds or altitudes. No one calls for any checklists, normal or otherwise. When the Captain tries to engage the autopilot with an active stick shaker (three times!) the First Officer does not question this action. By the time the aircraft reaches 1000' (and before MCAS ever showed up on the scene), the signs of unreliable airspeed were present. The Captain was absorbed in flying the aircraft and apparently greatly distracted. What was the First Officer doing? A fully qualified and proficient FO should have been monitoring both the aircraft and the Captain. He should have identified the UAS situation, but did not do so. If he had identified the UAS, he should have called for the appropriate NNC himself if the Captain did not do so. When the Captain called for the flaps to be retracted while they had an active stick shaker and before any non-normal procedure had been called for, the First Officer simply did as requested and did not question whether it was an appropriate action. As the airspeed increased toward VMO, the First Officer said nothing. When the Captain was obviously applying an excessive of back pressure on the control column without sufficient trimming, the First Officer did not prompt the Captain to trim or ask if the Captain needed help inputing trim. By not trapping
any of the Captain's errors, those errors now converted to new threats. The First Officer failed to be an effective barrier.
Some have pointed out, seemingly to the First Officer's credit, that it was he who finally identified the runaway stab trim problem (we should note for the record that the First Officer only made this observation the
second time MCAS began it's 9-second, 37 spin journey to oblivion). But rather than this being a positive result, it was actually the
final link in a long chain of errors that doomed this aircraft. Yes, that's right, the First Officer introduced his own deadly error into the chain.
From the transcript:
.
At 05:40:35, the First-Officer called out “stab trim cut-out” two times. Captain agreed and First- Officer confirmed stab trim cut-out.
When a non-normal checklist is needed, the procedure is for the first pilot seeing the problem to call out the problem (In this case "We have runaway stab trim") and then for the other pilot to
confirm ("Yes, I agree. We have a runaway stab."). This is a quote from my airline's FCOM:
"Prior to performing procedures, both pilots should communicate and verify the problem."
"Stab trim cutout" is not a
problem. It is a
command (maybe suggestion?). "Runaway Stab Trim" is a problem. When the First Officer said "stab trim cut-out", the (likely overloaded) Captain pounced on the suggestion, one of the pilots cutout the trim, and they were finally and fatally screwed with a stabilizer in an untenable position and no effective way to move it.
The next step in a non-normal situation is for one of the pilots (at some airlines it is the Captain, at some airlines it is the Pilot Flying) to call for the appropriate NNC procedure. Again from the FCOM:
"Identifying the correct procedure is critical to properly managing the non-normal situation."
There is a bit of divergence here depending on whether the airline uses a Quick Reference Card (QRC) or the "Memory Item" method. My airline uses a QRC, but basically the goal is to work through the steps in a
methodical fashion. Grabbing controls and switches without careful thought can lead to all sorts of misery. Think here of those accidents that resulted from crews shutting down the
wrong engine during an engine fire/failure in flight response. From the FCOM:
"Non-normal checklists use starts when the aircraft flight path and configuration are correctly established......Usually, time is available to assess the situation before corrective action is started. All actions must then be coordinated under the Captain's supervision and done in a deliberate, systematic manner. Flight path control must never be compromised." In other words, fly the aircraft first, and don't rush through the procedure.
Okay, I know some might find the preceding paragraphs tedious, but they are important to understand this final fatal error.
The Runaway Stabilizer checklist has been previously posted, so I won't duplicate it here except to enumerate two particular steps.
Step 2 of this NNC states: "Autopilot (if engaged) .... Disengaged. Do not re-engage the autopilot. Control aircraft pitch attitude manually with control column and
main electric trim as needed." It is not until
Step 5 of this checklist that we get this: "If the runaway continues after the autopilot is disengaged: STAB TRIM CUTOUT switches (both)..... CUTOUT." It should be added that it is really not necessary that all the
words be said correctly as long as all the
actions are performed correctly.
By methodically following the published procedure (rather than responding reflexively to the First Officer calling out "Stab Trim Cutout!"), the Captain would have been prompted to trim the aircraft with the Main Electric trim - the very thing he most needed to do after MCAS kicked in. Only
after the aircraft was returned to neutral trim was it appropriate to use the stab trim cutout switches, not
before.
The First Officer should have been a
barrier. Instead he was a
threat.
The Captain should also have been a barrier to his own errors and the errors of his First Officer. Being unable to trap either set of errors, those errors became threats.
Too many threats, too many errors, not enough effective barriers.
So we are now left with (a variation of) my final question:
What should one do when a barrier actually becomes a threat?