模型驅動的復雜裝備系統設計與仿真驗證研究

歐陽毅，孫 全，黃 旭，翟文華，呂炳均

（上海機電工程研究所，上海 201109）

隨著信息網絡技術的迅猛發展，武器裝備不斷優化升級和高科技作戰手段不斷更新，戰場環境日趨復雜，現代地面防空作戰面臨更多的挑戰［1］。復雜裝備系統逐漸由大系統向巨系統發展，呈現出功能高度復雜、各領域耦合關聯、跨域協同性強等特點。復雜裝備的研制是一項跨層級、跨專業、跨領域的規模龐大，過程復雜的系統工程，涉及多個學科，需要根據各系統、學科之間相互聯系，進行仿真驗證、方案對比和多輪迭代，最終完成設計過程。

傳統的系統工程設計方法是以文檔為核心，技術狀態分散于多份設計文件中，項目內的設計協調和任務傳遞主要依靠文檔來完成。文件的靜態性導致技術狀態缺乏有效的驗證手段，同時傳遞效率也較低，已無法滿足復雜系統的研制要求。采用基于模型的系統工程（model-based systems engineering，MBSE）方法能夠解決上述問題。它從需求階段開始即通過模型的不斷演化、迭代遞增而實現產品的系統設計，可以根據用戶需要刻畫產品設計初期的需求，并根據需求設計產品的功能、結構以及參數等；再通過仿真分析發現不合理的設計方案，為各方提供了一個通用的、無二義性的設計信息交流平臺。

近年來，基于模型的系統工程已陸續應用到相關裝備論證和設計中，羅松等［2］針對面向對象設計方法開展一些功能的實現研究；湯超等［3］立足于戰略層面，完成戰略體系結構的建模，著重進行需求分析；劉宇等［4］針對火控系統的單機設備，開展了需求分析和系統設計。但目前文獻中暫未涉及從作戰體系需求分析到產品實現全流程的裝備建模設計的案例，同時針對模型的有效性、完整性以及邏輯的一致性都無法通過合理的方法進行驗證，使得模型的可信度降低，甚至影響到產品的設計結果。因此，本文在MBSE 深入研究的基礎上，針對復雜裝備功能高度復雜的設計難點，結合裝備研制流程，提出了一種適用于復雜裝備系統建模設計和仿真驗證的方法，重點針對復雜裝備軟功能設計，即功能邏輯流程、輸入輸出流、接口等進行建模設計與仿真。

1 系統設計建模語言和建模工具

MBSE 的核心就是采用形式化、圖形化的建模語言及相應的建模工具，優化研制過程的系統工程［5］。針對不同的建模類型可以采用不同的建模方法與技術。統一建模語言（UML）在軟件工程領域的模型驅動軟件設計中取得了巨大成功［6］，它具有極好的擴展性與開放性。在UML 2.0 的基礎上，國際系統工程學會和對象管理組織對其進行面向系統工程的擴展，定義了一種新的系統建模語言標準——SysML。SysML來源于UML，規定了若干種自然語言外的符號，包括框圖、線條、箭頭等，來創建系統結構、行為、需求和參數模型。

建模工具是一類輔助工具，為用戶在遵守建模語言規則下用SysML 語言創建形式良好的模型。常見的建模工具包括Enterprise Architect、MagicDraw、Rhapsody、源圖等。在本文中綜合選取了源圖、Rhapsody、MagicDraw 作為建模工具，綜合了三者的建模優勢。

2 模型驅動的復雜裝備建模方法

建模方法就是如何利用系統建模語言的各種圖形來建立相關模型進行系統實現，這充分依賴于裝備特點和研制經驗。傳統武器裝備研制流程通常是個V字形，左側是系統設計，主要包括需求分析、系統設計、分系統設計、分系統實現，右側是系統集成驗證，主要包括分系統集成調試、系統集成調試、系統交付驗收等環節，如圖2所示。

圖2 傳統武器裝備研制流程Fig.2 The traditional development procedure of weapon equipment

本文結合傳統武器裝備研制流程，根據模型設計特點，將系統建模設計分為作戰體系需求分析、系統功能分析、系統架構設計、分系統功能分析、分系統架構設計、分系統產品實現和全系統集成等活動，設計師在每個活動上通過建模完成分析、設計和驗證，活動與活動之間通過模型進行傳遞，各個活動產生的模型都納入到模型庫中，推進后續裝備設計時產品化復用，如圖3所示。

圖3 基于模型驅動的復雜裝備系統設計流程Fig.3 Model-driven design process of complex equipment systems

2.1 需求分析

系統工程一般從用戶需求開始實施，用戶需求是系統的頂層能力，是針對用戶以面向問題的角度進行的表達。通常結合裝備的頂層作戰使命以及環境約束，通過作戰活動圖形式對每個作戰場景描述作戰過程，形成作戰活動圖和作戰時序圖，基于系統視角開展系統功能分析，形成系統功能流描述視圖，并對參與作戰的各個作戰單位形成所需要的作戰能力和作戰活動映射表，完成系統需求的捕獲。

2.2 系統功能分析

系統功能分析是以面向解決問題的角度，將系統功能需求轉化為對系統功能的描述，稱為黑盒階段。功能分析主要是對系統的功能進行定義，首先通過創建活動圖來分析用例的功能流，然后通過時序圖確定系統與外界的交互，最后通過狀態機圖來描述系統基于狀態的行為。在功能分析的最后階段，這些附加需求需要得到用戶的認可，并被導出到需求管理工具。

在功能分析階段，活動圖只分析系統與外部的交互情況和系統自身的運行情況，不涉及系統內部的結構，被稱為黑盒活動圖［6］。和活動圖類似，在功能分析階段，時序圖被稱為黑盒時序圖。狀態機圖將活動圖中的功能流和時序圖中的交互集中在一起，包含了黑盒活動圖和黑盒時序圖的信息。功能分析階段輸出主要是系統功能條目和系統黑盒模型。

2.3 系統架構設計

系統架構設計目的是設計合理的系統架構，并將系統功能進行分解。在架構分析階段，對系統進行權衡分析，在功能分析的基礎上，確定實現系統功能的最佳方法。由于確定了系統架構和系統內部各模塊與系統外部的交互，所以將架構設計過程稱為白盒階段，將該階段的各個視圖稱為白盒視圖。系統架構可以是權衡分析的結果或者傳統架構，對各模塊或子系統的行為、子系統之間的交互和子系統與系統外部的交互進行建模，將功能分析階段的黑盒視圖轉化成白盒視圖。架構設計過程和功能分析過程類似，白盒視圖同樣包括活動圖、時序圖和狀態機圖。

系統架構設計階段輸出主要是系統白盒模型和分系統需求條目。

2.4 分系統功能分析

分系統功能分析是根據上一階段輸出的頂層需求，將分系統看成一個黑盒，對每個業務用例通過活動圖、時序圖和狀態圖進行描述，對分系統需求條目進行抽象、合并、拆分，得到細化的功能需求，并形成分系統需求列表和分系統黑盒模型，如圖4所示。分系統功能分析輸出主要是系統白盒模型和分系統需求條目。

圖4 黑盒活動圖示意圖Fig.4 The black-box diagram

2.5 分系統架構設計

分系統架構設計目的是設計合理的子系統架構，并將分系統功能進行分解，分配到架構內各模塊（軟件）中。若分系統存在三、四級子系統，則依次類推，對分系統進行逐層分解。分系統架構建模可分為機械架構建模、電氣架構建模和軟件架構建模，通過建模可快速開展工程設計的迭代仿真驗證。隨著產品硬件的系列化、產品化，作戰指揮、發射控制等分系統架構設計更多偏重于軟件架構設計。通過對軟件用例過程的描述，完成軟件架構中各分析類的邏輯、接口和數據的設計，并牽引出邏輯模型和數學模型體系。

最終分系統（軟件）架構中各個分析類以活動圖、時序圖、接口圖等形態呈現，可以直接用于軟件專業開展分系統軟件開發，如圖5所示；邏輯模型和數學模型體系中各個模型以類對象的形式封裝，并通過接口圖描述其輸入輸出接口，可以直接用于模型專業進行模型設計和開發。

圖5 分系統（軟件）設計Fig.5 Subsystem software design

2.6 產品實現

各分系統（軟件）專業根據分系統架構設計輸出的各個分析類相關的時序圖、接口圖，將分析類轉換為設計類，并據此開展軟件開發。數學模型體系中各個模型以類對象的形式封裝，最終完成各分系統（軟件）設計。

各分系統產品實現后，交付總體開展系統半實物仿真驗證和系統外場對接聯調等集成驗證工作。

3 復雜裝備系統模型仿真驗證方法

3.1 系統模型構建

基于復雜裝備系統建模設計方法，本文建立了裝備系統典型工作過程的系統模型。首先，針對用戶需求，通過需求清單進行了總結，如圖6所示。在裝備系統典型作戰過程中，用戶需求主要包括對裝備系統需要的感知能力、打擊能力、通信能力以及指控能力。

圖6 用戶需求清單Fig.6 List of user requirements

針對典型工作過程，根據用戶需求，將其歸納為2個用例：目標探測和目標打擊。通過與利益攸關方進行關聯，可得到如圖7所示的用例圖。

圖7 裝備系統用例圖Fig.7 Use case diagram of equipment system

基于上述用例，分析裝備系統與系統運行環境之間各要素，結合其他利益攸關方之間的交互動作，可以通過活動圖來對用例進行細化，其中目標探測用例的活動圖如圖8所示。指揮員通過操作員向裝備系統下達目標探測指令，隨后系統綜合內外目標信息，通過計算處理，得到目標數據，顯示目標位置。

圖8 目標探測活動圖Fig.8 Activity diagram of target detection

裝備系統與系統外部的接口以及輸入輸出定義，具體如圖9所示。

圖9 裝備系統接口定義Fig.9 Equipment system interface definition

定義了系統接口以及輸入輸出后，裝備系統的運行環境以及各語境要素均已完善。通過定義系統運行環境可以更加準確地定義系統與用戶以及外部系統的交互關系。系統運行環境中的其他要素之間的交互如圖10所示。

圖1 SysML所有圖形的層次結構Fig.1 The Architecture of SysML diagrams

圖10 裝備系統運行環境Fig.10 The operating environment of equipment system

進入白盒階段意味著針對系統內部進行深入分析，理解系統如何運作，深入分析拆解系統功能，從而識別功能模塊及所屬的邏輯子系統。同時，系統行為和結構的細分是多層迭代的，以實現問題域定義的相關粒度。本文通過從系統到子系統的分解來描述系統功能逐層分解的方法。

通過用例細化得到的活動圖，對裝備系統進行更深層次的功能分析，針對屬于裝備系統的活動可繼續向更深層次進行分解，其中目標打擊中的制導飛行動作可以向下分解，如圖11所示。

圖11 制導飛行活動圖Fig.11 Activity diagram of guided flight

功能分析的完成幫助識別了裝備系統的邏輯子系統。同時在建立子系統連接的過程中及實現系統功能的過程中，需要考慮與其他系統連接的接口。裝備系統的架構通過模塊定義圖進行表示，如圖12所示。裝備系統的內部結構如圖13所示。

圖12 裝備系統架構及子系統接口定義Fig.12 Equipment system architecture and definition of subsystem interface

圖13 裝備系統內部模塊圖Fig.13 The IBD of equipment system

完成了邏輯子系統分解之后，可以將功能行為分配到相對應的邏輯子系統中，完善功能分析。

確認解決方案結構中的子系統后，開始進行子系統的系統結構設計分析工作。從定義子系統的內部結構開始，構建子系統的解決方案結構，并指定其各個部分的操作，及與外部的交互。

完成了系統結構及子系統結構定義，需要對系統行為進行定義。首先定義子系統行為，通過系統結構定義好的接口將所有子系統行為進行集成，完成系統行為定義。如圖14所示，裝備系統在典型作戰過程中的各類行為已通過狀態機進行定義。

圖14 裝備系統狀態機圖Fig.14 The state machine diagram of equipment system

3.2 系統活動模型仿真

測試系統之間是否按預期進行相互通信成為系統工程師下一步的主要工作。基于系統的運行環境，系統與利益攸關方和外部系統進行交互作用，通過設計定義的接口接收和發送各類物質、能量、信號與信息流，隨后系統、子系統將通過一系列的動作和行為來實現系統的預期功能。

在上述過程中，系統會進入不同的工作狀態。在不同的狀態下，系統所執行的動作也各不相同。通過控制信號來觸發系統狀態的改變，從而使系統實現不同階段所需要的功能。

基于4.1 章節中建立的裝備系統功能模型，本章將通過對系統的行為、狀態、接口、輸入輸出進行仿真分析，驗證上述模型的邏輯一致性、接口定義的準確性以及系統功能實現的預期情況。

首先，針對目標探測用例進行仿真。基于用例指導所建立的活動是系統設計的基礎，其中包含了系統預期的全部功能，其仿真過程如圖15所示。

圖15 目標探測活動仿真Fig.15 Simulation of target detection activity

其次，指揮員向操作員下達目標探測命令；隨后，裝備系統開始并行執行3 個動作：請求上級信息，請求導航數據，以及搜索空中目標信息，并發送相應的請求信號。

在搜索空中目標信息中，通過選擇框來完成“目標是否捕獲”判斷，模擬實際流程中可能出現的多種情況，保證模型邏輯的正確性與一致性。在搜索空中目標信息過程中，子系統3 在經過多次未捕獲目標后，完成對目標的捕獲，并將目標信息通過接口發送給子系統1，實現信息的傳輸。如圖16所示。

圖16 搜索空中目標信息Fig.16 Search for airborne target information

當裝備系統完成目標搜索，得到上級信息及導航數據后，開始進行下一步的目標信息綜合處理計算，并完成后續一系列的動作，直至完成整個目標探測活動，驗證該活動邏輯的完整性。

3.3 系統狀態機模型仿真

在狀態機圖中，系統通過觸發控制信號實現狀態的切換，并根據自身所處的狀態執行相應的動作。系統的一個狀態可能會包含幾個子狀態，這些子狀態同樣會根據觸發信號實現切換。在不同的子狀態下，系統本身還在執行相應的動作，但類似于活動的分解一樣，狀態的分解同樣會讓系統在同一狀態下執行分解后的動作。

如圖17所示，對裝備系統狀態機進行仿真驗證分析。首先，裝備系統經過上電開機自檢后，進入到待命狀態，等待外部的控制信號。

圖17 裝備系統狀態機仿真過程Fig.17 Equipment system state machine simulation process

在接收到目標探測指令后，裝備系統進入目標探測狀態，并隨后進入到信息收集子狀態中的請求導航數據子狀態、請求上級信息子狀態以及搜索空中目標子狀態。在子狀態中，裝備系統分別執行相對應的動作，并在完成后退出信息收集子狀態。

隨后經過綜合目標處理計算以及顯示目標位置，系統返回到待命狀態，并等待后續的控制指令。在接收到目標打擊指令后，裝備系統通過參數裝訂、導彈加電、導彈發射和命中目標一系列狀態并完成相應動作后，返回到待命狀態。

3.4 系統接口與輸入輸出模型仿真

經過上述兩節的仿真分析，明確了裝備系統行為模型（活動與狀態機）邏輯的完整性和一致性，因此后續將繼續對模型接口定義以及輸入輸出流的正確性進行仿真驗證。

由于系統、子系統的接口以及輸入輸出是基于系統的外部環境以及內部結構而定義的，因此，無法脫離系統的運行環境和結構單獨證明接口以及輸入輸出流是否定義正確。圖18綜合展示了裝備系統的運行環境以及內部結構。

圖18 系統運行環境及內部結構Fig.18 System operating environment and internal structure

由于裝備系統的接口與輸入輸出流數量多，本文選取導航數據進行仿真分析，具體流程如下。

首先，指揮員向操作員下達目標探測命令，并由指揮員向裝備系統下達目標探測指令。在接到指令后，裝備系統便向導航系統發送請求導航數據。導航系統接收到請求導航數據的指令后，向裝備系統發送系統的導航數據，并由裝備系統向子系統傳遞該數據，此時系統便記錄下導航數據。最終由子系統接收并記錄數據，目標數據如圖19所示。

圖19 導航系統返回導航數據Fig.19 The navigation system replies with navigation data

仿真結果證明，裝備系統的導航數據接口能夠實現與利益攸關方以及外部系統進行信息交互的功能，包括發送請求信息并收到相對應的數據。同時，裝備系統能夠實現與子系統之間的信息傳輸。

基于上述系統模型的仿真驗證方法，通過分析仿真結果，可以證明依據本文所提出的系統設計方法建立的系統模型具有良好的邏輯完整性和一致性，且接口與輸入輸出流的定義準確，能夠實現系統、子系統與外部環境和內部結構的復雜交互。

4 后續展望

本文提出的模型驅動的復雜裝備系統設計與仿真驗證方法，基本實現了從作戰需求分析到產品實現的全流程建模，對提高裝備設計質量和效率具有很大意義。然而由于研究時間的限制等，還存在許多問題需深入研究和加強攻關。

（1）對性能指標迭代驗證需要加強。目前建模工作側重于對各級系統功能需求的捕獲和驗證，偏重于邏輯控制層面，缺少對系統性能指標需求的捕獲和驗證，如電磁仿真、力學分析等性能指標分析。

（2）提升建模設計自動化水平。現有的建模工具難以實現自動化智能化建模，整個建模設計過程均需設計師手動完成。事實上，功能分析、架構設計和軟件設計之間存在一種映射關系。因此，如何利用現有技術基礎提高建模的自動化水平，實現自動輔助建模和自動軟件代碼生成值得研究與探索。

（3）探索機電液等物理建模方法。復雜產品具有其自身的許多特點，如多物理域、連續動態行為等，需要對機電液等多個物理域建模實現對復雜系統更為全面的描述。實現系統功能邏輯與物理性能的聯合仿真，驗證系統功能邏輯和物理性能的匹配性，對于全流程建模的研究具有重要意義和價值。

5 結 論

本文針對復雜裝備功能高度復雜的設計難點，結合裝備研制流程，提出了一種適用于復雜裝備系統全流程建模設計與仿真驗證的方法，覆蓋了從作戰需求分析、系統功能分析、系統架構設計、分系統功能需求分析、分系統架構設計、產品實現等裝備研制全過程，極大地提高設計效率和質量，具有較高的實用價值。同時探討該方法在性能指標迭代、建模自動化、物理建模等方面需要提升的地方，這些也是基于模型驅動建模在裝備研制應用中需要盡快開展重點研究和攻關的方向。