硬X射線調制望遠鏡衛星1553B總線芯片RAM故障容錯設計

董振輝 穆強 毛亮 張紅軍 張睿 元勇

(北京空間飛行器總體設計部,北京 100094)

航天器總線控制器(BC)端和遠程終端(RT)設備總線芯片隨機存取存儲器(RAM)發生永久性故障,將導致航天器部分或整體總線通信功能失效。傳統的在軌維護方式雖然能對故障進行消除,但是代價和風險較高。近年來,若干在軌衛星相繼發生1553B總線芯片RAM區部分損壞的故障,經分析均是因為在軌單粒子[1]鎖定后引起器件內部RAM區損壞,發生的故障均為永久性故障。雖然部分衛星通過在軌維護方式[2]對總線芯片RAM故障進行了消除,但是這種在軌維護屬于臨時應急處理,需要臨時查找軟件地址、設計維護方案并制作在軌維護指令,加之衛星壽命后期總線芯片故障集中爆發的時候,軟件人員對軟件狀態已經淡忘,進行在軌維護的風險較大。

鑒于進口總線芯片在軌頻繁故障,在硬件設計上將進口總線芯片替換為國產抗輻照總線芯片的基礎上,HXMT衛星軟件設計過程中對能夠采取的可靠性措施進行了分析論證。針對總線芯片RAM故障,設計了分別適用于BC端和RT端的總線芯片故障檢測和修復方案,可靈活便捷的處理各種總線芯片RAM故障。

1 難點分析

1.1 BC端總線芯片RAM容錯處理難點分析

HXMT衛星BC端設備為數管分系統中央單元(CTU)[3],其使用總線芯片的方法,是將1553B總線作為共享資源[4-5],各軟件進程排隊使用,即對總線芯片的操作分散在各個軟件進程中。每次啟動消息發送后,軟件等待總線消息通信結束后才執行后續操作。總線芯片一般使用增強型工作模式[6],其內存組織形式見表1。

表1 增強型BC端總線芯片內存組織形式Table 1 Bus chip memory map of enhanced mode BC terminal

軟件通過總線芯片發送或接收數據時,需要設置以下RAM區域:

(1)Stack A/B(寫入待發送消息所在的BLOCK的片內地址);

(2)Stack Pointer A/B(發送的起始位置);

(3)Message Count A/B(本次發送的消息個數);

(4)Message Block(待發送的數據、命令字、控制字,如果本消息用于接收數據,則無需寫入數據)。

從總線芯片RAM區資源重配置角度考慮,一種最理想狀態是軟件僅使用一個棧區,且消息塊使用不超過47個,從而主份棧區和消息塊區出現故障時,可以使用備份資源完全替換。HXMT衛星數管分系統CTU軟件設計時,僅使用總線芯片A棧區,使用最多64個消息塊,非常接近這種理想狀態,具備進行總線芯片RAM故障檢測和修復的條件[7]。

1.2 RT端總線芯片RAM容錯處理難點分析

HXMT衛星RT端設備以數管分系統遠置單元(Remote Terminal Unit,RTU)為例[8],軟件設計時將總線芯片RAM按照子地址數據傳輸內容進行固定分配,內存組織形式見表2。

表2 RT端總線芯片內存組織形式Table 2 Bus chip memory map of RT terminal

在0000～0247H區域中,查找表可以互相備份,0140 H～01BFH為查找表主區,01C0H～023FH為查找表備區。其余區域沒有可以使用的備份區,不進行備份。

0248 H～02FFH區域為RTU軟件沒有使用的區域,不進行備份。

0300H～03FFH為固定使用區,沒有備份區域,不進行備份。

0400H～0FFFH為數據塊區,根據RTU軟件對總線RAM的占用情況,將其分為主備兩區,0400H～07FFH為數據塊主區,0800 H～0BFFH為數據塊備區,主備區可以互相備份。

0C00 H～0FFFH為RTU軟件沒有使用的區域,不進行備份。

2 對總線芯片RAM故障的容錯設計

通過以上難點分析,HXMT衛星BC端和RT端分別采取了相應的針對總線芯片RAM故障的容錯設計。

2.1 對BC端總線芯片RAM故障的容錯設計

2.1.1 方案概述

對BC端總線芯片RAM故障的容錯設計如下:當CTU在軌發生總線芯片RAM區故障時,首先通過上注指令檢測定位RAM故障區域范圍,之后上注指令使用總線芯片RAM區中的冗余資源替換故障資源,處理流程如圖1所示。

圖1 BC端總線芯片RAM故障處理流程圖Fig.1 Flow chat of BC terminal bus chip fault handling

該設計在具體實現和使用策略方面具備如下特點。

(1)CTU軟件本身具備檢測總線RAM的功能,但是平時一直處于關閉狀態,根據地面上注指令打開自檢功能,以避免影響正常總線通信。

(2)由于1553B總線芯片RAM在軌故障的位置隨機,需要人去分析決策,因此總線芯片在軌故障后CTU軟件不進行自主處理,而是交由地面決策后處理。

(3)為了更好的處理1553B總線芯片在軌出現的永久故障,該設計提供了一組靈活便捷的遙控指令,而不是采用風險較大且復雜的在軌維護方式。2.1.2 BC端檢測定位RAM故障區域的方法

通過下傳的遙測數據發現BC與RT設備之間總線通信異常時,首先檢測定位總線芯片的故障區域。總線芯片RAM區自檢功能平時處于禁止狀態,檢測由地面上注總線芯片RAM區檢測使能指令觸發,CTU軟件接收到該指令后,對總線芯片RAM區寫入固定標識并回讀比較一致性來定位故障區域。總線芯片RAM區檢測使能指令格式如圖2所示。

圖2 總線芯片RAM區檢測使能指令格式Fig.2 Instruction format of bus chip RAM area detection enable

總線芯片RAM區自檢流程是以總線芯片4個字為一個檢測單元,先將整個RAM區全部寫為特定標識1并讀回檢測是否為特定標識1,再將整個RAM區全部寫為特定標識2并讀回檢測是否為特定標識2,其中特定標識1和特定標識2須保證RAM區每一位都被使用0和1獨立檢測過。如果使用特定標識1檢測時發現某個檢測單元讀寫數據不一致,則不再使用特定標識2檢測,直接將這個檢測單元標記為故障,將所有檢測單元的檢測結果保存。整個總線芯片RAM區自檢完成后,CTU軟件將自檢結果自動封裝在內存讀出遙測源包[9]中,通過測控信道下傳到地面。

上注一次總線芯片RAM區檢測使能指令,RAM區自檢操作執行一次,之后自動關閉。執行RAM區自檢過程中,自動停止所有總線通信,待自檢完成后再開啟。由于自檢過程中總線芯片的RAM區數據被修改,自檢完成后CTU軟件須按照自檢前總線芯片棧區和消息塊區的使用配置,重新初始化總線芯片。

地面分析遙測下傳的總線芯片RAM區故障檢測結果,如果經分析認為總線芯片中尚有足夠的備份資源,則采取相應的芯片故障修復手段。修復手段根據故障的嚴重程度分為兩種,處理方法如

2.1.3 節所述。

2.1.3 BC端RAM故障的處理方法

BC端總線芯片當前模式下使用的棧區(或消息塊區)發生故障,但是另一份棧區(或消息塊區)正常,處理方法是上注總線芯片模式切換指令,使用與當前模式下不同的棧區和消息塊區組合。對于這種非嚴重RAM故障,這一步即可完成處理。總線芯片模式切換指令格式如圖3所示。

圖3 總線芯片模式切換指令格式Fig.3 Instruction format of bus chip mode switching

其中,對于總線芯片模式:

(1)A1H表示使用棧區A(0x0000～0x00FF)和消息塊(0～63);

(2)B1H表示使用棧區B(0x0F00～0x0FFF)和消息塊(93～30);

(3)A2 H表示使用棧區A(0x0000～0x00FF)和消息塊(93～30);

(4)B2H表示使用棧區B(0x0F00～0x0FFF)和消息塊(0～63)。

這里的“總線芯片模式”是指總線芯片中棧區和消息塊區的使用組合方式。總線芯片具有A、B兩個棧區和94個消息塊,其中94個消息塊可以劃分成兩組,分別對應到A棧區和B棧區,每個棧區對應不超過64個消息塊。94個消息塊劃分為兩組的方式是,第一組為消息塊0～63,第二組為消息塊93～64,再加上從第一組中選擇的34個消息塊(塊號63～30,倒序排列),兩組均為64塊。這種消息塊組合策略在一次通信最大消息數小于等于47條時,能夠實現消息塊資源的完全互換,同時也支持了最大通信消息數為64條的情況(最大通信消息數大于47條時,A、B區對應消息塊重疊將不可避免)。

將總線芯片模式劃分為A1、A2、B1、B2四種,A1模式使用A棧區和塊號0～63的消息塊,B1模式使用B棧區和塊號93～30的消息塊,A2模式使用A棧區和塊號93～30的消息塊,B2模式使用B棧區和塊號0～63的消息塊。這樣,在最大總線通信消息數量小于等于47條時,A1與B1模式可實現資源完全互換,A2與B2模式可實現資源完全互換。

總線芯片模式的切換策略是:上電后總線芯片默認工作在A1模式,若總線芯片RAM區在軌發生故障,上注總線芯片RAM區自檢使能指令,判讀總線芯片RAM區自檢結果。如果故障發生在A1模式的棧區但總線芯片其它區域無故障,則可切到B1模式或B2模式;如果故障發生在A1模式的消息塊區但總線芯片其它區域無故障,則可切到A2模式或B1模式;如果A1模式的棧區和消息塊區均發生故障但總線芯片其它區域無故障,則可切換到B1模式。根據該策略,A1、A2、B1、B2四種模式可按需切換,將總線芯片重配置為無故障的棧區和消息塊區組合。四種模式切換指令可事先在地面制作并進行測試驗證,屆時直接上注到星上。

根據自檢結果,如果兩個棧區都發生了故障或者兩個棧區對應的消息塊區都發生了故障,但經分析認為總線芯片中仍然具有足夠的備份資源,可根據實際故障情況制作并上注總線芯片棧區和消息塊區設置指令,利用芯片中尚能使用的資源拼湊出一個新的棧區和消息塊區組合,使總線芯片能夠繼續工作。總線芯片棧區和消息塊區設置指令格式如圖4所示,可對總線芯片的棧區、固定地址區、消息塊區3類資源進行重新配置。

圖4 總線芯片棧區和消息塊區設置指令格式Fig.4 Instruction format of bus chip stack area and message block area setting

由圖4可知,其中:

(1)A、B區使用標志:0x AA——使用A區進行總線通信,0x BB——使用B區進行總線通信。

(2)用于替換棧區的塊號:塊號為0～87時,表示使用從該塊號開始的連續7個消息塊替換棧區,塊號為0x CC時,表示使用棧區0x0000～0x00FF,塊號為0x DD時,表示使用棧區0x0F00～0x0FFF。

(3)塊號01～塊號64:范圍0～93,用于保存總線通信消息,64個塊號不能有重復。

重新配置總線芯片棧區的方法是,如果A、B棧區中只有一個損壞則使用另一個棧區替換,如果A、B棧區均損壞,則使用未損壞的消息塊代替棧區,共需要7個連續的消息塊,同時重新設定新棧區對應的消息塊資源。在指令中可指定使用總線芯片原始A、B棧區或者使用連續消息塊替換原始棧區,當使用消息塊替換原始A、B棧區時,消息塊必須至少7個且地址連續。

總線芯片固定地址區包括堆棧指針和待發消息計數區,A、B區各有一套固定地址資源,可互相備份。因此重新配置固定地址資源的方法是,如果A區的堆棧指針和待發消息計數區故障則使用B區的堆棧指針和待發消息計數區,反之亦然。

重新配置總線芯片消息塊區的方法是,通過指令指定64個消息塊用來保存總線通信數據,塊號取值范圍為0～93,該64個塊號彼此之間不能重復,且不能與用于替換棧區的塊號重復。

上注總線芯片棧區和消息塊區設置指令后,BC端計算機軟件根據指令指定的總線芯片棧區資源、固定地址資源、消息塊區資源的設置方法對總線芯片重新初始化。

如果上注總線芯片模式切換指令或總線芯片棧區和消息塊區設置指令后,故障依然存在,說明總線芯片的寄存器出現故障,該故障不可修復,此時應采取BC端設備切備機的措施。

2.2 對RT端總線芯片RAM故障的容錯設計

由于1553B總線通信由BC端設備發起,RT端軟件寫入總線芯片RAM區的數據會受總線通信的影響,因此自檢無法在完成總線芯片初始化之后進行。通過實驗測試,在RT端總線芯片上電初始化之前,Lookup Table區和DATA BLOCK區寫入數據內容不受總線消息的影響,可以進行寫入讀寫自檢的操作。

HXMT衛星數管分系統RTU軟件設計時,將1553B總線RAM區的Lookup Table和DATA BLOCK劃分為主備兩個區。主區包括Lookup Table A和部分DATA BLOCK(0400 H～07FFH),備區包括Lookup Table B和部分DATA BLOCK(0800 H～0BFFH)。當RTU在軌發生總線芯片RAM區故障時,地面先發送RTU斷電指令,之后發送RTU加電指令,由RTU軟件在進行總線初始化之前自動完成RAM故障區域檢測和處理。處理流程如圖5所示。由圖5可知,在RTU軟件進行總線芯片初始化之前,首先對Lookup Table區和DATA BLOCK區進行自檢測,根據檢測的結果選用主區或者備區。如果主區檢測錯誤,則使用備區。使用主區或使用備區標志放在外部RAM中,若RT端軟件運行過程中,需要對總線重新初始化操作時,首先判斷主區備區標志,再進行總線重新初始化。

圖5 RT端總線芯片RAM故障處理流程圖Fig.5 Flow chat of RT terminal bus chip fault handling

3 測試驗證與在軌實施

測試環境如圖6所示,在圖6所示測試環境[10]中,CTU為航天器BC端設備,通過總線仿真卡模擬RT設備并監視總線通信狀態,總線芯片故障檢測和修復指令通過測試客戶機上注到CTU軟件,指令執行結果通過內存讀出總線芯片RAM數據進行判讀。測試內容如下:

(1)測試上注總線芯片RAM區檢測使能指令后,檢測結果正確下傳。

(2)測試上注總線芯片模式切換指令后,總線芯片模式切換,總線通信正常。

(3)測試上注總線芯片棧區和消息塊區設置指令后,棧區和消息塊區重配置,總線通信正常。

RTU為航天器RT端設備,對其總線芯片RAM故障容錯設計的測試內容包括:

(1)用RTU軟件仿真器加載RTU軟件,默認使用總線芯片RAM主區,總線通信正常。

(2)用RTU軟件仿真器制造總線芯片RAM讀寫錯誤,測試使用總線芯片RAM備區,總線通信正常。

上述測試驗證了本文所述方法的正確性和有效性,在軌實施時,通過兩條遙控指令即可完成總線芯片RAM區的故障檢測和修復,與傳統的在軌維護方法對比見表3。

圖6 測試環境Fig.6 Environment of testing

表3 兩種方法對比Table 3 Comparison of two methods

4 結束語

通過分析HXMT衛星BC端和RT端設備使用1533B總線芯片的特點,本文提出一種對總線芯片RAM故障的容錯設計,通過便捷的遙控指令即可實現對總線芯片資源的重配置,避免了采用傳統在軌維護手段給整星安全帶來的風險。對于BC端,該方法適用于總線芯片僅使用單區RAM資源的使用方式,并不適用于雙區均被占用的使用方式。對于RT端,該方法適用于總線RAM區空間足夠備份的情況。另外,若總線芯片的寄存器故障,或者RAM故障區域過大導致不能拼湊出最小可用資源集合時,則只能放棄修復或者功能降級修復。該方法在多個型號中進行了應用,對提高設備的可靠性和安全性起到了一定作用。

參考文獻(References)

[1]王良江,韓留軍．1553B總線器件單粒子效應實驗系統設計[J]．計算機測量與控制,2013,21(3):753-755 Wang Liangjiang,Han Liujun．Design of 1553B bus components single event effect testing system[J]．Computer Measurement&Control,2013,21(3):753-755(in Chinese)

[2]安軍社,劉艷秋,孫輝先．軟件的動態維護與實現[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)

[3]郭堅,張紅軍,付連芳．面向星載應用的1553B總線仿真卡二次開發軟件[J]．航天器工程,2012,21(4):78-82 Guo Jian,Zhang Hongjun,Fu Lianfang．Software design of 1553B bus emulator card secondary development for onboard application[J]．Spacecraft Engineering,2012,21(4):78-82(in Chinese)

[4]趙昶宇,顏昌翔,于平．1553B總線上消息的實時調度[J]．光學精密工程,2010,18(3):732-740 Zhao Changyu,Yan Changxiang,Yu Ping．Real time scheduling of messages on 1553B bus[J]．Optics and Precision Engineering[J]．2010,18(3):732-740(in Chinese)

[5]國防科學技術工業委員會．GJB 289A-97數字式時分制指令/響應型多路傳輸數據總線[S]．北京:國防科學技術工業委員會,1997 Commission of Science,Technology and Industry for National Defence．GJB 289A-97 Digital time division command/response multiplex data bus[S]．Beijing:Commission of Science,Technology and Industry for National Defence,1997(in Chinese)

[6]國防科學技術工業委員會．GJB/Z 209-2002數字式時分制指令/響應型多路傳輸數據總線應用手冊[S]．北京:國防科學技術工業委員會,2002 Commission of Science,Technology and Industry for National Defence．GJB/Z 209-2002 The handbook of digital time division command/response multiplex data bus[S]．Beijing:Commission of Science,Technology and Industry for National Defence,2002(in Chinese)

[7]江建慧,朱為國．嵌入式存儲器的內建自測試和內建自修復[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)

[8]郭堅,劉欣,毛亮．1553B總線終端消息覆蓋的原因及解決方案[J]．航天器工程,2011,20(5):88-92 Guo Jian,Liu Xin,Mao Liang．Cause and resolution for 1553b bus message overcast problem[J]．Spacecraft Engineering,2011,20(5):88-92(in Chinese)

[9]何熊文,張猛．遙控和遙測包應用標準在航天器中的使用方法[J]．航天器工程,2012,21(3):54-60 He Xiongwen,Zhang Meng．Application method of telecommand and telemetry packet utilization standard in spacecraft[J]．Spacecraft Engineering,2012,21(3):54-60(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)