高分三号卫星中央单元多分区引导的设计与验证

董振辉 王向晖 穆强 潘莉 韦涌泉

(北京空间飞行器总体设计部,北京 100094)

高分三号卫星中央单元多分区引导的设计与验证

董振辉 王向晖 穆强 潘莉 韦涌泉

(北京空间飞行器总体设计部,北京 100094)

针对某遥感卫星静态随机存取存储器(SRAM)芯片故障导致中央单元(CTU)主机无法启动的问题,高分三号(GF-3)卫星数管CTU软件设计了一种静态随机存取存储器(SRAM)芯片故障模式下的多分区引导方法。通过在可编程只读存储器(PROM)中增加一个应急故障处理软件分区,在SRAM芯片部分故障情况下,CTU软件能够从正常CTU软件分区跳转到应急故障处理软件分区,并引导CTU软件进入应急故障处理模式。在该模式下执行SRAM芯片故障检测和正常CTU软件在轨注入,使CTU使用SRAM芯片无故障区域运行正常CTU软件。在GF-3卫星中,对该方法进行了软件实现和验证,结果表明:此方法可在中央处理单元SRAM芯片部分故障情况下,提供一种挽救方案,从而避免采取单一的切换备机处理措施导致CTU主机彻底不能使用的问题,提高了数管分系统的可靠性。

高分三号卫星;中央单元;多分区;引导;数管分系统

1 引言

高分三号(GF-3)卫星数管分系统中央单元(CTU)以高性能容错计算机为核心,完成数管分系统自身的指挥调度和状态管理,并对卫星数据流进行控制和自主管理[1-2]。CTU的CPU板为A、B双机冷备份设计,每个单板由CPU、静态随机存取存储器(SRAM)、可编程只读存储器(PROM)及相应电路等组成,SRAM为40 bit位宽,支持错误检测与纠正(EDAC)。

部分国内外航天器计算机系统的SRAM存储器采用单份设计,一旦发生故障,将严重影响计算机系统的正常功能,甚至无法运行。通过增加冗余存储器芯片,可在一定程度上解决该问题,但是也带来了成本和功耗增加的问题[3]。某遥感卫星在轨曾发生过CTU中A机SRAM读写异常故障,最终CTU切换到B机工作。导致该问题的原因最终定位于SRAM器件故障,而引发该故障的最大可能原因,为空间环境效应或者器件缺陷引发的个体偶发失效[4-5]。由于采用相同单份SRAM设计,对GF-3卫星数管分系统展开针对性设计,主动应对在轨可能发生的SRAM故障情况,在硬件设计不变的基础上,提出了一种在PROM中增加一个应急故障处理软件分区的多分区引导方案。该方案使CTU软件尽可能地避开SRAM故障区域,挖掘故障芯片的使用潜力,使挽救故障数管计算机系统成为可能。

2 可行性分析

GF-3卫星CTU软件最初的SRAM自检策略为:向SRAM中写入固定标识,之后回读数据并比较一致性,若发现回读数据与写入数据不一致,则认为自检失败。主机SRAM自检失败后的处理措施为CTU切到备机运行,主机后续将无法使用。但是在这种情况下,主机的SRAM芯片可能仅仅是部分区域故障,而理论上只要剩余内存资源足够,软件就可能继续运行[6]。

由于GF-3卫星修改CTU硬件设备的成本较高且周期较长,因此一种可行的方案是,在GF-3卫星单个PROM的空闲区域中,增加一个应急故障处理软件分区,在检测到SRAM故障后跳转到该分区运行应急故障处理软件,检测SRAM的故障情况并实施在轨维护[7],从而挽救发生SRAM故障的主机。

应急故障处理软件需要与正常CTU软件一起固化到PROM中,且运行过程中需要使用少量SRAM,因此,需要CTU的PROM和SRAM具有一定的余量。统计GF-3卫星的PROM和SRAM的资源使用情况见表1。

表1 GF-3卫星PROM和SRAM余量统计Table 1 PROM and SRAM residual statistics of GF-3

其中,PROM为只读器件,只要PROM空间能够存储下应急故障处理软件,那么应急故障处理软件就可以正常启动,因此应急故障处理软件固化到PROM的二进制文件所占空间(约为30 kbyte)必须小于GF-3卫星PROM的空闲空间。

GF-3卫星SRAM空间尚有较多余量,应急故障处理软件运行过程中仅使用少量SRAM(约为3 kbyte),因此可以通过固定划分,保证正常CTU软件和应急故障处理软件使用不同的SRAM地址范围。

3 多分区引导设计与验证

3．1 方案概述

高分三号PROM固化内容最初只有PROM启动程序[8]、CTU应用软件和CTU系统软件,采用多分区引导设计后,原固化内容作为分区1,部分空闲PROM区域作为分区2用于固化应急故障处理软件。分区1和分区2使用不重合的PROM空间及SRAM空间,两个分区运行的软件各自独立编译生成二进制固化文件,最终合并成一个固化文件并烧写到PROM芯片。

正常CTU软件运行过程中,发现SRAM不可纠正错后自动复位,复位过程中执行SRAM自检,自检不通过情况下,是否跳转至应急故障处理软件由硬件切机使能禁止决定。若硬件切机使能则备机启动并关闭主机,应急故障处理软件不会被执行,若硬件切机禁止则写切机端口无效,最终运行应急故障处理软件。

应急故障处理软件运行后,将SRAM故障检测信息通过遥测实时下传,地面根据SRAM故障情况制定在轨维护方案,通过遥控手段上注新的正常CTU软件的二进制数据至SRAM非故障区域,最后通过跳转指令跳转至新的正常CTU软件运行。通过多分区引导方案处理SRAM故障示意如图1所示。

3．2 软件实现

1)对正常CTU软件的修改

应急故障处理软件在CTU正常启动的情况下不会运行,不需要修改CTU应用软件和系统软件,仅需修改PROM启动程序,增加SRAM故障情况下跳转到应急故障处理软件的操作,修改内容包括:

(1)SRAM自检不通过时,PROM启动程序的原设计为直接写切机端口。采用多分区引导方案后,改为当SRAM自检不通过时,延时30 s再写切机端口(延时期间复位“看门狗”,地面可在该期间发送切机禁止指令),之后延时400 ms(若切机使能,备机可在400 ms内完成关主机操作)跳转到应急故障处理软件分区。

(2)修改启动过程中的SRAM自检范围,PROM启动程序的原设计为自检整片SRAM,采用多分区引导方案后,改为只检查正常CTU软件使用的前1024 kbyte。

2)应急故障处理软件的实现

应急故障处理软件为一个独立软件,其所具备的功能如表2所示。

表2 CTU应急故障处理软件功能Table 2 CTU emergency fault handling software functions

由表2可见,受PROM空间余量和SRAM使用最小化原则的限制,CTU应急故障处理软件仅包含了最简化的数管遥测遥控功能,并提供了完备的SRAM自检和在轨维护功能。CTU应急故障处理软件的外部接口如图2所示。

CTU应急故障处理软件为不使用操作系统的小型软件,采用主循环加陷阱处理的编程方式进行设计。启动后首先执行初始化,之后进入主循环加陷阱处理的运行模式。其中,系统初始化和引导功能在仅上电或复位时运行一次,陷阱处理功能仅在发生陷阱时运行,其余功能模块均在主循环中顺序执行。主循环中完成遥测功能、遥控功能和内存自检功能,其软件运行逻辑流程如图3所示。

3．3 在轨实施

CTU多分区引导方案仅在CTU主机SRAM故障后,地面试图恢复主机功能时使用,不作为主机故障后的即时应急处理措施。即主机SRAM故障后应优先切备机,待地面进行充分的分析且通过备机采取了整星安全措施后,再运行应急故障处理软件,检测具体故障区域,制定主机挽救方案。具体在轨实施方法如下。

(1)CTU默认切机使能,SRAM芯片故障后主机自动复位,复位过程中SRAM自检失败后先切换到备用机,待将卫星设置为安全状态后,再发送切主机指令和切机禁止指令,使主机运行应急故障处理软件。

(2)通过应急故障处理软件完成主机SRAM的故障检测后,将结果通过遥测下传给地面,之后地面发送切机使能指令和切备机指令,卫星通过CTU备机继续正常工作。

(3)在使用CTU备机工作期间,地面根据SRAM故障检测结果,生成能够在SRAM无故障区运行的正常CTU软件的二进制数据,并制作在轨维护指令。

(4)发送切主机指令和切机禁止指令,使主机运行应急故障处理软件,并通过应急故障处理软件将正常CTU软件的二进制数据注入到SRAM无故障区,最后发送跳转指令,跳转到新上注的正常CTU软件运行,SRAM芯片故障处理结束。

3．4 约束及限制

多分区引导方案为GF-3卫星研制后期临时增加的可靠性设计方案,受系统资源的限制,在使用过程中的约束与限制如下。

(1)应急故障处理软件只有基本的遥测、遥控及在轨维护功能,不具备正常CTU软件的星务管理、整星数据服务、程控等功能。

(2)应急故障处理软件只将部分数管软遥测以及双远置单元(DRTU)采集的整星模拟量遥测下传,不支持下传其它分系统的总线遥测数据。

(3)遥控功能仅支持处理包含单个指令单元的遥控块,指令单元类型仅限于ON/OFF指令、总线指令、总线设置指令,在轨维护指令以及跳转指令,不支持延时指令功能,不支持转发其它分系统的遥控注入数据。

(4)若应急故障处理软件数据段所在的SRAM区也发生故障,应急故障处理软件不一定能正常运行。

(5)根据应急故障处理软件的自检结果,若SRAM存储单元大面积发生故障,或者SRAM存储单元故障区域较多且分散,制作在SRAM无故障区运行的正常CTU软件二进制数据的难度较大,只能放弃修复或者功能降级修复。

当一些制约条件不存在时,本文提出的方法可以在应急故障处理软件中实现更多功能。

4 测试验证

在图4所示测试环境[10]中,将多分区引导固化文件烧写到CTU的PROM芯片中进行了测试验证,验证内容包括:

(1)测试SRAM故障情况下,正常CTU软件跳转到应急故障处理软件的功能是否正常。

(2)测试应急故障处理软件的各项功能是否正常。

测试过程中,通过ERC32仿真器在CTU的SRAM芯片中人为制造双比特错的方式,模拟在轨发生SRAM器件故障的情况。测试结果表明,在模拟SRAM故障的情况下,正常CTU软件分区无法启动运行,在地面控制下CTU进入应急故障处理软件分区运行,应急故障处理软件各项功能正确。

5 结束语

本文针对某遥感卫星在轨发生SRAM故障的问题,以GF-3卫星为例,在不修改中央处理单元硬件的基础上,设计了一种多分区引导方案。该方法为遥感卫星中央处理单元首次在轨应用,可在SRAM芯片部分故障情况下,检测故障区域,实施在轨维护,恢复正常CTU软件的功能,从而避免采取单一的切机处理措施导致故障CTU主机彻底不能使用的问题,提高了数管计算机系统的可靠性,可为后续卫星设计提供参考。

References)

[1]赵思阳,张红军,董杰,等．高分二号卫星数管分系统设[J]．航天器工程,2015,24(z2):97-100 Zhao Siyang,Zhang Hongjun,Dong Jie,et al．Design of Gaofen-2 satellite OBDH subsystem[J]．Spacecraft Engineering,2015,24(z2):97-100(in Chinese)

[2]何熊文,孙勇．一种卫星数管中心计算机软件的工程实现[J]．航天器工程,2007,16(5):47-53 He Xiongwen,Sun Yong．Engineering realization of software in central terminal unit of satellite data management system[J]．Spacecraft Engineering,2007,16(5):47-53(in Chinese)

[3]朱玛,刘云鹤,刘宁,等．高分四号卫星信息流设计[J]．航天器工程,2016,25(z1):37-43 Zhu Ma,Liu Yunhe,Liu Ning,et al．Design of information flow for GF-4 satellite[J]．Spacecraft Engineering,2016,25(z1):97-100(in Chinese)

[4]范基坪,焦健,赵海涛,等．导航卫星单粒子软错误影响建模与仿真方法[J]．北京航空航天大学学报,2016,42(5):1008-1015 Fan Jiping,Jiao Jian,Zhao Haitao,et al．SEU soft error effect modeling and simulation method for navigation satellite[J]．Journal of Beijing University of Aeronautics and Astronautics,2016,42(5):1008-1015(in Chinese)

[5]张昊,王新升,李博,等．微小卫星单粒子闩锁防护技术研究[J]．红外与激光工程,2015,44(5):1444-1449 Zhang Hao,Wang Xinsheng,Li Bo,et al．Research on single event latchup protection technology for micro-satellite[J]．Infrared and Laser Engineering,2015,44(5):1444-1449(in Chinese)

[6]江建慧,朱为国．嵌入式存储器的内建自测试和内建自修复[J]．同济大学学报(自然科学版),2004,32(8):1050-1056 Jiang Jianhui,Zhu Weiguo．Survey on built-in self-test and built-in self-repair of embedded memories[J]．Journal of Tongji University(Natural Science),2004,32(8):1050-1056(in Chinese)

[7]安军社,刘艳秋,孙辉先．软件的动态维护与实现[J]．计算机工程,2003,29(2):238-239 An Junshe,Liu Yanqiu,Sun Huixian．Implementation of on-board software maintenance[J]．Computer Engineering,2003,29(2):238-239(in Chinese)

[8]王亚刚．嵌入式Bootloader机制的分析与移植[J]．计算机工程,2010,36(6):267-269 Wang Yagang．Analysis and transplant of embedded bootloader mechanism[J]．Computer Engineering,2010,36(6):267-269(in Chinese)

[9]王向晖,王同桓,李宁宁,等．一种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)

[10]董振辉,侯春青,郭坚,等．一种航天器软件进程堆栈使用深度的动态检测方法[J]．航天器工程,2017,26(1):85-90 Dong Zhenhui,Hou Chunqing,Guo Jian,et al．Dynamic detection method of spacecraft software process stack used depth[J]．Spacecraft Engineering,2017,26(1):85-90(in Chinese)

Multi-partition Boot Design and Verification of GF-3 Satellite CTU

DONG Zhenhui WANG Xianghui MU Qiang PAN Li WEI Yongquan
(Beijing Institute of Spacecraft System Engineering,Beijing 100094,China)

The failure of SRAM chip in a remote sensing satellite has caused the current central terminal unit(CTU)failed to boot up,GF-3 satellite central terminal unit software designed a multi-partition boot method under the fault mode of SRAM chip．By adding an emergency fault handling program partition in the PROM,in the case of SRAM chip part failure,center terminal unit software will jump from normal program partition to emergency fault handling program partition,and lead the central terminal unit into emergency fault handling mode．In this mode,the SRAM chip fault detection and on-board software maintenance are executed,so that the central terminal unit can run the normal CTU program using the SRAM trouble-free zone．In GF-3,this method is realized and verified,the result shows that the method provides a rescue plan in the case of central terminal unit SRAM part failure,so avoiding the single switching measure which will cause the current CTU to be completely unusable,and improves the reliability of the on board data handling subsystem．

GF-3 satellite;center terminal unit(CTU);multi-partition;boot;on board data handling subsystem

2017-10-20;

2017-11-16

国家重大科技专项工程

董振辉,男,工程师,从事航天器星载软件设计工作。Email:564760683＠qq．com。

V443

A

10.3969/j.issn.1673-8748.2017.06.020

(编辑:李多)