王 洋 薛 靜 劉春龍 武詠晗
北京航天自動控制研究所,北京100854
隨著航天產品在信息化、體系化、自主化和智能化等方面的飛速發展,軟件在整個系統中的重要性日益提高,軟件的規模越來越大、關鍵程度越來越高,軟件的質量與可靠性已經成為影響航天產品質量與可靠性的重要因素。軟件測試是目前普遍采用的提高軟件質量的重要手段,是軟件質量保證工作中的重要環節之一[1]。
根據QJA30A的要求,需要針對航天型號軟件進行軟件配置項測試和系統測試[2]。在配置項測試時通常采用全數字仿真測試平臺作為測試工具,該工具的優點是透明性好,可控性強,易于注入測試數據,對小概率、安全關鍵功能的測試可以提供有效的手段支持。另外,被測軟件代碼不需要插樁,在不做任何改動的情況下,就可以完成對被測軟件的非侵入式測試[3]。這種方法能夠較好地驗證被測軟件內部的功能和性能特性,在軟件系統復雜度較低的前提下,通過配置項測試可以得到較好的驗證效果,但是配置項測試是一種較為孤立的測試,難以發現軟件系統中配置項之間的接口和時序匹配方面可能存在的缺陷。
隨著航天系統復雜度提高,系統狀態空間與軟件運行剖面的數量膨脹,由于很多問題都是各子系統之間時序與運行狀態不匹配造成,因此系統級軟件測試越來越重要。而現階段的系統級軟件測試仍然擺脫不了對硬件設備的依賴,故障仿真的難度大,很多情況下由于受限于安全性和成本,系統測試的覆蓋性難以達到預期。因此急需開展系統級虛擬測試環境的研究工作。
本文研究了系統級測試環境構建方法,基于操作系統提供的進程間通訊技術,突破了多虛擬測試環境數據交換與時間同步的技術難點,為系統級測試環境構建提供了一個高效、可行的解決方案。
虛擬測試環境以真實箭載目標代碼為對象,利用軟件仿真技術逼真地模擬物理硬件目標系統,使運行于真實目標系統上的嵌入式軟件,可以不加修改直接在全數字仿真測試平臺上運行,并且其運行的動態特性與在真實目標機上一致,能夠讓硬件和軟件開發人員同時進行系統定義、軟件開發、集成和部署。單處理器的虛擬測試環境分層結構如圖1所示。

圖1 虛擬測試環境分層結構圖
由圖1可知虛擬測試環境是基于虛擬內核的分層結構,而系統級測試環境需要使多個虛擬測試環境形成一個閉環互聯的有機整體,在構建過程中需要解決2個關鍵問題:
1)數據交換:在運行過程中,一個虛擬環境通過接口的輸出將作為另一個虛擬環境的接口輸入,為了保證系統級虛擬環境運行的正確性,必須實現嵌入式系統之間的數據流仿真;
2)同步運行:在Windows操作系統中,每個虛擬測試環境作為一個單獨的進程運行。由于Windows不是實時操作系統,因此每個進程獲得的運行時間片并不相同,導致每個虛擬環境中運行的嵌入式軟件的虛擬時間有偏差。為了保證系統時序的一致性,必須實現多個虛擬測試環境的同步機制。
虛擬測試環境是操作系統中的一個進程,為了實現多個虛擬測試環境協同運行,考慮采用操作系統提供的進程間通訊機制,設計相應的數據傳輸與同步運行流程。在選擇進程間通訊機制時,需要從運行效率、可靠性2方面進行考察,既要保證虛擬環境之間的同步協作不會對運行時間造成過多負載,也要確保虛擬環境彼此發送的數據能夠完整可靠地發送到目的地址。
IPC是進程間通訊(interprocess communication)的簡稱。傳統上該術語描述的是運行在某個操作系統之上不同進程間消息傳遞的不同方式。最早的IPC機制由UNIX提出,主要有以下幾種方式[4]:
1)進程共享留存于文件系統中某個文件上的某些信息。為訪問這些信息,每個進程都需要通過系統調用穿越內核。當一個文件有待更新,某種形式的同步是必要的,這樣既可以保護多個寫入者,防止彼此相互串擾,也可以保護一個或多個讀出者,防止寫入者的干擾。
2)進程有一個雙方都能訪問的共享內存區。每個進程一旦設置好該共享內存區,可以根本不涉及內核就訪問其中的數據。Windows中的管道就是這種方式。
3)進程之間的數據傳輸通過網絡接口,進程可以在同一臺主機也可以在網絡互連的不同主機。進程的交互可以是基于流模式(TCP)——流模式中的數據需要確定的格式,以保證區分不同消息的邊界;也可以是消息模式(UDP、SCTP)[5]。
通過本地文件系統進行IPC的方式在每次進程同步過程中都要訪問磁盤,對運行效率有很大影響,因此本文在基于網絡和基于共享內存2種IPC方式之間進行選擇。
DDS是對象管理組織(OMG)制定的實現訂閱/發布通訊模式、滿足實時性要求的軟件設計標準和規范,該規范對分布式實時系統中的數據發布、傳遞和接收的接口和行為進行了標準化。DDS純粹以數據為中心分發數據,用QoS參數描述資源狀況、對資源的期待程度及網絡狀況等,大大增強了通訊的實時性和靈活性,簡化了分布式系統中數據的有效發布,為實時環境下以數據為中心的分布式應用提供高效、有用的通訊服務,其特點如下[6]:
1)具有開放式體系結構,提供規范的接口、服務和數據格式,使業務應用系統軟件可以輕松正確地實現移植、互操作和交互的功能;
2)具備共享數據能力,無需考慮數據生產者和使用者實際的物理地址和在組織架構中的位置;
3)支持以數據為中心的、高效的訂閱/發布模式。
DDS規范描述了2個層次的接口:以數據為中心的發布/訂閱層(DCPS)和數據本地重構層(DL-RL),其結構如圖2所示。

圖2 DDS結構圖
DCPS層是DDS的基礎層,為應用軟件提供了數據發布和訂閱的功能,使發布者能夠識別數據對象并發布數據;DLRL層是建立在DCPS層之上的一個可選層,能夠將服務簡單地集成到應用層,在數據更新后自動重組數據,并通知訂閱者及時更新。該模型中數據收發雙方均無需了解對方物理駐留位置、駐留形式,實現了通信雙方時間、空間和數據通信的多維松散耦合[7]。
管道(PIPE)是一個以共享內存為基礎的進程間通訊技術。創建管道的進程作為管道服務器(pipe server),連接該管道的進程作為管道客戶端(pipe client)。管道一端的進程向該管道中寫入數據,管道另一端的進程就能夠讀取到該數據。
Windows系統中的管道分為匿名管道與命名管道:
1)匿名管道:創建匿名管道不需要名稱作為參數,匿名管道是半雙工管道,管道服務器和管道客戶端各操作2個句柄,原理如圖3,進程1和進程2使用各自的2個句柄HD[0]和HD[1]操作管道。

圖3 匿名管道
2)命名管道:命名管道是一個全雙工管道,管道雙方可通過一個句柄完成數據收發操作,由操作系統維護獨立的接收緩沖與發送緩沖,Windows中的命名管道客戶程序本質上通過文件接口使用命名管道[8]。同時,命名管道提供了一對多的功能,可以使管道服務器并行地與多個管道客戶端交互,原理如圖4。

圖4 命名管道
為了盡量提高虛擬測試環境的運行效率,要保證多個測試環境之間數據傳輸的高效率,因此需要對2種常用的進程間通訊技術的數據傳輸吞吐量與代碼執行效率進行對比。本文通過實現2個示例進程,進程間傳遞的數據選取2種數據塊粒度,分別為1K字節和4K字節;傳輸次數為10000、50000、100000次;分為持久化和非持久化2個執行場景,編寫用例進行考核。具體比對條件及硬件平臺規格見表1:

表1 傳輸速率及執行效率比對條件
通過在相同執行平臺執行上述比對條件,得到的DDS與PIPE執行時間(單位:s),具體結果見表2和3。

表2 數據非持久化場景下傳輸速度與執行時間

表3 數據持久化場景下傳輸速度與執行時間
由表2和3的結果可知,PIPE在非持久化場景下的傳輸速率遠高于DDS,說明共享內存方式與基于套接字的網絡傳輸在執行效率上有很大差別。在持久化場景下,2種方式的運行時間差別不明顯,說明硬盤的讀寫速度是代碼執行效率的瓶頸,弱化了2種進程間通訊機制的效率差別,目前系統級虛擬環境對于持久化的需求并不大。從可靠性角度觀察,2種方式在數據可靠性方面均可以保證不丟數。
綜合數據傳輸效率和可靠性2方面的數據結果,本文選擇采用PIPE作為構建系統級測試環境的基礎。
虛擬環境之間的數據發送與接收是異步操作,彼此沒有約束條件。為了正確模擬該行為,需要采用多個線程實現,其中虛擬環境1作為管道服務器(PIPE Server)完成管道建立和外設仿真,管道服務器的主線程創建管道,并等待管道客戶端連接。虛擬環境2作為管道客戶端(PIPE Client)阻塞接收數據。每個虛擬環境根據自身對外的硬件接口數量,建立對應的管道數目,并維護管道的數據收發邏輯(圖5)。

圖5 數據交換順序圖
嵌入式系統需要按照設計的時序運行,為了保證系統中每個節點的狀態轉換操作一致,系統測試環境中的每一個節點也需要統一節拍進行計時。通過引入一個同步管理主節點(Syn master),專門去同步不同節點(Syn slave)的運行周期。具體實現方法如圖6。
1)當所有子節點已經處于就緒狀態后,同步管理主節點發送同步信號,所有子節點均反饋同步好信號后,平臺初始化工作結束;
2)平臺中任意一個節點先啟動運行,運行1ms后,把自己的輸出心跳輸出給同步節點,然后該節點停止運行,等待同步節點下一次心跳數據。其他節點類似,當同步節點收到通道中所有節點的心跳數據后,平臺該周期運行完成;
3)平臺中所有節點運行完一個周期(1ms)后,同步管理主節點輸出心跳數據,通知平臺中所有節點繼續下一周期的運行。如此循環直至整個嵌入式軟件運行結束。

圖6 時間同步順序圖
在某型號飛行控制軟件的測試過程中利用了本文所實現的高速系統級虛擬測試環境。該型號的飛行控制軟件采用多核處理器,不同于以往單核處理器架構,運行在多個處理器核心的飛行軟件構成一個嵌入式系統,該系統中多處理器核隨著軟件運行,彼此間存在數據交互和同步。圖7為該型號在平臺上運行與理論仿真導航速度的相對誤差和絕對誤差曲線,圖8為導航位置的相對誤差和絕對誤差曲線。由曲線可知,平臺計算結果與理論仿真數據誤差在允許范圍之內。

圖7(a) 三方向導航速度相對誤差曲線

圖7(b) 三方向導航速度絕對誤差曲線

圖8(a) 三方向導航位置相對誤差曲線

圖8(b) 三方向導航位置絕對誤差曲線
表4為該型號在平臺上運行時2個節點時間同步情況表。表中虛擬仿真時間始終保持在0.1ms內,能夠保證在同步周期內運行。而真實運行時間由于各節點的機器性能有較大差距。

表4 時間同步結果
該高速系統級虛擬環境實現技術已在型號中得到驗證。隨著系統級測試方法論的發展,該技術將逐步應用到其它型號軟件的系統級測試中。