Page 8 - MSDN Magazine, June 2019

Editor’s NotE MICHAEL DESMOND A Failure of Process
Last month I wrote about the twin crashes of Boeing’s new 737 MAX airliner and the automated Maneuvering Characteristics Augmentation System (MCAS) that precipitated both events. The investigations that followed point toward significant flaws with MCAS, which repeatedly commanded the aircraft nose down at low altitude as pilots struggled to diagnose the problem. (“Flight ofFailure,”msdn.com/magazine/mt833436).
Serious questions remain about MCAS and its behavior in the 737 MAX. For instance, MCAS was able to command 2.5 degrees of travel per increment on the rear stabilizer, yet the doc- umentation submitted to the FAA showed a value of just 0.6 degrees. Likewise, MCAS was designed to activate based on data from a single angle of attack (AoA) sensor mounted on the fuselage oftheplane.Yet,anysystemdeemedapotentialthreattocontrolled flight must activate based on multiple sensors.
ARP-4754 informs the DO-178 process to determine the level of rigor required for software development around aircraft systems like MCAS.
What’s concerning is that the integration of software into aircraft systems is strictly managed under guidelines such as DO-178B/DO-178C (“Software Considerations in Airborne Systems and Equipment Certification”) and ARP-4754 (“Guidelines for Development of Civil Aircraft and Systems”). Both impose rigor- ous documentation and review requirements on manufacturers
with an emphasis on safety. DO-178 focuses on software develop- ment across planning, development, verification, configuration management and quality assurance. ARP-4754 is a system-level process that addresses the integration of software and hardware systems and subsystems.
I spoke with a longtime aviation engineer. He says the layered levelsofdocumentation,testing,reviewandvalidationdefinedin DO-178 and ARP-4754 should ensure that a subsystem like MCAS is implemented in a way that minimizes risk.
“It’s all phases and gates,” he says of the process. “There are checks and balances forward and backward. If a test fails we can go back up the line and see what the requirement was and see if the code was written badly or if the test case was designed badly. It’s a very prescriptive, methodical process when we do this.”
ARP-4754 informs the DO-178 process to determine the level of rigor required for software development around aircraft systems like MCAS. Failure hazard analysis performed under ARP-4754 enables engineers to define failure rates and risk factors for aircraft systems. This data is then used to calculate the Development Assur- ance Level (DAL) of systems like MCAS in DO-178. The five-point scale—from Catastrophic to No Effect—determines the severity of impact should a system fail in flight, and thus the required level of robustness in the code driving that system.
So what of the disparity between the documented and actual incre- ment of the rear stabilizer? Perhaps field testing showed that MCAS required more authority. However, changing those specs should have kicked off another round of evaluation and testing to confirm MCAS behavior and failure states during flight, and mandated redundant sensor input to protect against inadvertent activation.
One of the emerging lessons of the 737 MAX catastrophe is that a process is only as good as the people and the institutions that execute it. Once undermined, it can
lead to dangerous outcomes.
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