NASA 有幾次任務失敗是因為程序里的 bug?

11-28

目前嚴重的幾次事故，都不是軟體Bug導致的，但可以認為是程序出現了問題：

阿波羅1號起火，3名宇航員罹難。純氧環境下火花導致的火災
挑戰者號升空後解體，7名宇航員罹難，O型密封環失效
阿波羅登月艙氧氣罐爆炸，宇航員安全返回。
哥倫比亞號返回時解體，7名宇航員罹難，升空時，機翼被泡沫海綿擊中導致返回時被高溫溶化解體。

例如在挑戰者號升空前，如果按照程序對低溫下的O型密封環進行再次檢查，則事故可能就不會發生。阿波羅1號的成員擔心被炒，而不對電線質量發表意見。哥倫比亞號升空後，地面基層人員報告有海綿脫落撞擊到機翼。但高層的傲慢與無視，導致7名宇航員罹難。如果採納基層建議，動用空軍的設備國際空間站的相機，進行掃描，則很可能不會發生事故。

贊同馮東的回答。任務失敗是多方面的，具體問題要具體分析。任務失敗是否由程序Bug導致，需要等待詳細的調查結果。比如哈勃太空望遠鏡剛開始的「近視」問題，是由於地面程序出現Bug，在檢測鏡面時忘記考慮地球引力的因素。再者好奇號登陸火星，use case考慮非常全面，但飛往火星需要8.5個月。途中好奇號遇到宇宙隕石撞擊怎麼辦？如果use case中包含隕石的檢測，而好奇號又不幸撞擊到了，則可以稱之為程序的Bug，否則則不能怪之。程序在先，Bug在後。

Bug 之所以造成危害，是因為沒有冗餘，以及測試無法覆蓋所有 use case。個人系統，為了把硬體投入的收益推向極致，完全沒有冗餘。Use case 方面，商業軟體都是提出一組操作原語，允許用戶自由組合。但是 NASA 不同。首先，它的系統預算里必須有冗餘；其次，它對 use case 的限制是很大的，這是其它商業軟體不能比的。NASA 的 use case 是設計為 mission，只允許有限的預定操作序列。在這樣的系統里，任何一次失敗都不能歸結為普通意義上的軟體 bug。

純軟體炸的好像就一個阿利亞納5，歐洲的

早期的運載火箭系統，由於受到當時技術條件的限制，其各個分系統的可靠性指標是及其低的。（最主要是基礎理論還存在未突破的問題）譬如重要的分系統的冗餘技術及可靠性設計建立數學模型等諸多理論問題。如要展開此題，實在太大了。搞科研的如果不踏踏實實做好每一步工作，其後果可想而知。後幾次發射失敗筆者認為有很大程度上歸結為系統的可靠性問題。其工作理論上是沒問題。

國際太空2004 年5 月號刊登了一篇題為《1990 2001 年航天器制導導航與控制系統故障分析研究》，文章收集整理1990-2001 年全世界主要國家，即美國，歐洲，日本和加拿大成功發射的764 個航天器（這764 個航天器都是發射成功後在軌運行的航天器，不包括運載火箭和上面級火箭，同時也不包括載人航天器）的GNC系統所發生故障的記錄材料。在成功發射的764 個航天器中，總共有121 個出現故障，其中GNC系統故障35個。
現在開始說重點，姑且認為火箭的軟體集中在GNC系統內，其中軟體錯誤造成的故障有5個，就是七分之一，只能說軟體故障還是比較多的。

除了軟體的BUG佔了少部分外，主要還是以設備的缺陷居多而造成任務失敗：
http://w.hudong.com/b04c608b8b9a470d899dd826648dec8b.html盤點NASA的十次失誤