題:
火箭科學家如何進行迭代開發？
TheEnvironmentalist
2018-04-05 11:50:31 UTC
view on stackexchange narkive permalink

在軟件中，開發任何東西的一般過程是代碼，測試，修復，重複。這是容易且便宜的，因為運行程序通常花費很少的金錢。

在火箭科學中，情況有所不同。每次發射都可能耗資數千萬甚至數億美元，並且比例模型通常具有不同的流量和性能屬性，從而降低了其實用性。

鑑於這些限制，火箭科學家進行迭代開發的過程是什麼？

啟動一個災難性的軟件開發項目的第一步是相信開發既簡單又便宜。在火箭科學中，發射前要進行地面測試。
好吧，有[this]（https://www.youtube.com/watch?v=bvim4rsNHkQ）。
最佳SE網站的“ +1”顯然可以迭代選擇！
如果一開始您沒有成功，請再次嘗試，嘗試，嘗試，嘗試，嘗試（etc）... https://www.youtube.com/watch?v=13qeX98tAS8
@Richard我以為您要鏈接一個E.P鏈接。相反，我還要注意，它們還使用https://kerbalspaceprogram.com/的“成人版” *，它也為迭代開發提供了很多機會。 _ *我指的是真正的工程仿真軟件，而不是遊戲_
除非軟件運行需要花費數月時間並花費數百萬美元的電費，否則...
“建造一個炸藥。反正你要去...” :-)
如果在超級計算機上運行的軟件需要花費數月的時間，則其硬件使用成本也很高。
如果安裝正確，火箭軟件非常昂貴。根據https://www.fastcompany.com/28121/they-write-right-stuff的說法，該團隊的負責人在每次航天飛機發射前都飛了出來，以表明該軟件不會傷害機組人員。只有通過非常謹慎地工作才能獲得這種信任-這使每行代碼都非常昂貴！
直到阿波羅11號，我們才登陸月球。
@corsiKa:看看美國在成功發射第一顆成功衛星之前炸毀火箭的次數。蘇聯也炸毀了很多，包括R-16和幾個土星V等效的N1。而且SpaceX已經炸毀了至少一個...
現在，SpaceX可以使火箭著陸了，他們就有機會將它們拆開並向二手發動機學習。
@Harabeck:但是，成功降落SpaceX之前，SpaceX崩潰了多少？
馬斯克（Elon Musk）有句著名的話：“只要每個人*因為不同的原因而炸毀*，我們就會取得進步。”
作為軟件開發人員，我不喜歡您的軟件開發形象。火箭發射等同於實時發佈軟件。而且，我們不只是抓住所有被黑客入侵的程序員，然後將其傾銷到生產中。那太瘋狂了。取而代之的是，我們擁有使軟件經受連續複雜（自動化）測試的測試環境，並且在真正部署代碼之前，我們將部署過程重複應用於越來越多的“類似於生產”的環境中。當您這樣看時，軟件和火箭開發之間並沒有太大區別。
...用他們的手指按中止按鈕。 [正確的東西：發射失敗]（https://youtu.be/Te_3gfOoh8c?t=15）
@Euphoric好吧，海事組織（IMO）您對一般軟件開發的看法過於樂觀。並非每個軟件都通過了與太空探索中使用的HW + SW組合相當的測試程度（就此而言，甚至是汽車）。購買汽車固件時，您無需簽署EULA。汽車的儀表板上沒有包含“原樣出售此硬件”的免責聲明！我希望太空飛船也是一樣。 :-)
五 答案:
Hobbes
2018-04-05 13:20:03 UTC
view on stackexchange narkive permalink

軟件開發必須是迭代的，因為很難數學上證明給定的軟件將按預期工作。

對於物理對象，情況並非如此。使用現代的CAD軟件，您可以設計零件，並確保設計會按預期工作。因此，在製造第一部分之前可以進行很多測試。

那是說，火箭的研發仍需進行許多物理測試，尤其是在較複雜的零件上。

  • 發動機（或發動機零件）在發動機試驗台上進行測試
  • 結構零件進行結構測試
  • 電子產品進行環境測試（溫度和電壓），電磁兼容性和振動測試
  • 整個階段都可以在大型測試台上進行測試

尤其是在火箭上進行了迭代開發。在早期。

  • V-2進行了數百次的測試發射，其中許多以火球結尾。
  • 對N-1火箭進行了迭代測試。第一階段是如此之大，建造一個試驗台，因為它將使該計劃延遲到一定會失去太空競賽的地步，所以蘇聯決定改為進行一系列試驗發射。在最初的幾次試飛中，使用了上層樣板文章，隨著測試的進行，增加了試飛硬件。計劃進行14次測試。只進行了4次，最後一次發射幾乎使它在第一階段完全燃燒。
  • 用於土星V一級發動機的F-1發動機存在燃燒不穩定性的問題。由於不穩定性的原因尚不清楚，因此使用不同的配置進行了許多測試觸發，試圖消除不穩定性。
“很多都以火球結尾”-啊，我們在IT中稱之為媒體錯誤。
當然，V-2也使用了發動機試驗台，請參見]（https://en.wikipedia.org/wiki/Test_Stand_VII）。
“對Mittelwerk製造的火箭進行的首次測試在點火後三秒鐘引爆，沒有升空：“我們吹了一百萬個標記，以便猜測可能價值相當於小型摩托車價格的儀器所能準確報告的內容。”（HartmutKütchen，負責測試台VII的工程師）[5]“是的，我可以稱其為迭代開發
如果他們可以模擬核爆炸，那麼他們可能也可以模擬火箭。
-1
@ThorbjørnRavnAndersen從理論上講，理論與實踐之間沒有區別。實際上，有。
請注意（根據Wikipedia：https：//en.wikipedia.org/wiki/N1_（rocket）#Launch_history），這四個N-1都沒有成功飛行。
“因為很難以數學方式證明給定的軟件將按預期運行，所以這是很難的。”與在現實世界中操作的硬件相比，證明軟件的正確性要容易得多。仍然很容易迭代。
@Russell Borogove:我不同意。除非在某些特殊情況下，否則很難以數學方式證明軟件的正確性，因為不可能提出“正確”的數學定義。
除了“證明”和“正確”的語義外，確定軟件正確性的難易程度肯定取決於應用程序領域和復雜性。驗證簡單的數學函數能否正確運行並不難，但要證明某種圖像識別算法或地理分佈的數據存儲解決方案是正確的可能並不困難。軟件採用多種形式。
如果我們有Kerbal太空計劃，我想某個地方的某人必須有一個* fancier *模擬器...
>很難甚至不可能以數學方式證明給定的軟件可以按預期工作。也許很難，但絕對不是不可能。參見：https://github.com/seL4/l4v，https://github.com/leanprover/lean
@ElectricHead對於機械組件也是如此。容易驗證，例如，物體的質量是否在給定範圍內，但是證明（！）組件在像火箭發射這樣複雜的環境中不會破裂也同樣困難。
我不太相信物理對象的行為是確定性的。湍流動力學（與火箭發動機非常相關）仍然很難激發。同時，我不同意這個答案的前提，即“軟件開發必須是迭代的”，我更喜歡@BertHaddad's答案引用離線測試。
@koalo是的，絕對如此。我無意無意暗示物理領域中的系統也不適用-值得明確指出。
@craq嗯，[不是]確定性可能不是我要使用的詞，是的-當軟件既是系統又是系統的一部分時，關於軟件比物理更簡單或反之亦然的說法並沒有真正意義。設計方法是否迭代（所有設計方法基本上都是對不重要的事物進行迭代……）與軟件與物理的內在關係無關，而與系統複雜性無關。
Electric Head
2018-04-05 19:03:40 UTC
view on stackexchange narkive permalink

首先，“火箭科學”是一個誤導性術語。火箭是一種推進系統，在大型系統（如運載火箭，航天器，導彈系統等）中發揮作用。對這些複雜的系統進行工程設計是一個整體的，多學科的過程。 b>

系統工程和現代軟件開發實踐類似，儘管它們有些不同，但它可以追溯到1930年代。 em>獨立進化。 IT和軟件工程界熟悉的設計過程模型（例如Waterfall和Vee）發揮了作用，而並行工程（Concurrent Engineering）等方法與敏捷軟件開發實踐有很多共通之處，並且需要反復進行。參見 ESA對並行工程的描述作為示例。

整個系統生命週期中迭代的特定性質將取決於項目，誰來做，誰來付錢。生命週期的階段是什麼，但是“設計，測試，修復”範式並沒有太大的區別（儘管暗示，規模可能不同）。

數學模型，仿真和設計模式對於降低成本非常重要，尤其是在早期設計階段。可以根據規範開發和驗證組件和子系統，並通過其他測試中涵蓋的地面測試來測試集成。在某些方面，可以說組件的物理性質比軟件[系統]的抽象性質更易於量化和根據規范進行驗證，但是-如所指出的-在物理上進行工程設計存在其他困難和成本

軟件工程是一門相對較年輕的學科，隨著它的成熟（軟件系統變得越來越複雜），會出現相當程度的融合，但是工程是工程學。

建議以供進一步閱讀：

我建議使用Kelly的_Moon Lander_而不是SEBoK。湯姆·凱利（Tom Kelly）描述了他如何運行格魯曼計劃以開發現代SE初期的Apollo LEM，這是一本很好的書。更深入地講，我會去看莫里斯的《項目管理》，該書涵蓋的內容不僅僅包括SE，而且還介紹了PM。
謝謝;建議深表感謝！我隨意添加它們。我之所以提到SEBoK和SWEBoK，是因為它們是自然地說明相似性/融合性的資源，而不是因為它們特別引人入勝......）
motosubatsu
2018-04-05 12:47:16 UTC
view on stackexchange narkive permalink

火箭的大多數部件都可以在地面上單獨進行測試。這是例如用於SLS的RS-25發動機的測試示例。因此，大部分的迭代開發都是使用這樣的測試完成的。

第二階段的發動機可以在地面上進行測試。但是很難在真空測試室內測試強大的火箭發動機。在阿波羅6號發現的土星V的第二階段，存在燃油管路破裂的問題。在發動機在大氣中工作的地面測試中，該問題並未顯示。
Tristan
2018-04-05 18:52:27 UTC
view on stackexchange narkive permalink

簡短的答案是，迭代主要通過分析（行業術語是DAC和VAC，用於設計分析週期和驗證分析週期）進行，並在必要時進行小規模開發測試（例如單元測試），在開發項目快要結束時進行一系列的資格測試（即集成測試）。

Bert Haddad
2018-04-06 05:29:36 UTC
view on stackexchange narkive permalink

事實上，火箭上的航空電子設備/軟件（最容易發生故障的位之一）可以像軟件一樣反復進行測試。 SpaceX的Falcon 9的所有接線/計算機都在工廠佈置。然後，他們為這些組件提供語音輸入，並查看代碼如何響應。這種類型的模擬對於測試新的創新（例如可重複使用的火箭）非常有用。

許多（如果不是最多的話）火箭和飛船的問題都與軟件有關。火星探測器墜毀是因為有人忘記了將英尺轉換為米，而阿麗亞娜火箭炸毀了是因為速度太快，以至於速度值出現整數溢出，導致火箭認為它正在向後移動（與

我知道問題主要是關於物理物質，通常是像霍布斯在回答中所說的那樣在測試台上進行測試。不過，請記住，現代火箭與硬件一樣多。

有趣的是，值得指出的是，這些軟件問題又可以[顯著歸因於]團隊之間的溝通問題和流程不充分的問題（http://hdl.handle.net/2014/33742）。
一些相關的關鍵字：軟件在環和硬件在環測試。當然，還有廣泛的持續集成套件，這些套件現在已成為所有領域軟件開發的關鍵部分。


ⓘ
該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到，我們感謝它分發的cc by-sa 3.0許可。
Loading...