基于SysML的作戰場景監測仿真研究

黃玉錢，胡保坤，刁灣灣，夏征華

(杭州師范大學信息科學與技術學院，浙江 杭州 311121)

0 引言

技術進步使當今世界的作戰場景變化多端，為國家強大而研發新型作戰系統的任務日益復雜和困難.作戰系統包括戰略、戰術、訓練和資源(如工具，供應和設施)[1]等方面.設計開發這類新型作戰系統通常包括5個步驟:概念設計、設計驗證、原型制作、評估和測試.完成和實現這些步驟需要花費大量的時間和金錢，因為在每個步驟中都使用獨自的方法和技術.擁有強大國防力量的國家在概念設計階段就開始使用建模和仿真技術[2-3]以減少作戰系統開發的時間和成本.建模和仿真技術的另一個優點是：可以通過考慮各種作戰要素，回顧作戰過程中實時變化的數據，為武器的設計和研發帶來便利性和高效性.為此還需要一個能夠獲取作戰過程實時數據的方法，以減少因數據變化而導致的反復實驗.

基于模型的系統工程(Model Based System Engineering，MBSE)[4-6]是一種使用模型表達設計的系統工程方法.為了對MBSE進行更好的支持,對象管理組織 (Object Management Group, OMG)和國際系統工程學會 (International Council of Systems Engineering, INCOSE)聯合開發了系統建模語言SysML[7-8].SysML是領域無關的建模語言，可以通過SysML的可擴展性[9]對其進行擴展，以形成領域相關建模語言(Domain-specific Modeling Language，DSML).

目前基于模型的系統工程概念已被工業界廣泛研究,并于航天、航空、作戰、動車等領域得到一定應用[10-12].彭斯明[3]等研究人員提出了將系統建模語言(SysML)用于作戰概念的可視化和規范化描述的方法，并分析了將國防部體系結構框架(Department of Defense Architecture Framework,DoDAF)和SysML相結合用于作戰概念描述的思想，采用多視圖產品的形式對作戰概念的作戰背景、能力需求、體系構成和作戰活動等多個方面進行規范化描述，最后通過“分布式殺傷”作戰概念作為實例，論證了其所提方法的有效性和可行性.謝文才[13]等研究人員針對當前體系結構的建模方法不是基于統一的元模型規范，提出了基于元模型的軍事信息系統體系結構建模方法，能夠實現不同體系結構框架方法論及體系結構工具下所開發體系結構的可理解、可比較、可交換等優點，促進了體系結構數據的共享和重用.蘇瑾[14]等研究人員探索了車輛顯控系統智能構建方案中基于元模型的需求建模方法，通過擴展標準系統建模語言定義顯控領域的專用語言，在此基礎上構造包含需求域元任務的可重用模型庫，使系統能夠依照戰場任務目標自動確定顯控信息內容和提供布局方案.該模型的優點是使用了元模型建模，使開發過程更加高效率、規范化，并且可以支持后續的任務功能分解和顯控界面布局.但缺點是當戰場上的任務目標變化時，需要重新修改模型中的數據再次實驗，實驗過程繁瑣，造成一定的局限性.

綜上所述，在作戰領域中基于MBSE方法和任務建模方面已有較多相關研究.但在數據交互上仍存在一定的局限性，為解決該問題，本文以作戰場景監測為研究對象，提出基于SysML的作戰場景監測仿真的統一流程框架，研究基于元模型的構建方法，并且在仿真模型的基礎上，探索了模型與外部平臺之間的數據交互方式，實現模型數據動態變化功能.

1 總體流程

本文擬定將作戰場景監測仿真系統應用于海上軍事系統中.假設該系統包括：監測系統、中央指控系統、作戰系統、武器系統.本文假設系統之間的交互如下：監測系統能夠監聽到其他客戶端發出的數據信號，捕獲該數據信號并且發送數據信息給中央指控系統.中央指控系統處理數據，再把數據發送給作戰系統.作戰系統接收數據并分析各個數據，根據結果發送信號給武器系統.收到信號的武器系統做出進一步操作.總體流程如圖1所示.

圖1 作戰場景監測仿真設計流程Fig.1 Combat scene monitoring simulation design process

針對本文的研究內容和領域，可以進一步細分為以下步驟：

1)需求表達，采用基于模型的需求圖和約束組件，表達作戰場景的功能領域相關需求；

2)系統上下文關系表達，采用基于模型的模塊定義圖，表達系統上下文之間關系；

3)設計領域元模型，采用基于模型的構造型組件《stereotype》，設計一套作戰場景領域元模型；

4)信息流表達，采用基于模型的內部模塊圖，表達作戰場景功能之間的信息流內容；

5)接口表達，采用基于端口的組件，表達作戰場景的對外接口以及接口之間的連接；

6)數據監聽，采用JAVA代碼對軟件進行二次開發，基于通訊協議，獲取外部界面傳遞來的相關數據；

7)數據賦值，采用JAVA代碼對軟件添加數據接收功能，基于SysML語言底層代碼邏輯，將外部數據傳到模型系統中；針對以上內容，提出了總體設計方案，如圖2所示.本文采用JAVA語言中的Socket通訊框架實現數據交互，為了提高通訊的性能以及考慮到代碼與建模軟件的適配性，選擇異步與非阻塞方式(AIO)進行數據的捕獲與發送.

基于SysML模型的作戰場景建模與仿真，通過對元模型的擴展進行模型搭建.詳細方案如圖3所示，步驟如下：

首先，深入學習、總結專家的作戰領域知識，定義作戰場景的功能模型集合和組件庫，將領域知識充分應用在仿真模型中.

其次，在建模語言SysML(System modeling language)原本的元模型基礎上，充分利用它的擴展機制，根據仿真的需求擴展領域元模型并且遵守元模型搭建原則(MOF)，包括在活動(Activity)的基礎上擴展功能類型、在類(Class)的基礎上擴展組件元模型、在端口(Port)的基礎上擴展適合表達作戰場景監測領域的新端口類型.本文以在活動(Activity)的基礎上擴展功能元模型為例.

最后，基于擴展的元模型，搭建作戰場景監測仿真模型.并且在模型基礎上，擴展其數據交互功能.

圖2 作戰場景監測仿真總體設計方案Fig.2 Combat scene monitoring simulation overall design scheme

圖3 模型驅動作戰場景設計技術方案Fig.3 Model driven combat scene design technical scheme

2 基于SysML的武器作戰場景元模型

元模型是模型系統建模的基礎，領域元模型是在基于領域知識的基礎上建立的，它描述了領域相關的模型內容以及它們之間的關系，并規范這些模型元素的使用方法.

2.1 元模型構造方法

元對象機制Meta-Object Facility(簡稱MOF)，它起源于統一建模語言(Unified Modeling Language，UML).MOF是模型驅動架構(Module Driven Architecture, MDA)4個標準之一，它共包含4個模型層次：元元模型層、元模型層、模型層、對象層.

元元模型層：元元模型層位于頂部，它是MOF建立元模型的基礎，是為了描述元模型而定義的一種“抽象語言”.一個元元模型可以定義多個元模型，在本文中可以將元元模型理解為SysML語言.

元模型層：元模型層由元元數據組成，元數據的組件和語義由元元數據定義，元模型是元元數據的集合.在本文中可以將元模型理解為構造的領域模型庫，用于搭建領域內一類產品的模板.

模型層：模型層包含各種模型，元模型層的實例就是它們的結構.模型層是為了描述模型層而定義的抽象語言，一個模型即是元模型的一個實例.在本文中可理解為領域內一類產品的模板.

對象層：對象是由我們希望描述的數據組成，這些數據可以是特定領域中數據，主要職責是描述領域中的詳細信息.在本文中可以理解為領域內一個具體型號的產品.

2.2 SysML擴展

SysML是一種領域無關的建模語言，為了使模型能夠更加貼切地表達作戰場景領域的相關需求和功能，需要基于SysML進行擴展以構建領域相關建模語言.構建生成的領域元模型庫需要能夠為同一型號模型復用，以減少設計階段的工作量.目前，SysML的擴展方法主要有兩種：

1)輕量級擴展方法：主要是在SysML語言所提供的模型元素基礎上，創建一些包含領域相關語義模型元素的構造類型(Stereotype)，通過創建的構造類型定義相關領域模型.

2)重量級擴展方法：將SysML語言的元模型根據自身的需求進行修改，創造符合特定領域的全新模型元素.

輕量級擴展方法具有效率高、靈活性強等特點.但是輕量級方法是在SysML語言元素基礎上通過繼承的方式進行擴展，其局限性比較大，可擴展范圍小.重量級擴展方法需要了解SysML元模型內部結構，從而對其進行相應的修改，其擴展空間比輕量級擴展方法大，但是工作量大，效率低.兩者各有其優缺點，本文依據作戰場景領域的擴展內容和需求，選擇SysML輕量級擴展方法進行研究.

2.3 作戰場景領域元模型

基于上述元模型的生成原理以及SysML元模型輕量級擴展方法，設計出圖4所示的功能元模型以及對應的功能類型和流類型.

功能是系統的核心，功能表示系統應該實現某種預期的行為，與功能最貼切的SysML模型元素是Activity.故而此處選擇SysML中的Activity作為它的基類.

1)function表示的是作戰場景中的系統功能，它的類型是functionType.其中最為關鍵的功能是信號傳遞、數據捕獲.

·信號傳遞：一個組件從等候的狀態進入執行狀態，需要依靠信號進行數據或者消息傳輸，因此信號傳遞的功能在仿真系統中是必不可少的.例如本文的研究內容，在中央指控系統中發送“數據信號”給作戰系統.

·數據捕獲：在本次研究中，外部數據捕獲起著重要作用，只有它的成功執行才能真正實現仿真系統與外部平臺軟件之間的交互，將外部數據傳入到模型系統中，實現數據的實時變化，將仿真系統由單一模型向多元交互的方向發展.

(2)inputFlow表示的是輸入流，從輸入數據到輸出數據的數據轉換是一個產品在系統設計層主要強調的.因此，關鍵的一個任務是指定功能的輸入流，其類型為flowType.例如作戰系統發送“X-x防空導彈發射”給武器系統，這里的“X-x防空導彈發射”就是作為輸入流輸入到武器系統中.

(3)outputFlow表示的是輸出流，它和inputFlow類似，用于指定復雜產品在系統設計層面表示的輸出元素，通常以流的形式呈現.輸出流的類型也是flowType.

SysML提供的<>組件，具有枚舉的功能.如圖4所示，“functionType”中列舉了作戰場景領域的主要功能：信號傳遞、數據捕獲、導彈數量查詢、外部數據通訊、數據格式修改等.

同樣的，通過<>自定義了“flowType”，它主要是用來表示inputFlow和outputFlow的構造類型.如圖4所示，使用“flowType”表示“inputFlow”和“outputFlow”的類型.

圖4 基于SysML構造類型定義的功能元模型、功能類型和流類型Fig.4 Construct the functional metamodel, functional types, and flow types of type definitions based on SysML

圖5 功能元模型Fig.5 Functional metamodel

表1 數據流參數Tab.1 Data flow parameter

具體的功能元模型如圖5所示，“復雜功能”和“元功能”構造類型是由“功能”構造類型繼承而來.“元功能”再進一步可以細分為驅動、數據傳遞、制動、輸入、輸出、支撐、輔助功能等元功能，其中輔助功能也可再進一步細分為信號監測、異端傳輸、信號傳遞、數據捕獲等元功能.

模型中的流，則是繼承了來自SysML中的Parameter構造類型.對于流又可以進一步分為輸入流、輸出流和信號流.本文中對于流中的數據字段，設定了一個名為Block的類，該類中包含isEnable、missileCount、isReady和isCaptureTargeted 4個參數.參數描述和類型如表1所示.

3 武器作戰場景系統建模

元功能是模型系統中較為重要的一部分，它是系統中各個功能的基石.因此元功能設計在整個過程中是十分重要的環節，元功能的設計需要依據以下原則：

1)元功能應盡量達到各資源實體的要求.每個元功能是由具體的資源實體來承擔的，因此元功能不能超過各資源實體的能力范圍，否則不能被有效執行，即分解失效.

2)元功能需要明確且獨立.首先元功能作為資源實體執行的不可再分的功能單元，必須要明確目標，才能匹配對應的資源實體.其次元功能必須獨立，以減少功能之間的耦合度.

基于上述元功能設計原則，構建作戰場景監測的元功能模型.首先創建Activity組件，對于復雜的任務需要將其分解為多個子任務.其次根據每個Activity所擔任的功能將其命名為所要創建的元功能名稱.

圖6展示了功能分解關系.在模型中條件校驗功能可以被認為是父任務，信號接收、發射環境校驗、發送信號、導彈發射狀態校驗、導彈數量校驗、捕獲目標校驗、數據捕獲則被認為是子任務.

圖6 條件校驗功能詳細信息及其關系Fig.6 Conditional verification function details and relationships

4 作戰場景監測仿真系統及驗證

4.1 定制化作戰場景監測原型系統

為了推進模型的多樣化發展，本文在上述內容的基礎上研究了模型與外部平臺之間的數據交互功能.基于Cameo Systems Modeler軟件，研發了“SIM”插件，使該插件能夠兼容Cameo Systems Modeler軟件并且實現模型與外部平臺之間的數據交互.

4.2 定制化作戰場景監測系統流程

圖7 定制化作戰場景監測流程及原理Fig.7 Customized battle scene monitoring process and principle

本文通過Java代碼模擬外部平臺的數據發送，定制化作戰場景監測流程及原理如圖7所示.具體步驟如下：

1)在java代碼中編寫異步且非阻塞(Asynchronous IO)的Socket通信代碼，并且監聽指定IP地址和端口號；

2)在軟件中通過插件的方式導入開發功能，并且開啟數據監聽；

3)在外部平臺中發送missileCount、isReady、isEnabled、isCaptureTargeted等數據，數據的發送同樣是基于Socket通信的基本原理，并且采用異步非阻塞的方式進行；

4)監測系統捕獲到所有數據，通過中央指控系統進行數據的處理.

4.3 系統驗證

為驗證上述方法的有效性，本文建立了如下遐想任務：在某一作戰場景中，雷達系統監測到前方存在非法入侵，數據傳送系統將數據發送至指定IP及端口，具體內容為如下：前方30 n mile發現非法入侵船只，正在向西南方向以30 Knot的速度行駛.我方導彈狀況數據：’missileCount’:15，’isEnabled’：true，’isReady’：true，’isCaptureTargeted’：true.

首先在模型中通過開啟監聽任務，之后將對應數據賦值到模型指定位置中，替換舊的數據同時開啟仿真.以上文的“條件校驗功能”為例，由上文可知，條件校驗功能可視為父任務，其還可以具體細分為發射環境校驗、狀態校驗、導彈數量校驗、捕獲目標校驗等子功能.如圖8所示，該圖為模型中的狀態圖，在通過初始化檢查后，可分別對數據信號中的missileCount、isReady、isEnabled、isCaptureTargeted參數進行校驗.

圖8 條件校驗狀態圖Fig.8 Conditional check status diagram

圖9 發射環境校驗活動圖Fig.9 Launch environment verification activity diagram

圖9為發射環境校驗的具體內容，在校驗過程中，采用readSelf組件獲取信號，使用readStructuralFeature組件讀取信號中的對應參數(注意此時該參數已經替換為最新數據).當isEnabled參數的值為false時，則通過OpaqueAction組件在控制臺輸出“當前環境不符合發射條件”，并且退出整個系統.反之在控制臺輸出“當前環境符合發射條件”，之后進入下一個參數校驗.

圖10 發送信號活動圖Fig.10 Send signal activity diagram

當所有的參數都校驗成功后，進入“發送信號”狀態中，圖10為發射信號狀態下的具體內容，在該部分，通過StartObjectBehavior啟動“導彈系統”(在此之前導彈系統是處于等待狀態)，然后在參數中添加一個名為“launch”的參數并通過addStructuralFeatureValue組件給該參數賦值為true.最后通過“sent_signal”發送信號到導彈系統中，其中“send_signal”中編寫的代碼為“ALH.sentSignal(sig，o)”，最終再由導彈系統完成發射指令操作.

本次實驗，以“條件校驗功能”行為為例，在模型中開啟數據監聽，系統能夠成功收到其他客戶端發來的數據，在數據解析后順利地將數據賦值到模型對應的組件中，使模型在仿真的過程能夠讀取到最新的數據.該實驗驗證了外部平臺與模型之間數據交互的可行性.當系統的數據量十分龐大時，就能體現出該方法的優越性，能夠極大地減少勞動時間和勞動量，并且降低手動修改模型的次數，在一定程度上為模型仿真提升了效率.

5 結論

以MBSE思想為基礎，以基于SysML模型的作戰場景監測仿真為研究對象，研究了作戰場景監測仿真構建方案中基于元模型的建模方法，擴展了標準的SysML語言，通過創建構造類型的方式，建立系統功能的領域元模型，基于領域元模型搭建作戰場景監測仿真模型.并且實現了將模型中的數據與外部數據進行交互的功能.在數據交互方面，將單一化的模型向多元化的方向發展.

在未來的研究中，將繼續探索和實踐模型多元化方法.擬在現有的基礎上，一是提升軟件自動化建模能力，減少建?；ㄙM的人力物力及時間，提高建模效率.二是進一步提升數據交互的多樣性，研究將模型的數據實時傳遞到外部客戶端的方法.形成多平臺模型關聯的智能建模方案，為完成作戰任務建模提供先進的技術手段.