一种基于构件的可重配置通用星载遥测软件设计

张亚航 袁珺 郭坚

（北京空间飞行器总体设计部，北京 100094）

1 引言

航天器遥测是把航天器上各种被测信息，经感知、采集和调制，通过天线传输到地面接收站，再经过解调、记录和处理的测量全过程［1］。星载遥测系统是航天器数据管理系统或综合电子软件的重要功能组成部分。

不同航天器型号任务，往往对遥测参数设置、采集频率、存储方式和下传方式等需求不同。我国航天器一般采用高级在轨系统（AOS）遥测体制［2］，但是不同型号通常对遥测数据源包组包、调度和虚拟信道调度等方面有不同的需求。传统星载遥测软件设计方法，软件逻辑处理与用户需求紧密耦合，因此，不同的型号任务需要单独开发一套遥测处理模块，难以重用，造成了许多重复性劳动，耗费了大量人力物力。

本文首先对AOS链路协议［2］、空间包协议［3］、包调度方法［4］和航天器遥测需求［5-6］等一般遥测技术涉及的内容进行分析和研究，其次介绍了星载软件构件技术［7］，并在此基础之上，提出基于构件的通用遥测软件设计方法。该方法通过参数配置和组装的方式满足不同的遥测需求，从而实现通用化遥测软件模块，可以作为其他航天器软件构件化设计的参考。

2 传统遥测软件

航天器遥测模块，一般包括遥测数据采集、存储、组织和调度下传等子功能模块［1］，属于星载软件重要的模块之一。现有卫星型号，为了实现对遥测数据更加灵活的处理和调度，进行标准的数据组装，往往采用国际上空间数据系统咨询委员会（CCSDS）规定的AOS遥测体制。传统遥测处理软件，其典型的设计方式是将软件分为多个时间片，每个时间片按照顺序做不同的事情，共同协调完成遥测数据采集、组包、包调度、组帧和帧调度等相关功能。其流程如图1所示。

图1 典型遥测处理流程Fig．1 Typical TM process

遥测系统设计分为源包的调度和虚拟信道的调度。对于源包级别的调度，包括源包的生成和下传。遥测系统根据源包各自的生成周期完成源包生成，并根据源包各自的下传周期安排下传。对于虚拟信道的调度，主要是对虚拟信道进行同步调度或者异步调度等方式，以满足数据按照不同优先级或频率占用信道的需求。虽然不同的卫星型号任务遥测模块完成的基本功能类似，都包含遥测采集、组包、包调度、组帧、虚拟信道调度和最终下传等功能。但是，由于卫星型号软件的设计方法仍然是基于传统的代码编写方式，在实际任务中各个功能模块之间的耦合非常大。以图1为例，显然该遥测模块与卫星型号具体需求和结构紧密绑定。具体来说，传统设计的遥测模块，其子功能模块耦合性主要体现在以下方面：①遥测采集功能和型号任务对遥测参数的定义和来源耦合紧密；②源包组织和遥测采集后的数据存储方式耦合紧密；③源包组织和源包调度算法紧密耦合；④源包调度和VC帧组织紧密耦合；⑤VC帧组织和VC调度算法耦合紧密。

除此之外，即便是针对相同或极为相似的卫星型号需求，不同设计师实现的结果，在代码级一般存在较大的差异。由于以上原因，从软件角度来看，导致两个问题：①由于软件与具体卫星型号任务需求耦合度高，因此，无法实现不同卫星型号之间代码构件级复用，进而影响卫星型号软件开发效率；②由于软件模块间耦合度高，因此星载软件需求变化适应能力低，难以应对卫星型号需求在研制过程中的变化，同样也影响软件健壮性。

3 构件化可配置通用遥测软件

为了提高遥测模块的通用性和适应性，进而提高软件开发效率和可靠性，本文采用构件化方式设计遥测各子功能模块，并通过构件的组装，完成遥测模块整体的设计。应用程序将通过参数设置的方式，完成不同任务需求。

3．1 星载软件构件模型

星载软件构件［3］（简称构件），指的是一个可独立发布，并可以由第三方进行组装的功能模块，它满足一定的航天器软件需求，并通过接口提供服务。它应具备4个基本属性：①独立性，构件发布，必须与所在的环境和其他构件分离，除了基本运行环境，不能依赖构件以外的数据或代码；②完整性，构件发布时，构件使用方不能访问构件内部细节，且不可拆分；③组装性，构件用户能够根据既定规则将构件进行组装；④功能性，必须具备具体的、明确的一个或多个功能，并且能够被用户调用，并在预定的运行环境下正确运行。

如图2所示，典型的星载软件模型由对外接口、实现体和构件规约三个要素组成。其中，对外接口是构件向用户提供服务的唯一渠道；实现体为具有一定功能的源程序片段，实现对外接口所提供的服务；构件规约作为对构件的描述，是构件使用说明书。其中，对外接口和构件规约对外可见，被用户调用或阅读；实现体对外不可见，从而保证构件的信息隐藏和独立性。

图2 星载软件构件模型Fig．2 Spacecraft software components model

3．2 通用遥测构件设计

通过对卫星遥测需求的梳理，遥测处理模块TmProc主要处理遥测采集、存储、组包、包调度和虚拟信道调度等工作。因此，根据需求设计5种构件，分别是数据池构件（DataPool）、空间包构件（SpacePacket）、元素周期调度构件（PeriodSelector）、虚拟信道构件（AosVc）和同步异步调度构件（SynAynSelecotr）。其中构件DataPool完成对星载软件数据（包括遥测数据）的统一索引和存取；构件SpacePacket完成空间包组织；构件PeriodSelector实现元素周期性调度算法；构件AosVc实现帧组织；构件SynAynSelecotr实现元素同步／异步调度算法。

这些构件所封装的主要是处理逻辑和算法，并不与具体的用户数据（如遥测参数表、遥测大纲等）绑定。用户（即应用程序）根据具体的需求，通过初始化接口，完成对构件实例基本参数的设置，再通过调用构件对用户提供的功能接口，满足不同的型号任务需求，即可通过有限个通用的构件，来实现不同卫星型号的多样化任务。

下面将从基本功能、初始化接口和对外功能接口等方面，分别对每个构件的详细设计进行说明。

3．2．1 数据池构件（DataPool）

（1）基本功能：提供对不同长度数据按照统一索引进行存储、更新和获取等服务，用于满足对整星数据（包括遥测数据）的采集、存储、更新和获取需求。

（2）初始化接口参数：①data＿size＿arr，数据池中预定义的数据项长度数组；②data＿size＿arr＿len，数据池预定义数据项长度数组的长度。

（3）功能接口：①GetDataSingle，获取单个数据项；②SetDataSingle，设置单个数据项；③GetDataBlock，获取包含多个数据项的数据块；④SetDataBlock，设置包含多个数据项的数据块。

3．2．2 空间包构件（SpacePacket）

（1）基本功能：提供CCSDS标准空间包协议服务，满足遥测包组装、发送等需求。

（2）初始化接口参数：①type，包类型，1bit，1为遥测，0为遥控；②sec＿hdr＿flag，副导头标识，1为有，0为无；③apid，应用过程标识，11bit；④seq＿flags，包序列控制标志；⑤data＿msg，包数据组成结构。

（3）功能接口：BuildPacketWithDataInput，根据包数据域进行包组织和生成。

3．2．3 元素周期调度构件（PeriodSelector）

（1）基本功能：提供对元素按照一定的周期，按照一定的算法进行调度，用于满足遥测包生成调度和下传调度控制需求。

（2）初始化接口：①elem＿arr，被调度元素数组；②elem＿num，参数elem＿arr数组长度。

（3）功能接口：①ResetPeriodSingle，重置单个元素的周期。若该元素无周期，其输入的初始周期和设定周期为同一值。元素的查找是通过元素指针或者元素序号；②SelElemSingle，选择一个优先级最高的元素；③SelElemAll，选择所有到期的元素；④DecWait，所有元素的计时自减。若某元素无周期，不自减；若某元素计时为零时，不自减。

3．2．4 虚拟信道构件（AosVc）

（1）基本功能：提供CCSDS标准AOS链路协议虚拟信道中的包装业务、多路复用业务、组帧业务等服务，用于满足数据组帧的需求。

（2）初始化接口：①Scid，有效航天器标志；②Vcid，有效VC 标志；③input＿type，输入数据类型；④ctrl＿field＿flag，操作控制域；⑤frame＿len，帧长；⑥insert＿len，插入域长；⑦circle＿count＿flag，VCDU 帧长；⑧pri＿freq，VC 在被调度时的输出优先级或频率；⑨Buf，虚拟信道IO 缓存；⑩buf＿size，虚拟信道IO 缓存长度。

（3）功能接口：①SendData，往虚拟信道中发送源包E＿PDU、虚拟信道数据访问单元VCA＿SDU或位流数据单元B＿PDU；②OutputExist，查询VC中是否有输出数据；③DownOutput，根据包数据域进行包组织和生成遥测包；④GetMpduIdleBytes，获取当前组织的多路复用协议数据单元（MPDDU）中剩余字节数。

3．2．5 同步异步调度构件（SynAynSelector）

（1）基本功能：元素同步异步调度构件，提供对元素的同步、异步和多级调度服务，用于满足对虚拟信道同步异步调度需求。

（2）初始化接口：①elem＿arr，元素数组；②elem＿arr＿len，当前元素对子元素同步或异步调度；③syn＿ayn，应用过程标志；④pri＿freq，优先级或输出频率。

（3）功能接口：SelectElem，根据同步或者异步方式调度元素。

3．3 构件组装和使用

在各个功能模块的构件化设计之后，需要将各个模块进行有效的组装，以形成完整的遥测系统，实现遥测源包的生成、下传和存储等功能。采用统一建模语言UML［8］类图描述其静态结构，如图3 所示。其中TmProc表示遥测模块。该图重点描述模块的构成，且在本文3．2节已经详细描述了各个构件对外提供的功能接口和功能，因此本图不再详细描述各个构件自身的属性和函数，均以空格表示。

图3 遥测模块软件构件组装关系Fig．3 Relationship of software components in TM module

为了实现星载遥测软件的通用化，本文通过软件构件化设计，通过对构件配置接口参数设置和构件功能结构参数设置，从而满足不同卫星型号任务的需求。构件化的遥测模块对构件对象初始化后，周期性进行操作。构件化遥测模块通过调用各个构件实例完成遥测采集、组包、包调度、组帧和虚拟信道调度等功能，其处理流程如图4所示，整个流程在任务启动后不断循环。

图4 通用遥测模块任务处理流程Fig．4 Flow chart of generalized TM module

4 试验结果及分析

本节对基于构件的通用星载遥测处理方法的应用情况进行分析，并对虚拟型号软件在应用该方法前后的开发效率、模块复杂度和资源消耗情况进行比对。

以Mission 1、Mission 2、Mission 3 和Mission 4等卫星型号为例进行试验验证，其中Mission 1采用传统的软件实现方式，Mission 2继承Mission 1遥测模块，并在Mission 1的基础上进行了适应性的改进。Mission 3采用了构件化设计，Mission 4继承Mission 3遥测模块。相关数据见表1。

表1 星载软件构件应用相关数据Table 1 Spacecraft software component utilization data

4．1 构件化开发技术对型号研制影响分析

两种不同的遥测功能实现方法，在软件研制效率和复杂度方面存在着较大的差异。

由图5可以看出，首次采用构件化设计的Mission 3，其效率并没有比普通型号提高多少。但是对于其后继承Mission 3 的型号Mission 4，与继承Mission 1的传统型号Mission 2相比，其研制效率迅速提高了3～5倍。

由图6 可知，使用了构件化的Mission 3 和Mission 4，应用程序所需要涉及的全局变量数量大幅度降低，不到Mission 1的1／4。即使是Mission 2对Mission 1 进行了优化，变量数量也是Mission 3或Mission 4 的3 倍以上。在定义的结构体方面，Mission 3和Mission 4应用程序所定义的结构体数量为0，即使是算上构件数量，也只是5 个，少于Mission 1和Mission 2的1／3。

图5 不同型号任务软件开发效率对比分析Fig．5 Analysis of efficiency of SW development in different space missions

图6 卫星型号任务应用程序设计复杂度分析Fig．6 Analysis of software complexity of different space missions

由此可见，采用了构件化设计后的型号Mission 3和Mission 4，其研制效率得到极大提高，应用程序复杂度大幅度简化，其优势表现在：①基于构件的通用星载遥测软件设计方法，极大地提高了对不同型号任务的适应程度，降低了型号任务开发时间和工作量；②基于构件的通用星载遥测软件设计方法，降低了型号任务应用程序的复杂度，一定程度上提高了系统健壮性。

4．2 构件化设计的遥测模块对代码规模的影响分析

从对存储资源的占用（即软件代码量）角度对比构件化的遥测模块与传统遥测模块，考虑不同卫星型号任务对遥测参数的定义数量存在较大差异，为了保证一般性，只对不同卫星型号任务的逻辑代码行数进行比较（见图7）。

图7 卫星型号任务遥测模块代码总行数Fig．7 Analysis of total code linage in different space missions

分析图7的数据，随着卫星型号对软件构件复用个数的增加，遥测模块涉及的总代码行数不但没有上升，反而呈下降趋势。可见通用遥测软件设计方法不会增加对资源的需求，反而在一定程度上节约了资源。

5 结束语

本文提出了一种基于构件化设计的可配置通用遥测软件方法，并经试验验证，对应用效果进行了统计和分析，研究表明：构件化的遥测模块通过参数配置的方式，能够将处理逻辑和用户需求分离，即构件化的功能设计，可提高软件的适应性、通用性，进而大幅度提高软件的开发效率；而且降低了代码设计的复杂度，提高了代码健壮性。除此之外，构件化设计的通用遥测模块，并未增加软件对资源的占用。本文的研究结果，可为星载遥测软件设计和其他星载软件设计提供参考。

（References）

［1］谭维炽，顾莹琪，空间数据系统［M］．北京：中国科学技术出版社，2004

Tan Weichi，Gu Yingqi．Space data system［M］．Beijing：China Science and Technology Press，2004（in Chinese）

［2］CCSDS，AOS Data Link Protocol．Recommendation for space data system standards，CCSDS 732．0-B-2．blue book［S］．Issue 1．Washington D．C．：CCSDS，2006

［3］Space Packet Protocol．Recommendation for space data system standards，CCSDS 133．0-B-1［S］．Issue 1．Washington D．C．：CCSDS，2003

［4］王向晖，王同桓，李宁宁，等．一种AOS遥测源包多路调度算法［J］．航天器工程，2011，20（5）：83-87

Wang Xianghui，Wang Tonghuan，Li Ningning，et al．An efficient scheduling algorithm of multiplexing TM service based on the AOS［J］．Spacecraft Engineering，2011，20（5）：83-87（in Chinese）

［5］赵和平，李宁宁．CCSDS标准在军用航天任务中的应用［J］．航天器工程，2007，16（4）：78-82

Zhao Heping，Li Ningning．Implementation of CCSDS standard in military space mission［J］．Spacecraft Engineering，2007，16（4）：78-82（in Chinese）

［6］杨仁宝，祝转民．组件化遥测处理方法的设计与实现［J］．测试技术学报，2010，24（4）：299-303

Yang Renbao，Zhu Zhuanmin．Design and implementation of component method for telemetry processing［J］．Journal of Test And Measurement Technology，2010，24（4）：299-303（in Chinese）

［7］张亚航，张猛．基于C语言的综合电子星载软件构件技术研究［C］／／第一届高分辨率对地观测学术研讨会．北京：中国航天科技集团公司，2012

Zhang Yahang，Zhang Meng．Research of space-borne integrated electronic software components based on C language［C］／／Conference on High Graphics Earth Observation Technology．Beijing：China Aerospace Science and Technology Corporation，2012（in Chinese）

［8］Object Management Group．OMG unified modeling language specification［S］．Needham：Object Management Group，2003