张雪丰 杨甲森 苏举 刘明洁 徐聪 张鑫宇

(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)经历多型号任务后，查漏补缺，进一步提升模型驱动有效载荷地面综合测试系统的可重构、可重用。