ECSS包应用标准的发展思路分析*

吕良庆 周玉霞 王维嘉

（1中国科学院复杂航天系统电子信息技术重点实验室/中国科学院国家空间科学中心，北京，100190；2中国航天标准化研究所，北京，100071）

在上世纪80年代末，空间数据系统咨询委员 会 （Consultative Committee for Space Data System，CCSDS）提出了遥测包和遥控包的标准建议书及其概念原理的绿皮书，到2001年为止，进行了几次升级。欧洲空间局 （European Space Agency，ESA）标准批准委员会 （Standards Approval Board，STAB）随即也推出了自己的兼容标准。这些标准规定了星地应用过程之间传递遥测遥控包的通信协议，但是没有规定如何部署和应用。这使得项目在使用CCSDS包时，需要有自己的解决方案，从而导致定制的星载包管理系统和地面监控支持的应用增多、扩散而难以控制的局面。为此，ESA的操作和地面支持系统标准委员会（Committee for Operations and EGSE Standards，COES）负责开发并于1994年推出了第一个包应用标准 （Packet Utilization Standard，PUS），成为此后所有ESA任务中的事实标准。

经过多年的应用实践，PUS标准积累了一些改进意见。同时CCSDS的包标准也在发展，提出了空间包的概念。而随着制定空间标准的职责从ESA转移到欧洲空间标准化合作组织（European Cooperation for Space Standardization，ECSS），也需要重新发布PUS标准。为此在经历了一个长期的审查过程后，在2003年发布了PUS的A版 本 （Telemetry and Telecommand Packet Utilization：ECSS-E-70-41A，以下简称PUS A版）。又经过了十几年的发展和经验积累，在2016年发布了PUS的C版本（ECSSE-70-41C，以下简称PUS C版）。

PUS中最主要的一个术语是“service”，在翻译成中文时，有“业务”和“服务”两种译法，它们在概念内涵上是有区别的。“业务”是为表现能力而执行的功能实体，关注其内在的执行过程。“服务”是处于系统架构上层通过某项业务表现出来的对用户预期的外在响应，它可以是某项业务及其之下层次的多项业务能力的叠加表现。本文斟酌使用这两个词，以区别原文中“service”不同的内涵。

1 PUS A版的主要思想

PUS A版定义了地面可以监控的标准业务的集合，从操作概念、业务模型和相关的遥测、遥控包结构3个方面来描述。

操作概念分为全局概念 （包括应用过程、包设计、遥控指令、遥测报告等），例行操作（例如：遥控遥测验证、遥测报告、星载软件管理、星载运行规划、星载监控、星载存储和检索以及数据包转寄控制），非例行操作 （例如软件维护和故障排除）。业务模型围绕遥控包和遥测包的结构定义，进行服务规格的说明。上述内容主要来自CCSDS和一些以往的实践经验。

PUS A版定义了16项标准业务模型，详见表1。每项业务模型以最小能力集和附加能力集的概念，描述该项业务应具备的基础能力和可扩展能力。每项能力以遥控或遥测包的形式提供业务对外的服务，定义为不同的服务子类型，在包的副导头中通过［业务类型号，服务子类型号］区分。例如参数统计报告业务的“报告统计参数”指令包是［4，1］，而“参数统计报告”遥测包是［4，2］。

表1 PUS A版的标准业务模型[4]

PUS规定的标准业务可以根据任务的需要选用，部署在系统中所需要的层次，其复杂程度可以通过不同能力集的组合进行剪裁，并允许任务特定业务的加入和扩展。

2 PUS C版的主要思想

PUS C版给出了PUS服务类型模型，主要分为3个层次，即基础模型，业务类型模型和空间系统服务模型，如图1所示。

图1 PUSC版的PUS服务类型模型[5]

图1中的PUS基础模型 （PUS foundation model）描述了星地之间提供支持和服务的关系，主要思想来自CCSDS已经规定的内容。为了描述这种关系，规定了一些基本概念和规则，可以分为一般业务类型抽象级别和部署抽象级别。类型抽象级别定义了几个主要概念（业务、子业务、消息、请求、报告、能力等）和运用规则，每个概念的类型定义说明了这个概念的逻辑含义和进行编码时应该包含的内容，以便在实例化时，可以进行类型编码和定义。部署抽象级别主要说明了各个概念类型相互之间的位置包含关系、通信关系等。

业务类型模型（Service type model）是能够提供服务的业务规格描述，又可以分为标准业务模型（standardized service type model）和任务特定业务模型 （mission-specific service type model），在具体任务中可以剪裁和增加，明确在任务的 “PUS定义文件”中，供相关方遵照使用。PUS C版中规定的标准业务模型在PUS A版的基础上增加了4项（见表2）。

表2 PUS C版的标准业务模型[5]

空间系统服务模型是指按照任务“PUS定义文件”中选择好的各式各类业务类型，将其实例化，部署到系统中。模型中最重要的内容就是系统业务拓扑结构图，即任务系统架构的设计。不同层次的空间系统服务模型包含的内容不尽相同，可以是上层架构分解的内容，又可作为下层内容分解的出发点。而顶层的空间系统服务模型包含任务背景下的全局星地系统架构。

3 PUS C版对PUS A版的主要发展

经过十几年的实践经验积累，PUS C版对PUS A版进行了比较大的修改和调整，除了为与PUS A版兼容而保留了相应的业务编号和名称外，对描述方式、每个业务模型的规格，以及请求、报告的包格式都进行了重新梳理。

PUS C版最主要的变化是模型描述的思路。PUS A版的模型化主要是针对CCSDS空间包概念，规定了以遥控包和遥测包包装的业务对外的服务能力，对业务模型只给出了外在的规格要求，而没有规定业务模型内部的设计规格。PUS C版不仅提出了图1的服务类型模型，还规定了每个标准业务模型内部详细的设计规格，并在此基础上全面梳理了业务外在服务能力的表现（请求和报告的包格式）的约定。

PUS A版定义了服务子类型的概念，但并不是各项业务的简单划分，而是以能力集的概念来表现业务对外提供的服务能力。这些能力以[业务类型号，服务子类型号]的形式来标识不同的遥控包和遥测包。PUS C版明确子业务的概念就是业务的划分，而不是业务外在服务的能力集合，并据此规定了每个标准业务中包含的子业务。同时以请求和报告的概念泛化了遥控和遥测的概念，以“消息”概念作为请求包和报告包的传输载体，编号方式变为 [业务号，消息号]。这样一来，一方面能够兼容按照PUS A版已经建立的遥控包、遥测包库和相应的基础设施，另一方面为PUS C版扩展定义请求包和报告包提供了一致的概念方式。

为了兼容PUS A版，PUS C版继承了PUS A版定义的16项标准业务模型，并且对它们进行了内涵的调整和扩充，体现在名称的变化和子业务的划分上，增加的4项标准业务模型与原有业务不冲突。例如ST[18] “星载操作规程”到“星载控制规程”在名称上的变化，反映了该业务的实践经验积累，并且针对这项业务，在2010年推出了“星载控制规程”标准（ECSS-E-ST-70-01）。ST[12]星载监视业务中，PUS A版只提出了参数监视，PUS C版则提出了参数监视基础上的功能监视的规格。

在标准章节编排方式上，PUS C版将业务模型规格的描述与请求包和报告包的格式定义分成了2个独立的章节，而在PUS A版的章节安排上，二者是在一起描述的。这种编排方式的变化导致PUS C版的篇幅从PUS A版的228页猛增到626页，也反映了思路上的变化，从以描述外在的数据格式为主，转向了关注业务模型内在的规格说明。而且这种分开描述的方式也有利于业务模型和请求包、报告包的实例化，以及各自独立的扩展和积累。如果这种模型化思路不变的话，那么下一个PUS版本中，我们看到的变化将主要是标准业务模型和请求包、报告包的扩展。

4 PUS的应用建议

PUS标准业务模型的建立是基于ESA的实践和文化思维方式背景的。由于ESA的多国联盟的性质，其星载系统架构多具有分布式集中控制的特点，即系统不同的组成部分分布式研制和部署，通过一个集中的数据管理系统集成在一起。这种集成由于ESA的标准和生产制造的统一，为建立归一化的系统构建方式铺平了道路，也是PUS标准业务得以建立、发展、积累和继承使用的背景和基础。

而我国的卫星建设单位并不统一，而且各级各类的星载数据管理系统和设备的设计也各有其架构和特点，反映了不同组织机构的发展背景和特色。也正因如此，国内要统一星载数据管理系统的设计，不是一件简单容易的事情，更多的是通过协调统一接口方式的办法解决互联互通问题，而不是统一星载设计规格。这也导致国内使用PUS标准时，必然会出现不同的思路和理解，以及结合不同的设计实例进行改造的局面。

为适应这一现实情况，各组织机构在使用PUS标准时，需要结合自身已有的系统架构和设计经验，对PUS标准业务进行本地化改造。改造时，应保证请求包和报告包代表的外在服务形式，以及内在设计规格的能力表现这两方面的一致性，继承使用组织机构已有的架构设计，参照PUS进行标准化改造和完善设计。

另一方面，PUS A版在开篇就明确说明，其定义的标准业务模型在实际使用时，并不具有固定的层次关系，而且是一个业务模型菜单，可以供特定任务按照自己的任务需求和架构进行具体的部署和剪裁。在实际使用时，PUS通常被认为主要规定的是星载应用层的标准业务，与地面的支持服务具有一定的对应关系。但是PUS C版的发展，模糊了这一层次结构，例如ST[02] “设备命令分发”更名为“设备访问”，内涵从“向设备分发指令”扩展到 “设备的数据采集”内容，且通信方式包括了逻辑寻址和物理寻址两种方式，有层次下移的意思。因此，在本地化改造和规范的时候，还是需要在架构设计上具有灵活性和可扩展性，而不是固定不变的。

5 结语

PUS的发展反映了十几年来欧空局在星载应用业务方面的技术进步和积累，其背后的一个理念就是架构的归一化设计思想。这种归一化并没有统一具体的实例化设计和实施，而是通过标准化、规格化手段给出了一致的外在服务和业务内部的设计规格，既有利于已有知识、设计和实例的兼容、继承和重用，同时又能够适应外在需求和技术进步带来的变化。