The Indonesian National Transportation Safety Committee this week released its preliminary report [PDF] into the crash on 29 October of Lion Air flight JT610 near Jakarta. The crash involved Boeing’s new 737 MAX 8 aircraft and claimed the lives of 187 passengers and crew. The report sheds some light into the rash of maintenance problems with the aircraft in the days leading up to the crash, but doesn’t provide any probable cause of the crash itself. The Safety Committee stated that it is “too early” to identify a cause.
One reason for a lack of a probable cause is that the cockpit voice recorder has not yet been located and studied. Further, the recovered aircraft’s allegedly faulty angle of attack sensor, which is currently being investigated as a potential contributing factor in the crash, still needs to be tested. Other parameters from the flight data recorder also have to be analyzed.
The report indicates that the pilots of flight JT610 encountered difficulties immediately upon takeoff. The left (pilot’s) control column stick shaker activated during takeoff, and continued for the whole flight. The stick shaker warns the pilot that the aircraft is entering a stall condition.
The activated stick shaker was most likely caused by erroneous inputs received by the flight-control computer by a faulty angle of attack (AoA) sensor on the pilot’s side of the aircraft, while the sensor on the copilot’s side apparently was fine. The recovered digital flight-data recorder revealed a difference between the angle of attack logged on the left and right sensors of about 20 degrees that began during ground taxi and continued throughout the flight, the report indicated.
The angle-of-attack sensor data outputs feed into the flight computer system. In fact, a faulty AoA sensor can cause more than just a continuous or intermittent stick shaker on the affected side, according [PDF] to Boeing. The effects a faulty sensor can produce include: inability to engage autopilot; automatic disengagement of autopilot; warning alerts for indicated air speed, altitude, or angle of attack; and increasing nose-down control forces.
The last is the focus of concern in the crash because the new Boeing 737 MAX flight computer is equipped with the Maneuvering Characteristics Augmentation System (MCAS), which automatically pushes the aircraft’s nose down (or automatically trims the aircraft) if it detects a stall. Older 737s don’t have MCAS. Boeing included the system on the 737 MAX series because of aerodynamic changes mainly resulting from the position of its engines.
In this figure from the report, the up/down on the blue line shows the pilots trying to manually trim the aircraft’s stabilizer. The orange line below shows the MCAS system automatically trimming, and then countering the pilots’ manual efforts to trim. Image: Indonesian National Transportation Safety Committee
According to the report, the incorrect angle of attack data triggered the MCAS into thinking that the aircraft was entering a stall, and it dutifully pushed the aircraft’s nose down. The pilots countered the MCAS by manually bringing the nose back up. However, the MCAS again countered that action. All in all, the pilots tried to counteract the MCAS some 26 times.
The report indicates that during several previous flights of the 737 involved in the Lion Air crash, pilots encountered problems involving the AoA as well as the pitot tube used to measure airspeed. In a flight in the same plane the day before, to Jakarta, the pilot experienced many of the same symptoms as the pilots on flight JT610: the stick shaker activated during rotation, an indicated airspeed warning alert appeared, and the aircraft began automatically pushing the aircraft nose down.
The pilot, after determining that his flight display system was malfunctioning, ran a runaway stabilizer non-normal checklist which led to the MCAS being disconnected when the stabilizer trim switches were turned off. The copilot flew the rest of the flight using manual controls and without autopilot.
That Jakarta flight was using an angle of attack sensor that had been replaced after the previous Lion Air flight to Denpasar experienced problems. The problems with the Jakarta flight were recorded in the aircraft’s maintenance log. However, it is not clear whether the pilot communicated that he ran a runaway stabilizer non-normal checklist during the flight, which might have alerted the airline’s engineering staff that there was still a problem.
Engineering performed maintenance on the pilot side’s air pitot data module before the 737 was returned to duty. No maintenance work was performed on the AoA sensor replaced on the previous flight, however. The 737 crashed on the next flight.
An outstanding question, which, hopefully, the information on the missing voice data recorder can help resolve, is why the pilots on the previous flight were able to successfully cope with the problems they encountered, and the pilots of flight JT610 were not. In particular, why did two experienced 737 pilots not turn off the stabilizer trim switches, which would have allowed them to control the aircraft stabilizer manually?
Although one can’t say with certainty, the symptoms seen by the pilots on Lion Air flight JT610 seemingly would have indicated a likely uncommanded stabilizer motion (or stabilizer trim runaway), not necessarily an AoA sensor problem affecting the MCAS.
That appears to have been what happened in the previous Lion Air flight. Was there something else that happened that led these pilots to understand the situation they faced differently?
Another question raised is whether 737 MAX 8 pilots should be able to tell the difference between a stabilizer trim runaway and a faulty AoA sensor that commanded the MCAS. If so, given that the procedures to address the symptoms are nearly the same, would it matter? This is a topic of hot debate.
Another issue is whether the MCAS software needs fixing. According to news reports, Boeing is working on a fix but has not yet discussed what it will do.
Peter Lemme, a former Boeing avionics engineer who has written extensively about the crash at his Satcom Guru blog, told me that the “persistence of MCAS” was one element of the design that was troubling. “It’s a feature that won’t give up,” in event of a malfunction such as a bad AoA sensor, Lemme said, until it is physically turned off. Boeing should consider how the MCAS can be more quickly physically or automatically disconnected, he said.
Whether it is possible for the flight computer to recognize an obviously faulty AoA sensor and to keep not only the MCAS from engaging but also keep it from activating the stick shaker and other alarms is also a question. AoA sensor data will be “incorrect” occasionally (due to a gust of wind, for instance), so it may be difficult to determine when it is truly malfunctioning.
Of course, another question is whether Lion Air flight JT610 should have taken off in the first place, given the rash of maintenance problems leading up to the crash. Indonesian officials insist that the aircraft was airworthy, but others question that assertion.
The final report is due out next year. Hopefully, it will give a clearer picture of what was happening on the flight deck, how the MCAS system works, its role in the crash, if any, and what needs to be done—be it better training, better automation, or both—to prevent future accidents.
Contributing Editor Robert N. Charette is an acknowledged international authority on information technology and systems risk management. A self-described “risk ecologist,” he is interested in the intersections of business, political, technological, and societal risks. Along with being editor for IEEE Spectrum’s Risk Factor blog, Charette is an award-winning author of multiple books and numerous articles on the subjects of risk management, project and program management, innovation, and entrepreneurship. A Life Senior Member of the IEEE, Charette was a recipient of the IEEE Computer Society’s Golden Core Award in 2008.