基于SOIS EDS的实例化设计

张煦冬，吕良庆，安军社

(1.中国科学院复杂航天系统电子信息技术重点实验室 国家空间科学中心，北京 100190；2.中国科学院大学 计算机与控制学院，北京 100049)

0 引 言

针对不同的任务需求，航天器设计出现了种类繁多的接口方式和通信方案，工程项目中的星上数据管理系统往往是个性化设计，使得跨项目重用设备、部件、软件的难度增大。为解决这一问题，特别是跨组织的互联互通，空间数据系统咨询委员会(consultative committee for space data systems, CCSDS)开展了航天器接口业务(space onboard interface services, SOIS)领域的研究工作[1]。SOIS领域主要解决的是航天器数据管理的接口服务问题。SOIS架构针对航天器系统设计提出了标准的层次划分，使得个性化设计的设备、部件可以在几乎不更改软件的情况下连入系统。为此SOIS工作组提出了基于SOIS架构的EDS(SEDS)的相关建议标准。

1 SEDS简介

为解决异构部件的兼容使用问题，每个部件需要一个自描述EDS，内容是数据格式、接口、功能、协议等[2]。当一个部件要接入一个系统时，系统通过解析这个部件的EDS，获得它在系统中运行所需要的信息，实现对部件的识别和配置。符合CCSDS SOIS 876.0[3]规定的EDS称为SOIS EDS(SEDS)。在SEDS文件中按照SOIS的层次划分描述部件的信息，支持SOIS架构的实现。SEDS所使用的元素和类型的抽象概念及其之间的关系如图1所示。

图1 SEDS的关键元素和抽象类型[3]

SEDS文件使用可扩展标记语言(eXtensible Markup Language, XML)[4]按照图1描述系统定义，构建XML文件。

图1中，SEDS以Datasheet元素为根元素，Package元素包含Data Type、Interface、Component这3部分，其中Data Type包括9种数据类型的定义：两种复杂数据类型，数组类型、容器类型；6种标量类型变量，整型、二进制型、枚举型等；一种范围数据类型，表示变量的取值范围。

SEDS元素类型分为两类，语法类型和语义类型。语法类型指SEDS元素的拼写语法规则，比如特定的字符串、变量的比特数、变量的编码方式等。语义类型指SEDS元素代表的行为和含义[1]。在SEDS XML文件中使用的元素和属性的标签所对应的这两类类型在术语字典(dictionary of terms, DoT)[5]中定义。DoT以XML Schema的形式供用户使用。

文件对象模型(document object model, DOM)[6]是解析XML文件的方法之一。XML和DOM都是万维网联盟(world wide web consortium, W3C)的推荐标准。DOM解析文件的方法是将XML文件的元素作为节点组成树形数据结构[7]，通过对树的通用访问，实现对信息的归纳。很多程序设计语言(如java，python)都支持DOM方法。

2 基于SEDS的系统设计

采用EDS进行星载软件设计的路线需要解决工具链的建设和EDS的设计问题。

EDS的编辑、传递和解析，以及系统内部的管理信息库(management information base, MIB)[8]配置过程应该是工具化的，即工具链设计。异构系统之间交换EDS需要的转换工具如图2所示。

异构系统是由不同机构组织按照自身的需要设计的，在需要进行互联互通时，异构系统及其软件系统提供的功能业务都需要继承使用，而不是重新设计。这也是引入EDS概念的应用背景之一。为此，异构系统之间传递的EDS应遵循统一的标准(如CCSDS由space assigned numbers authority(SANA)统一管理的、用XML描述的SEDS[9])。通常设备方将自身的信息(requirement list, RL)按照系统要求的实现一致性声明(implementation conformance statement, ICS)的规则，使用ICS编辑工具或手工填写数据表单。876.0中有ICS的推荐内容，可以根据需要补充设计，类似于接口数据单(interface data sheet, IDS)。设备方可以通过SEDS编辑工具，或直接手工编辑，生成SEDS的XML文件。

系统方接收的个性化EDS文件用以继承系统内部的数据设计。道理上EDS文件是对外的数据隔离墙，可以进行统一设计。但是由于继承系统内部原有的设计未必是规范化的，而且不同业务的MIB和使用的EDS内容千差万别，使得EDS文件难以统一设计。因此这一点只能通过规范化ICS来针对性、逐一、积累完成。其设计的有限性则取决于系统架构的规范性，如规范的CCSDS SOIS架构和欧空局的包应用标准(package utilization standard, PUS)业务[10]。

数据解析工具的作用是将SEDS XML文件解析成系统可以识别的个性化EDS文件。这一解析过程是按照SEDS的XML编辑语法进行的，包括提取信息、综合属性和组织数据对象等过程，可以采用常规的XML解析工具软件(函数)来完成。最后按照系统内部的数据设计生成实例化EDS文件，供系统直接使用，实现对系统已有部分的继承。而在进行系统新增业务设计时，直接按照个性化ICS、SEDS XML文件和实例化EDS的思路进行规范化设计，从而实现新增部分和继承部分在EDS表达方式上的统一，方便系统业务的积累。

在EDS设计方面，EDS的产生可以来自于模型化业务需要的数据结构，包括业务的输入、输出，以及内部的MIB管理的信息，因服务模型不同而不同。其主要思路是服务模型的MIB应有明确的格式，内容可以配置。EDS在格式设计上应具有可修改性和可扩充性，以允许同属一个服务模型的不同实例业务的设计，从而实现业务的即插即用，适应不同系统的不同配置需要。

图2 异构系统之间的EDS转换过程

图2中有两种工具使用场景。一种是互联双方是对等机构组织，则以SEDS XML文件为界，各自开发各自的工具。这种情况下，双方各自有自己的ICS编辑工具、SEDS编辑和解析工具，输出的SEDS XML文件是对外表达的自描述信息，就如同个人的名片那样，可以被任何可识别这种信息的系统所接纳。另外一种是单纯的设备接入系统的场景。这种情况下，设备方可以直接使用系统方提供的ICS和SEDS编辑工具，规范ICS表单和SEDS XML文件的生成，也可以直接手工编写SEDS XML文件，从而最大限度地降低了设备方使用EDS的难度和工作量，也不改变约定IDS的工作习惯。通过这一基于工具的过程，互联双方可以表达自身的需求，了解对方提供的服务能力，达到需求自动匹配的效果。而上述两种场景既有利于接口标准化，也有利于非标准化设备继承使用。

3 基于SEDS的工具链设计

3.1 从ICS到SEDS XML

表1将CCSDS 876.0推荐的ICS表进行补充和整理，这些内容所使用的数据元素和图1中SEDS规定的内容对应。

表1 在CCSDS 876.0推荐的ICS基础上的补充设计

表1(续)

在ICS的基础上，经过编辑过程，将用户填写好的个性化需求ICS转化为SEDS的XML文件。编辑过程依据SEDS和DoT的规则进行。这一过程可以手工完成，也可以建造相关的编辑工具，以方便项目使用。

3.2 SEDS XML文件的解析工具

SEDS XML文件解析工具实现从SEDS个性化XML文件到实例化EDS文件的转化，即二者之间的映射过程。它的转化过程和使用的数据结构如图3所示。

图3 SEDS XML文件的解析过程

图3中使用DOM方法读入XML文件中的元素数据作为节点，形成树形数据结构，称为文档树。文档树和XML文件之间有严格元素数据的对应关系。通过文档树可以添加、更改、删除、查找XML文件中的元素。

XML文件中的所有元素标签都要在解析工具中识别，相同标签的节点组成链表。在SEDS规则下，标签相同的元素具有一致的属性，为下一步提取元素属性的值，形成SEDS数据对象做准备。每种数据类型定义所需的元素构成一个SEDS数据类型定义实体。图3中以数组类型为例，数组类型包含2种元素，ArrayDataType元素和Dimension元素，后者是前者的子元素，因此SEDS数组类型定义包括2个链表，是由这2种元素节点组成的。从SEDS元素、ICS到解析过程的对应关系见表2。从表中可以看出解析过程需要对所有的SEDS元素进行针对性处理，而ICS的填写只关心内容。

图3中的SEDS数据对象是对SEDS XML元素定义的实现，例如，SEDS对数组数据对象的定义是标签为ArrayDataType的元素，其中的属性定义了每个数据单元的数据类型，它的子元素Dimension定义了数组的长度。相同SEDS XML元素定义对应的SEDS数据对象是同一类型的，它们的集合对应于图3中的SEDS对象链表。

表2 SEDS标签对应关系

一个SEDS数据对象中包含对应的SEDS XML元素的所有信息，但输出文件是根据系统需要，对ICS中填写的数据值选择输出后的实例化EDS，可以直接提供给系统使用。因此从ICS的内容开始反映的就是用户的个性化需求，此后的XML文件中的数据与ICS内容是等价的，而实例化EDS则是针对某个系统的输出。这种针对性表现在某个系统的特定数据格式和选择的内容上。(例如4.2节所举示例)

4 1553B EDS的实例设计

4.1 1553B EDS的应用背景

EDS的概念源于即插即用技术。在网络环境下，首先需要在链路协议层解决EDS的传送交换问题，然后是反映传输需求的EDS内容设计，即插即用的传输协议设计。在此以1553B总线为例进行说明。

1553B总线是总线型、主从式的单工通信方式，总线上的总线控制器(bus controller, BC)控制着全部的通信协议过程[11]。为不影响接入的设备终端(remote terminal, RT)原有的通信设计，1553B总线即插即用协议[12]是在已有的链路层通信协议基础上，增加在初始阶段交换RT EDS的协议过程，由BC根据RT EDS动态配置和调度总线，实现RT的自动加入和撤出，并满足其通信需求，系统仍然能够稳定运行。而RT方只需要遵守初始握手协议要求，其设计重点放在了RT EDS的内容设计上[13,14]。

4.2 1553B总线的ICS设计

根据1553B总线通信协议的特点，BC方需要了解的RT传输需求包括两个部分，即如何握手和子地址消息配置需求。这两部分通过RT EDS定义，首先反映在用户填写RL完成后的ICS中，见表3。

4.3 1553B总线的RT SEDS XML文件

根据用户填写的1553B总线ICS，可以编辑相应的1553B总线的RT SEDS XML文件，如图4所示。

图4中，第6行至10行定义了矢量字数据域是数组类型。第11至19行定义了子地址定义的第1个字为容器类型。第20至25行规定了子地址定义是容器类型。第26至30行为子地址定义数组规定了发送子地址定义和接收子地址定义这2个域的格式。第31行至第144行定义了矢量字和子地址消息定义的各个字段的值。

图5为1553B总线SEDS实例的文档树结构，元素的属性数据作为元素节点的叶子节点。解析过程是将XML文档树的节点转化为SEDS数据对象的过程。例如，图5中的ArrayDataType节点是SEDS定义的数组类型变量，该节点及其所有子孙节点所构成的分支树对应于SEDS的数组类型数据对象。需要说明的是图3中的节点链表是元素节点组成的链表，不包含属性节点，因为通过元素节点即可访问属性节点，不需要将属性节点组成链表。

表3 1553B总线即插即用协议所需的ICS

图4 1553B总线RT SEDS XML文件

图5 1553B实例的文档树结构

4.4 1553B EDS的实例化输出

在收到图4的XML文件后，系统根据自身使用的RT EDS的格式定义(见表4)，进行针对性的信息提取和转换，生成实例化的EDS文件(如图6所示)。

本文设计的SEDS解析工具输出的结果如图6所示，为了方便理解增加了注释。

表4 RT EDS格式[13-15]

图6 二进制文件结果

图6中矢量字定义数组的前5个值，发送子地址定义数组前2个值,以及接收子地址前3个值见表5。

5 结束语

在航天器数据系统中使用EDS，使系统能够对个性化需求做出通用性设计。通用性表现在处理方法上，是指对每个部件的数据设计上，都要包括3个数据对象(ICS、SEDS XML文件、EDS)，以及对它们进行转换的工具链设计思路。3个数据对象内容是系统针对性选择的信息结果。正因为如此，EDS技术可以解决异构系统之间的信息传递和互联互通问题，以及新增设计和原有设计的兼容、继承、重用等问题。工具链的设计和使用能够进一步扩充EDS内容和应用范围，并方便使用。本文介绍的1553B总线即插即用SEDS实例设计说明了这一思路的可行性。

由于星上和地面EDS都可以采用XML进行描述，因此SEDS与XML Telemetric and Command Exchange (XTCE)[15]可以衔接。XTCE主要描述遥测遥控，这恰与PUS的请求与报告可以挂钩，应作为EDS内容的一部分，加入EDS工具链中的数据库，供通用设计使用。当积累的标准服务、请求、报告的内容足够多时，可以支持重用、数据挖掘，作为深度学习的数据源使用。再扩展，可以支持星地一体化智能信息系统的设计和建设。

表5 实例化EDS结果含义