支持任务自主接入的星务软件重构方法

李翔,宫江雷,2,郭莉芳,韩笑冬,*,王超,杨凯飞

1.中国空间技术研究院 通信与导航卫星总体部,北京 100094

2.西安电子科技大学,西安 710126

1 引言

随着软件定义理念在航天领域的大力推广,卫星软件技术逐步向着自主化、易重构的方向飞速发展。卫星所处的物理空间环境恶劣,硬件设计时出于抗辐照、防单粒子效应等因素的考虑,大多采用宇航级元器件,导致单机计算和存储资源有限[1-4],因此星务软件设计及操作系统选型上以简单可靠为核心目标,无法支持复杂的上层应用如文件系统、补丁发布等功能,这对提升整个软件系统的可重构性带来了较大的难度。

星载综合电子系统作为卫星数据流与指令流交互的核心系统,时刻扮演着卫星大脑的角色。而综合电子系统的主要功能及任务都是依托于星务管理软件来实现。在轨期间由于器件老化、设备损坏等原因,卫星状态及相关性能会发生变化,软件控制策略随之可能发生改变,此时存在上注补丁修改星务管理软件的需求[5];同时随着技术的发展,现有的星务控制策略和任务设计已无法满足未来用户需求和技术的更新换代要求,通常需要通过更新星务管理软件的方式来适配新的应用需求,延长卫星在轨的服务时间[6-7]。

但是星务管理软件一旦固化后,在轨更改的手段很匮乏,目前只能通过在轨维护的方式对软件进行修改,传统的在轨维护方式存在以下几个问题:

1)目前星务管理软件在轨维护手段偏少,能力偏弱,无法支持在轨扩展自定义任务的需求。现有软件设计主要提供函数级和整个配置项级的维护能力。配置项级维护方式作为软件修复的最后一道防线,维护颗粒度过于粗放,且对上行信道资源占用时间开销较大,除非现有程序无法正常运行,一般情况下不予采用。而目前函数级维护只能对预先设计好的固定类型的函数进行维护,无法引入自定义类型的函数。传统的函数维护方法,是在软件设计阶段筛选出可能被维护的目标函数,根据目标函数类型生成函数指针列表,并在程序里预埋钩子函数,实际维护过程中不能超过配置好的函数列表的范围。同时当前的函数维护机制无法支持自定义类型的函数的上注,因此具有一定的局限性。

2)传统星务管理软件的设计中,卫星在轨执行的任务是预先规划好的,在轨无法进行扩展和重新规划,而且任务相关资源也是静态配置好,无法在轨动态重配。在实际应用中,时常需要通过任务的重构来重新定义卫星的功能及应用场景,并且实现上注任务动态加载,即插即用,现有机制无法支撑卫星任务动态扩展的需求。

3)在轨维护上注的数据具有掉电即失的特点,星载计算机复位或切机的情况下,存在维护补丁失效的风险。现有维护机制下,补丁上注后,软件会修改内存中的数据段或代码段内容,星载计算机复位或者断电后内存上内容会被清除,软件再次启动时,补丁失效。即使在某些研究中,存在通过非易失器件保存维护补丁的设计,但其仅能解决本机重启后恢复问题,发生系统故障切机后仍然无法恢复补丁。通常在轨维护补丁用于对星务软件的算法性能进行优化,对软件潜在BUG进行修复,一旦星载计算机复位或切机,软件恢复到维护前旧状态,地面需重新上注补丁进行软件维护,存在维护不及时导致软件性能降低或BUG复现的风险。

因此,基于以上的问题现状,需要设计一种安全灵活的软件在轨重构方法,支持卫星任务的动态扩展及自适应接入,确保任务补丁的常驻存储及重启后自主恢复,进一步提升卫星重构的安全性与灵活性,满足卫星快速响应的需要。

2 支持任务重构的星务软件架构设计

2.1 相关硬件环境概述

典型卫星硬件系统由中心计算机、星内总线、遥测遥控单元、敏感器及执行机构、载荷计算机以及其他远置单元构成,如图1所示。中心计算机是整星信息、数据、指令交互的中枢,物理层由CPU搭配异构计算单元提供面向用户应用的计算和存储能力,并且汇聚了多种高中低速总线接口,提供不同需求的星内数据访问以及星间通信能力。

图1 卫星硬件系统结构示意

(1)中心计算机

中心计算机系统以CPU模块为核心,与搭载软件一起构成自主管理与控制系统,一般由CPU,外围存储器如RAM,PROM,FLASH,总线通信模块以及容错模块等构成,如图2所示。

图2 中心计算机组成示意

(2)容错SRAM

容错SRAM用于保存卫星运行期间内的重要数据及相关参数,在设计时,利用主备机热备工作的SRAM以实现重要数据的保存。当班机异常导致切机后,对方机上电后,从容错SRAM中恢复之前保存的重要数据。例如,CPU主机故障后,CPU备机上电从容错SRAM中恢复CPU运行所需的重要数据[8]。

容错SRAM与CPU-主、CPU-备之间采用交叉的连接关系,如图3所示。

图3 容错SRAM交叉连接示意

CPU-主机、CPU-备机之间通过隔离电路实现与SRAM的交叉访问,通过对数据方向的控制来实现故障的隔离,CPU-主机(或CPU-备机)发生故障时,不会影响另一机对主备SRAM的正常访问。

当班CPU模块正常工作期间,依次对主备容错SRAM进行读写,并将重要数据保存至双份容错SRAM,当完成容错SRAM的写操作后,CPU模块会自动地回读写入的数据,并进行数据比对,当数据与写入数据不符时,CPU模块会将无效标志写入容错SRAM,当连续三个周期都出现比对错误时,则CPU模块会将错误状态通过遥测下传地面,并停止对故障容错SRAM进行访问操作。当CPU模块发生切机后,对方机CPU模块上电后会依次读取主备容错SRAM中的重要数据。CPU模块首先对容错SRAM有效标志进行判断,如为无效状态,则CPU模块停止对当前容错SRAM进行访问,CPU模块判断完有效标志后,对重要数据校验和进行计算,CPU模块只选择校验和正确的重要数据进行恢复,当主备容错SRAM重要数据均正确,则CPU模块选择星时大的重要数据。如果上电后,CPU模块读取的主备容错SRAM均为无效状态,则对主备容错SRAM初始化清零处理。

2.2 星务软件架构设计

(1)分层设计

星务软件架构遵循“软件定义”的设计理念,通过分层设计及协议优化实现软件组件与模块的即插即用,提高卫星软件产品的功能可扩展性[9],具体架构如图4所示。

图4 星务软件架构示意

图5 软总线通信示意

该框架从子网层到支持层,再到用户应用层均采用自适应的交互协议,可实现自定义任务的即插即用。

1)子网层:其中物理层主要是指星载计算机硬件设备;数据链路层主要用来屏蔽底层硬件,进行基本硬件系统的初始化和驱动;子网业务层主要提供底层硬件服务任务,实现总线通信协议、串口通信协议等。其中总线协议采用自适应的通信协议,符合该协议的总线设备接入时通过握手通信实现自动注册,合法设备可实时加入系统中,无需提前配置,真正实现接入设备的即插即用,为可编程载荷的实现提供了可能。

2)应用支持层:其中专用业务层提供通用管理任务,将应用软件与数据链路层的物理拓扑结构和数据子网隔离开;而软总线层,提供通用的数据和信息交互的管道,向下将总线设备进一步抽象为共享缓存区的数据源,往上向应用层开放访问接口,合法模块只要注册成功均可实现对共享缓存区中数据的访问,随时注册随时访问,实现了软件组件的即插即用,为实现软组件重构提供了基础。

3)应用层:星务任务的集合,根据获取的数据进行星上任务的管理。平台任务层为卫星系统维持平台正常工作而设计的最小任务包络,完成对在轨工作中能源、信息、结构等系统的正常工况保持和故障检测。用户任务层为面向用户开放的自定义任务集合,在现有的自适应总线和软总线协议基础上,用户通过任务级维护的方式实现功能重构,重新定义用户的应用场景。

(2)软总线设计

软总线的设计思路是将软件系统看成是具有总线拓扑结构的网络,通过软总线实现类似于硬件总线的桥梁功能,任何一个符合一定标准的应用程序都可以通过插件方式获得软总线的支持,与总线上的其他部件相互通信、协调与控制[10]。采用软总线体系结构的系统集成方式,可以有效地降低需要集成的系统之间的耦合程度,具有良好的可扩展性、可复用性、可维护性[11-12]。

具体到上一节的软件框架中,软总线将底层驱动及通用业务进行抽象,形成与硬件无关的资源分配及读写操作,提供星上遥测及遥控信息流驱动接口,上层应用任务通过对软总线层的接口调用完成遥测获取、遥测下传、指令接收、指令分发等任务,实现对下位机设备的控制[13]。从而使应用任务在设计上屏蔽具体总线接口和硬件设备形式,只需专注于应用具体任务的实现,便于软件在不同型号不同平台卫星上的移植。

应用任务初始化时,将该任务模块进行注册,获取对应下位机设备数据源的操作权限。初始化完成后,软件模块与对应的遥测包号完成配对,自动完成软总线两端“设备”,即软件模块与下位机设备的通信建立。应用任务在获取数据之前,会自动判断对应的数据包的状态,如果硬件通信状态不正常,则获取的数据包为无效或者不更新状态,此时软件模块无法通过软总线获取正常更新的数据,软件会将错误信息下传地面。如果通信状态正常,则软件模块可通过读数据接口获取总线上的遥测数据。软总线提供了多个从硬件总线缓存中获取遥测数据的接口,可按位、按字节、按字、按遥测包号来获取或者回写不同类型的数据,并且按照数据协议格式进行自动校验。

同时,通过软总线的指令接口,软件模块可以实现对硬件设备的主动控制。软总线提供写指令接口,由底层驱动完成相关时序的匹配,发送指令。而且软件模块在运行过程中会收到由地面设备发送的遥控指令,软总线对上行通道的指令缓存的读取进行了封装,通过读指令接口直接获取遥控指令,从而完成地面对软件模块的控制。

(3)链接脚本设计

软件工程中,软件功能实现是从源代码开始,编译链接后形成可执行文件,在此基础上生成机器可识别的bin文件,生成过程中,一般由集成开发环境中嵌入的连接器自动分配程序中text段、data段、bss段的位置,这样会导致自定义任务与原有任务的空间界限不清晰,不便于单独管理新增任务的内存空间[15]。

此时可以采用定点链接的方式,自定义指定新任务各个段在程序运行时的地址空间布局,指定新增任务的text段、data段及bss段的位置,同时预留出足够大的空间给预扩展任务使用,实现与原有软件任务内存空间的隔离,如图6所示。定点链接通过改写链接脚本,通过SECTIONS和MEMORY等关键字,完成对目标文件各段空间分布的约束,实现原有代码与维护代码的定向隔离,避免新任务内存空间与原任务内存空间之间的冲突和污染。

图6 定点链接原理示意

图7 任务重构流程示意

可以看出,星务软件架构中的分层设计保证了新增任务与已有任务逻辑层面的分离,而基于链接脚本的定点链接设计,则实现了新增任务与已有任务物理空间的分离,进一步保证了新增任务对已有星务软件系统的影响是严格可控的。

3 任务上注、接入及恢复机制

目前,卫星软件在轨重构主要通过在轨维护方式实现,传统在轨维护方式重构的颗粒度较大,维护方式过于粗放,且对上行信道资源占用时间开销很大,效率较低。

本文在现有软件维护的基础上进行优化,采用定点链接技术,实现新型的支持任务自主接入的重构机制,全面支持用户任务的自适应扩展。同时设计任务重构的数据封装协议,支持任务动态的新增、删除和修改,对重构后的新功能提供断电后自主恢复服务。

3.1 任务上注及自主接入流程

任务重构的核心目标是以应用任务为基本单位,在轨进行动态的增删改操作,主要流程是上注一个新的任务模块实体,替换任务池中已有的应用任务,或者在原有任务集合基础上新增一个任务模块,并且动态地加载运行。

一般来说,描述一个任务除了任务体内容外,还需要定义任务ID、任务名称、主函数入口、堆栈大小等配置信息。所以一个任务补丁至少需包含一个函数和若干全局变量。任务上注流程主要分为两大步骤:一是上传任务体内容,即函数及变量的静态上注,二是发送任务新增或替换请求,随即启动任务。

在用户任务上注并成功启动后,通过操作系统的任务加载接口可实现将新增任务插入星务软件任务池中,但新任务要完成具体的业务功能,还需要获取星上通信资源池的访问权限,用户才能通过星上遥控遥测资源完成与新任务的信息交互。星务软件设计中可通过一键注册的方式实现新任务与通信资源池的对接,无需地面介入,新任务通过资源注册接口可获取专属的指令与数据空间及操作资源,自主获取资源池访问权限。而星务软件可对外提供星务通信资源池的操作访问接口,作为API接口文件面向用户或第三方开放,通过调用该接口可实现自定义任务在成功加载后自主接入星务通信资源池中。星务通信资源池通过共享缓存区来实现星内以及星地信息流和指令流访问与管理,原理如图8所示。

图8 新任务上注流程示意

步骤如下:

1)用户在编写自定义任务程序时,在任务入口处进行初始化操作时,调用软件资源管理模块中的任务注册接口Register_Cmd、Register_PK,输入唯一且合法的任务ID,可自动获取该任务专属的指令与数据缓存区,空间大小可作为入口函数的输入参数由用户自定义。

2)注册完成后,自定义任务成功获得缓存区操作权限,可通过Read_Cmd、Read_PK接口获取任务的输入信息。Read_Cmd用于获取地面发送的遥控指令,通过ID号从星地遥控指令缓存区中识别并读取发往该任务的遥控指令,任务根据指令类型做出响应。Read_PK则用于获取下位机遥测信息,通过ID号从星内总线遥测缓存区中读取该任务被授权操作的下位机采集的遥测包数据,作为该任务工作的输入条件。

3)任务在运行过程中可通过Write_Cmd、Write_PK接口输出软件控制与状态信息。Write_Cmd用于向下位机发送控制指令,通过ID号向分配的专属星内总线指令缓存区中写入指令,由总线发送给对应的下位机,实现软件对目标设备的控制。Write_PK则用于将任务运行状态、控制参数等软件信息写入分配好的专属PK包遥测缓存区中,通过遥测下行通道传至地面,实现地面对自定义任务状态的监测。

3.2 数据补丁协议

任务重构是一个动态过程,需要分成两步来完成:一是任务所含所有函数及变量内容,即任务数据补丁的上注,二是任务动态启动的指令,即任务启动补丁的上注。

要完成上述两种补丁的上注,需要按照一定的数据格式要求进行对生成的任务体内容文件进行分割及封装,工作量较大,采用操作系统在轨维护工具来自动配置完成在轨维护序列的生成。生成的数据块,可以通过地面总控发送在轨维护指令至卫星,将对应的数据块写入到配置的地址上,然后发送在轨维护启动指令,软件调用在轨维护接口加载对应的数据块,完成相应类型的数据/函数注入功能。具体协议及操作流程如图9所示。

图9 任务数据补丁协议及操作流程

数据补丁分为补丁头和补丁内容两部分,补丁头由校验和、标志位、序列号、维护类型及数据载荷大小组成,其中维护类型分为三种:数据和函数注入、新增任务、删除任务。补丁内容由注入头、相关任务区、数据变量区和函数代码区组成,注入头包括数据补丁中相关任务数量、变量数量和函数数量,相关任务指的是与重构任务有共享变量或者竞争关系且优先级不同的任务,重构过程中会先将竞争关系任务挂起,等重构任务启动后再依次唤醒相关任务,保护重构过程的原子性。补丁制作完成后需按照星地遥控指令长度进行分割,然后按照星地遥控指令格式进行封装[13]。

在变量/函数注入完成后还需进行任务启动补丁的上注,完成对重构任务的动态加载。任务启动补丁协议如图10所示。

任务启动补丁也分为两部分内容,启动补丁头包括校验和、标志位、序列号、维护类型、载荷大小。任务启动补丁内容中任务ID、任务名称、任务优先级、任务堆栈、堆栈大小、入口函数地址、任务参数等均为新建任务所需传递的参数。

3.3 补丁容错及自主恢复

在轨维护场景发生一般是卫星功能需要更新或BUG需要修复,维护完成后新增功能是插入到当前RAM区启动运行,如果中心计算机在轨切机或者复位后,新增的任务就丢失了,此时仍然会回到旧版软件运行。而往往地面不能及时发现,此时维护任务就失败了。

为了避免这种情况,在更新时代码上注到中心计算机后,将该补丁数据拷贝到容错SRAM中,作为重要数据保存下来,在硬件重启或切机后,软件初始化时对任务补丁进行逐个恢复。

上注到应用层的新增任务是插入到内存RAM区启动运行的,如果星载计算机切机或者软件复位后,上注的新增任务就丢失了,此时用户任务的功能将无法正常运行。为了避免这种情况,在新增任务上注到星载计算机后,将该任务数据拷贝到常加电的容错SRAM中,作为重要数据保存下来,在硬件重启或切机后,星务软件初始化时对用户层任务进行逐个恢复。

任务补丁在上注时若选择重要数据保存,星务软件在容错SRAM中会依次保存三份相同补丁内容,如图11所示。

图11 任务补丁储存示意

存储成功后,星务软件会定时读取本机及对方机容错SRAM内容,采用三模冗余纠错机制,定时刷新容错SRAM内容,减少单粒子效应对SRAM的影响。刷新周期的设计需考虑对任务空闲时间的充分利用并兼顾任务负载的均衡,一般设计为10s刷新一次。

硬件复位后,星务软件恢复,从本机容错SRAM重要数据保存区中读取维护的数据补丁,重新调用在轨维护接口,实现维护补丁的恢复。

硬件切机后,星务软件恢复,从对方机容错SRAM重要数据保存区中读取维护补丁数据,重新调用在轨维护接口,实现维护补丁的恢复。恢复过程对用户来说是透明的,复位或切机过程完成后,维护补丁第一时间恢复。

4 仿真验证

基于以上技术方法,搭建仿真验证系统,以任务即插即用典型应用场景为示例,开展仿真验证。通过地面演示系统,验证技术路线的可行性,展示程序可靠接入及安全卸载的能力,为探索出快速灵活的软件在轨重配置方法奠定基础。

在实验室搭建目标硬件环境,进行仿真验证,组成如图12所示。

图12 仿真系统结构示意

目标硬件性能指标如表1所示。

表1 目标硬件性能指标

以上述原型系统为基础开展自定义任务的上注功能验证。在上述硬件条件下建立软件多任务运行环境,搭载高可靠的实时嵌入式操作系统,支持基于优先级抢占的任务调度机制。

以星务管理软件常规功能为例,共设计9个应用任务,主要包括重要数据保存(SLIP)、热控(TCS)、能源(PCS)、程控(EM)、故障监测(FDIR)、在轨维护(OMT)、遥控(TC)、遥测(TM)、延时遥测(DTM)、新增任务为载荷管理(PLCS)、优先级配置如表2所示,主要分为三档,遥测和延时遥测最高,以确保星地遥测码流连续,遥控次之,其他应用任务同优先级。

表2 仿真任务列表

所有任务均在1s周期内至少运行一遍,运行周期排布如图13所示。

图13 任务运行周期示意

根据在轨正常工况,模拟任务全负荷运行状态(全功能使能,采集遥测全输入),随后上注新增任务,流程如图14所示。

图14 新增任务示意

新增任务完成载荷自主管理功能,实现对载荷设备状态的采集和数据预处理,该任务独立编译后目标码占空间大小45kbyte,在上述硬件平台上运行平均时间为42ms,通过指令上注实现任务重构,该过程共耗时18min。任务运行时间统计结果如表3所示。

表3 任务运行时间统计

表中T1代表上注前平均运行时间,T2代表上注过程中平均运行时间,T3代表上注完成后瞬态运行时间,T4代表上注完成后稳态下运行时间,T5表示复位后恢复到稳态情况下的任务运行时间,T6表示硬件切机后恢复到稳态情况下的任务运行时间。上注前平均时间是通过在任务代码中打桩插入调试信息,计算对应任务的运行耗时数据,实际运行1h后,对调试数据进行统计计算得到的平均值。上注完成后瞬态为地面发送重构启动指令后的3个运行周期。表中标红数字表示在上注前后有明显变化的时间信息,详细变化趋势如图15所示。

图15 任务时间开销曲线

经过分析,将表3中标注的任务时间信息变化原因分别描述如下:

1)上注过程中在轨维护模块由于负载变大导致运行时间增加,在上注期间该模块负责解析上注指令块并实时写入待搬移内存空间上。

2)启动指令由遥控任务进行处理,任务开销略微增大,处理完成后调用加载任务接口将自定义任务加入当前就绪任务队列中,在下一个周期任务调度时自定义任务随即运行。

3)上注完成后的瞬态,自定义任务需先进行星载资源注册,主要完成遥测遥控缓存区资源、任务堆栈资源的注册,被认定为注册合法后,再启动周期任务。因此瞬态下自定义任务运行时间较正常运行变大,进入稳态后运行时间与独立运行工况下一致。

4)由于新增任务的加入,原有任务中遥测与延时遥测任务运行时间变长,因为自定义任务引入了其专属的遥测数据,需原有遥测与延时遥测任务进行处理,导致其任务工作量增大,但在可控范围内。除此之外,其他任务未受影响。

5)在复位和切机情况后的一段时间内,重要数据恢复任务运行时间会上升至90ms左右,这是因为新增任务补丁的恢复和重启功能在重要数据保存及恢复任务中实现,完成从非易失存储器中读取补丁数据并动态加载的过程,待新增任务正常运行后,重要数据任务的运行时间随之恢复至稳态60ms左右的水平。

通过上注试验可以看出,新增任务的上注对其他非相关任务的运行特性基本无影响,在新增任务加载和接入过程中的瞬态对相关任务会造成其时间性能上的抖动,加载完成后,各任务运行性能迅速恢复到稳定状态,总的任务机时仍满足1s周期的要求。在整个验证过程中,各任务调度正常,未出现任务中断或超时的情况,即使在硬件出现复位或切机的故障情况下,软件会自动恢复新增任务补丁,重新加载该任务,恢复到正常状态,说明该方法能确保重构过程的安全性。

对于用户来说,自定义任务的启动和加载过程几乎无感,且可靠。地面发送完数据块上注指令后,只需发一条任务启动指令,软件会自主完成任务动态加载、遥测遥控资源注册、数据补丁保存及故障下恢复等功能,无需地面参与,实现一键接入,大大提升现有重构方法的灵活性。

5 结论

本文提出了一种支持任务重构及自主接入的星务软件架构,开展对任务自主接入及硬件重启后自主恢复机制的研究,提出支持任务自主接入的星务软件重构流程及补丁协议,最终针对新型软件架构和任务接入方法进行仿真,结论如下:

1)结果验证了在轨任务级重构的可行性与正确性,为星务软件设计打破硬件资源紧张带来的条件约束提供了解决方案,大大提升了星务软件的可扩展性。

2)方法中容错SRAM的设计提供了软件切机后恢复补丁数据的能力,解决了硬件复位或切机情况下新任务数据丢失且无法恢复的难题,提升了重构功能的安全性。

3)自主接入策略完善了现有任务加载后新资源的分配与获取功能,实现了资源一键注册,自主加载,减少了地面介入,具备较好的灵活性。