基于XTCE標準擴展的測試序列建模方法

張雪豐 楊甲森 蘇舉 劉明潔 徐聰 張鑫宇

(1 中國科學院國家空間科學中心， 北京 100190) (2 中國科學院大學， 北京 100049)

在以激勵-響應為基本原理[1]的有效載荷地面綜合測試任務中，測試序列是任務執行的直接驅動，也是有效載荷測試需求分析與測試任務執行之間的橋梁。在自動化、智能化測試需求的驅動下，測試序列描述對象的范圍，正在從早期的控制指令、驅動時刻，拓展覆蓋到綜合判讀知識[2]，順序、條件、循環等測試流程控制[3]。

測試序列建模是實現模型驅動測試系統研制的前提，圍繞測試序列建模與生成方法，眾多航天單位開展了相關研究并付諸于工程任務實踐。文獻[3]基于有向圖理論，采用簡單且易于理解的表格方式建立衛星測試序列模型，并將其成功應用于神舟飛船及多顆衛星的測試任務；文獻[4]亦基于開放數據庫互聯(Open Database Connectivity，ODBC)接口技術，設計快速、智能的測試序列自動化生成方法，研制測試序列生成軟件并將之應用于載人航天任務；文獻[5]采用組態方式實現圖形化測試序列建模，成功應用于嫦娥四號、實踐十號任務。上述文獻測試序列建模與生成方法，個性化特征突出，工程實用性強。其缺點在于：①未能實現模型規范化、標準化，不利于設備研制、總體集成、測試、國際合作等多航天單位間的信息交換。②對判讀知識、測試流程控制的表達不足，難以實現模型對測試系統研制的直接驅動。

基于可擴展標記語言的遙測遙控信息交換(XML Telemetry & Command Exchange，XTCE)標準，采用XML Schema對航天器遙測和遙控數據格式、處理方法等進行了詳細且規范化的描述[6]，以其通用性和擴展性，在遙控指令生成[7]、遙測數據處理[8-9]等方面得到廣泛應用，同時也為以遙測、遙控為基礎元素的測試序列標準化建模提供了可能。

本文面向航天單位間信息交換、模型驅動測試系統研制需求，在分析測試序列內容的基礎上，以現有XTCE標準為基礎，對測試序列中的控制指令、判讀知識、測試流程進行建模，提出面向測試序列的XML Schema。以該方法建模輸出的測試序列模型為基礎，構建測試序列執行、綜合數據判讀、載荷運行狀態監視等測試軟件的工程實踐結果表明：模型驅動的測試軟件面向不同測試需求可實現靈活重構，可有效減少測試系統開發成本、降低開發風險。

1 測試序列概念及內容

測試序列是在分析有效載荷等被測對象測試需求的基礎上，以測試大綱為綱領性文件，依據測試細則，對測試過程中需要執行的遙控與注入指令、驅動時刻、預期結果、流程控制等元素進行描述的文件，是測試運行過程中的執行文件，也是自動化測試過程中不可或缺的文件[10]。

一個典型的測試序列見表1(僅示例，非工程實際)。測試序列包含內容說明如下。

(1)遙控、遙測是構成測試序列的基礎數據。有效載荷的測試過程，是對被測對象施加外部激勵得到響應，通過分析激勵與響應得出測試結論的過程。作為“激勵”的遙控指令與作為“響應”的遙測數據，必然是構成測試序列的基礎，這也是已具備遙控、遙測元數據模型基礎的XTCE標準，對測試序列建模具有先天優勢的原因。

(2)測試序列中預期結果通常以判讀知識的形式體現，判讀知識將遙控指令與遙測數據有效關聯。指令執行的預期結果以電壓、電流、溫度、注入計數、載荷運行模式等遙測數據改變的形式呈現，這些改變的特征包括更新為預定數值、更新至某預設區間、更新前后變化量在某預設區間等。如表1中“載荷控制器主份開”指令執行后，遙測參數“一次電流”的增加量將在區間[0.37,0.39]。

(3)測試執行的路徑包含順序、條件、循環等多種結構。其中順序結構表示測試步驟按時間順序依次執行；條件結構表示測試步驟執行后根據條件選擇后續路徑分支；循環結構表示測試步驟執行后根據條件進行跳轉，直到滿足某條件后終止。如表1中，執行步驟7后將跳轉至步驟4，直到循環20次結束。

(4)測試的激勵不全是單指令形式，實際測試中，將若干條指令按照一定邏輯包裝起來并分配特定序號，稱為事件表。事件表中包裝的事件亦可作為測試激勵的一種，類似編程語言中的子函數調用。如表1步驟8，“中分相機模式表注入”即為步驟4～7的順序封裝，該事件激勵下遙測數據的響應與步驟4～7全部執行的響應一致。

綜上，一個好的測試序列模型，需要既能支持遙測、遙控基礎數據的描述，同時也要支持判讀知識、測試執行路徑多種結構的表達，其表達方式以“可直接驅動測試系統研制”為宜，另外模型還要能夠支持事件的嵌套封裝。

2 基于XTCE擴展的測試序列建模

2.1 XTCE數據模型基礎

XTCE以標準化語言對航天器遙測遙控數據進行描述，具有明顯層次化結構，易于擴展和集成。XTCE定義了遙控元數據、遙測元數據以及通用數據類型[11-13]。其中遙測元數據是對航天器遙測數據的描述，定義參數類型、參數、數據流、算法、容器、消息等內容，如圖1所示。遙控元數據是對航天器遙控數據的描述，含有參數類型、參數、消息、數據流、算法、數據段類型和元指令，如圖2所示，其中元指令是對遙控指令的進一步描述。

圖2 XTCE遙控元數據模型

2.2 XTCE數據模型擴展

2.2.1 事件的定義

借鑒包應用標準(Packet Utilization Standard，PUS)中事件的概念[14]，本文將測試過程中一條或多條可能重復執行的遙控或注入指令，按照順序、條件、循環等控制邏輯組織形成的序列稱為一個事件，如圖3所示。從事件的定義可見，一個事件包含一條指令或多條指令，某一事件可與其他指令或事件一起，組成更大的事件，亦即事件是支持嵌套封裝的。事件與事件、指令之間的聚合關系，便于在測試序列執行過程中，將整個序列全部拆分為“指令”這一基本可執行單元的組合，有效減少測試序列執行軟件多級數據管理帶來的復雜度。

圖3 事件統一建模語言類圖

如圖3所示，事件的定義是以“指令”為基礎的。每條“指令”除了包含常規的執行時間(含絕對時間、相對時間)、當前執行指令(XTCE標準元指令類型)之外，為了描述指令執行的順序、循環、條件等路徑結構、指令執行判讀知識，還定義了后置指令集合、分支條件集合，以及判讀知識集合。其中后置指令集合與分支條件集合的元素分別是XTCE標準元指令、知識(見2.2.2節)，兩個集合元素數量一致，以實現后置指令與分支條件的一一映射。判讀知識集合元素用于判定指令是否成功，或指令執行后載荷運行狀態是否正常。只有在集合中所有知識均滿足的情況下，該指令才判定為執行成功或載荷運行狀態正常。

2.2.2 知識的定義

將測試過程中，用于判定遙控或注入指令是否執行、星載設備當前狀態是否正常的判據稱為知識。其中載荷狀態判據表現為一個或多個遙測參數的條件表達式組合，遙控或注入指令是否執行的判據表現為遙控指令與一個或多個遙測參數的關聯，如圖4所示。

圖4 知識統一建模語言類圖

知識的屬性包含與之關聯的指令、遙測、判讀規則等元素。其中判讀規則包括5種類型。

(1)定值類型：指令c執行后，與之相關聯的遙測參數yi將變化為定值vinew，即

yi(c)=vinew

(1)

(2)區間類型：指令c執行后，與之相關聯的遙測變量yi將變化為某區間的值[vimin,vimax]，即

yi(c)=vimin+ε(vimax-vimin)

(2)

式中：ε為0到1之間的隨機數。

(3)增量數值類型：指令c執行前對應時刻t1，執行后對應時刻t2，與之相關聯的遙測變量yi的數值變換之差為定值vi，即

yi(c,t2)-yi(c,t1)=vi

(3)

(4)增量區間類型：指令c執行前對應時刻t1，執行后對應時刻t2，與之相關聯的遙測變量yi的數值變換之差在區間[vimin,vimax]之間，即

yi(c,t2)-yi(c,t1)=vimin+ε(vimax-vimin)

(4)

(5)多變量線性相關類型：指令c執行后，與之相關聯的多個遙測參數y0(c),y1(c),…,yn(c)之間有線性相關關系，ki為遙測變量yi的系數，即

(5)

2.2.3 測試序列模型

XTCE標準已有的遙測、遙控元數據模型和基本數據類型比較完備地給出了遙測參數、遙控指令、基本數據類型和相關算法的定義。為了覆蓋測試序列中的判讀知識、流程控制，擴展出的測試序列數據模型由名稱、附加信息、遙控數據、遙測數據、知識元數據、事件元數據組成，如圖5所示(圖5中灰色陰影部分為XTCE固有內容，無陰影部分為本文擴展內容)。

圖5 測試序列統一建模語言類圖

其中，名稱用于描述測試序列的名稱、版本等信息；附加信息包含測試序列的測試對象、測試目的、被測載荷計數、發送指令計數、判定遙測計數等信息；遙控數據引用XTCE遙控元數據，用于描述當前測試序列使用的指令信息，其中指令名稱為該指令唯一標識；遙測數據引用XTCE遙測元數據，用于描述當前測試涉及的遙測參數，其中參數名稱為該參數唯一標識；知識元數據是判讀知識的集合，判讀知識是在遙測參數、遙控元指令的基礎上構建的，知識的類型主要包含2.2.2節所述的5種；事件元數據是事件的集合，事件包含一條或多條指令，以分支條件、后置指令等元素將指令或事件組織為測試序列，其中各指令之間通過指令標識符、后置指令、分支條件構成順序、條件、循環等多種結構。

上述描述信息所建立的測試序列模型通過引用XTCE遙測、遙控元數據的形式支持遙測、遙控基礎元素的描述，定義知識元數據支持判讀知識的表達，定義事件元數據支持測試執行路徑的表達，同時考慮了事件的嵌套封裝，較好地滿足了第1節中評判一個“好”的測試序列模型的標準。

2.3 測試序列模型設計

2.3.1 模型Schema文件設計

模型以XML Schema形式表達，引用現有XTCE模型的遙測元數據模型和遙控元數據模型，在建立Schema文件時需要進行相應標注以示引用。本文使用類型命名(NamedTypes)方法建立模型，以增加模型所定義元素的可重用性。將測試序列模型的命名空間命名為XML Test Sequence，簡稱XTS，模型主要代碼如圖6所示。

圖6 測試序列模型主要代碼

XTS模型定義了主元素“TestSequence”，以類型命名的方式進一步定義其內容，TestSequence類型是以命名描述(即名稱)為基礎的擴展，除名稱外還含有附加信息、遙測數據、遙控數據、知識元數據、事件元數據。由于遙測數據和遙控數據引用了XTCE遙測元數據、遙控元數據，在XTS模型中沒有進一步定義，知識元數據和事件元數據則在XTS模型中定義。XTS模型主要分為4個部分，上述代碼展示了XTS模型的頂層結構，剩余3個部分分別為知識模型、事件模型和通用類型集合。通用類型集合中定義了一些通用類型，例如“時間類型”，該類型規定時間有相對時間和絕對時間兩種格式。知識模型定義知識元數據以及知識模型相關的類型數據。事件模型定義事件元數據以及事件模型相關的類型數據。

2.3.2 測試序列模型實例

以表1所示測試序列為例，表1中包含了順序、條件、循環結構，使用本文設計的測試序列模型對表1的測試序列進行描述如圖7所示，圖7中用到的指令和參數是對表1中的各指令和參數的簡單標識，以指令名稱的形式表示指令標識，以參數名稱的形式表示參數標識。

圖7 測試序列模型生成文件示例

3 模型驅動測試系統軟件設計及應用效果

以本文方法建模輸出的測試序列模型為驅動，設計有效載荷地面綜合測試系統如圖8所示。得益于本文方法對測試流程控制、指令判讀知識描述的規范化，測試軟件可直接將方法生成的測試序列模型轉換為軟件內部數據結構、邏輯控制，驅動測試軟件針對不同測試序列模型的靈活重構，有效解決傳統自然語言描述方法中，不同建模人員對同一信息描述存在差異，導致計算機無法提取確定信息的問題。與測試序列模型相關的軟件主要包括測試序列執行、綜合數據判讀、載荷狀態監視等3個軟件。其中測試序列執行軟件關注模型中的事件及構成事件的指令，依據指令執行時間、分支條件、后置指令逐條發送指令碼字；綜合數據判讀軟件關注判讀知識，并根據遙控、遙測數據判定目前測試數據與知識的符合性；載荷狀態監視軟件關注知識關聯的遙控、遙測數據，將具有強關聯關系的遙控指令、遙測參數采用鏈表方式進行管理，以二者關聯的方式將其呈現給載荷用戶。

圖8 模型驅動測試系統軟件架構設計

目前，基于XTCE標準擴展測試序列模型驅動的有效載荷地面綜合測試系統已經應用于天問一號環繞器、著陸巡視器的測試任務中，正在應用于天問二號等后續深空探測任務，與傳統方法相比其特點見表2。工程實踐結果表明：采用本文方法模型的有效載荷地面綜合測試系統，測試序列執行、綜合數據判讀、載荷狀態監視等3個軟件代碼無需更改即可支持不同型號任務，可有效減少測試系統的開發成本，提升測試系統可靠性。

表2 本文測試序列模型特點

4 結束語

現有XTCE規范為以遙測、遙控為基礎數據的測試序列標準化建模提供了可能。本文在系統梳理測試序列建模內容的前提下，引入“知識元數據”、“事件元數據”概念，對測試序列中的判讀知識、測試流程控制進行了建模。工程實踐結果表明：本文方法輸出模型驅動的測試序列執行、綜合數據判讀、載荷狀態監視軟件，可實現對不同測試需求的快速響應。后續可開展工作如下。

(1)進一步豐富測試序列包含知識的類型。現有工作關注指令判讀和遙測判讀知識，尚未包含諸如遙測數據統計特征(如均值、極值、方差等)判讀知識、指令間約束(如成對匹配、先后順序約束等)知識等。

(2)基于測試序列建模方法，研制測試序列編輯工具軟件，對遙測參數、注入指令、判讀知識、流程控制等測試序列相關組成提供輔助編輯工具，使其不僅支持XML文件格式檢查，同時支持數據內容一致性的檢查，亦可支持生成對應XML文件的文本表格文件，用于測試細則的評審和測試報告的編寫。

(3)經歷多型號任務后，查漏補缺，進一步提升模型驅動有效載荷地面綜合測試系統的可重構、可重用。