引

言

本文是美國噴氣推進實驗室就MBSE技術在火星2020項目的應用階段總結性論文，論文給出了使用MBSE的最初動因、遇到的問題、實踐過程中的經驗和目前的困境。該論文可為MBSE在系統工程應用的定位帶來一些客觀的思考。

本文為知元公司根據原文翻譯整理，鑒于專業能力，翻譯中難免存在錯誤或理解歧義，請參考使用。

摘要

噴氣推進實驗室（JPL）好奇號火星探測任務的成功，促使美國宇航局支持Mars2020火星探測實驗室建造第二個火星車（毅力號）。Mars2020選擇引入基于模型的系統工程（MBSE）來協助設計飛行系統。本文將介紹在Mars2020項目中引入MBSE的動機，并將解釋Mars2020飛行系統模型的當前狀態。此外還將討論MBSE方法的局限性。

1引言

2012年8月6日，噴氣推進實驗室（JPL）火星探測器科學實驗（MSL），的好奇號探測器成功登陸火星表面，開始了它的地質和環境研究，尋找火星上過去存在生命環境的證據，這些環境非常適合支持微生物的生命。飛行器著陸方式設計為自主式，飛行器在火星大氣層中自動轉向，展開降落傘，并采用了一種空中起重機方式，把直立的火星探測器漫游者用繩子拉下來，讓它的輪子在火星上著陸。在不到一年的時間里這次令人驚奇的著陸方式，好奇號已經達到了它的主要科學目標，并繼續在火星巖石中鉆取樣品，通過分析儀器內的車載試驗室分析樣品的化學成分。

MSL的成功促使美國宇航局向噴氣推進實驗室提出新的挑戰，要求它建造第二個火星車，要求價格僅為原計劃的一小部分。這項新任務命名為Mars2020，要求繼承MSL的大部分飛行系統（FS）設計，但有新設計的科學儀器用來尋找火星上過去生命的跡象。此外，該探測器將收集和儲存一套土壤和巖石樣本，這些樣本將會返回地球，這次任務還將測試新的土壤和巖石樣本有利于未來機器人和人類探索火星的技術。 Mars2020必須最大限度地利用MSL的成果，以滿足項目的成本要求，包括早期購買的傳統硬件的再次使用，重復使用MSL的軟件等。

在Mars2020開發的早期，發現在獲取MSL項目已有數據方面存在的問題。MSL項目整個研制過程技術基線是使用“盒子學”管理的，技術都是以幻燈片和視圖方式記錄、存儲，缺乏嚴謹性或共同的術語，并經常存在多個版本的時效問題。系統工程設計文檔，如系統塊圖表和電氣互連清單，最新的配置單等重要資料的獲取非常可困難。此外，MSL兩年的發射周期存在重大的人為因素和人員不連續性，導致很難把從項目開始到結束所有的數據資料都恢復過來。遇到這些困難后，飛行系統工程（FSSE）團隊提出了Mars2020綜合技術基線的工作目標，該團隊希望提供一個權威的飛行系統信息源，整個項目都可以很容易地訪問它，從而消除信息孤島的危險，提高系統的可用性、技術基線變更的可見性和可追溯性。

    Mars2020 飛行系統工程團隊選擇利用MBSE的先進技術來更好地解決上述問題。本文將進一步闡述MSL 系統工程方面的經驗教訓和M2020 飛行系統工程團隊的目的，以解釋基于飛行系統模型的系統工程（FSMBSE）方法。將MSL信息作為飛行信息并填充飛行系統設計模型（FSDM）的過程，討論并舉例說明項目正在使用的模型生成產品的當前能力。

2從MSL到Mars2020

在MSL工作的Mars2020 飛行系統工程團隊成員開始了一個總結經驗的過程，最終了列出Mars2020項目希望改進的系統工程挑戰：

（1）“盒子”模式的技術基線：技術基線是用無關聯的視圖創建生成的，技術基線無法用來解釋技術之間的內聚；一個演示文稿中的矩形也可以用線條代替表達，沒有人能解釋兩者的區別；各種數據表格使問題更加復雜；缺乏綜合術語的技術基線容易理解混淆。各種技術文件/表格的解釋權留給使用者導致開發后期發現設計問題的風險增加。

（2）信息孤島：需要一個龐大的團隊來管理航天器的復雜性。團隊成員在本地管理信息，然后定期向管理層和其他團隊成員。數據存儲在個人手里的現狀的導致了團隊成員之間需要花費較大的代價對信息的可用性進行知識交流。雖然有共享的數據庫，但信息的實效性一直是一個問題。因此不得不采用通過電子郵件聯系信息所有者以獲得最新的數據。共享數據庫在描述航天器設計時缺乏一致性，消耗大量的時間和精力來協調信息不一致、團隊成員互相向對方解釋自己的數據。

（3）人員/工作不連續性：MSL在2008年經歷了一次發射失敗，因此在項目組工作的部分人員過渡到其他的項目。導致了集體知識的喪失。MSL開始重新安排員工，在理解完成的工作、還有什么工作要做上存在很大的不連續性，技術文檔記錄的正確性和不連續性導致了項目風險。

（4）并行工程：隨著航天器設計的復雜度提高，很多工作很難量化。這一困難部分歸因于航天器各個系統設計的成熟度各不相同，很難執行并行協作和并行工程。

（5）產品一致性和相關性：通常情況下，系統工程所關注的工作與需要交付的產品并不一致。管理分歧、審查工作經常導致團隊不得不定期停止或減少其工程的研制工作，花很多精力手工創建必要的表格、圖表和圖表。而在發射前的幾個月里，項目的重點又成了測試和發射航天器，而沒有人再關注技術狀態是否被記錄在文件和表格里。

值得注意的是，Mars2020/MSL 系統工程的挑戰并非這個項目所獨有。系統工程界對當前使用的系統工程流程和方法來管理跨學科、信息和技術高度復雜的項目感到悲觀。基于這些經驗教訓，Mars2020 飛行系統工程團隊旨在解決在飛行系統工程技術基線方面減少與此相關的各種障礙。技術基線一個方面要解決的是準確捕捉探測器設計和產品的制造，兩者在性能方面都應是一致的信息內容和布局。另一個方面要解決的是改善溝通、理解和可見性，通過提供一個權威的信息來源來改善整個團隊都可以訪問的信息（從而減少信息孤島并減少人員不連續性造成的信息缺失），以及通過定義一種通用語言來描述飛行系統。

Mars2020 飛行系統工程團隊新的技術基線技術的目標是采用系統建模語言（SysML）來表達FS設計中的信息模型、包括模型創建和維護。最初的重點是對MSL遺留設計變化的支持。Mars2020 FS由巡航級、下降級和巡航級組成，火星車是FS的主要組成部分，它與MSL傳統設計不同，原因是要適應新的科學儀器和樣品緩存系統，這導致火星車成為MBSE初期工作的主要應用重點。

3 Mars2020 建模框架

MSL的大多數設計工作都是在非集成的表格視圖中開展的，因此，對于FSDM的創建來說希望有一個共同的語言來描述系統，更重要的是對設計意圖信息的表達理解。Mars2020建模框架定義了模型元素以及它們之間的關聯關系表達要素。該框架擴展了一個通用的SysML，并嵌入系統工程4.0以及JPL特定的框架中，術語的規定按照Mars2020經常熟悉和具體的術語為基準。從2020年3月建模框架開始研發，它可以擴展以滿足項目生命周期的需求進展。框架的當前內容專注于支持飛行系統工程期間需要交付的產品，隨著設計的成熟和產品從權衡研究、基線轉換將設計識別轉化為分析驗證，框架也將發生擴展。

抽象符號是用于描述Mars2020物理飛行系統的主要組件。它允許在設計時定義無需更多信息（例如零件編號或采購規格）的情況下定義一個物理對象。這對模型的創建提供了極大的便利，團隊可以用抽象符號來表達各種組件。因此，框架將抽象符號定義為表達模型的主對象。該框架允許抽象符號之間以兩種方式相互關聯：一是它們在航天器上的物理組成以及它們的電氣連接。二是可以通過其各自的質量和MSL傳統使用的關系來表征。框架提供了一種模式來對抽象符號表達的規范性進行檢查。

該框架還包括一組用于驗證模型規范的python腳本。對框架中定義的模型進行驗證的好處有兩個：確認團隊正確地實現了抽象符號，框架可以以可量化的方式詢問關于設計模型的完整性和剩余工作的問題。所有這些都允許FSSE團隊對技術基線設計管控。例如，編寫一個驗證規則來檢查給定的SysML模型種某類抽象符號的數量，在技術方面這意味著物理組件在物理硬件中的位置是未知的可能會缺少電氣連接。FSSE可以運行驗證規則，檢查驗證錯誤日志，并進行工程評估，以確定錯誤是否為設計失誤或缺陷。

圖1 Mars2020框架。黃色區域為Mars2020特有的對象表達模式，白色為繼承的其他表達模式。

4基于模型的系統產品表達

飛行系統設計采用SysML模型，FSSE團隊可以查看和使用這些信息模型，整個FSSE產品的信息孤島、不一致的信息和缺乏產品一致性的情況會大大減少。更有意義工作的是從SysML模型提取文檔工件方面取得了重大進展，所有技術手段在Mars2020項目中發揮了支撐作用。通過SysML模型視圖和python腳本，FSSE團隊能夠將設計模型“投影”到更廣泛的用戶所期望和熟悉的各種數據表格視圖，每次執行信息數據轉換時都會驗證模型信息，確保所產生的技術文檔與Mars2020建模框架一致，是正確和完整的。目前正在基于SysMl模型生成的此類產品技術文檔的包括產品組成邏輯圖、電氣功能列表、以及大量設備清單。用于生成這些列表的相同模型也用來生成技術說明報告，如接口資源度量列表（標識備用和連接的電氣接口）以及質量趨勢報告（航天器的當前質量，并顯示了航天器質量圖）等。這些模型生成的文檔可以通過web界面訪問。web界面提供按需或按計劃生成文檔、以pdf或html格式查看文檔的功能。

圖2文檔生成：Python腳本可遍歷FSDM并將模型轉換為表格形式，不同類型的模型元素（工作包、參考指示符）邏輯和它們之間的關系被轉換生成到一個數據表中，其中每一行標識一個引用指示符及其與其他模型元素的關系。從而為更廣泛的項目成員提供由模型生成的詳細描述文檔。

 

飛行系統工程團隊已經做了大量的工作來解決如何利用SysML建立的模型派生各種視圖。當前的MBSE實踐大多把精力放在如何用SysML創建各種模型，如內部框圖、用例圖、活動圖。但這些模型圖并不能被所有的團隊人員能夠使用，必須按不同的視角來產生數據表、描述文檔等輔助文件，問題在于這些輔助文件是根據SysML模型來手工維護的。隨著SysML模型的復雜度提高，輔助文件的生產會非常緩慢，并且更新圖表的過程非常耗時。目前沒有什么手段能保證SysML模型與輔助文件之間的一致性和完整性。FSSE團隊對當前MBSE實踐發現的另一個問題是SysML圖不能有效地將設計意圖傳達給更廣泛的受眾。大多數項目成員在查看電氣連接視圖時不希望看到SysML模型的端口信息，雖然端口在語義上是正確的，并且有利于對電氣功能進行建模，但是它們在項目成員的視角中存在沒有必要，團隊成員不得不使用非語義驅動的工具（例如，PowerPoint）來對SysML模型的細節進行簡化、刪除、添加要素等圖片化處理。

FSSE團隊已經開始使用商用圖形建模軟件來實現圖表的自動生成和布局。通過使用這個工具，團隊能夠執行元素表示規則（例如，所有1553個數據連接應表示為藍色虛線）如下所示以及元件的布局（例如，所有探測器航空電子設備箱應位于探測器結構內部）。額外的好處這些關系圖可以靜態地作為文檔包含的圖片使用，也可以動態地作為基于web的交互式應用程序交互使用。Mars2020 MBSE工具箱中定制模型生成的圖表的功能插件，該功能插件減少了飛行系統工程團隊在保障能夠提供了更廣泛的成員不同視圖文件的前提下，維護系統的典型“powerpoint”視圖的時間，這些事SysML或MBSE商業公司無法做到的。

圖3基于規則的模型視圖實例：規則生產的視圖能允許輕松看懂模型，辨識技術類別和更新狀態

 

而在更新設計后，在新的設計模型中只需按下一個按鈕，模型生成的輔助文檔就可以與新的設計模型保持一致的信息內容，并提供時間戳來通知更團隊成員關于設計信息的變更，允許他們查看并依據他們的工程判斷繼續提供不要的工程信息。

5 MBSE的采用和改進

FSDM已經開始使用建模框架來表達新的飛行系統硬件設計，即科學儀器和樣品緩存系統，并已擴展到考慮電氣符合等具有概念性的功能，同時還能夠在為更廣泛的團隊成員提供生成產品技術文檔。事實上，我們的努力已經變成了設計表達、接口和質量的標準，允許FSSE團隊把大部分時間花在設計新元素上。此外，設計團隊開始將FSDM擴展到他們特定的主題領域。目前有一個端到端的信息系統（EEIS）原型工作正在進行中，希望連接FSDM的數據接口，將其進一步擴展以連接到地面數據系統（GDS）模型。最終的EEIS模型將用來更加精準的評估MSL和Mars2020運行差異。

當兩年前FSDM工作開始時，FSSE團隊的很大一部分人不熟悉SysML和與之配套的建模軟件。6位MBSE專業人員加入到團隊引導設計實踐。首先，六名MBSE專業人員的工作人員用MSL的歷史數據填充了FSDM的飛行設計信息。在六個月的時間里，整體框架被確定，大量的模型被梳理并創建，并從這些生成初步文件。當時因為MBSE專業人員中的一個成員轉移到其他項目，導致剩下的FSSE團隊成員維持并為項目付出更大的努力。FSSE團隊使用MBSE的一個障礙是，所有人員不能每天都有時間開展MBSE的學習。該小組嘗試通過利用公司的MBSE wiki門戶，其中包含MBSE相關軟件、網站、文檔和視頻的鏈接來實現成員的培訓，以及發布學習計劃、制定個人目標、學習成果分享等。MBSE專業人員中另一位培訓師將注意力集中在如何使用模型生成擴展報告上面。此外，MBSE培訓師也要負責模型設計的具體工作。MBSE的實踐是一個真正的雙向工作，MBSE培訓師們也要學習Mars2020產品的其他專業知識。

在系統工程師的日常工作流程中引入MBSE還有很多工作要做。而模型作為設計的權威來源，FSSE團隊成員仍在探索其他輔助工具來提高他們的工作效率。基于模型的協作性是人們希望多人使用模型的動機之一。在當前工具集中，一個團隊成員可以鎖定限制其他人對模型進行編輯。模型信息的靜態報告文檔生成是另一個動機，團隊目前正在評估與在線模型編輯工具集成的潛在解決方案。

MBSE方法能夠讓團隊更加關注其工作的困難和復雜的工程方面，并讓團隊更確信他們所使用的信息是完整的和最新的。Mars2020框架促進了MSL遺留的數據作為飛行工程產品被協調成一個有凝聚力的飛行系統模型，它的好處是在任務生命周期的早期能夠修復設計誤解/錯誤。不一致的地方就會被識別和發現，如果做不到這一點，修復成本或任務風險可能會更大，因為很可能在制造或集成之前不會被發現。

從模型生成文檔和可視化的能力也使FSSE團隊能夠快速的回答、追蹤可行性研究管理者的各種詢問，而這以往通常需要耗費大量時間。這類問題的一個例子電氣功能設計，現在工程師可以將更多精力關注那些沒有被歸類為規范的電氣功能。線束設計者和電路數據表設計者都在使用此電氣功能模型告知他們的工作日程。

6總結

Mars2020飛行系統采用MBSE方法，以克服常見的SE挑戰，這是一項持續的工作。Mars2020建模框架：提供了一個通用術語，可用于描述飛行整個項目的系統，從而提供精確，明確的設計溝通。框架提供了一種易于擴展和添加飛行系統設計信息的機制和一種從模型提取信息的能力。規則檢查與驗證提供了一種識別信息不一致或不連續性設計信息的能力。

模型生成系統工程產品：通過模型生成一致的數據表、報告文檔。通過web界面訪問文檔可以減少信息孤島，通過提供一個公共位置來訪問飛行系統設計信息。

基于規則的圖表創建：直接從模型轉換，可單獨處理數據的布局和顯示方式，使更廣泛的團隊成員能夠多種視角訪問模型，減少信息孤島。

隨著MBSE的發展，Mars2020飛行系統將從長遠考慮注入更先進技術以期對飛行系統設計有更深入的了解。

文章來源知元創通