原文地址：英文版地址，作者作者Jake Edge，發表於2013年3月6日。
文中灰色背景的是我的一些不成熟的看法，部分數據和資料來源於網絡和相關論文，由於是非正式發表，也就不標註來源了，有興趣的朋友可以自行查證，歡迎留言討論。
在2013年嵌入式Linux大會的第二天，SpaceX的羅伯特·羅斯（Robert Rose）談到了“從經驗中學到的航天器開發軟件”。在演講中，他討論了SpaceX如何開發其基於Linux的軟件，以完成將航天器送入軌道甚至最終超越軌道所需的各種任務。他說，Linux在SpaceX上無處不在，從臺式機到航天器，應有盡有。
Rose是SpaceX航空電子飛行軟件團隊的負責人。他曾是一名視頻遊戲程序員，並說從這項工作中獲得的一些教訓對他目前的工作很有價值。他於1994年通過Slackware開始使用Linux。
作爲一家公司，SpaceX堅信要使人類成爲多行星物種。他說，火星殖民地是目標，但要到達那裏，就需要火箭和宇宙飛船。目前發射航天器很昂貴，因此有必要“降低成本”以達到目標。
這裏說明了SpaceX的公司願景，並將公司願景通過分解，讓程序員瞭解到了公司願景，公司願景通過分解落實到的部門願景，以及和每個人工作的聯繫。很多偉大的公司都設立了很明確的公司願景，並將每一個員工的工作與公司願景相連接，從而增強員工的歸屬感和責任感。
Rose說，該公司遵循可重用性的理念，這有助於降低成本。航天飛機計劃已經對此進行了一定程度的嘗試，但是SpaceX對此進行了進一步的研究。不僅硬件組件可以在不同的航天器之間重複使用，而且軟件也可以共享。該公司在自己的工廠從頭開始製造火箭，而不是外包各種碎片。這樣可以更緊密，更頻繁地進行硬件-軟件集成。
複用的重要性，複用的前提是在總體設計中充分的解耦，將總體分解成一個一個的模塊，並對模塊進行充分的測試與評估，並制定完整準確的模塊使用說明，才能讓模塊真正成爲資產。這一點其實非常難以達到，一方面需要總體設計人員的水平很高，這樣才能充分的解耦；另一方面還需要對模塊資產有充分的掌握，才能在總體設計中充分利用現有資源；此外，還需要員工有較高的學習熱情，才能在最終實現中利用模塊而不是重新造輪子。
Rose在SpaceX的早期發現很難適應的一件事是該公司對“最終目標”的關注。在做出決定時，人們經常會提出來：“這對火星任務有用嗎？” 在做出決定時總是要考慮這個問題。他說，火星並不總是贏家，但是人們總是會檢查這種擔憂。
資源和員工精力的集中能極大的提升效率，這一點在敏捷的Scrum方法中也被作爲重點進行說明。管理學中的一些統計數據也表明，即使是隻佔員工精力和時間不足10%的瑣碎工作，也會造成至少30%以上的工作效率損失。（個人認爲這一點在編程工作中損失更大，可能會在50%以上，而且增加出現Bug的機率）。
挑戰性
公司面臨的一些挑戰是極端的，因爲涉及人員和財產安全。飛船是危險的飛行器，例如，如果其燃料爆炸，可能會造成嚴重損害。沒有“撤銷”，沒有第二次機會把事情做好。一旦火箭發射“它就飛走了”。在開始從事該行業之前，他沒有遇到的另一個問題是太空輻射的影響，這種輻射會“隨機翻轉”位，這是系統設計需要考慮的問題。
看過另一篇報道說明了SpaceX是如何通過多個商用CPU共同運算，因爲被隨即反轉的CPU（內存數據）畢竟是少數，因此可以通過設置多個CPU共同運算，少數服從多數的選擇方法實現系統的可靠性。畢竟航天級器件幾片芯片的價錢，普通的CPU能買一車了。但是需要注意的是，這些協同處理也是需要底層程序的支持的。
羅斯說，SpaceX與其他行業共同面臨的挑戰要少一些。例如，處理專有硬件和與開發平臺不同的目標平臺是嵌入式Linux面臨的挑戰。另外，SpaceX團隊不得不面對一個普遍的問題，即“軟件之外的任何人都不瞭解軟件”。
Linux並不是SpaceX在龍式上唯一採用的軟件系統，其飛船平臺上採用的是Linux，編程語言是C和C++。他們針對自己的研發過程，專門寫了一套自己的研發管理系統，主要用到了C#（windows?)/MVC4/EF/SQL/Javascript/Knockout/Handlebars/LESS/REST API。地面系統由於可靠性要求相對不高，因此採用了LabView。（我一直認爲LabView是兒童玩具而拒絕在工程中使用，僅在實驗系統中用於系統原型搭建，看來是小看LabView了）他們還有一套自己的航電測試團隊和硬件工程師一起完成測試。其人數最多的是飛船上的軟件開發人員，有35人，地面團隊只有9人（2013年的人數，這個開發效率和能力嚇死我了）。
SpaceX從Falcon火箭開始，最終將航空電子代碼轉換爲Dragon飛船。共享代碼的明顯優勢是，在一個平臺上修復的錯誤會在另一個平臺上自動修復。但是，對運載火箭和航天器的軟件要求有所不同，很大程度上與可用的不同反應時間有關。只要航天器不在國際空間站（ISS）的250米以內，就可能需要一些時間來解決任何問題。對於火箭來說，這種奢侈是無法獲得的。它必須在短時間內做出反應。
我認爲，需要注意的是，共享代碼庫需要有良好的質量控制，否則可能帶來很大的質量隱患，特別是在後期，型號增多，模塊增多，維護會越來越困難。這方面的資料還沒有收集到，不知道他們是怎樣管理的。
誤報是一個需要考慮的問題。羅斯提到了水星6號任務（美國首次載人軌道飛行）的隔熱屏指示器，該指示器表明隔熱屏已分離。美國宇航局試圖找到一種沒有隔熱罩的再次進入的方法，但“最終還是成功了”。事實證明這是一個誤報。同樣，運載火箭和航天器的可反應時間不同。
收集數據
羅斯 引用弗雷德·布魯克斯（Fred Brooks，《神話人月》的成名作），稱“軟件是隱形的”。他說，要使軟件更清晰可見，您需要知道它在做什麼，這意味着在“您能想到的一切上創建度量”。對於火箭，您不能僅通過JTAG進行連接並“啓動gdb”，因此該軟件需要跟蹤其運行情況。這些指標應涵蓋性能，網絡利用率，CPU負載等領域。
他說，無論是從測試還是在實際使用中收集的指標，都應該存儲起來，因爲它“非常有價值”，可以追溯到它們。對於他的系統，遙測數據與程序度量標準一起存儲，所有正在運行的代碼的版本也是如此，以便在需要時可以重現所有內容。
我所見到的系統大多數也有收集，但很少有設計的這麼細的，我覺得這一點值得所有系統設計人員考慮借鑑。當然，應該輔以歷史回放與分析工具。我覺得這也是該公司能夠快速發現問題並進行迭代的基礎之一。
SpaceX的程序可以解析度量標準數據，並在“情況惡化”時發出警報。Rose說，實現這一點很重要，因爲強迫一個人這樣做“會很爛”。無論是從開發人員的測試，從航天器的運行還是從任務生成的數據，這些程序都可以運行相同的程序。任何失敗都應被視爲添加新指標的機會。這樣做需要一段時間才能“融入節奏”，但“非常有用”。他喜歡使用libSegFault和ftrace之類的工具“監視錯誤報告”。
Rose說，自動化很重要，持續集成“非常有價值”。他建議始終爲每個平臺構建，甚至爲“您不再使用的東西”構建。SpaceX做到了這一點，並且在構建未使用的代碼時發現了有趣的問題。每當代碼更改時，單元測試就從連續集成系統運行。他開玩笑說：“這裏的每個人都有100％的單元測試覆蓋率”，但是運行任何可用的測試並創建新的測試都是有用的。當他從事電子遊戲時，他們進行了一項測試，可以將角色“扭曲”到某個水平的隨機位置，並使其在四個方向上觀察，這通常會發現問題。
他說：“實現流程自動化”。應該自動完成諸如編碼標準，靜態分析，空格與製表符或檢測Emacs之類的事情。SpaceX的過程很複雜，沒有票證，代碼審查，簽收等操作就無法進行更改，但是所有這些操作都會自動檢查。如果靜態分析是工作流的一部分，請確保靜態分析不會生成，除非該代碼通過了該分析步驟。
自動化很重要，持續集成很重要，自動化測試也很重要，自動化的流程管理與控制也很重要。這一點前段時間CMMI專家叢斌博士在線上答疑的時候也着重強調過，國內在這一塊做的還很差，涉及多方面的原因，這裏不做過多闡述了。
當構建失敗時，它應該“大聲地失敗”，並帶有“開始閃爍紅色的監視器”，並通過電子郵件發送給團隊中的每個人。發生這種情況時，您應該“立即響應”以解決問題。在他的團隊中，他們有一個全尺寸的賈斯汀·比伯（Justin Bieber）摳圖，放置在面對破壞構造的團隊成員面前。他們發現“ 100％的軟件工程師不喜歡Justin Bieber”，他們將迅速解決構建問題。
構建失敗的措施，這一點應該是源自於豐田的生產線管理中的質量控制措施。justin照片這個方法不錯，不過估計放一張justin的照片效果不好，他太帥，在國內，可以考慮放一張如花或者喬碧螺的大幅照片。
項目管理
在向經理過渡的過程中，羅斯不得不學會擔心與以往不同的事情。他指出了“ 每個程序員都應該知道的97件事 ”中的“ 使看不見的東西更加可見 ”一文，將其作爲靈感的來源。對於硬件，很明顯它的集成狀態是什麼，因爲您可以查看並看到它，但是對於軟件而言並非如此。沒有“軟件開發沒有進度條”。這導致他的團隊嘗試使用不同的方法來嘗試進行項目規劃。
各種“現成的”項目管理方法和方法估計項目將花費多長時間對於他的團隊來說是行不通的。Rose說，設置適合您的人員和任務集的內容非常重要。他們嘗試了各種技術來估算時間需求，從寬帶delphi到基於證據的調度並發現沒有一種技術本身可以很好地適用於該小組。他說，由於他們是軟件工程師，因此“我們編寫了自己的工具”，這是幾種不同技術的混合。沒有用於計劃的“靈丹妙藥”，而且“不太可能您採用我們的方法並將其應用”到您的域。他學到的一個難聽的教訓是，一旦您使用一種特定的調度方法取得了成功，您就“需要完成銷售工作”以向工程師展示它的工作原理。下次，它將使它變得更好，因爲會有更多的支持。
軟件的計劃制定與管理，在國內外都是個難題。每日站會和看板，能夠讓計劃的追蹤有依據，其數據可以作爲計劃調整的輸入，從而實現計劃的動態調整。我相信SpaceX也是應該這樣做的。（如果誰有相關參考資料，麻煩賜教啊）
一些技術細節
在SpaceX，Linux用於所有事物。Falcon，Dragon和Grasshopper車輛使用它進行飛行控制，地面站運行Linux，開發人員的桌面也使用Linux。他說，SpaceX是“ Linux，Linux，Linux”。
羅斯繼續簡要描述了Dragon飛行系統，儘管他說他不能提供太多細節。它是一個容錯系統，可以滿足NASA接近ISS的要求。關於規則，即航空器需要能夠容忍多少故障並仍允許其接近該站點，存在一些規則。它使用三重冗餘計算機來達到所需的容錯級別。當三個計算機數據不一致時，將採用拜占庭將軍的算法（ Byzantine generals’ algorithm）來處理。例如，可能由於輻射事件更改內存或寄存器值而發生這種情況。
對於導航，Dragon使用從ISS接收到的位置信息以及它自己計算的GPS數據。當它接近站點時，它使用ISS的圖像和站點的相對大小來計算到站點的距離。由於可能處於黑暗中，Dragon使用了熱成像技術，因爲測站的溫度略高於背景溫度。
他的團隊不使用“現成的發行版內核”。相反，他們花費大量時間評估內核的需求。他們關注的領域之一是調度程序性能。他說，它們沒有嚴格的實時要求，但確實關心喚醒延遲。他們使用一些測試來量化調度程序在不同情況下的性能，例如在對網絡施加壓力的情況下。一旦選擇了內核，“我們將盡量不對其進行更改”。
這也就是爲什麼採用匪夷所思的非實時操作系統Linux，而不是實時操作系統VxWorks或者其他航天用的系統。因爲即使是非實時的系統，其相關時延參數也基本摸透了。而且我相信，在實時性要求很高的情況下，很有可能採用了針對硬件的底層操作。關於這一點，我想如果沒有很高的設計能力，最好不要這樣做，因爲這樣設計如果沒有強大的技術實力，其風險其實很高。就如濟公大師所說的：“酒肉穿腸過，佛祖心中留。世人若學我，如同進魔道。”
羅斯說，他們使用的開發工具“極爲複雜”。他們使用GCC和gdb，而在編輯器和開發環境方面“每個人都做自己的事”。開發始終以Linux爲目標，但開發人員並不總是以其爲臺式機，因此他們還開發了許多基於POSIX的工具。切換到Linux桌面的主要原因是“開箱即用”的開發工具，例如ftrace，gdb（可以直接連接到調試目標平臺），netfilter和iptables。
Rose爲大型和複雜的嵌入式Linux環境的軟件開發提供了有趣的觀點。此外，他的演講比我們之前介紹的SpaceX演講更爲公開，很高興看到。該公司使用的許多技術對於大多數程序員來說都是熟悉的，這清楚地表明，爲航天器創建代碼的過程並非完全是火箭科學。