專業/阿麗亞娜 5 號 501 航班

阿麗亞娜 501 叢集

事件

1996 年 6 月 4 日，歐洲航天局發射了阿麗亞娜 5 號火箭，501 航班從法屬蓋亞那庫魯發射。火箭的目標是將商業有效載荷發射到軌道，特別是四顆星群衛星。這些衛星將被放置在高橢圓軌道上，以對地球的磁層進行研究，從而使歐洲在商業太空業務中佔據主導地位。歐洲航天局花了 10 年時間和 70 億美元生產了這枚火箭。

那天，該局在建造火箭上投入的所有努力都付諸東流，包括 3.7 億美元，發射器偏離了飛行路徑，解體並爆炸，發射序列開始後僅約 40 秒，在 3700 米的高度上爆炸，將燃燒的碎片散落在法屬蓋亞那。幸運的是，沒有人員傷亡。來自阿麗亞娜 5 號專案的 CNES 和工業團隊的工程師立即開始調查故障，一個小型的計算機程式試圖將一個 64 位數字塞入一個 16 位空間造成的。

由於向發動機傳送了錯誤的控制訊號，並在升空後 37 秒使火箭旋轉，慣性參考系統（用於計算和引導火箭的速度、位置和方向）失效。火箭爆炸增加了地面和水中的氧化鋁含量，損害了法屬蓋亞那沼澤的環境。

技術故障

阿麗亞娜 501 墜落區

事件發生後幾天，成立了一個獨立的調查委員會，其中一個結論是，由於慣性參考系統 (SRI)的規格和設計錯誤，發射器在主發動機點火序列開始後 37 秒失去了制導和高度資訊。調查委員會發現，SRI 軟體中的以下設計缺陷導致了501 航班的失敗：升空後維護的預發射功能（對準模式）與飛行不相容。在備用SRI（正在待命，用於制導和姿態控制）內的計算機失效後約 0.05 秒，正在使用的SRI（硬體和軟體與備用系統相同）由於相同的原因失效。由於備用慣性系統已經失效，因此無法獲得正確的制導和姿態資訊。由於備用SRI失效，正在使用的SRI向發射器的主計算機發送了診斷資訊，主計算機將其解釋為飛行資料，並將其用於飛行控制計算。根據這些計算，主計算機命令助推器噴嘴和主發動機噴嘴對未發生的升高度偏差進行大幅度修正。由於氣動力，由此產生的快速升高變化導致發射器在主發動機點火序列開始後 39 秒解體。按照設計，解體後自動啟動銷燬。

所有其他證明有效的程式測試和審查都沒有發現這些異常，並且地面/飛航模式介面沒有得到充分識別。NASA 天體物理學資料系統提供的一篇來自歐洲航天局的論文解釋說，501 航班的慣性測量單元程式由於程式碼片段（飛行階段未使用）而失敗，因此，徹底識別死程式碼和未使用的但活躍程式碼，並證明未使用的可執行程式碼永遠不會導致執行時錯誤非常重要。

儘管在阿麗亞娜 5 號開發計劃期間進行了廣泛的審查和測試，但它們沒有包括對SRI 或完整飛行控制系統的充分分析和測試，這本可以檢測到潛在的故障。該機構錯誤地認為，由於SRI適用於阿麗亞娜 4 號，因此它也適用於阿麗亞娜 5 號，而阿麗亞娜 5 號的技術規格不同。

現狀偏差

隨著 100 多次成功發射，阿麗亞娜 4 號成為ESA歷史上最成功的火箭之一。它服役了 20 多年，被稱為ESA發射器艦隊的“主力”。阿麗亞娜 5 號專案團隊的任務是設計阿麗亞娜 4 號的繼任者。新火箭必須在不影響可靠性的前提下，超越其前身的有效載荷能力。

考慮到阿麗亞娜 4 號的成功，從事阿麗亞娜 5 號工作的工程師開始從阿麗亞娜 4 號專案中借用主要部件，包括阿麗亞娜 4 號的軟體包。阿麗亞娜 4 號的大部分軟體被設計為“黑盒子”，這意味著它可以在不同的發射器中重複使用，而無需進行重大修改。阿麗亞娜 5 號工程師從制導控制系統到飛行路徑最佳化軟體，都進行了回收，因為阿麗亞娜 4 號的軟體包擁有 100% 的成功率。

阿麗亞娜 4 號的元件實質上成為現狀。在設計新系統和使用阿麗亞娜 4 號元件之間，工程師選擇了更輕鬆、更便宜的途徑。重新設計系統意味著要對該系統的成功負責。工程師不想改變他們認為已經有效的東西，最終借用了太多東西。

導致501 號航班失敗的軟體是從阿里安 4 號借來的。它不像阿里安 5 號工程師想象的那樣適應性強，而且沒有按預期工作。工程師對SRI寄予了過高的期望。為了避免額外的風險，阿里安 5 號設計團隊無意中做出了一個導致火箭災難性失敗的決定。

責任分散

阿里安 5 號501 號航班爆炸代表了一種責任分散，因為沒有人或團隊對災難負責。法國和歐洲航天局成立的獨立調查委員會發布的報告指出，五個分別在航天器上工作的團隊本可以防止爆炸。這些團隊是

• 程式設計師：更好的程式設計實踐可以防止由將 64 位浮點數轉換為 16 位有符號整數值導致的軟體錯誤。
• 設計師：更好的設計，不允許軟體異常停止正常執行的硬體單元，可以防止SRI關閉。
• 需求工程師：更好的需求分析和可追溯性可以防止來自早期阿里安型號的對齊程式碼的異常部分被啟用，導致航天器故障。
• 測試工程師：一項測試驗證SRI在受到阿里安 5 號飛行序列和軌跡影響時是否能正常工作，將暴露故障。
• 專案經理：改進的專案管理流程，促進更緊密的工程合作，明確的許可權和責任，以及一致的程式碼和文件，將增加暴露故障的可能性。

雖然許多團隊都可能受到指責，但歐洲調查人員選擇不單獨指認任何特定承包商或部門。他們說，“一個決定已經做出。它沒有得到充分的分析或理解。在飛行過程中讓它繼續運作的可能後果沒有被意識到。”

偏差的正常化

如果工程師有更積極的測試程式，錯誤可能會及時被發現。然而，工程師在設計測試過程中採取了捷徑，這是為了應對一系列全面預算削減。歐空局指定了非常嚴格的軟體測試程式，旨在發現導致501 號航班墜毀的那類問題，但它們沒有被遵守。就像挑戰者號災難一樣，冒險行為逐漸成為常態。

當工程師測試阿里安 5 號軟體包時，成本是他們決策中的一個重要因素。工程師有兩個選擇

1. 進行一次完整的模擬發射，同時測試所有軟體。
2. 進行一些獨立的測試，只測試軟體子系統。

該團隊選擇了第二種方案，因為它比第一種方案便宜得多。由於軟體是獨立測試的，導致501 號航班失敗的故障沒有被發現。

削減成本促使在阿里安 5 號的軟體設計中使用了有風險的測試程式。事故發生後，調查委員會的分析顯示，該軟體包的主要元件充滿了被忽視的錯誤。由於軟體代表了一個單點故障，冗餘系統難以實現，因此透過測試盡職盡責尤為重要。阿里安 5 號軟體工程師未能盡職盡責。

未來

歐洲調查委員會調查了這場災難，並對如何防止災難提出了一些建議。在調查委員會提出的 14 項建議中，特別是第 12 至 14 項建議，指的是流程中的缺陷或故障。這三項建議說明了飛行是如何失敗的，以及如何防止未來發生類似的失敗。

• 建議 12：“對證明文件的重視程度與程式碼相同。改進保持程式碼及其證明一致的技術。”
• 建議 13：“成立一個團隊，制定軟體資格認證程式，提出嚴格的確認資格認證的規則，並確保阿里安 5 號專案的軟體規範、驗證和測試始終保持高質量。應考慮包括外部RAMS專家。”
• 建議 14：“必須考慮更透明地組織阿里安 5 號專案合作伙伴之間的合作。需要進行緊密的工程合作，明確的許可權和責任，以實現系統協調，合作伙伴之間擁有簡單明瞭的介面。”

展望未來，這三項建議將有助於促進更加協調、清晰和專業的合作環境，以減輕未來的混亂。

概括

從阿里安 5 號501 號航班災難中吸取的教訓可以推廣到其他案例。首先，即使是最小的細節也至關重要，並可能產生巨大的後果。64 位浮點數的轉換錯誤導致了價值數百萬美元的巨大航天器的爆炸。在許多系統中，小細節與大細節一樣重要。

其次，除了測試系統應該做什麼，還應該測試系統不應該做什麼。如果系統測試了浮點數轉換失敗的情況，那麼導致爆炸的錯誤本可以被發現。測試不應該發生的情況可以提高可靠性。

第三，許可權和責任應該明確。沒有人對導致501 號航班爆炸的錯誤負責。當沒有人對故障負責時，更難找到問題，也更難避免未來出現問題。當團隊成員之間的職責明確時，更容易發現問題，溝通和合作也會得到改善。

第四，不要設計一個系統，其中單個元件故障會導致整個系統故障 - 單點故障。對於航班 501，軟體錯誤不僅導致SRI（一個軟體系統）故障，還導致了整個航天器的爆炸。一個系統中一個故障不會導致整個系統崩潰，這樣更可靠也更安全。