波音737 MAX Fiasco的5個經(jīng)驗教訓(xùn)

雖然我們將在幾個月前收到關(guān)于737 MAX崩潰的完整報告，但我們不必等待從這些事件中汲取教訓(xùn)。1908年9月17日，Orville Wright和Lt Thomas Selfridge從Fort Meyer Virginia的Wright Flyer起飛。起飛后不久，賴特飛行員突然停下來，將飛機撞向地面，打傷了賴特并殺死了塞爾弗里奇。當其中一個木質(zhì)螺旋槳在支撐線上分開并拉動時發(fā)生碰撞，這導(dǎo)致后方舵從垂直位置移動到水平位置1。這是導(dǎo)致死亡的第一次飛機失事?？爝M大約110年：飛機不再是由賴特和早期航空先驅(qū)駕駛的簡單機械飛機，而是由數(shù)百萬行軟件驅(qū)動的高度復(fù)雜的電子系統(tǒng)。上個世紀的進步使航空旅行成為最安全的交通方式。

最近新聞頭條由兩起墜機事件主導(dǎo)，涉及波音公司新型737 MAX飛機在類似情況下六個月內(nèi)相互撞擊。這些災(zāi)難的后果可能只是在世界各地的飛機停飛，737 MAX的生產(chǎn)減少以及3月飛機的銷量降至零時才開始。波音公司作為安全領(lǐng)導(dǎo)者的聲譽受到的損害現(xiàn)在也受到質(zhì)疑，因為已經(jīng)開始調(diào)查研究中心的系統(tǒng)MCAS是如何開發(fā)和認證的。

對導(dǎo)致失去這些飛機的事件順序及其原因的調(diào)查將需要相當長的時間才能完全暴露并由事故調(diào)查人員實現(xiàn)。但是，根據(jù)目前發(fā)布的信息，嵌入式系統(tǒng)公司和開發(fā)人員可以查看波音目前正在經(jīng)歷的慘敗，并了解并提醒他們可以應(yīng)用于自己的行業(yè)和產(chǎn)品的一些常規(guī)課程。讓我們來看看這些課程。

人工智能長期以來一直是開發(fā)人員從事高性能計算和基于云的系統(tǒng)的工具。人工智能改變了網(wǎng)絡(luò)監(jiān)控方式，電子郵件掃描方式，甚至是我們與手機和設(shè)備交互的方式。雖然AI和機器學(xué)習(xí)總是感覺像是一個生活在實時嵌入式系統(tǒng)之外的遙遠工具，但機器學(xué)習(xí)正在基于微控制器的系統(tǒng)中實現(xiàn)，事實上，它已經(jīng)存在!

第1課 - 不要妥協(xié)您的產(chǎn)品以短期儲蓄或賺錢

今天的企業(yè)和開發(fā)商面臨著規(guī)范性的壓力，要求他們盡快增加收入，降低成本并運送產(chǎn)品?？陬^禪不是品質(zhì)。這不是安全。它不是用戶友好的。口頭禪是最大的短期增長，在我看來，只要短期增長最大化，不惜任何代價。現(xiàn)在，我不相信這是波音公司的口頭禪，甚至是他們的意圖，但考慮到他們似乎承擔了客戶和股東提供可以與空客A319neo競爭的飛機的壓力，我相信我們可以看到他們可能已經(jīng)開始屈服于這種規(guī)范性的壓力。

這將我們帶到第一課：不要冒險妥協(xié)您的產(chǎn)品以節(jié)省或賺更多錢。在短期內(nèi)取得成功非常重要，但除了本季度和下一季度產(chǎn)生的銷售額和收入之外，還有更多的業(yè)務(wù)。即使競爭對手發(fā)布競爭產(chǎn)品并且客戶施加壓力，重要的是要記住長期的敘述，而不是犧牲質(zhì)量，聲譽或使客戶的業(yè)務(wù)處于危險之中。

第2課 - 識別并緩解單點故障

在正在開發(fā)的任何嵌入式系統(tǒng)中，了解潛在的故障模式以及這些故障對系統(tǒng)會產(chǎn)生什么影響以及如何減輕它們非常重要。團隊有很多方法可以做到這一點，包括執(zhí)行設(shè)計失敗和影響分析(DFMEA)，分析設(shè)計功能，故障模式及其對客戶或用戶的影響。完成這樣的分析后，我們就可以確定如何減輕故障的影響。

在可能影響用戶安全的系統(tǒng)中，通常的做法是避免單點故障，例如傳感器故障或單個輸入。顯然，如果單個輸入突然提供垃圾數(shù)據(jù)，只有上帝知道該系統(tǒng)將如何響應(yīng)，當你投入墨菲定律時，結(jié)果不會是積極的。當我讀到MCAS系統(tǒng)依靠單個傳感器進行決策時，我真的很吃驚。過去曾經(jīng)致力于安全關(guān)鍵且強大的嵌入式系統(tǒng)，令人難以置信的是，單個傳感器輸入的使用將被認為是可接受的，并且在第二個傳感器的輸入中添加，如果傳感器發(fā)生故障則會禁用系統(tǒng)似乎沒有讓事情變得更好2(但這真的取決于工程哲學(xué)和文化)。

第3課 - 不要以為您的用戶可以處理它

我認為許多工程師可以從慘敗中獲得的一個有趣的教訓(xùn)是，我們不能假設(shè)或依賴我們的用戶正確操作我們的設(shè)備，特別是如果這些設(shè)備是自主運行的話。我并不是說這是貶義的，而只是指出復(fù)雜的系統(tǒng)需要更多的時間來分析和排除故障。波音公司似乎認為，如果出現(xiàn)問題，用戶就有足夠的培訓(xùn)和經(jīng)驗，并且知道現(xiàn)有的程序足以彌補。對或錯，作為設(shè)計師，我們可能需要使用“降低的期望”并盡我們所能來保護用戶免受他自己的傷害。

第4課 - 經(jīng)過高度測試和認證的系統(tǒng)存在缺陷

Edsger Dijkstra寫道：“程序測試可用于顯示錯誤的存在，但永遠不會顯示它們的缺失。”我們無法證明系統(tǒng)沒有錯誤，這意味著我們必須假設(shè)即使我們經(jīng)過高度測試和認證的系統(tǒng)有缺陷。這應(yīng)該改變每個開發(fā)人員思考如何編寫軟件的方式。我們應(yīng)該開發(fā)缺陷策略，而不是試圖在個案基礎(chǔ)上暴露缺陷，這些缺陷策略可以檢測到系統(tǒng)行為不正?；蛘咻斎肟雌饋聿徽！Ｍㄟ^這樣做，我們可以盡可能多地測試系統(tǒng)中的缺陷。但是當一個新的領(lǐng)域出現(xiàn)時，一般的缺陷機制??有望能夠檢測到某些東西是不對的并采取糾正措施。

第5課 - 傳感器和系統(tǒng)出現(xiàn)故障

傳感器和系統(tǒng)出現(xiàn)故障這一事實看起來似乎是一個明顯的陳述，但我看到很多開發(fā)人員編寫軟件，好像他們的微控制器永遠不會鎖定，遇到單個事件擾亂或內(nèi)存損壞。傳感器將凍結(jié)，處理器將鎖定，垃圾進入將產(chǎn)生垃圾。作為開發(fā)人員，我們需要假設(shè)事情會出錯并編寫代碼來處理這些情況，而不是如果我們總是擁有一個在現(xiàn)場工作的系統(tǒng)，就像在實驗室工作臺上一樣。如果你考慮到它會失敗的事實來設(shè)計你的系統(tǒng)，那么你最終會得到一個強大的系統(tǒng)，它必須在最終找到失敗的方法之前做很多艱苦的工作(如果有的話)。