Page 8 - MSDN Magazine, May 2019

Editor’s NotE MICHAEL DESMOND Flight of Failure
Two fatal crashes in five months. Not since the Dehavilland Comet in 1954 (bit.ly/2D0z51d) has a new commercial jet airliner suffered this kind of calamity so early in its life. A pair of Boeing 737 MAX aircraft, introduced just last year, crashed minutes after takeoff, when Lion Air 610 (LI610) plunged into the Java Sea off Indonesia in October 2018 and Ethiopian Airlines 302 (ET302) crashed just outside of Addis Ababa in February. In all, 346 lives were lost.
I’ve written about airline accidents before (“Chain of Disaster,” msdn.com/magazine/mt573708), exploring the role that automation and instrumentation played in the 2009 crash of Air France 447. And in the recent 737 MAX accidents, some of the same issues are cropping up. Commercial aviation has become significantly—even remarkably—safer over the past 30 years, but when accidents do happen, it’s often at the intersection of automated systems and the pilots who command them.
In the case of the 737 MAX, a system introduced to ease the aircraft’s nose down at certain points of flight malfunctioned at the worst possible moment—just after takeoff. The Maneuvering Characteristics Augmentation System (MCAS) was designed to make the 737 MAX behave more like its predecessor, the widely deployed 737NG, by counteracting a tendency in the new jet to at times pitch up when under power with the nose high. The goal was to make the 737 MAX and NG so similar to fly that no simulator training was needed for NG pilots, potentially saving airlines millions of dollars.
And there’s the rub: MCAS had to be pretty much invisible. Adding instrumentation to the cockpit or publishing procedures specific to erroneous MCAS activation could mandate simulator training. So when an angle of attack (AoA) sensor failed on LI610 and tricked MCAS into thinking the plane’s nose was way too high soon after takeoff, it caught the crew unprepared. The pilots repeat- edly countermanded the nose-down trim from MCAS, only for the system to redouble the down force moments later, ultimately resulting in a high-speed dive.
Five months later ET302 encountered the same phenomenon. Investigators reported that the crew responded appropriately,
disabling the trim motors in the tail to keep MCAS from forcing the nose further down. But now the pilots had to wrestle with a physical trim wheel, using cables to move the stabilizers at the back of the plane. Unfortunately, at the high speed the jet was traveling, aerodynamic forces made this impossible. When they re-engaged the trim motors in a bid to raise the aircraft’s nose, MCAS almost immediately pushed the nose down and the crew lost control.
The investigation into the accidents is ongoing, but hard lessons are emerging. Among issues being discussed in its implementation: Data validation: The AoA sensor data in each accident was clearly anomalous, yet MCAS remained activated throughout each event. By contrast, automated systems like autopilot typically fall
back to manual control when fed incoherent data.
Redundancy: MCAS activated based on input from just one of the two AoA sensors on the 737 MAX fuselage. Implementing a second sensor would significantly reduce the risk of inadvertent activation. Conditional code: MCAS activated in response solely to high AoA values. Adding logic to account for airspeed, altitude and pilot input might prevent unwanted activation—for instance, MCAS could be coded to disable if a pilot commands trim up
after an MCAS input.
Mission scope: MCAS has been described as an enhancement
to make the 737 MAX fly and feel to pilots like a 737NG. Yet the software repeatedly counteracted pilot commands and ultimately trimmed to maximum deflection.
Transparency: MCAS had no UI—no visual or aural indication that it had activated or encountered a failure state—and no pub- lished failure checklist for pilots. The assumption was pilots would interpret unwanted MCAS activation as a runaway trim motor and use that checklist to shut down the motor.
While the flaws in MCAS are likely resolvable, the larger question remains of how this system ended up in an FAA-approved aircraft design. I expect the lessons of the 737 MAX and MCAS will inform software and systems development for decades to come.
Visit us at msdn.microsoft.com/magazine. Questions, comments or suggestions for MSDN Magazine? Send them to the editor: mmeditor@microsoft.com.
© 2019 Microsoft Corporation. All rights reserved.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, you are not permitted to reproduce, store, or introduce into a retrieval system MSDN Magazine or any part of MSDN Magazine. If you have purchased or have otherwise properly acquired a copy of MSDN Magazine in paper format, you are permitted to physically transfer this paper copy in unmodified form. Otherwise, you are not permitted to transmit copies of MSDN Magazine (or any part of MSDN Magazine) in any form or by any means without the express written permission of Microsoft Corporation.
A listing of Microsoft Corporation trademarks can be found at microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx. Other trademarks or trade names mentioned herein are the property of their respective owners.
MSDN Magazine is published by 1105 Media, Inc. 1105 Media, Inc. is an independent company not affiliated with Microsoft Corporation. Microsoft Corporation is solely responsible for the editorial contents of this magazine. The recommendations and technical guidelines in MSDN Magazine are based on specific environments and configurations. These recommendations or guidelines may not apply to dissimilar configurations. Microsoft Corporation does not make any representation or warranty, express or implied, with respect to any code or other information herein and disclaims any liability whatsoever for any use of such code or other information. MSDN Magazine, MSDN and Microsoft logos are used by 1105 Media, Inc. under license from owner.
4 msdn magazine