[论文解读] Candidate Software Process Flaws for the Boeing 737 Max MCAS Algorithm and Risks for a Proposed Upgrade

J.A. Bergstra, Mark Burgess|arXiv (Cornell University)|Jan 16, 2020

Software Reliability and Analysis Research参考文献 17被引用 11

一句话总结

本文識別出可能導致波音737 Max飛機MCAS系統失敗的軟體流程缺陷——例如可疑的安全等級分類、對前沿技術的隱含認知、對需求的不熟悉，以及干預過度——並指出這些缺陷很可能與事故有關。論文評估波音公司提出的升級方案（B-Max-New）作為解決這些缺陷的承諾，主張軟體工程的嚴謹性，而非僅技術設計，應成為認證與安全保證的核心。

ABSTRACT

By reasoning about the claims and speculations promised as part of the public discourse, we analyze the hypothesis that flaws in software engineering played a critical role in the Boeing 737 MCAS incidents. We use promise-based reasoning to discuss how, from an outsider's perspective, one may assemble clues about what went wrong. Rather than looking for a Rational Alternative Design (RAD), as suggested by Wendel, we look for candidate flaws in the software process. We describe four such potential flaws. Recently, Boeing has circulated information on its envisaged MCAS algorithm upgrade. We cast this as a promise to resolve the flaws, i.e. to provide a RAD for the B737 Max. We offer an assessment of B-Max-New based on the public discourse.

研究动机与目标

• 調查軟體流程缺陷（而非僅技術故障）是否在MCAS相關的737 Max空難中扮演了關鍵角色。
• 評估波音公司提出的MCAS升級方案（B-Max-New）作為正式承諾，以解決系統性軟體工程缺陷的可行性。
• 提出一個框架，運用承諾理論與外部分析方法，評估高保障系統中軟體工程的完整性。
• 透過識別軟體開發實務中可驗證的缺陷，支持訴訟、認證與未來軟體流程改進。
• 提倡負責任的軟體工程，強調在安全關鍵系統中，應重視責任制、透明度與對既定工程原則的遵守。

提出的方法

• 運用承諾理論分析公開論述，從波音與監管機構的聲稱中推斷軟體流程缺陷。
• 識別出四種候選軟體流程缺陷：可疑的安全等級分類、對前沿實務的隱含認知、對需求的不熟悉，以及干預過度。
• 將波音的升級提案視為正式承諾，以解決先前缺陷，評估其可行性與與安全標準的一致性。
• 採用「演算法」為獨立於實作的抽象智力創作之定義，與軟體及文件區分開來。
• 根據現行認證標準（如FAA型號認證）評估升級方案的可行性，考慮MCASu是否可在無新方法論的情況下獲得認證。
• 運用邏輯推理與電信與多執行緒技術的類比，模擬功能交互風險與系統層級失敗。

实验结果

研究问题

• RQ1 公開聲稱中關於MCAS的內容，在多大程度上顯示出系統性軟體工程流程缺陷，而非單一的程式碼錯誤？
• RQ2 所提出的B-Max-New升級方案是否可合理解讀為對解決識別出的軟體流程缺陷的承諾？其技術與程序上的可信度為何？
• RQ3 如干預過度或缺乏對前沿實務認知等軟體流程缺陷，如何導致航電系統的安全關鍵失敗？
• RQ4 當內部系統細節不可得時，承諾理論與外部分析在訴訟、認證與軟體流程改進中可如何提供協助？
• RQ5 在現行B737 NG型號認證標準下，是否可行認證升級版MCASu？還是必須採用根本上全新的認證方法論？

主要发现

• 識別出四種可能促成MCAS事件的候選軟體流程缺陷：可疑的安全等級分類、對前沿技術的隱含認知、對需求的不熟悉，以及干預過度。
• 所提出的B-Max-New升級方案被解讀為承諾解決這些缺陷，但由於缺乏內部系統細節，其技術與程序上的可信度仍不確定。
• MCAS與手動駕駛員輸入之間的功能交互風險在軟體工程中早已知悉，而未能妥善處理此風險，反映出盡職調查的缺失。
• 本文主張，軟體工程失敗不僅是技術問題，更涉及流程與責任，而無責後向分析可能掩蓋這些問題。
• 原則上，可在現行標準下認證MCASu，但因缺乏對可行升級方案不存在的正式證明，未解決缺陷的風險依然存在。
• 演算法（抽象智力創作）與軟體（實作）之間的區分至關重要：即使程式碼正確，若演算法本身有缺陷，仍可能危害安全。