束韶光,崔 宇,劉俊陽
(北京航天自動控制研究所,北京,100854)
隨著計算機技術和設備數字化的飛速發展,航天系統從早期以硬件設備為主導、軟件實現硬件系統特定功能的年代,逐漸邁入以軟件為神經中樞,貫穿于航天系統的各條脈絡的年代。如今的航天軟件,既可在天上實現飛行控制,又可在地面完成各項檢測任務,其可靠性已成為影響航天系統質量的關鍵因素。
近年來,中國運載火箭型號進入了跨越式發展的關鍵時期,大量軟件和硬件的新技術在載人運載型號中得到了應用與推廣。這些新技術的應用,造成軟件功能和復雜度的不斷增加。當前的軟件已不再是簡單堆疊起來的獨立配置項,而是有機結合的復雜分布式軟件系統。軟件產品作為中國運載型號的重要組成部分,直接影響航天任務的成敗,可能造成人員傷亡、設備損壞和環境破壞等事故,在這種背景下,載人航天任務對軟件可靠性提出了更高要求,而運載火箭承擔著空間站工程的發射和運載的重要任務,軟件可靠性更是倍受關注,其中承擔關鍵重要功能的嵌入式軟件的可靠性設計又是一個重要環節。
航天型號關鍵軟件大多是飛行中使用的嵌入式軟件,固化在航天箭載計算機中,與硬件關系密切,協同完成特定功能;航天型號大部分為強實時系統,具有嚴格的時限要求,要求軟件在一定時間完成相應的處理,系統處理結果不僅要求邏輯正確,而且要求時間時序正確可靠。
軟件的錯誤或缺陷(不可靠)會導致任務的失敗,甚至導致災難性的后果。1996年6月4日,阿里安5運載火箭因64位浮點向16位帶符號整數值的數據轉換問題導致首飛失敗。1998年12月,美國火星軌道器數據數制轉換問題,導致毀壞。1999年4月,美國某軍事衛星發射任務中,由于運載器某個常量輸入錯誤,并且地面試驗未檢查出,導致系統工作異常。2009年8月19日,韓國首枚運載火箭羅老號,由于測量高壓罐壓力的軟件出現了問題取消發射。大量的事故案例表明,軟件設計和數據設計過程中,都需要對可能發生的故障進行分析,采取充分的可靠性措施,避免出現缺陷或消除故障,來確保系統不發生失效。
軟件可靠性一般是指在規定的條件下和規定的時間內,軟件無失效運行的概率,軟件可靠性設計是軟件可靠性工程的重要內容,實質是在常規的軟件設計中,應用各種必須的方法和技術,使程序設計在兼顧用戶的各種需求時,全面滿足軟件的可靠性要求。軟件的可靠性設計貫穿于研制過程始終。本文主要從載人航天嵌入式軟件的程序設計和數據設計兩個方面來具體描述高可靠嵌入式軟件的一些設計方法。
運載型號的嵌入式軟件的代表產品是控制系統飛行軟件,由它自主、實時完成對火箭的飛行控制,保障載荷精確入軌。同樣在火箭發射流程中,也有些嵌入式軟件與發射點火這類安全關鍵的功能相關。針對具有這些安全關鍵功能的程序,都需要采取充分的可靠性設計措施,來確保軟件安全可靠運行,避免發生危險事件,導致任務失敗。而程序的查錯容錯設計、多版本容錯設計、同步輸出設計是保障嵌入式軟件可靠性的重要方法。
軟件查錯容錯設計是指在業務邏輯功能設計基礎上,增加某些特定可靠性措施,使程序在運行過程中自動查找存在的錯誤并控制錯誤影響的一種設計方法。它主要包括檢查點設計和巡回檢測設計兩個方面。
1.1.1 檢查點設計
檢查點設計是在程序的相關部位設置檢查點,檢查是否發生了故障。檢查點設置和執行的原則有以下兩點:
a)接口原則:在設計時考慮其它硬件或軟件單元存在著錯誤;
b)實時原則:當錯誤征兆被偵測到后,應盡快處理,限制錯誤的損害程度。
嵌入式軟件的檢查點的選取是為了有效和及時地識別故障,從而讓軟件的業務邏輯不應該因為故障特別是瞬發故障而不能繼續執行任務。
原則上講,嵌入式軟件在與其他硬件交互時,往往需要進行檢查點設計來完善可靠性措施。對于有時間應答要求的操作,可以設置一個計時器,當在預定的時間內未獲得應答要求時,則可推斷必定出現了故障。如軟件通過硬件進行信號采集,對等待外部信號的程序可進行超時處理,在采集過程中插入檢查點程序,實現使用定時器來控制循環動作的上限,使得程序能在規定時間內(無論采集成功或失敗)退出等待外部信號的狀態,避免程序陷入死循環,從而避免出現程序“假死”現象。飛行控制軟件中AD采樣單元在采樣速率陀螺模擬量數值時采取了該方法。AD采樣單元中對某一路AD通道的采樣流程見圖1。

圖1 速率陀螺信號單個通道采集設計流程Fig.1 Rate Gyro Signal Acquisition Design Diagram
圖1中加粗線的程序段就是一個簡單的檢查點設計。程序在未判斷出AD轉換結果寄存器有效前,會循環讀取該寄存器的值,為了避免AD轉換結果寄存器出現異常而無法退出循環的故障情況發生,在此處設置檢查點,通過對AD讀取次數進行控制來完成AD采樣的可靠性退出機制,能有效避免硬件錯誤的影響范圍和程度。
另外軟件與軟件之間的交互過程中也往往需要設計檢查點。以三冗余的飛行控制軟件與組合導航軟件通過雙口RAM交換信息的設計方法為例。單模的組合導航軟件在讀取三冗余的飛行控制軟件前,需要通過讀取三CPU雙口RAM硬件同步信號判斷三CPU數據是否準備好,當組合導航軟件判斷存在未準備好數據的CPU時,會進入判斷硬件同步信號的循環中。為了避免硬件同步信號出現異常無法退出循環的故障情況發生,組合導航軟件在查詢同步信號狀態處設置了檢查點,通過設置超時時間完成可靠性退出機制。組合導航軟件讀取雙口RAM檢查點設計見圖2。

圖2 組合導航飛控導航數據的錄取設計流程Fig.2 Navigation Data Admission Design Diagram
圖2中加粗線的的程序段是組合導航軟件的2個檢查點。根據圖2中流程可知,無論數據準備好的飛行控制軟件是2個還是小于2個,均會進入循環查詢的檢查點,區別僅是所設置的超時時間不同,此項可靠性設計使得組合導航軟件能在飛行控制軟件各種異常狀態下均能繼續正常運行。
1.1.2 巡回檢測設計
巡回檢測設計,即軟件主動對硬件及程序或數據進行循環檢查的設計,其中包括定時或低優先級的巡檢等。嵌入式軟件中主要檢測以下幾個方面:
a)對RAM中代碼區進行CRC校驗,以保證正確的操作;
b)對RAM中諸元區進行CRC校驗,以保證正確的操作;
c)對關鍵及重要的標志字及邏輯功能進行校核。
嵌入式軟件啟動后,會完成各關鍵數據及關鍵硬件寄存器的初始化工作,同時在后臺對存放在RAM區的代碼段和諸元數據段進行了循環CRC校核,確保程序與數據上傳及搬移的正確性,循環校核任務工作在火箭點火前。圖3給出了飛行控制軟件的自檢流程,它是巡回檢測的典型應用。

圖3 飛行控制軟件巡回自檢流程Fig.3 Flight Control Software Tour Self-check Flow Chart
版本程序設計由個開發小組各自獨立實現相同功能的相異程序和表決器組成,各相異程序的運算結果經過比較(表決)以確定輸出。在表決器不能分辨出對錯的情況下,采取少數服從多數的表決方式確定輸出。
火箭的點火時序程序采用了3版本程序設計。點火時序程序是控制系統能順利完成火箭點火控制工作的重要組成部分,它由3個功能相同、版本不同、相互獨立的程序組成。3個程序由3個開發人員獨立完成,點火1時序程序的輸出經過硬件控制與點火2時序程序、點火3時序程序的輸出三取二后完成火箭的點火和緊急關機時序的控制。3個軟件在實現相同時序控制功能的前提下,采用了不同的設計方法:
a)點火1時序程序的計時零點為點火,后續時序的輸出采用相對于點火零點的絕對時間;
b)點火2時序程序的計時零點為點火,時序的輸出采用相對于前一時序的相對時間;
c)點火3時序程序使用了跑表型延時接通定時器和延時斷開定時器,時序的接通以點火計時到為條件;本路斷開以本路接通作為起始,延時斷開。
3種不同的設計方法避免了共因失效,即避免了軟件同因一種邏輯故障機理失效的可能性,從而提高了軟件系統的可靠性。
載人航天中使用到的三冗余軟件在完成相同的功能時,由于輸入的隨機性以及軟件運行方式的差異性 ,存在三冗余軟件在相鄰的不同周期收到同一輸入信號的情形,三冗余軟件信號響應時刻的不同,會導致輸出結果會有所差別。為避免上述情況的發生,嵌入式軟件采用了交互表決策略進行同步處理。
以三冗余驅動信號輸出嵌入式軟件為例,在三CPU輸出前需要軟件進行三CPU同步判別:運行在單個CPU上的每個軟件通過查詢三CPU同步狀態,以及表決功能完成三CPU同步輸出。三CPU同步輸出判別流程見圖4。

圖4 三CPU同步輸出流程Fig.4 Three CPU Synchronous Output Flow Chart
圖4描述的同步輸出基本邏輯如下:
a)本機在決定是否要輸出前,需確定本機及另外兩機是否準備好輸出;
b)如果本機和另外兩機均準備好,則本機立即輸出,此時另外兩機也會立即輸出,可以確保此情況三機同步輸出;
c)如果本機未準備好,而另外兩機準備好,則進入超時等待機制;如果超時時間Timerout 1過了本機仍未準備好輸出,則本機不輸出,另外兩機輸出;
d)如果本機準備好,而另外只有1機準備好,則進入超時等待機制,如果超時時間Timerout 2過了三機仍未全部準備好,則本機和另外一機輸出。
這種同步策略從邏輯上保障了只要有兩機準備好時就能實現輸出的脈沖嚴格同步,確保脈沖驅動功能的可靠性。
火箭使用的數據主要包括計算常量、內部變量、諸元數據以及實時采集的數據。計算常量固化在軟件代碼中。諸元數據與當次飛行任務密切相關,它隨著飛行任務不同而變化,需要在臨發射前生成并裝訂到箭載計算機內存中,供飛行軟件使用。實時采集的數據主要包括電壓、壓力、液位等。本章以諸元數據為例闡述嵌入式軟件中數據的可靠性設計方法。
諸元數據設計過程中,考慮到在人工輸入、計算、生成、使用等環節可能引入錯誤,因此采取了相應的可靠性設計方法進行避錯、查錯,同時從流程上規范諸元數據生成及驗證的過程,具體流程如圖5所示。圖5中闡述了諸元數據設計含諸元輸入數據確認、諸元數據自動生成、諸元數據完整性確認、諸元數據驗證等工作,本節分別從諸元產生的全生命周期中各個階段闡述可靠性設計和驗證的技術方法。

圖5 諸元數據設計及驗證流程Fig.5 Data Design and Verification Process
為避免人工生成諸元數據過程中引入操作錯誤,通過諸元生成系統讀取諸元原始數據以及配置文件,自動生成箭上飛行控制軟件能夠識別的二進制格式的諸元文件。諸元原始數據由多組文件組成,如制導諸元、姿控諸元、時序諸元等數據輸入文件。配置文件也由多組文件組成,與諸元數據輸入文件相對應,它規定了相應諸元的數據類型、數目、計算約束條件等信息。諸元數據自動生成軟件依次讀取諸元原始數據輸入文件中的數據,轉換成為目標處理器識別的二進制數據,根據配置文件排列順序。圖6為諸元自動生成系統的示意圖。

圖6 飛行諸元數據設計和生成系統Fig.6 Flight Metadata Design and Generation System
a)諸元輸入數據合理性檢測。
根據查錯設計原則,對讀到的數據進行合理性檢測,當檢測到輸入數據不合理時立即中止諸元生成工作,并向用戶反饋該錯誤。合理性檢測主要包括:
1)變量范圍合理性檢測。如助推段俯仰、偏航切換網絡時間的非負性判斷。
2)數組變量非負性和單調性檢測。如為對飛行時和各段飛行時t的非負性和單調性檢查,以及每行數據時間間隔合理性檢查。
b)數組型諸元數據外推設計。
為保證飛行控制軟件使用諸元數據時工作于內插狀態,將數據進行外推,最終裝訂量滿足裝訂時間范圍后如果仍未填滿數據空間,則將數據進行外推擴展,直至填滿整個裝訂數據空間,對飛行控制軟件起到內插保護的效果。
為確保諸元數據的完整性,對諸元數據進行完整性檢驗設計。在二進制諸元文件開頭增加諸元數據開始標志,尾部增加諸元數據結束標志以及校驗信息,使飛行控制軟件能在啟動運行后,根據文件中諸元數據開始標志和結束標志計算出諸元文件長度,根據諸元文件的長度以及文件中的CRC值循環進行諸元段CRC校驗,如果計算的CRC校驗碼與文件中自帶的CRC校驗碼相等,則諸元數據沒有損壞,否則說明諸元數據在傳輸或存儲過程中發生損壞。二進制格式的諸元數據空間分配示意見圖7。

圖7 二進制諸元文件結構Fig.7 Binary Metafile Structure Diagram
為驗證編譯器在諸元數據源碼向目標碼轉換過程的正確性。對諸元數據目標碼進行快速逆向解析、比對和翻譯,并在源碼中定位,生成比對報告,驗證諸元目標碼和源碼的一致性。設計上是先以內存map文件和諸元模板文件為基礎,把諸元目標碼逆向生成源碼,其中要解決目標碼中諸元變量的源碼定位、分析和格式翻譯等諸多問題。再利用諸元模板、誤差容限配置進行諸元比對。它能確保生成諸元數據目標碼產品同源碼完全一致,避免由于生成過程缺陷影響最終諸元數據產品的正確性。計算溢出錯誤便可通過諸元數據的反向比對進行檢驗。計算溢出錯誤,就是在計算過程中,變量的值超過了該變量類型的有效范圍。通過反向生成得到的源文件同初始源文件進行比對,即可檢驗出計算溢出錯誤。圖8為諸元源文件和逆向生成源文件比對設計示意。

圖8 諸元源文件和逆向生成源文件比對設計示意Fig.8 Schematic Diagram of Comparison Design between Data Source Files and Reverse Generated Source Files
本文重點從程序可靠性設計與數據可靠性設計兩方面入手,介紹高可靠嵌入式軟件中與可靠性相關的重要而具體設計的方法,也正是這些方法的實踐和應用,使火箭系統冗余方案能有效發揮作用,從而圓滿完成載人航天工程發射任務。