SafetyPee, with respect to the erroneous angle of attack issue that I assigned elephant in the room status too…my thinking is that we have two airplanes, and three AoA vanes, all on the left side, that have generated faulty data in a very short fleet history. My concern is that there is a problem in either the hardware or software that is processing the AoA inputs. As the NG does not, to my knowledge, have an extensive history of this, I have to wonder what else is different in the air data systems of the Max, and how changes in design at that location may also have been poorly vetted...which of course leads to lots of other questions about the design process.
There is no doubt that Boeing’s MCAS stability augmentation idea has failed miserably. It is another case of a safety system introducing more risk than it was installed to prevent. The unscheduled operation of this system , particularly as it was modified following flight test (from 0.6 degrees per actuation to 2.5 degrees), introduces a very serious threat that clearly was not contemplated by the system safety analysis. Further, Boeing’s contention that the runaway stabilizer procedure is an adequate mitigation of this threat is not valid. Since the 707, Boeing aircraft have incorporated cutout switches in the control column designed to interrupt the pitch trim system if it is trimming in the opposite direction to which the pilot is pushing or pulling. These switches are intended to stop the system from moving the horizontal stabilizer too far until the pilot has the time to manually disable the system entirely. The MCAS bypassed these switches, which is a logical design when looked at solely from the purpose of the MCAS itself. Since MCAS is intended to increase the control force as the angle of attack approaches the stall, it doesn’t make much sense to allow MCAS to be cut out as the pilot inadvertently pulls the nose up toward that stalling angle.
But when looked at from the standpoint of the threats posed by a powerful stabilizer running away at high airspeed, this design is absurd. And since the first step in the runaway stabilizer procedure is to hold the control column firmly, thus utilizing those column cutout switches to inhibit further trimming, the risk mitigation assured by that procedure is severely diminished.
That all said, Muillenberg was appropriately diplomatic when he said that Boeing owns one link in the chain, but not the whole chain.
When crew of ET-302 lifted the airplane off the runway at Addis Ababa, the first thing that happened was the captain’s stick shaker activated. This is pretty much the same thing that happened to LNI610, the Lion Air flight that crashed on Oct 29, and LNI043, the flight to Jakarta on Oct 28 . It may well have occurred to that airplane on Oct 26 and 27 as well. The crew operating LNI043 did not record the stick shaker operation in the aircraft maintenance log; perhaps others did not as well.
The captain of LNI043 was able to ascertain pretty quickly that the left side instruments were unreliable by comparing with the standby flight instruments. The crew of LNI610, on the other hand, did not believe they had any reliable altitude information, and asked ATC for groundspeed information. To date, I have not seen any information regarding discussion on the ET-302 flight deck about standby instruments, or comparisons between left and right instruments.
The captain of LNI043 retracted the flaps after he had determined which instruments were malfunctioning, and he had verified the airspeed. In the ET-302 case, that does not appear to have happened; instead, it looks to me like they retracted the flaps because they were task saturated and clinging to normal procedure.
The ET-302 crew did not comply with the Boeing procedure for a runaway stabilizer. As far as I can tell, no one actioned any item on the procedure except the most important step, disabling the master trim cutout switches. The procedure calls for the autopilot and autothrottles to be turned off. This crew made several attempts early on to get the autopilot engaged; it finally engaged and then disengaged itself 33 seconds later. They selected level change and set the speed to 238 knots. No one ever made any attempt to actually control the airspeed. My hunch is that they assumed the autothrottle would control the airspeed, which is a pretty standard response for automation-dependent flight crew. However, level change controls the airspeed with pitch; without being able to get the nose up, the airspeed is headed for the barber pole.
If they still had 238 knots in the MCP window and were actually doing well over 300, the FD command bar was probably pasted to the top of the PFD; that may be what the captain meant when he said the “pitch is not enough”. I can’t see any other reason. They were climbing. In the final 3 minutes, with the pitch trim selected off, they had climbed about 4000 feet.
It appears that the first officer attempted to crank the manual trim wheel after they had shut off the electric trim system. Only eight seconds after the captain told him to try the manual trim, the first officer reported that it wasn’t working. It is impossible to know exactly how he reached that conclusion; at the speed they were moving at, I’m pretty sure the trim would have been difficult to move. I’m skeptical toward the claim that it was impossible to move; I would be more inclined to believe that if the first officer had said more or taken more time attempting to crank the wheel. The two ANU trim inputs shortly before the end indicate that a) the master trim switches were back on, and b) the trim motor was capable of moving the stabilizer. I really don’t know whether the manual trim can be frozen while the trim motor still works, but I suspect it would be the other way around. Bear in mind that it takes a couple of dozen revolutions of the manual wheel to make a dent in the nose down trim forces. I’d certainly love to see some flight test data on this…my visit to recurrent training next month will be interesting and possibly colorful.
I really don’t know whether the captain knew that the master trim switches had been selected back on. Prior to this, the captain had successfully countered MCAS inputs with nose up electric trim, just as the Lion Air captain did. When the MCAS operates the final time, the captain does not appear to attempt to counter it with the electric trim switches. I cannot help wondering if he still believed the electric trim was off; if so, he may have thought there was nothing he could do except try to pull up with the elevator control.
We have what appear to be three flights with very, very similar attributes. The crew of LNI043 managed to resolve the entire problem, even without knowing of the existence of MCAS (possibly with help from the jumpseater). They resolved it so successfully that they flew all the way to Jakarta with the autopilot off and manually trimming. They then failed to accurately record all of the faults (like the stick shaker) in the AML, a fact they will have to live with for the rest of their lives. The crew of ET-302 knew about MCAS, disabled it, and were still unable to get the situation under control…despite gaining what appears to be adequate altitude.
I suspect that there are huge issues of automation dependency, systems knowledge (standby instruments), and workplace cultural issues (repetitive writeups that are not resolved and turn out to be incomplete) in play here.