基于模型系統工程方法的衛星測控模擬器設計

李忠華 高小亮 強立冬 劉政男

(中國空間技術研究院通信衛星事業部 北京 100094)

0 引 言

傳統的衛星測控模擬器研制模式以文檔為驅動，通過文檔的版本管理進行技術狀態控制。產品的功能特性以及設計表達均通過文檔進行陳述，由于文字表達的多樣性，較難形成格式化標準，使得產品的設計的數字化程度較低，將需求、設計和測試等各類孤立文檔的信息進行集成，需要消耗大量時間。產品研制的幾個階段之間需求和設計的更改追蹤需要人工比對，產品的設計文檔不能直接映射到產品，相似產品之間的繼承和復用通過文檔復制實現，較難進行自動化的對比和分析[1-2]。另一方面，傳統的基于文檔的產品設計很難將設計文檔進行直接仿真驗證。

MBSE提供了解決現有研制模式問題的指導方法，其基本思想是以模型驅動工程設計，利用數字化模型進行技術狀態控制。文獻[2-3]提出了利用MBSE進行系統設計、任務分析與設計，文獻[4-6]提出了利用MBSE進行天線、北斗接收機、機電產品的設計與研究，以上是MBSE方法在設計上的具體實踐，但沒有進行基于MBSE的仿真驗證。文獻[7]提供了MBSE設計中的驗證方法，但需要模型代碼的生成和集成，需要精確的數字模型，實施門檻較高。鑒于此，本文以衛星測控模擬器的產品設計為例，進行MBSE在具體產品中的實施，并提出了一種快速的模型驗證方法，最后結合產品實踐進行應用分析。

1 MBSE簡介

國際系統工程學會(International Council on System Engineering，INCOSE)對MBSE的定義是：基于模型的系統工程是通過形式化的建模手段，從概念設計階段開始就能夠支持系統需求、設計、分析、驗證和確認等活動，并持續貫穿整個開發過程和后續的生命周期階段。根據在INCOSE發布的2020年規劃，到2025年各個領域將應用MBSE[1]。

建模語言、建模方法和建模工具是MBSE的三大支撐，建模工具則是建模語言的設計應用工具。MBSE作為一種系統設計的方法論，并沒有規定哪一種工具或者語言來進行系統的建模和設計。一般而言，各種建模語言和專業的軟件工具都可以作為實施MBSE的工具，SysML是MBSE實施的常用建模語言之一。

SysML是一種多用途的標準建模語言，能夠支持復雜系統的詳細說明、分析、設計、驗證和確認，這些系統可能包括硬件、軟件、信息、過程、人員和設備等。在MBSE工程實踐中，SysML是應用最為廣泛的系統級建模語言，支持SysML的商業工具有IBM Rational Rhapsody、MagicGrid及Enterprise Architect等。

2 衛星測控模擬器簡介

在衛星發射前，衛星地面站需要與衛星進行接口匹配性測試，以驗證地面測控系統是否具備測控衛星的能力。通常而言，衛星制造商會使用衛星測控模擬器到地面站進行接口測試。衛星地面站與衛星測控模擬器之間通過無線射頻接口，進行遙測參數、遙控指令和測距信息的檢查，以驗證接口的匹配性。

衛星測控模擬器仿真了衛星的遙測、遙控與跟蹤設備的功能，在產品研制方面包含了軟件和硬件，傳統的衛星測控模擬器研制分為需求制定、產品設計和測試實驗3個階段，每個階段的成果為文檔或者產品。

3 MBSE建模設計

在MBSE工程實踐中，不同角色的工程人員利用不同的建模工具工作。在典型的案例中，系統工程師通常采用SysML進行系統模型設計，控制工程師采用Simulink進行控制模型設計，軌道工程師采用STK進行航天器軌道建模設計。本節利用SysML對衛星測控模擬器從需求、設計、測試三個方面進行建模設計，并提出了利用中間件進行SysML模型與其他模型進行仿真驗證的方法。

3.1 需求模型設計

在傳統的測控對接模擬器產品研制中，技術要求中規定了產品的功能、工作模式、性能和設計約束。本節通過需求圖、用例圖、狀態機圖及參數圖進行產品需求模型的設計。

3.1.1需求圖設計

在SysML體系中，需求圖作為需求的拓撲表達形式被廣泛應用。需求圖的基本元素包含需求和需求關系兩部分。如圖1所示，衛星測控模擬器產品的三方面的需求分別為功能需求、性能需求和可靠性需求，每個頂層需求下繼續分解為子需求，例如性能需求下面分為遙控誤碼率、遙測誤碼率和射頻信號捕獲門限需求。需求本身可以進行逐級細分，需求關系表達了需求之間或與外部元素的關系，例如圖1中除了需求包含關系之外，還有需求跟蹤trace關系。例如圖中表示“遙控模塊”的設計需要跟蹤“遙控指令接口”的需求，當需求變更時，相應的設計部分將會收到提示信息，同時也能需求跟蹤矩陣的建立。需求圖可以涵蓋技術要求中各需求條目，需要進行說明的是，SysML建模工具在進行需求分解時，如果單純的框圖無法表達具體需求，每個框圖都支持框圖的迭代描述，以及文檔鏈接或文字陳述的鏈接。

圖1 系統需求圖設計

3.1.2用例圖設計

技術要求的提出者為產品的用戶，因此會從用戶角度對產品的功能進行描述。SysML中的用例圖是從用戶角度來描述系統功能的模型圖。如圖2所示，user是抽象的用戶，衛星測控模擬器對于用戶而言，其主要的操作的功能為遙測遙控仿真用例以及跟蹤仿真用例，遙測遙控仿真用例又包含遙控指令解析、遙控指令執行、遙測參數組幀、遙測參數發送和停止仿真用例。用例圖一方面用于需求模型的建立，另一方面也用于系統的測試。

圖2 系統用例圖設計

3.1.3狀態機圖設計

在傳統的衛星測控模擬器技術要求中，除了對產品功能的描述外，還會對產品的工作模式進行規定。SysML中的狀態機圖描述系統或模塊根據事件而產生的行為，在系統各個層級的建模中均可使用。狀態機圖既可以描述系統層級的工作行為，也可以描述模塊細節行為，因此狀態機圖可直接用于代碼的生成。在技術要求這種系統層的狀態機圖，主要描述產品頂層的行為。衛星測控模擬器系統層的狀態機圖如圖3所示，系統啟動后默認進行遙測遙控仿真，再通過使能或者禁止事件來進行跟蹤仿真或者結束仿真。

圖3 系統狀態機圖設計

3.1.4參數圖設計

產品技術要求中還會對產品的內外部參數的數學模型進行限制，一般而言作為設計約束出現在文檔中，SysML中參數圖可以表示等式或者不等式的數學模型。如圖4所示，在衛星測控模擬器跟蹤仿真中，跟蹤仿真即仿真跟蹤接收機與地面設備間的時間延遲，除了跟蹤接收機的固定延遲a外，還可以設置附加延遲b。固定延遲a仿真的是衛星本身對測距信號的延遲，附加延遲b仿真衛星與地面設備間空間距離造成的信號延遲，因此衛星測控模擬器輸出的總延遲為兩者之和，即對輸入測距信號的延遲為a+b，參數圖從數學角度表達了這一設計約束。

圖4 測距參數圖設計

3.2 技術方案模型設計

在工程實踐中，產品技術要求確定后需要進行技術方案或者設計方案的制定。基于MBSE的思想，這一階段的模型與需求模型緊密對應，將需求模型對應的內容進行設計表達。本節通過模塊定義圖、內部模塊定義圖和活動圖三種元素進行產品技術方案模型的設計。

3.2.1模塊定義圖設計

技術方案的首要內容是對所設計產品的系統結構的闡述，在SysML體系中模塊定義圖，英文名稱為“Block Definition Diagram”，簡稱BDD，是系統建模過程中最為常見的圖之一，BDD是一種結構圖，它主要對系統的結構組成以及組成元素間的關系進行描述[8-9]。如圖5所示，在技術方案中衛星測控模擬器由遙測遙控模塊、跟蹤模塊和用戶界面組成。每個模塊還能繼續細分成更小的功能模塊，遙測遙控模塊分成遙控模塊和遙測模塊，跟蹤模塊分成調制解調模塊和測距應答模塊。模塊定義圖從結構上對所設計的產品進行了說明，也可以作為系統研制進度管理中的工作分解結構的依據。

圖5 系統模塊定義圖設計

3.2.2內部模塊定義圖設計

在進行功能模塊設計后，技術方案會給出各設計模塊間的接口關系。在SysML體系中的內部模塊定義圖，英文名稱為“Internal Block Diagram”，簡稱IBD，IBD定義了系統內部的結構及接口關系[8-9]。如圖6所示，衛星測控模擬器的IBD中定義了對外的射頻接口，明確了射頻接口功能由跟蹤模塊提供。射頻接口接收和發送衛星射頻信號，調制解調模塊將解調后的遙控指令發送到遙控模塊，遙控模塊在遙控指令解析和執行后，驅動遙測參數變化以及組幀和發送。遙測數據發送到調制解調模塊進行數據調制后，通過射頻接口發送。IBD支持級聯定義，兩個模塊間的接口可以通過IBD進行詳細定義，可以代替傳統軟件產品研制中的接口數據單。

圖6 系統內部模塊定義圖設計

3.2.3活動圖設計

在產品詳細設計中，基于MBSE的體系既可繼續迭代使用SysML提供的模型圖進行設計陳述，也可使用其他專業工具進行建模。在衛星測控模擬器的詳細設計中，跟蹤模塊須采用硬件設備進行實現，在建模時可使用System C、Verilog、VHDL等硬件描述語言進行建模。在本文中，衛星測控模擬器的跟蹤模塊采用貨架式產品，因此不再贅述。衛星測控模擬器的遙測遙控模塊和用戶界面模塊采用軟件形式實現，在建模形式繼續沿用SysML的活動圖、序列圖和狀態機圖進行建模。在行為模型建模中，活動圖被廣泛地應用，一些商業的SysML建模工具可支持活動圖生成C++、C#、Java等編程語言源代碼。如圖7所示，遙測模塊和遙控模塊在收到遙控指令這一事件后產生的一系列活動。遙控指令模塊首先驗證指令譯碼，并進行指令驗證，然后將驗證結果以遙測的形式通過遙測模塊進行下傳。如果遙控模塊驗證指令錯誤，則事件相關活動結束，如果指令正確則指令執行，并將指令執行結果以遙測形式下傳。遙測模塊的常駐狀態為遙測定時下傳，根據遙控模塊的事件響應更新遙測。

圖7 指令譯碼活動圖設計

需要進行說明的是，SysML中的活動圖可通過建模工具生成測試用例，因此活動圖是系統驗證的基礎。

3.3 產品模型設計

3.1節利用SysML進行了衛星測控模擬器的需求模型設計，3.2節進行了技術方案模型設計，本節將給出產品模型的整體設計，如圖8所示，整個產品模型包含需求、結構和行為三大部分。按照SysML的分類，需求模型、結構模型屬于靜態模型，描述了產品構造性的特征；行為模型屬于動態模型，描述了產品執行任務時的狀態；產品的模型圖即為產品模型。需求模型和結構模型已經在前面進行了論述，行為模型中只討論了指令譯碼。根據產品需求，系統還具備遙測組幀和測距信號轉發兩個活動，限于篇幅沒有對遙測組幀和測距信號轉發這兩個活動的設計進行展開敘述。需要進行說明的是，行為模型可以在建模工具中進行仿真，從而驗證所建立模型的正確性。在建模工具中，這些模型彼此關聯，既能進行需求追蹤，又可以進行模型的調試。因此，模型的仿真實驗內容主要是對產品行為模型的執行與調試。

圖8 衛星測控模擬器產品設計模型

4 模型驗證擴展設計

在SysML中，行為模型(序列圖、狀態機圖和活動圖)在建模工具中可以進行動態運行，在形式上和邏輯上驗證模型設計的合理性。SysML作為系統級的建模工具，適合于總體設計，不能代替MATLAB等專業工具的仿真，因此在進行模型驗證時需要引入其他工具。在文獻[7]中SysML與Simulink通過生成C/C++代碼的方式進行系統協同驗證，這種方式需要SysML模型顆粒度精細，能夠通過SysML模型生成直接應用于工程的C/C++代碼，需要投入大量時間進行模型細化和調試，不適用于快速系統驗證。此外，在現有技術中，FMU(Function Mock-up Unit功能模型)作為外部模型進行嵌入，與SysML模型進行聯合仿真，但FMU需要專用的工具進行封裝及設計。鑒于此，本文提出基于中間件的驗證擴展設計，大多數成熟的模型仿真工具都提供中間件接口。

如圖9所示，SysML模型與外部模型間彼此的交互通過中間件實現。中間件既可以作為外部模型的容器，也可以作為外部模型的中轉接口，典型的中間件有COM、Javabean和CORBRA。SysML建模工具支持的腳本語言作為調用主體，以使中間件處于工作狀態，并返回仿真參數到SysML模型。

圖9 中間件交互設計

在圖9中，SysML模型中的行為模型用于系統行為建模和驗證，因此在引入外部模型時主要是對模型元素進行修改和行為的展示。EA模型工具即Enterprise Architect的建模環境，腳本語言在系統作為模型檢查工具，并不參與模型仿真。與SysML模型運行在不同的上下文環境中，腳本語言可以獲取模型元素的屬性，但無法識別每一個模型元素的具體功能，需要腳本語言對模型元素進行識別，具體流程如下：

1) 遍歷行為模型圖中的元素，根據元素屬性和預先指定的元素特征識別元素，例如以元素名稱識別模型元素。

2) 根據識別的結果，建立模型元素變量以備和外部模型進行數據交互。

4.1 基于COM組件的仿真擴展

以遙控指令譯碼為例進行中間件設計說明，在圖7中有活動“遙控指令譯碼”，該活動采用外部模型的譯碼工具實現，在進行設計驗證時，將譯碼工具封裝為COM組件。以腳本語言VBScript進行實驗，譯碼活動有“指令碼”和“譯碼輸出參數”兩個屬性，基于中間件的驗證流程如下。

1) SysML流程到達“遙控指令譯碼”，VBScript根據存儲的模型元素讀取屬性“指令碼”。

2) VBScript以COM組件方式調用譯碼工具，具體實現為利用CreateObject函數創建COM對象，將“指令碼”傳入COM對象，并獲取“譯碼輸出參數”。

3) VBScript將譯碼工具輸出寫入模型元素屬性“譯碼輸出參數”。

需要進行說明的是，在Windows平臺下，STK、Matlab和Simulink等專業仿真工具均支持COM組件形式調用，因此利用此方法可以進行SysML模型與外部模型的協同仿真，以實現快速驗證設計。

4.2 基于RPC的仿真擴展

遠程過程調用(Remote Procedure Call，RPC)最早應用于分布式系統開發，為本地計算機提供了訪問遠程服務器上應用構件的方法。隨著計算機硬件性能的不斷提升，RPC也適用于同一計算機內獨立構件的交互。RPC在本質上也是通過中間件接口進行通信，只不過在底層形式上可能是進程通信、網絡通信等，部分仿真工具直接提供了RPC接口。在圖4中，附加延遲b可由外部模型工具STK計算得到，具體流程如下：

1) 腳本語言創建與STK連接的字符串，并通過Socket接口發送到STK。

2) 腳本語言讀取模型元素的屬性，將衛星軌道根數、地面站經緯度發送到STK，并獲取衛星距離地面站的距離。

3) 衛星距離地面站的距離除以光速即可得到附加延遲b，將b的數值寫入模型元素的屬性。

4.3 與傳統方法的比較

基于中間件的模型擴展驗證方法，在技術途徑上更利于實現快速仿真，有更廣泛的應用范圍。如表1所示，通過每種方法的實現途徑可知，本文方法需要的工作步驟較少且簡易。在模型調試和修改過程中，其他方法都需要做較多的調整，而本文方法僅須腳本語言且即時生效。此外，在方法適用范圍上，本文方法的環境適應性也更強。

表1 幾種模型擴展驗證方法比較

5 應用分析

通過基于MBSE的方法進行產品的設計，將衛星測控模擬器的設計由傳統的文檔驅動替換為模型驅動，通過MBSE的應用設計和模型驗證擴展設計，可得到如下的分析。

1) 維度清晰，易于復用、更改易于追蹤。用SysML語言進行系統設計時，需求和設計都被組織成模型圖，各圖之間又緊密聯系，各圖的組織結構清晰。因此進行相似產品的復用時，只需修改特定圖表的某一部分，即可完成設計。SysML建模工具會對SysML模型進行一致性檢查，在某個圖表修改時，會自動識別影響區域，因此產品的復用和修改都具有較高的效率。

SysML在需求管理方面，在設計時進行需求的鏈接和跟蹤，可以快速進行需求變更分析，以及進行相應模型的更新，有較強的產品技術狀態控制能力。

2) 系統集成和深度驗證。SysML的建模工具不能直接進行與專業工具的集成，利用中間件方式進行集成后進行模型的驗證，使得設計和驗證同步進行。另一方面，目前的集成方式僅限于數據集成，實現了系統功能在形式上和邏輯上的驗證，尚難以進行精確的時序仿真、系統性能評估等。各專業建模工具隸屬于不同技術領域，各廠商產品對外接口不統一，還沒有相關行業標準。因此在后續的基于MBSE的衛星相關配套產品研制時，進一步研究SysML模型與各專業建模工具的深度交互接口，能夠進一步提升MBSE的設計驗證能力。

6 結 語

本文利用MBSE實現了衛星測控模擬器設計，并利用中間件技術實現了SysML模型與其他專業建模工具的協同驗證，克服了基于設計文檔的產品研制模式在信息孤立、難于需求跟蹤和復用方面的問題。在模型擴展驗證方面，緩解了傳統驗證方法技術途徑復雜，難于快速仿真驗證的技術問題。此外，本文分析了基于MBSE的衛星測控模擬器的設計在實踐中仍然需要研究的內容。