高分三號衛星中央單元多分區引導的設計與驗證

董振輝 王向暉 穆強 潘莉 韋涌泉

(北京空間飛行器總體設計部,北京 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

(編輯:李多)