段雨昕,卿杜政,周敏,王源源
(1.中國航天科工集團有限公司 第二研究院,北京 100854;2.北京仿真中心 航天系統仿真重點實驗室,北京 100854; 3.北京電子工程總體研究所,北京 100854)
仿真系統根據系統中人員參與和仿真模型的組成關系不同可分為實況仿真(live simulation)、虛擬仿真(virtual simulation)、構造仿真(constructive simulation)[1-2]。構造仿真重點應用于對戰爭的分析和演練。其在軍事領域應用廣泛,涵蓋了武器裝備效能評估、模擬戰爭過程和基于仿真的試驗評估等。構造仿真系統具有人員參與少,系統自身閉環,批量運行,運行過程中計算量大和數據處理要求高的特點[3]。
目前國內構造仿真中構建分布式仿真系統時通常是基于HLA標準,使用運行支撐環境(run time infrastructure,RTI)[4]。在構造仿真中仿真軟件存在重新建模帶來的仿真可信度問題[5]。而且模型的校核也需要大量的工作,難以與裝備的研制同步進行。隨著實際裝備不斷的更新換代,仿真模型開發者為保證與實裝同步需要進行大量重復的開發工作。
使用實裝軟件接入構造仿真系統是提高仿真置信度與仿真效率,減少仿真系統開發建模重復工作的重要途徑。但因為實裝軟件與仿真系統軟件的通信機制和時間管理策略都存在差異,所以需要通過適配中間件的形式使實裝軟件和仿真平臺間實現交互信息的正確傳遞和統一的時間管理。通信組件將實裝軟件的網絡通信數據轉換成為HLA標準的交互類消息通過RTI分發。時統組件統一仿真系統中各個實裝軟件的時間來實現仿真系統的時間一致性。
HLA并不考慮怎么在對象的基礎上構建成員,它重點在于解決構建聯邦的問題。它把仿真支撐環境的工作和聯邦成員的開發工作作為2部分,將運行管理工作還有通信工作與仿真功能分別進行[6]。HLA以面向對象的思路來構建、研發和應用仿真對象模型,進而能夠使這樣開發出來的仿真聯邦擁有很好的互操作和可重用性[7-8]。RTI按照HLA的接口規范標準進行開發,它具體支持了HLA規范中的服務,使基于HLA標準開發的軟件在RTI平臺的支撐下組成分布式仿真系統成為可能。基于HLA標準的仿真系統邏輯結構如圖 1所示。

圖1 HLA標準的仿真系統邏輯結構Fig.1 Logic structure of HLA simulation system
HLA所規定的是一種分布式仿真標準體系,RTI是基于HLA標準結構的軟件實現。HLA標準定義的通信是以對象類和交互類的發布/訂閱來完成聯邦成員之間的信息交互。由對象管理服務統一對聯邦執行過程中的信息交互進行管理。HLA/RTI的時間推進方式可以分為3類:基于步長的時間推進,基于事件的時間推進以及樂觀的時間推進。最為常用的是采用固定步長和基于下一事件的時間推進方式[9]。
實裝軟件是武器系統實際裝備軟件的簡稱,一般具有多個節點,是多個軟件組成的一套整體運行的軟件集合。部分實裝軟件具有高實時性要求,是在VxWorks硬實時操作系統上開發運行的。還有部分軟件是在Windows系統上直接運行的。本研究中基于VxWorks系統的實裝軟件經過操作系統移植后,能夠正確在Windows+RTX(8.1.2)系統上運行且測試通過。
實裝軟件之間通信主要通過網絡套接字實現,在與HLA集成之前需要采用模擬套接字方式通過共享內存進行通信數據接管[10-11]。實裝軟件時間來源一般是GPS等硬件授時設備,也可以采用本機時間作為相對時間來執行任務。
根據實裝軟件仿真適配中間件數據交互方式以及時間管理策略,通過與HLA/RTI的標準進行通信適配并采用統一的時統技術,構建集成運行的仿真系統。
本文提出實裝軟件接入仿真平臺總體架構如圖2所示,圖中的實裝軟件都可以運行在Windows系統上,仿真適配中間件承接了實裝軟件的網絡通信,以共享內存的形式提供了通信數據的接口。通信組件和時間統一組件則完成了與仿真平臺的信息交互和時間同步。通信組件使實裝軟件原本基于網絡傳遞的消息以HLA標準的交互類進行交互。通過RTI發送實裝軟件需要發送的數據,同時從RTI接收其他節點的交互數據。時間統一組件則主要完成仿真系統和實裝軟件間的運行時間、任務同步等方面的匹配,從而保證實裝軟件運行時序正確。

圖2 仿真集成總體架構Fig.2 General structure of integrated simulation system
實裝軟件的通信消息從原本的網絡套接字的形式通過共享內存機制,分別以接收共享內存和發送共享內存的形式提供數據對其他進程的共享通道。因此通信組件的功能是制定通用的HLA交互數據協議,通過RTI標準接口將數據正確發送和接收。
3.1.1 交互協議模型
為了使通信組件的數據交互協議能夠盡可能的通用,本文只定義了交互類并沒有定義對象類,也沒有對消息的內容進行區分。本文定義的交互類只設計了一個基類BaseMsg。其他的交互類則繼承自該基類,因此也繼承了基類中的全部參數。在HLA聯邦數據傳輸中有reliable模式和best_effort模式,reliable模式在RTI中使用TCP協議發送,保持消息可靠性,而best_effort模式RTI中采用UDP方式發送[12]。本文考慮到使用的網絡環境是局域網基本不存在丟包的現象,因此交互類消息全部采用best_effort方式,而且希望設計的組件盡量具有通用性因此只使用一個交互類基類進行交互。以繼承自BaseMsg 類的A_Inter和B_Inter 2個交互類為例,對象數據模型如下:
(interactions)
…
(class BaseMsg best_effort receive
(parameter SendSockAddr)
∥發送方IP地址
(parameter RecvSockAddr)
∥接收方IP地址
(parameter CurrentTime)
∥發送時間
(parameter EventTime)
∥事件發生時間
(parameter MsgType)
∥消息類型
(parameter CommType)
∥通訊類型
(parameter MsgLength)
∥消息長度
(parameter MsgContent)
∥消息內容
(class A_Inter best_effort receive)
∥繼承自BaseMsg的交互類A
(class B_Inter best_effort receive)
∥繼承自BaseMsg的交互類B
…
(class _Outer best_effort receive)
∥繼承自BaseMsg的交互類B
)
)
上面定義的_Inter類對應著一套閉環運行的軟件的內部的交互,當需要多套軟件之間交互時還需要訂購與發布_Outer類。
3.1.2 交互類發布/訂購模式
交互類的發布/訂購模式如圖 3所示,如果所有成員采用統一的BaseMsg交互類進行發布和訂購會使A組內的成員間的消息也被B組成員接收,因而降低網絡傳輸效率。本研究采用的是為組成一個火力單元的實裝軟件定義單獨的交互類的模式。以圖中結構為例,定義A_Inter,B_Inter 2種交互類。其中A_Inter用于A組內成員的交互,B_Inter用于B組內成員的交互。如果A組成員需要與B組成員交互則通過_Outer類進行。通過這種方式可以有針對性地對交互類進行管理與擴展,避免網絡中的通信冗余。

圖3 交互類發布/訂購關系圖Fig.3 Relation structure of interactive publishing & subscription
RTI支持HLA標準的交互類數據的訂購與發布功能,在仿真聯邦運行過程中通過標準的數據發送和數據接收接口可以實現交互類數據的發送與接收。
當實裝軟件要通過RTI發送交互數據時,其在仿真適配中間件中設置了一個發送信息的回調函數,該函數回調RTI交互數據發送標準接口。在RTI平臺接收到交互數據需要傳遞給實裝軟件時,RTI的接收消息處理框架中調用通信組件提供的接收消息處理接口函數。交互數據的發送和接收信息流程如圖4所示,圖中上半部分是通信組件與實裝軟件的信息流程本文不再贅述,下半部分SendMsg()與SubmitRecvMsg()是RTI與通信組件的數據發送和接收的函數接口。

圖4 交互數據信息流程示意圖Fig.4 Schematic flow chart of interaction message
時間統一組件實現實裝軟件與RTI多個節點軟件的同步運行功能和時間管理功能。
在RTI基于步長推進方式的框架中控制仿真周期任務的函數為OnStep( )也稱為周期調度函數。它隨著每一幀的仿真運行不斷的循環執行,每執行完一次都使仿真時間推進一個周期[13]。實裝軟件運行時同樣具有周期定時執行的任務。同步控制需要把RTI周期調度函數與實裝軟件的周期任務進行同步。在RTI周期調度函數開始時觸發實裝軟件的任務運行信號量,任務結束后設置結束信號量通知RTI。如此采用信號量控制的方式與RTI的周期調度函數進行同步,實現同步控制功能。
本文中同步控制函數有2組共4個。其中一組為部署在實裝軟件端的WaitingForEnterOnStep( )和ExitOnStep( )函數,另一對為部署在RTI仿真集成框架周期調度函數OnStep()中的EnterOnStep( )和WaitingForExitOnStep( )函數。
其中EnterOnStep( )和ExitOnStep( )函數的實現主要是借助RTX的系統事件觸發函數RtSet-Event( )[14]。其功能是使括號內的特定的事件激活。
而與之對應的WaitingForEnterOnStep( )和WaitingForExitOnStep( )函數的實現主要是借助RTX的事件等待函數RtWaitForSingleObject( )。其功能是等待括號內的特定事件處于激活狀態直到事件超時。
在此基礎上能夠實現RTI的周期調度函數對實裝軟件的運行周期進行同步調度。WaitingForEnterOnStep( )部署在實裝軟件周期控制函數的周期開始之前, ExitOnStep( )函數部署在周期結束后。同理在RTI生成的仿真框架中的周期調度函數開始位置部署EnterOnStep( )函數,在周期結束位置部署WaitingForExitOnStep( )函數。通過RTX事件控制函數就可以完成同步控制任務,其同步過程如圖 5所示。

圖5 同步控制過程圖Fig.5 Procedure chart of synchronous control
(1) 實裝軟件中需要同步的任務在初始化之后進入等待信號量狀態;
(2) RTI周期調度函數中EnterOnStep激活處于等待狀態的任務,實裝周期任務開始執行;
(3) 周期任務執行結束后由ExitOnStep通知RTI周期調度函數;
(4) RTI周期調度函數接收到ExitOnStep信號量,向聯邦申請時間推進;
(5) RTI時間管理推進仿真時間后繼續本同步過程。
循環等待機制的功能是實現實裝軟件的運行線程與仿真運行的主線程之間相互協調。保證實裝軟件在運行過程中與仿真執行的主線程在運行時間不一致時能夠統一調度,防止線程阻塞而影響仿真運行。循環等待機制通過在RTI周期調度中獲得本成員節點的實裝軟件調度結束的標志,但其它成員節點的調度并未結束時循環調用RTI標準接口的等待函數進行等待。當所有節點的實裝軟件都發出周期調度結束標志后,循環等待任務結束,向RTI發出時間推進請求。
基于VxWorks系統的實裝軟件在沒有硬授時設備時系統采用tick數作為任務運行的時間參考標志[15]。軟件移植的時候已經采用RTX定時器的方式實現了一個硬實時的時鐘tick計數器,并設置有計數器的啟動和停止的標志位。
當實裝軟件與HLA/RTI仿真平臺集成之后,軟件運行的時間應該以仿真實際執行的時間為標準,通過RTI統一進行時間的推進。而如果實裝軟件依然在運行時按照本身系統時鐘的tick數執行任務,則會出現運行時序與任務邏輯的錯誤。本文采用的方法是通過控制實裝軟件時鐘tick計數器啟停的方法,在接入仿真系統后停止時鐘tick計數器的目的。
TicksRunning標志位是控制時鐘tick計數器的標志,其值為0時系統內tick數不再隨物理時間進行自加,值為1時系統tick數隨物理時間繼續執行自加。該標志位部署在實裝軟件同步控制函數前。同步控制函數發出激活實裝軟件周期任務事件之前將TicksRunning標志位置0,在實裝軟件周期任務執行結束事件之后將系統tick數加一個周期時間。如此部署后,實裝軟件內部任務執行時讀取的tick數實際上就是仿真任務執行的時間。
本文中的適配中間件已經成功的應用在一個基于實裝軟件的分布式仿真系統中。系統組成如圖 6所示。
計算機A上的各個雷達軟件組成的小閉環系統運行狀態正常,雷達主控軟件通過RTX輸出面板顯示軟件運行狀態信息無異常無報錯。計算機C上指控軟件和發射車軟件工作狀態正常,顯控顯示各軟件狀態更新正確。雷達系統能穩定跟蹤目標,向指控發送目標信息,指控系統判斷后發出打擊指令,完成攔截任務。系統整體運行狀態與實際裝備狀態一致,證明軟件交互正確、時間管理正確、邏輯正常。
采用線程模式對同一仿真場景進行20次重復試驗并記錄。仿真虛擬時間需要750~800 s的情況下,仿真系統都可以在實際物理時間520~620 s完成仿真執行。仿真加速比記錄如表1所示。系統平均加速比為1.37,證明系統具有一定超實時運行能力。

圖6 典型應用系統組成Fig.6 Structure of typical application system

次數加速比次數加速比11.26111.4021.23121.3931.36131.4541.48141.2451.53151.3361.35161.3171.38171.4281.42181.4091.38191.32101.45201.37
注:平均加速比:1.37
本文提出了一種以實裝軟件為基礎構建HLA仿真系統的方法。重點分析了帶有仿真適配中間件的實裝軟件通信機制和時間管理機制。通過設計統一交互類協議實現了實裝軟件通信消息以交互類的形式通過RTI平臺進行發送和接收的方法,并以同步控制機制和相應的時間管理策略實現對實裝軟件與仿真平臺運行時間的統一管理。最后由一套實裝軟件作為仿真節點接入到閉環仿真系統中的實際應用驗證了該方法的可行性和優勢。未來可探索基于Windows系統的自主可控的集成中間件技術方案,提升本研究應用深度。