載人火箭故障檢測與逃逸控制軟件可靠性設計

2022-03-10 06:21:42路長剛王曉鵬亓俊卿

導彈與航天運載技術 2022年1期

錢航，黃晨，路長剛，王曉鵬，亓俊卿

（北京宇航系統工程研究所，北京，100076）

0 引言

載人火箭具有故障檢測能力，并在重大故障時可實施逃逸。故障檢測處理系統（以下簡稱為“故檢系統”）是承擔載人火箭故障檢測和逃逸控制的關鍵系統，通過檢測火箭的重要飛行參數，按事先確定的判據自動進行火箭故障判別，當發現故障時向有關系統發出逃逸指令和中止飛行指令，迅速將載人飛船的返回艙和軌道艙帶離危險區，利用飛船的返回著陸系統完成逃逸救生任務。正常飛行至120.4 s時完成備保拋逃逸塔動作，即若逃逸塔已分離則不動作，若未分離則發出逃逸塔分離指令。完成系統核心功能的是兩項關鍵等級為A級的箭上軟件：故障檢測處理飛行軟件和逃逸程序控制軟件。

故障檢測處理飛行軟件（以下簡稱為“故檢軟件”）是一個嵌入式的實時測控軟件，運行于火箭儀器艙中（如圖1所示）的故障檢測處理器上。

圖1 載人火箭結構Fig.1 Basic Components of Manned Launch Vehicle

其工作時間為：從火箭起飛前30 min開始運行到船箭分離為止，大約40 min。正常時，從外部獲取火箭狀態信息（如：過載、姿態角、分離信號、關機信號、程序角等），按照火箭故障模式判別準則進行狀態判斷，按飛行時序發出相應的指令信號；若火箭出現異常，則按判據要求發出“逃逸”等控制指令。

逃逸程序控制軟件（以下簡稱為“逃逸軟件”）是一個嵌入式的實時測控軟件，運行于火箭整流罩內（如圖1所示）的逃逸程序控制器上，其工作時間為：從火箭起飛前30 min開始運行到整流罩分離為止，大約運行33 min。正常時，完成120.4 s備保拋逃逸塔的功能，即在120.4 s檢測逃逸塔是否分離，若分離則不動作，若未分離則執行拋逃逸塔功能。在故障時，逃逸程序控制軟件接到逃逸信號后，根據運載火箭當時的飛行狀態輸出相應的逃逸時序信號給火工品裝置，實現逃逸功能。

為保證載人運載火箭的可靠性和安全性，確保航天員的生命安全和順利執行飛行任務，故障檢測和逃逸控制軟件可靠性設計是全箭工作的重點之一。該兩項軟件作為故檢系統的核心箭上軟件，在滿足功能性能要求外，也需要在硬件正常情況下，軟件不會誤報也不會漏報，這要求軟件具有良好的可靠性。故檢逃逸軟件開發周期較長，需要經過需求分析、概要設計、詳細設計、程序編碼，編碼完成后需要進行代碼規則檢查、靜態分析、代碼審查、單元測試、配置項測試、第三方測試、系統聯試等測試驗證項目，錯誤和缺陷會滲透到每一個環節。另一方面，該箭上軟件隨型號使用周期較長，跨度達到十多年甚至更久，中間進行若干次重要更改，型號軟件人員也不斷更迭，需要對軟件可靠性及軟件質量進行提高和監管。因此，該箭上軟件可靠性設計就顯得尤為重要。

1 功能與可靠性邏輯

故障檢測處理飛行軟件是一個嵌入式的實時測控軟件，程序結構設計采用樹狀結構圖，包括主處理模塊、手動逃逸中斷、起飛中斷、遙測中斷、控制系統中斷、同步中斷等模塊，其中主處理模塊循環執行，周期為20 ms，在軟件啟動時執行；5個中斷為外部中斷，中斷產生時執行。另外，為防止誤中斷影響軟件的運行，設計時鐘中斷、箭地中斷和錯誤中斷占用剩余3個中斷，這些中斷進入后即退出，不做實際處理。故障檢測處理飛行軟件功能框圖給出了整個軟件的調用關系，如圖2所示。

圖2 故障檢測處理飛行軟件功能框圖Fig.2 Functional Block Diagram of Flight Software for Fault Detection and Processing

故障檢測處理飛行軟件可靠性框圖描述功能模塊的處理邏輯關系，如圖3所示。

圖3 故障檢測處理飛行軟件可靠性框圖Fig.3 Reliability Block Diagram of Flight Software for Fault Detection and Processing

逃逸程序控制軟件是一個嵌入式的實時測控軟件，程序結構設計采用樹狀結構圖，包括主程序模塊、緊急關機處理模塊、拋逃逸塔處理模塊、三取二判定處理模塊、逃逸處理模塊、起飛中斷模塊、逃逸中斷模塊，其中主程序模塊循環執行，無周期，在軟件啟動時執行；4個中斷為1個內部中斷，為高優先級（時鐘中斷），其他為外部中斷，為低優先級（中斷的查詢順序：起飛中斷、逃逸中斷、接收逃逸參數中斷），中斷產生時執行。逃逸程序控制軟件功能框圖給出了整個軟件的調用關系，如圖4所示。

圖4 逃逸程序控制軟件功能框圖Fig.4 Functional Block Diagram of Escape Program Control Software

逃逸程序控制軟件可靠性框圖描述功能模塊的處理邏輯關系，如圖5所示。

圖5 逃逸程序控制軟件可靠性框圖Fig.5 Reliability Block Diagram of Escape Program Control Software

2 可靠性關鍵項目

FMEA是型號產品研制基礎，是做好單點故障、特性分類、3類關鍵特性等工作的前提。對故檢逃逸軟件進行全面識別3類關鍵特性并采取有效控制措施。

嚴酷度是指故障模式所產生后果的嚴重程度，為軟件FMEA分析的重要成果，一般分為4類，即Ⅰ類（災難的）、Ⅱ類（嚴重的）、Ⅲ類（一般的）、Ⅳ類（輕微的）。嚴酷度等級引用于中國航天行業標準QJ3050A-2011《航天產品故障模式、影響及危害性分析指南》，軟件故障模式影響的嚴酷度等級，見表1。

表1 軟件故障模式影響的嚴酷度等級Tab.1 Severity Level of Software Failure Mode Effects

故檢軟件根據嚴酷度等級為Ⅰ類和Ⅱ類，得出關鍵項目清單見表2。

表2 故檢軟件關鍵項目清單Tab.2 Key Projects List of Flight Software for Fault Detection and Processing

逃逸軟件根據嚴酷度等級為Ⅰ類和Ⅱ類，得出關鍵項目清單見表3。

表3 逃逸軟件關鍵項目清單Tab.3 Key Projects List of Escape Program Control Software

3 可靠性設計準則

根據型號可靠性設計規定，以及故檢系統“不漏逃、不誤逃”的要求，明確了作為箭上A級軟件的故檢逃逸軟件適用范圍，主要準則要求包括：

a）系統應進行初步危險分析，明確系統級的危險事件，軟件研制人員應參與系統的初步危險分析工作，可靠性與安全性要求應在軟件研制任務書中明確提出；

b）軟件研制各階段均應開展可靠性與安全性工作，將結果文檔化并保持一致性和可追溯性；應在需求分析階段開展軟件需求的安全性分析和驗證工作；應在設計階段開展軟件設計的安全性分析和驗證工作；應在測試、系統聯試階段，針對需求分析、設計、實現階段及其它階段未分析或驗證的安全性內容開展軟件安全性測試；

c）對于A級軟件，必須明確其冗余和容錯要求，并進行多版本程序設計，限于條件不能進行多版本程序設計時，應采取其他技術措施以確保安全性及可靠性；

d）對于A級軟件，失效容限為2?？筛鶕嶋H情況，采用軟硬件結合的方法達到容限目的；

e）軟件可靠性、安全性需求中必須包括對各種不期望事件加以適當響應的要求；

f）對于實時嵌入性關鍵軟件成份，應通過采用適當的采樣周期和適當的軟件工作時序來保證其可靠性和安全性；

g）應根據型號可靠性大綱和安全性大綱的要求，進行軟件FMEA和軟件安全性分析。

4 可靠性設計方法

故檢逃逸軟件可靠性設計的本質是在滿足總體任務書功能性能和遵循可靠性設計準則要求的前提下，在軟件研制周期內使用各種方法來滿足軟件的可靠性要求。這些方法分為避錯設計、查錯設計、糾錯設計、容錯設計和余量設計。這5種設計方法貫穿在整個軟件研制周期。

4.1 避錯設計

故檢逃逸軟件采取了以下避錯設計實施方法：

a）嚴格按照軟件工程化的方法進行設計工作。在設計階段精心完成《需求規格說明》，并同具有豐富經驗的需求專家和軟件可靠性專家一起分析、討論，細心劃分每一項功能；在編碼階段遵循《921工程軟件工程化技術標準》中C語言安全子集以及相關編程規范，嚴格依據《概要設計》和《詳細設計》完成軟件編碼。

b）加強軟件頂層設計。軟件設計充分估計接口間的各種故障，并采取相應措施；軟件設計采用結構化或面向對象的設計方法，盡量采用重用模塊，提高軟件的模塊化水平，模塊要高內聚、低耦合，注意模塊的扇入扇出數。

c）加強軟件編碼變量與邏輯避錯能力。

1）避免使用位判斷，而是將位信息轉化為字節信息，避免了因某一位跳變而引起誤判，比如，故檢軟件發送給逃逸軟件的逃逸參數中推力擋板是否打開只有兩個狀態：打開與不打開，為避免位信息出錯，將該狀態位轉化為字節信息，僅該字節前4位或后4位推力擋板對應數據位為“1010”時，表示Ⅲ象限或 Ⅳ象限控制發動機推力擋板打開；

2）不用全0或全1表示邏輯零或邏輯一，而是用有意義的46H和31H（數字之后加H或之前加0x為十六進制）來表示，比如，逃逸軟件中起飛標志、緊急關機標志、拋塔標志、逃逸標志、檢測密封板解鎖信號、檢測返回艙分離信號等所有箭上使用的標志和信號均采用46H/31H表示動作無效/有效；

3）不用0或1表示邏輯假或邏輯真，而是用有意義的0xAA和0x55來表示，比如，故檢軟件在代碼最開始就進行宏定義#define false 0xAA及#define true 0x55，相關函數中含有大量關鍵狀態邏輯判斷，通過用有意義的0xAA和0x55替換后，避免了0/1意外跳變后重大狀態誤判；

4）常數和變量的標識分開，代碼中的數字量用常量取代，比如，故檢軟件在代碼最開始采用將常量進行集中宏定義，再對全局變量進行集中定義及初始化，代碼中的數字量諸如時序T1-、T1+、T2-、T2+等用常量代替；

5）軟件低空逃逸處理邏輯采用通用化代碼，故檢逃逸軟件原固定III象限控制發動機點火變更為II象限或III象限控制發動機點火，為避免采用兩套代碼實現該邏輯，也為避免后續增加象限的更改需求，故檢逃逸軟件均采用通用化代碼設計，一套代碼能夠適應4個象限，該項更改在CZ-2F Y12載人飛行任務中得到驗證；

6）故檢軟件要求實時檢測故障，避免漏檢，采用周期循環工作制，每個周期設置為20 ms；

7）為防止故檢軟件飛行時間超過船箭分離一定時間后時鐘計數器溢出，在時鐘計數器到達該時間后將其清零。

d）加強軟件測試。對程序進行了多次代碼走查，并進行了靜態測試、單元測試和確認測試，盡可能提高語句和分支覆蓋率，對某些確實難以測到的語句和分支均做了詳細的說明；完成編碼和開發方測試后提交具備資質的第三方進行測試。

e）制定了軟件問題報告單、修改記錄單和試驗記錄，控制住軟件的修改過程。

f）編制了模塊關系樹形圖，對程序結構一目了然。

4.2 查錯設計

軟件設計注意數據有效范圍，進行數值運算時對關鍵數據應進行合理性判斷，記錄故障并采取故障隔離的處理措施。比如，故檢軟件對于故障判據信號超值域、控制通信故障和遙測故障這3種異常，會通過對相關信號多次檢測判出，記錄該故障后切換判據。

在設計接口時，對數據通訊首先確定數據傳輸協議，然后根據確定的數據傳輸協議，在數據傳輸之前對數據傳輸通道進行正確性檢測，以確保數據傳輸的正確性；數據傳輸開始后，通過奇偶校驗方法來驗證數據傳輸的正確性。

逃逸參數是故檢軟件發給逃逸軟件的數據，關系到發射臺及低空逃逸的安全性。因此，逃逸參數中控制發動機點火時間、控制發動機點火方向、推力擋板是否打開這3項數據均是3遍重傳，并增加了2個字節作為校驗和。逃逸軟件接收該數據后會依次進行以下多重查錯方法：是否是完整1幀數據、校驗和是否相等、數據三取二、逃逸時間合理性判斷、擋板方向的合理性判斷，確保接收到正確的逃逸參數。該項更改在CZ-2F Y12載人飛行任務中得到驗證。

4.3 糾錯設計

為避免干擾信號影響故障判斷的準確性，開關量信號和模擬量信號都采用了以一定時間為間隔多次采集，采集到數據后再進行可靠性判斷的方法。比如，故檢軟件中對A/D信號和開關量信號的讀入處理，為防止數據有誤，各個參數均采集3遍。

所有中斷觸發的功能在響應中斷后還要對觸發信號進行確認，以免誤動作。比如，故檢軟件中所有中斷處理函數中還要對觸發標志或指令連續讀入3遍確認后再執行。

為防止誤逃或漏逃，故障檢測是在連續檢測到3次同樣的故障時才發出報警或故障。

4.4 容錯設計

軟件中做了相關的容錯設計。如：

a）所有的故障、報警門限值采用三冗余的方法，確保查到數據的準確性；

b）由于故檢軟件一定時間之前的程序角為預置，采用3套相同數據冗余，確保正確；

c）某些重要的變量有兩個備份，做三取二判定后才使用；

d）對串口狀態進行限時判定，若硬件出問題，軟件能夠跳出該功能，避免停滯；

e）所有中斷必須進行誤中斷處理，即進入中斷后立即返回。

4.5 余量設計

在遵從可靠性準則過程中，軟硬件結合共同形成整體可靠性提升。故檢逃逸軟件都使用軟件級三冗余設計，假設在飛行中1個單機（含軟件）發生故障，系統能夠通過比較、判斷、篩選掉異?；蝈e誤的輸出，仍滿足系統功能要求；故障檢測和逃逸控制軟件的各重要變量、標志、故障限、報警限均使用3冗余、3中取2判定等方法確保軟件可靠性。同時，對軟硬件性能也做了余量設計。

a）故檢軟件三冗余設計。

逃逸軟件在確定方案時，既要保證軟件可靠性指標的要求，又不要使系統過于復雜，采用了軟件三冗余和接口冗余的設計方案。確定設計方案為故檢軟件相互獨立冗余工作在3套CPU主機板，CPU使用了經多次飛行考核的成熟技術，而重要接口，例如對姿態角、過載信號、加速度信號、捷聯信號等模擬量的采集采用三冗余，對分離信號、指令輸入信號及切換信號的錄取也采用了三冗余的技術，對指令輸出采用四重邏輯設計，輸出級采用串并結構，控制級與輸出級隔離，采用錯位控制等方法，確保防誤報以保證火箭正常時的安全飛行，不致造成由于故檢軟件誤報而造成飛行失敗。對于起飛、緊急關機、手動逃逸3個非常重要的中斷源采用三套接收，三取二判別等措施以保證中斷的可靠性。

b）逃逸軟件三冗余設計。

逃逸軟件是為了在火箭故障時，根據逃逸指令發出火工品指令，與飛船系統協調完成逃逸時序控制的關鍵軟件。由于其使用上的特點，系統要求正常動作可靠性為0.999，不誤動作的可靠性為0.9999。為此，根據可靠性指標及功能要求，在設計上，首先考慮到高可靠性要求，確定設計方案為逃逸軟件相互獨立冗余工作在3套CPU主機板，火工品時序輸出電路采取三中取二冗余表決輸出形式；同時為了滿足上述的設計思想，在電源設計上使3塊逃逸軟件CPU板相互獨立供電，火工品輸出表決電路采用并聯冗余供電模式，從而構成一個系統級冗余。

c）性能余量設計。

軟件設計考慮了空間余量（軟件的內存余量不小于20%）和時間余量（軟件運行周期的時間余量不小于20%），合理安排各功能的處理順序。