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

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

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

人工智能長期以來一直是開發人員從事高性能計算和基于云的系統的工具。人工智能改變了網絡監控方式，電子郵件掃描方式，甚至是我們與手機和設備交互的方式。雖然AI和機器學習總是感覺像是一個生活在實時嵌入式系統之外的遙遠工具，但機器學習正在基于微控制器的系統中實現，事實上，它已經存在!

第1課 - 不要妥協您的產品以短期儲蓄或賺錢

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

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

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

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

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

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

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

第4課 - 經過高度測試和認證的系統存在缺陷

Edsger Dijkstra寫道：“程序測試可用于顯示錯誤的存在，但永遠不會顯示它們的缺失。”我們無法證明系統沒有錯誤，這意味著我們必須假設即使我們經過高度測試和認證的系統有缺陷。這應該改變每個開發人員思考如何編寫軟件的方式。我們應該開發缺陷策略，而不是試圖在個案基礎上暴露缺陷，這些缺陷策略可以檢測到系統行為不正常或者輸入看起來不正常。通過這樣做，我們可以盡可能多地測試系統中的缺陷。但是當一個新的領域出現時，一般的缺陷機制??有望能夠檢測到某些東西是不對的并采取糾正措施。

第5課 - 傳感器和系統出現故障

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