楊兆瑞, 于 翔, 王 堅, 魯金直, 蘭小平, 姚春波

1(電子科技大學 信息與通信學院, 成都 611731)

2(中國電子科技集團公司第二十九研究所, 成都 610036)

3(北京中科蜂巢科技有限公司, 北京 100088)

4(兵器工業(yè)信息中心, 北京 100094)

5(深圳市慧宇系統(tǒng)有限公司, 深圳 154100)

隨著現(xiàn)代作戰(zhàn)信息化與智能化演進, 作戰(zhàn)體系需要通信、機械、自動化等多個領域的復雜系統(tǒng)協(xié)同工作[1], 如何設計出高效能的作戰(zhàn)體系成為各國研究的熱點. 美國最先于1996年發(fā)布了信息通訊指揮系統(tǒng)(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance, C4ISR)[2]支持作戰(zhàn)體系開發(fā), 隨后在此框架基礎上于2003年頒布了美國國防部體系結構框架(Department of Defense Architectural Framework, DoDAF)[3]指導美軍作戰(zhàn)體系設計. 基于DoDAF的思想, 英國于2005年頒布英國國防部體系結構框架(Ministry of Defence Architecture Framework, MoDAF)[4]支持英軍作戰(zhàn)體系開發(fā), 北約于2007年發(fā)布北約結構框架(NATO Architectural Framework, NAF)[5]支持作戰(zhàn)體系開發(fā).

然而, 目前作戰(zhàn)體系的設計過程中還存在一些挑戰(zhàn), 比如:

(1)體系建模工具之間異構數(shù)據難以共享. 作戰(zhàn)體系設計涉及到多個不同領域的復雜系統(tǒng), 需要用到多種建模工具, 而這些工具建模語言不統(tǒng)一、數(shù)據結構不一致、模型組件庫不兼容, 這使得不同建模工具之間的異構數(shù)據難以共享.

(2)體系建模工具與仿真工具聯(lián)動困難. 目前大多數(shù)建模工具只支持建模, 缺乏與之配套的仿真工具. 對于體系模型的仿真往往需要移植到其他平臺中實現(xiàn),導致體系建模與仿真聯(lián)合工作難度大.

為解決上述問題, 本文提出一種多架構體系建模與仿真聯(lián)合平臺, 該平臺采用多架構建模語言(Kombination of ARchitecture Model specificAtion, KARMA)[6]支持元元模型、元模型與體系模型的形式化表達以及體系模型的仿真, 實現(xiàn)元模型設計、體系模型設計以及體系模型仿真一體化設計能力.

1 相關工作

近年來, 人們對體系設計展開了廣泛的研究. 體系設計相關研究工作主要分為兩大塊內容: 體系建模和模型仿真.

1.1 體系建模

20世紀90年代后期, 體系研究的重要性初步得到認可, 體系工程研究開始起步[7]. 2009年國際系統(tǒng)工程學會(INternational Council On Systems Engineering,INCOSE)[8]提出了基于模型的體系工程(Model-Based System of Systems Engineering, MBSoSE)概念后,MBSoSE成為了體系工程領域的研究熱點. MBSoSE使用圖形化的模型支持體系或其系統(tǒng)中要求、設計、分析、驗證和確認等活動[9], 不斷迭代這些活動完成整個體系的設計開發(fā). MBSoSE主要由建模語言、建模方法和建模工具組成.

MBSoSE的建模語言有很多種, 對象管理組織(Object Management Group, OMG)和國際系統(tǒng)工程學會INCOSE于2006年提出了統(tǒng)一建模語言(Systems Modeling Language, SysML)[10]支持體系設計中系統(tǒng)建模, 隨后又開發(fā)了支持DoDAF與MoDAF的統(tǒng)一建模標準(Unified Platform for Defense Modeling, UPDM)[11],此外還有針對特定領域模型描述的領域建模語言(Domain Specific Modeling Language, DSML)[12].

MBSoSE的建模方法有很多種, Lutz等人提出了基于agent的體系建模方法[13]； 美國國防部提出了基于能力規(guī)劃(Capability-Based Planning, CBP)的體系建模方法[14], 以能力分析為核心對體系進行建模設計； 美軍開發(fā)了聯(lián)合能力集成開發(fā)系統(tǒng)(Joint Capabilities Integration and Development System, JCIDS)[15]支持體系建模分析.

1.2 模型驗證

模型驗證旨在突破體系模型的仿真驗證技術, 支持體系設計的概念仿真驗證. 對于這方面的研究工作,Clarke等人提出了Promela[16]設計約束語言對系統(tǒng)設計進行約束, 同時搭配SPIN[17]驗證工具對模型進行驗證； 瑞典的Uppsala大學與丹麥的Aalborg大學聯(lián)合開發(fā)了一款自動驗證工具UPPAALL[18], 實現(xiàn)實時系統(tǒng)的仿真驗證； Cimatti等人開發(fā)了一款名為NuSMV[19]的模型驗證工具, 實現(xiàn)模型符號驗證.

盡管有許多的建模語言與建模方法, 但多數(shù)建模工具不能支持所有的建模語言和建模方法的實現(xiàn), 導致體系建模工具之間異構數(shù)據難以共享. 同時多數(shù)模型仿真驗證方法只支持特定的驗證工具, 導致體系建模工具與仿真工具聯(lián)動困難.

2 多架構體系建模與仿真聯(lián)合平臺

本文提出多架構體系建模與仿真聯(lián)合平臺, 設計概念圖如圖1所示, 該平臺具體流程如下: 首先基于GOPPRR (Graph, Object, Point, Property, Relationship,Role)元元模型[20], 采用GOPPRR建模方法建立特定建模語言的元模型庫； 其次基于元模型庫, 按照特定體系設計框架進行體系建模； 最后針對建立的體系模型,通過混合有限狀態(tài)機仿真技術對體系行為進行仿真.整個平臺采用KARMA多架構建模語言實現(xiàn), 從而支持元元模型、元模型與體系模型的形式化表達與體系模型仿真的無縫銜接.

圖1 多架構體系建模與仿真聯(lián)合平臺

2.1 模型設計

模型設計涵蓋元模型層與體系模型層. 基于M0-M3建模層級[21], 采用GOPPRR建模方法[20]建立元模型與體系模型. 如圖2該建模層級將模型分為4個層次, 分別是M3 (元元模型)、M2 (元模型)、M1 (體系模型)和M0 (真實視角), 其中M3與M2層為平臺中元模型層, M1與M0層為體系模型層. M3層包括圖、對象、點、屬性、關系和角色6種元元模型[17], 首先,通過元元模型建立M2層的不同建模語言的元模型庫；其次, 基于建立的元模型庫, 通過實例化元模型建立M1層中描述體系視角的模型； 最后, 通過M1層中的模型來表達M0層中真實體系的不同視角.

圖2 M0-M3建模層級

2.1.1 M3元元模型層

M3層為元元模型層, 代表最高抽象程度的模型,是對元模型的抽象表達. 6種元元模型分別是圖、對象、屬性、點、角色和關系, 其含義如下:

(1)對象(object): 可以單獨存在的模型. 即可以獨立于角色和關系而存在, 也能與其他對象進行連接.

(2)屬性(property): 不能單獨存在,只能附屬在其他元元模型上表達對應參數(shù)或特征值.

(3)關系(relationship): 用于表達兩個對象之間的連接關系, 通過角色和對象進行連接.

(4)點(port): 附屬在對象上的模型, 用于表示對象上能夠與關系連接的接口.

(5)角色(role): 存在于連接對象的關系兩端的模型, 用來表示對象或對象的點之間連接.

(6)圖(graph): 圖由以上5種元元模型組成, 用于描述體系視角的模型.

通過6種元元模型的組合, 開發(fā)M2層特定建模語言的元模型.

2.1.2 M2元模型層

M2層為元模型層, 元模型由6種元元模型組合而成, 用于描述特定建模語言, 元模型設計流程如下:

(1)定義屬性元模型, 用于描述其他元模型的參數(shù)或特征值, 支持其他元模型的引用.

(2)定義點元模型, 為其添加屬性元模型, 并定義其方向, 包括輸入、輸出和無向3種, 支持附屬在對象元模型上, 描述對象上用于連接關系的接口.

(3)定義對象元模型, 添加對象名稱, 并對不同對象元模型添加特有的屬性元模型, 同時包含接口的對象需要添加點元模型.

(4)定義關系元模型, 添加關系名稱, 并對不同關系元模型添加其特有的屬性元模型, 支持連接兩個對象, 描述對象之間的交互關系.

(5)定義角色元模型, 添加角色名稱, 并對不同角色元模型添加其特有的屬性元模型, 支持對象與關系的連接, 描述對象的連接方式.

(6)定義圖元模型, 首先, 添加其含有的對象元模型、關系元模型與角色元模型； 其次, 定義關系與角色的連接； 最后, 定義對象或對象上的點與角色的連接關系.

本文以DoDAF八個視角對應的UPDM (Unified Platform for Defense Modeling)標準下的元模型為例,基于GOPPRR元元模型相互組合, 建立UPDM標準的元模型庫, 如對象元模型“作戰(zhàn)節(jié)點”、屬性元模型“作戰(zhàn)名稱”、點元模型“資源出口”和關系元模型“資源交互”等.

2.1.3 M1體系模型層

M1層為體系模型層, 基于特定建模語言的元模型庫, 按照特定體系設計框架, 通過實例化6類元模型建立描述體系的模型.

以DoDAF框架下的作戰(zhàn)視圖為例, 作戰(zhàn)視圖所包含的模型圖及描述如表1所示. 基于UPDM標準元模型庫, 首先實例化對象元模型、屬性元模型、點元模型、關系元模型與角色元模型, 其次通過這5類元模型的組合實例化出描述體系的圖模型, 例如圖模型“OV-2作戰(zhàn)資源流描述”. 圖模型需要根據DoDAF框架的作戰(zhàn)視圖建模順序進行建立, 作戰(zhàn)視圖建模順序如圖3所示.

圖3 作戰(zhàn)視圖建模順序

表1 作戰(zhàn)視圖模型圖描述

2.1.4 M0真實視角層

M0層為真實的體系視角, 基于M1層建立的體系模型, 建立描述真實體系的不同視角, 如基于M1層建立的OV-1、OV-2、OV-3、OV-4、OV-5b、OV-6a、OV-6b及OV-6c共8張模型圖, 組成DoDAF框架的視角“作戰(zhàn)視圖”, 支持作戰(zhàn)任務使命、環(huán)境及資源交互的描述. 此外還包括“能力視圖”“服務視圖”“全景視圖”“標準視圖”“數(shù)信視圖”“系統(tǒng)視圖”及“項目視圖”共8個視角, 支持從不同角度描述真實體系.

2.2 模型驗證

基于混合有限狀態(tài)機的狀態(tài)仿真技術, 對描述體系動態(tài)行為的模型進行仿真, 根據仿真結果對體系行為中的各對象參數(shù)與變量進行分析, 驗證其變化是否滿足設計需求, 同時支持根據仿真結果進行方案權衡.狀態(tài)仿真技術的原理圖如圖4所示.

圖4 狀態(tài)仿真原理圖

如圖4所示, 狀態(tài)仿真技術基于KARMA語言, 實現(xiàn)體系行為模型的形式化表達. 體系行為模型包含圖屬性、狀態(tài)屬性、狀態(tài)變遷屬性以及對象屬性4種模型屬性, 其含義如下:

(1)圖屬性: 該屬性描述狀態(tài)機圖中需要用到的初始變量與參數(shù), 如任務場景中的“飛機狀態(tài)”初始值為“靜止”及“雷達開啟狀態(tài)”初始值為“關閉”等, 支持描述場景中的各種初始變量與參數(shù).

(2)狀態(tài)屬性: 該屬性描述狀態(tài)機圖中每個狀態(tài)的屬性, 包括狀態(tài)名稱, 以及該狀態(tài)下的環(huán)境參數(shù), 如飛機的“加速”狀態(tài)下的環(huán)境風速參數(shù)等, 支持描述體系行為中包含的狀態(tài).

(3)狀態(tài)變遷屬性: 該屬性描述狀態(tài)機圖中各個狀態(tài)之間的變遷屬性, 包括狀態(tài)之間變遷的條件, 如兩個對象之間的距離小于100時跳轉至下一個狀態(tài)等, 以及變遷時的執(zhí)行動作, 如飛機跳轉至“探測”狀態(tài)時將飛機的探測雷達狀態(tài)置為“開啟”等, 支持描述體系行為中對象的狀態(tài)跳轉.

(4)對象屬性: 該屬性描述狀態(tài)機圖中的對象的屬性, 包括對象在整個行為中的參數(shù), 如飛機的長、寬、高等, 以及參數(shù)變化的數(shù)學公式, 如飛機的速度公式與耗油公式等, 支持針對體系行為中對象的各種參數(shù)的動態(tài)變化進行分析.

首先, 通過多架構建模語言定義4種模型屬性； 其次, 基于4種模型屬性合成語言仿真片段； 最后, 將語言仿真片段導入混合狀態(tài)機求解器中求解得出仿真結果, 實現(xiàn)針對描述體系動態(tài)行為的模型進行仿真.

3 案例分析

本文案例以空地協(xié)同防御體系中的人機協(xié)同防御場景為例, 使用多架構體系建模與仿真聯(lián)合平臺對場景進行體系設計, 驗證該平臺支持體系設計的有效性.

3.1 案例場景描述

空地協(xié)同防御體系中的人機協(xié)同防御場景的作戰(zhàn)任務概念圖如圖5所示. 敵軍入侵我方領地被我方雷達檢測信號捕獲后, 我方雷達控制中心指揮戰(zhàn)機出擊,尋找敵機并驅逐敵機. 隨后, 戰(zhàn)機尋找敵方戰(zhàn)車并追蹤敵方戰(zhàn)車. 敵方戰(zhàn)車撤離后, 雷達控制中心指揮戰(zhàn)機前往指定區(qū)域收集地面圖像信息. 最后, 戰(zhàn)機前往指定區(qū)域肅清, 保證區(qū)域內無敵軍后返回基地.

針對作戰(zhàn)場景的設計, 存在戰(zhàn)機的任務所需時間、耗油量及飛行高度等需求指標, 設計中需要滿足這些指標, 如表2所示. 本文給出假想的敵方偵察機以及我方幾架備選戰(zhàn)機的性能指標, 如表3所示.

表2 任務需求指標

表3 戰(zhàn)機性能指標

3.2 案例實現(xiàn)

首先, 基于GOPPRR元元模型建立UPDM標準元模型庫； 其次, 基于UPDM標準元模型庫, 按照DoDAF框架建立場景的作戰(zhàn)視圖模型； 最后, 基于作戰(zhàn)視圖模型, 通過混合有限狀態(tài)機仿真技術對作戰(zhàn)任務中的戰(zhàn)機狀態(tài)進行仿真, 并根據仿真結果與任務指標進行出擊戰(zhàn)機方案權衡.

3.2.1 UPDM標準元模型建立

基于GOPPRR元元模型建立DoDAF八個視角對應的UPDM標準下的元模型庫, 建立的元模型庫包含DoDAF的8個視角共52張圖所對應的所有UPDM標準元模型(由于UPDM元模型庫數(shù)量過多, 本文只列出DoDAF中的OV-2對應元模型庫供參考), 本文提出的平臺以MagicDraw[22]工具中元素為參考進行元模型設計, 建立的OV-2元模型如表4所示.

表4 多架構體系建模與仿真聯(lián)合平臺 OV-2元模型(MagicDraw OV-2元素)列表對比

3.2.2 UPDM體系建模

基于UPDM標準下的作戰(zhàn)視圖元模型庫, 根據2.1.3節(jié)介紹的作戰(zhàn)視圖的建模順序建立體系模型, 建立人機協(xié)同防御場景作戰(zhàn)視圖模型如圖6所示.

圖6 作戰(zhàn)視圖模型

(1)首先建立作戰(zhàn)概念部分. 建立OV-1分析人機協(xié)同防御場景任務的高層作戰(zhàn)概念圖及功能需求, 描述作戰(zhàn)任務的概念流程.

(2)隨后建立組織、指揮關系部分. 建立OV-4描述作戰(zhàn)任務中我方的參與組織結構關系來明確作戰(zhàn)中的指揮層級關系.

(3)明確了作戰(zhàn)概念、功能需求和組織結構后建立作戰(zhàn)流程部分. 首先建立OV-5b, 以活動圖的方式建立出整個防御場景作戰(zhàn)流程以及每個作戰(zhàn)活動所需要的觸發(fā)條件； 其次建立OV-6a, 給出場景中的我方各要素的性能邊界, 以此作為選擇作戰(zhàn)方案的指標； 最后建立OV-6b和OV-6c, OV-6b以狀態(tài)機圖的方式描述出各作戰(zhàn)節(jié)點的狀態(tài)變化, 描述出作戰(zhàn)順序, 以及作戰(zhàn)之間的轉換、OV-6c以序列圖的方式, 強調了各作戰(zhàn)節(jié)點之間的信息交互事件和時間順序.

(4)最后建立作戰(zhàn)活動間的資源和信息交互關系.分別建立OV-2和OV-3. OV-2描述了人機協(xié)同防御場景作戰(zhàn)活動之間的信息交換和依賴關系, 反映了作戰(zhàn)節(jié)點之間的信息需求, 形成信息流動網絡. OV-3具體描述了每個節(jié)點之間交互所產生的資源和信息, 反映作戰(zhàn)節(jié)點之間的連通性.

基于圖6中建立的體系模型進行仿真并通過仿真結果對我方戰(zhàn)機指標進行評估實現(xiàn)出擊戰(zhàn)機方案權衡.

3.2.3 狀態(tài)仿真

本文案例任務中出擊戰(zhàn)機有3架戰(zhàn)機備選, 存在戰(zhàn)機的任務執(zhí)行正確性、任務所需時間和耗油量這3個任務指標進行對比分析, 選出最佳出擊戰(zhàn)機. 本文使用狀態(tài)仿真技術對建立的體系模型中的狀態(tài)機圖“OV-6b作戰(zhàn)狀態(tài)轉換模型”進行動態(tài)仿真. 首先根據仿真結果來驗證作戰(zhàn)任務中戰(zhàn)機狀態(tài)轉換流程是否符合預期設計, 其次根據仿真結果的戰(zhàn)機執(zhí)行任務時間和耗油量兩個參數(shù)來對比分析選出最佳出擊戰(zhàn)機, 狀態(tài)仿真設計順序圖如圖7所示.

圖7 OV-6b狀態(tài)轉移模型及狀態(tài)仿真設計順序

首先, 定義狀態(tài)機圖中戰(zhàn)機對象的屬性, 如戰(zhàn)機的加速度公式、初始速度與最大推力等參數(shù)及變化公式；其次, 定義狀態(tài)機圖的圖屬性值, 如雷達開關狀態(tài)、我方戰(zhàn)機加速狀態(tài)與敵機加速狀態(tài)等場景中的初始變量與參數(shù)； 隨后, 定義每個狀態(tài)具有的屬性值, 如狀態(tài)名稱； 最后, 定義每個關系的狀態(tài)變遷屬性, 如敵機距離雷達1000 km時轉移到下個狀態(tài)且執(zhí)行我方戰(zhàn)機加速狀態(tài)開啟等轉換條件和執(zhí)行動作.

根據上述設計完成狀態(tài)仿真圖如圖8所示.

如圖8(a), 為更清晰的看出作戰(zhàn)過程, 本次仿真時只選取了3個對象與我方領地的距離參數(shù)顯示在圖中,其余的均不顯示. 圖中橙色線為我方戰(zhàn)機與領地的距離隨時間的變化曲線、綠色線為敵方戰(zhàn)車與領地的距離隨時間的變化曲線、紅色線為敵方戰(zhàn)機與領地的距離隨時間的變化曲線. 首先3張圖曲線顯示我方戰(zhàn)機狀態(tài)轉換均滿足設計的作戰(zhàn)任務流程, 其次可以看出3架戰(zhàn)機完成任務的時間分別是47.5 min、51.8 min和50.1 min, 均滿足約束“任務完成時間小于52 min”.

如圖8(b), 本次仿真僅顯示戰(zhàn)機執(zhí)行任務過程中的耗油量的隨時間的變化曲線, 其中紅色線為備選戰(zhàn)機一的耗油量隨時間的變化曲線、黃色線為備選戰(zhàn)機二的耗油量隨時間的變化曲線、綠色線備選戰(zhàn)機三的耗油量隨時間的變化曲線. 3架戰(zhàn)機完成任務的耗油量分別是2451 kg, 2875 kg和1141 kg, 均滿足約束“耗油量小于3000 kg”. 數(shù)據表格如表5所示. 根據表5結果進行對比分析, 首先3架戰(zhàn)機的3個指標都滿足約束,均可以選擇； 其次任務完成時間最短的為備選戰(zhàn)機1,耗油量最少的是備選戰(zhàn)機3, 但是備選戰(zhàn)機3在任務完成時間只比備選戰(zhàn)機1少2.6 min的情況下, 耗油量幾乎是備選戰(zhàn)機1的一半, 因此案例中選擇備選戰(zhàn)機3作為出擊戰(zhàn)機實現(xiàn)方案權衡.

圖8 備選戰(zhàn)機狀態(tài)仿真結果

4 總結

本文提出一種多架構體系建模與仿真聯(lián)合平臺,該平臺采用KARMA語言支持元模型設計、體系建模以及體系模型的仿真, 實現(xiàn)元模型設計、體系模型設計以及體系模型仿真一體化設計能力. 首先, 基于GOPPRR元元模型, 實現(xiàn)用于設計作戰(zhàn)場景的UPDM標準元模型庫建立； 其次, 基于UPDM標準元模型, 按照DoDAF框架, 實現(xiàn)對作戰(zhàn)場景的作戰(zhàn)視圖模型建立； 最后, 基于建立的體系模型, 通過狀態(tài)仿真技術, 實現(xiàn)對作戰(zhàn)任務中戰(zhàn)機狀態(tài)轉換的仿真, 并通過仿真結果對出擊戰(zhàn)機方案的進行權衡選擇. 為了驗證該平臺的有效性, 本文以人機協(xié)同防御場景為例, 采用該平臺進行體系設計. 案例證明了該平臺支持體系設計的有效性, 實現(xiàn)了對案例場景的建模、仿真一體化設計以及模型數(shù)據與仿真數(shù)據的整合分析, 解決了目前體系設計方法中存在的不足, 完成體系設計方法的改進.