某伺服實時控制軟件SFMEA/SFTA*

黃梅紅，黃志華，宋 冰，王 玥，薛 靚

( 1. 上海航天控制技術研究所·上海·201109；2.上海伺服系統工程技術研究中心·上海·201109)

0 引 言

提高軟件的安全性、可靠性，是當前宇航型號軟件研發與驗證工作的迫切需求，是各研制型號的重點和難點，也是國家推進GJB5000A《軍用軟件研制能力成熟度模型》的重要目的。法國阿里安5運載火箭的首飛失敗、日本X射線太空望遠鏡“瞳”升空后失效等案例，都可歸因于由軟件引發的系統故障。

軟件的安全性和可靠性實現均采用了需求分析驅動、設計編碼實現、測試運行驗證的技術途徑，以實現指標要求。在軟件需求分析階段，需提出安全性和可靠性需求。所采用的方法中的第一類是以故障樹FTA為代表的“演繹法”技術，“自上而下”地進行分析，多用于從系統故障角度追溯軟件的原因分析，進行系統需求的安全性、可靠性分配；第二類是以FMEA(失效模式分析)為代表的“歸納法”技術，“自下而上”地進行分析，從軟件需求自身的角度出發，識別和獲取軟件失效可能導致的系統故障。一旦該故障會導致危險事故發生，則這個軟件導致的故障就是一個安全性問題；如果故障未導致危險事故發生，則是一個可靠性問題。上述故障的源和因——軟件失效的控制措施，就成為了軟件的安全性和可靠性需求，這也是提出軟件安全性、可靠性需求的最重要的階段[1-2]。

本文以助推伺服控制軟件為例進行了SFMEA和SFTA分析，該軟件安裝于三通道冗余伺服控制器中。三通道采用了同一版本的控制軟件，該軟件的功能為：接收1553B總線指令，回送伺服系統參數，通過CAN總線實現在3個DSP間交換數據進行反饋和指令的“三取二”冗余表決功能，與三冗余伺服控制器硬件協同工作，控制伺服機構推擺發動機，實現伺服系統的閉環實時控制。

1 SFMEA分析

SFMEA是一種針對安全性、可靠性的分析與設計技術，用來分析、審查系統及其軟件的潛在故障模式，確定其對系統工作能力的影響，從而發現設計中潛在的薄弱環節，提出可能采取的預防改進措施，以消除或減少故障發生的可能性，提升軟件和系統的安全性和可靠性水平。

基于軟件功能的SFMEA以SPHA為基礎，根據助推伺服控制軟件任務書對軟件功能、性能、可靠性、安全性的要求，按以下幾個步驟實施：

1)根據系統設計要求進行軟件安全性需求分析；

2)確定助推伺服控制軟件的工作分解結構；

3)軟件失效模式、影響分析及改進措施。

1.1 根據系統設計要求進行軟件安全性需求分析

1.1.1 系統安全性、可靠性設計要求

1)軟件需求分析必須遵守《軍用軟件需求分析》(GJB1091)的規定，確保軟件需求規格說明的無歧義性、完整性、可驗證性、一致性、可修改性、可追蹤性和易使用性。

2)通過PHA分析，以及按照《軟件可靠性和安全性設計準則》(GJB/Z102)，確定助推伺服控制軟件的等級為A級。

3)軟件具有健壯性，對系統所受的外界干擾、接口故障(非法輸入、常0/1故障)等具有適應能力；安全關鍵功能必須具有強數據類型；不得使用1位的邏輯“0”或“1”來表示“安全”或“危險”狀態。

4)軟件在設計過程中應采取必要的可靠性措施。可根據軟件的關鍵性及特點采取冗余設計、多數表決處理、軟件自檢等方法，以提高軟件的可靠性。軟件在完成設計后，應進行優化處理，刪除多余的指令和內容。

5)狀態信息的獲取，應考慮采用在一個周期內進行多次查詢或在多個周期內進行連續查詢的濾波處理方式，濾除掉可能的干擾信號。

6)數據的存放應考慮其安全性及需要便于軟件的優化，重要的標志應安排在所有數組前面，確保即便在下標超界的情況下，數組也不會對重要標志造成破壞。對重要標志應盡量采用直接尋址的方式進行尋址。

7)為確保總線數據傳輸的有效性與完整性，應為每幀數據后置CRC校驗和，并且在總線超時未收到數據時，應采取缺省值等必要措施。

8)軟件(程序)多余物的處理，程序塊的隔離，內存未用空間和未采用中斷的處理，對關鍵數據、變量的保護和校核等采取有效措施。

9)對于控制軟件分支的重要判別標志和軟件結構，必須保證足夠的可靠性。

10)要處理好運行過程中產生的極小值。

11)使用中斷要慎重，各中斷無論是否屏蔽，都應有“出口”。

12)在軟件設計過程中, 對內存的使用應滿足20%的余量要求。特別是對動態數據緩沖區及計算周期時間的余量，更應準確地進行測算。

13)在軟件設計過程中, 應注意收集有關助推伺服控制軟件的信息和數據，逐步對軟件進行定量的可靠性分析。

14)對任務書中描述的公式、變量，其量綱、定義域和值域在軟件實現時要予以說明和仔細檢查。

15)要求助推伺服控制軟件周期監視BU65170芯片的工作狀態，在發現異常后，對BU65170芯片重新進行初始化設置。

1.1.2 軟件安全性需求分析

1.1.2.1 軟件性能的安全性需求

1)在助推伺服控制軟件中，對未使用中斷和野中斷(指在程序運行過程中不期望發生的異常中斷)應采取安全保護措施；盡量避免中斷嵌套的使用。在必須使用中斷嵌套完成對各項任務的調度時，需要對中斷嵌套在使用過程中引起的中斷沖突和資源競爭進行深入分析：

a)對程序運行過程中不使用的中斷源用屏蔽字進行屏蔽；

b)對不使用中斷編寫的空中斷處理程序，需使程序正確地返回到原來的斷點。在正常情況下，未使用中斷和野中斷不會出現，該處理程序不會執行，因此，不會對程序運行產生任何影響。只有在非正常狀態下，即未使用中斷和野中斷出現時，該處理程序才會起作用；

c)對于使用中斷嵌套而引發的每一種中斷沖突情況，需做具體分析，對所有可能產生的資源沖突(包括堆棧、全局變量、處理器的標志寄存器等)逐一進行分析，判斷是否有發生的可能或進行了保護。

2)軟件應滿足對時間、容量的使用預留20%余量的要求，對周期內的運行時間余量應進行準確的測算：

a)如果軟件運行時間不能滿足要求，一方面可優化程序，一方面可根據計算精度適當調整控制周期；

b)如果空間不能滿足要求，則需要進行優化處理。如果經優化后的軟件仍然超過有效范圍，導致程序不能正常執行，則需要尋求新的途徑以解決問題。

3)軟件設計要考慮實時性要求：

a)上電后按任務書提出的時間要求完成系統的初始化設置；

b)在控制周期內完成對伺服機構的實時控制指令和位置反饋等信號的綜合、校正、濾波，將計算得到的誤差信號分別送達對應的DA，以驅動伺服機構；

c)1553B總線周期應滿足任務書要求；

d)上電或收到“啟動自檢測”模式碼后，按任務書提出的時間要求完成自檢；

e)從收到BC控制指令(SCU1擺角控制信息)到指令實際輸出的時間，應滿足任務書要求；

f)在收到“時間同步消息”后，在控制周期內完成系統對時；

g)在控制周期內完成位置反饋等重要信號的AD采集，其余遙測用信號完成1次采樣更新，采樣周期不小于1553B總線周期；

h)在控制周期內完成1次遙測數據的更新上傳。

4)在軟件設計完成后，需對整個軟件的程序結構和數據結構進行優化和完善，刪除多余的語句、數據和注釋。

1.1.2.2 軟件功能的安全性需求

1)在收到時間同步碼后，不再響應、啟動自檢測模式碼和復位遠程終端模式碼。

2)對擺角指令絕對值按任務書要求進行限幅。

3)軟件中不允許出現不期望的死循環。

1.1.2.3 關鍵數據安全性需求

1)針對數據合理性檢測，需采取有效措施對關鍵數據、變量等進行校核，例如對變量的值域進行檢測。

2)數據有效性處理。對關鍵數據進行有效性判斷，注意計算過程中數據的合理性，對除法計算的分母、被開方數和反三角函數進行合理性保護，對浮點數下溢等問題進行處理，避免出現無效操作數。

3)軟件設計所用的公式和參數的量綱，必須與任務書的要求一致。

4)數據必須全部初始化為合理數值，數據緩沖區、查詢表需被正確初始化。

1.1.2.4 接口安全性需求

1)軟件采用結構化設計方法，應合理劃分功能模塊，模塊設計需按高內聚、低耦合的設計原則進行，調用關系及輸入、輸出數據需明確。模塊和標志間的接口應盡可能簡單。

2)對AD采樣數據和DA計算數據進行限幅。

3)為保證助推伺服控制器1553B總線芯片發送、接收數據的完整性，需要采用發送、接收數據雙緩沖的設計方法。

4)注意數據采樣的時間，避免出現死循環。

1.2 助推伺服控制軟件工作分解結構

根據軟件任務書，繪制軟件功能流程圖，定義軟件約定層次結構，確定不同角度的2種分法，如圖1所示。

圖1 軟件約定層次圖Fig.1 Functional and design blocks

1.2.1 主程序模塊

1)初始化功能

2)自檢功能

3)參數燒寫功能

1.2.2 毫秒中斷模塊

1)AD采集功能

2)DA輸出功能

3)“三取二”表決功能

4)差分方程計算功能

5)遙測消息更新上傳功能

6)本機發送CAN數據功能

1.2.3 1553B中斷模塊

1)1553B消息解析功能

2)1553B消息執行功能

1.2.4 CAN中斷模塊

1)接收另2機CAN數據的功能

1.3 軟件失效模式、影響分析及改進措施

基于功能的軟件失效模式、影響及危害性分析大致可分為4類。軟件失效模式影響的嚴酷度等級的評分標準從1級(無影響)到10級(影響系統運行的安全性)，共分為10級；發生的可能性從1級(無影響)到10級(影響極高)，共分為10級。

基于功能的軟件失效模式、影響及危害性分析中的第1類，為地面各項試驗、負載試驗、全箭綜合試驗、發射前電氣系統試驗可發現的錯誤，通過更換控制器備份、程序重新燒入等方法可以解決，但可能會推遲發射，其危害程度相對較低。軟件失效模式的影響輕微，嚴酷度等級的評分為3～4分，發生的可能性較低，評分為3～4分。例如：

1)DSP初始化錯誤；

2)65170芯片初始化錯誤；

3)上電自檢功能錯誤；

4)1553總線自檢功能錯誤；

5)參數燒寫功能錯誤。

第2類，為地面試驗、發射前電氣系統試驗可發現的錯誤或火箭飛行時可能發生的錯誤，但對火箭的飛行結果影響不大，軟件失效模式影響的嚴酷度等級評分為5～6分(系統仍能運行，但影響使用的方便與舒適性)；發生的可能性較低，評分為3～4分，例如：

1)遙測消息更新上傳功能錯誤；

2)本機發送CAN數據功能；

3)接收另2機CAN數據功能(CAN總線在本系統中的作用為：在一路1553指令故障或一路反饋故障時提高可靠性)。

第3類，經地面試驗的充分考核，火箭在飛行時發生錯誤的可能性低，但錯誤一旦發生，會嚴重影響火箭控制系統的控制精度，對火箭飛行的成敗影響重大。軟件失效模式影響的嚴酷度等級的評分為8分(影響系統喪失主要功能而不能運行)，但其發生的可能性很小，評分為2～3分，例如：

1)差分方程計算錯誤；

2)程序版本號代碼和錯誤；

3)“三取二表決功能”錯誤。

第4類，火箭在飛行時可能發生的錯誤，會影響火箭控制系統的控制精度，對火箭的飛行結果影響大。軟件失效模式影響的嚴酷度等級的評分為7～8分，發生的可能性評分為4分，例如：

1)DA輸出功能錯誤；

2)AD采集功能錯誤；

3)1553B控制指令接收錯誤。

經SFMEA分析，對各種故障模式分別采取改進措施，例如：1)嚴格按芯片使用手冊，進行程序設計；2)加強軟件單元測試、代碼走查、配置項測試、綜合試驗等測試；3)仔細檢查諸元文件，設立一二崗，確保諸元生成正確；4)在出廠前、基地單元測試時設置強制檢驗點，確保軟件版本、代碼和正確。

2 SFTA分析

軟件故障樹分析是一種用于風險分析的、系統性的、自上向下的演繹方法，即從助推伺服控制軟件不希望發生的事件(頂事件)、特別是對人員和設備的安全產生重大影響的事件開始，向下逐步追查導致頂事件發生的原因，直至到達基本事件(底事件)。SFTA的結果可以用來指導后續的可靠性、安全性設計，確定軟件測試的重點，使軟件可靠性得到更充分的保障。

軟件故障樹中的危險事件是由軟件初步危險分析(SPHA)的結果確定的，在需求分析階段，需進行基于軟件功能的SFTA分析，該分析按以下3個步驟進行：

1)軟件控制流分析；

2)建立軟件故障樹模型；

3)對軟件故障樹進行定性分析。

2.1 控制流分析

助推伺服控制軟件按照功能可劃分為4個相對獨立的功能模塊，即主程序、毫秒中斷、1553B中斷和CAN中斷，其層次關系如圖2所示。各模塊的控制流程如圖3～圖6所示。

圖2 助推伺服控制軟件的層次關系圖Fig.2 Design blocks of servo-control software

圖3 主程序的控制流程Fig.3 Flow chart of main program

圖4 1553B中斷處理流程Fig.4 Flow chart of 1553B interrupt

圖5 毫秒中斷處理流程Fig.5 Flow chart of millisecond interrupt

圖6 CAN中斷處理流程Fig.6 Flow chart of CAN interrupt

2.2 故障樹模型的建立

軟件故障樹由一套邏輯和事件符號構建而成，利用圖形化的方式直觀地標識故障事件之間的邏輯關系。建立故障樹的基本流程是：選擇要分析的頂事件(即不希望發生的事件)作為故障樹的根，然后分析導致頂事件發生的直接原因，并用適當的邏輯門與頂事件相連，作為故障樹的節(中間事件)，以此逐步深入，一直追溯到導致頂事件發生的全部原因(底層的基本事件)。這些底層的基本事件被稱為底事件，構成故障樹的葉。

本軟件SFTA的過程為：首先，選擇故障樹的頂事件(根)為系統報廢、任務失敗，底事件(葉)則定義到軟件功能級的失效原因；其次，根據控制流程中各功能模塊間的調用關系，得到故障樹的結構；再通過對各功能模塊的輸入數據進行分析，得出故障樹的葉節點，從而繪制出完整的軟件故障樹模型，如圖7所示。

根據軟件故障樹模型，在進行軟件設計時，應對所有底事件中的失效原因進行有針對性的安全性設計，從而防止中間事件和頂事件的發生，或降低其發生概率。

圖7 助推伺服軟件基于功能的軟件故障樹模型Fig.7 FTA model based on software function

其中,符號的含義為：

T1：系統報廢、任務失敗；

M1：主程序模塊失效；

M2：毫秒中斷模塊失效；

M3：1553B中斷模塊失效；

M4：CAN中斷模塊失效；

M11：初始化功能錯誤；

M12：自檢功能錯誤；

M13：參數燒寫功能錯誤；

M21：差分方程計算錯誤；

M22：DA輸出功能錯誤；

M23：AD采集功能錯誤；

M24：遙測消息更新上傳功能錯誤；

M31：1553B消息解析錯誤；

M32：1553B消息執行功能錯誤；

M111：DSP初始化錯誤；

M112：65170芯片初始化錯誤；

M121：上電自檢功能錯誤；

M122：總線自檢功能錯誤；

X1：寄存器初始化錯誤；

X2：中斷向量地址設置錯誤；

X3：查詢表初始化錯誤；

X4：數據塊地址初始化錯誤；

X5：DSP內存自檢錯誤；

X6：65170芯片檢測錯誤；

X7：機構參數自檢錯誤；

X8：獲取RT地址有誤；

X9：燒寫參數錯誤；

X10：燒寫地址錯誤；

X11：反饋輸入錯誤；

X12：差分方程錯誤；

X13：DA輸出地址錯誤；

X14：DA輸出值超范圍；

X15：AD采集地址錯誤

X16：AD采集反饋值錯誤；

X17：AD采集遙測值錯誤；

X18：總線消息解析錯誤；

X19：總線消息有效位判斷錯誤；

X20：時鐘同步錯誤；

X21：總線消息發送錯誤；

X22：CAN中斷標志位判斷錯誤；

X23：CAN郵箱讀取錯誤；

X24：“三取二”表決錯誤；

X25：CAN發送錯誤；

X26：程序版本號代碼和錯誤。

2.3 定性分析

通過故障樹模型分析出最小割集。所謂割集是指能引起頂事件發生的底事件的集合。最小割集是指不包含任何冗余因素的割集。如果去掉最小割集中的任何事件，它將不再成為割集。

當故障樹建立并得出所有的最小割集后，應對割集進行定性比較，并將結果應用于指導故障診斷或指出改進方向。最小割集定性比較應遵循以下原則：

首先，根據最小割集的階數(所包含底事件的數目)將割集進行排序，再參照各底事件發生的可能性(可能性越大就越重要)。在各底事件發生的可能性均較小且差別不大的情況下，再根據各底事件的出現次數、定性地確定各底事件的重要級別。一般而言，最小割集越多，引發的頂事件的故障模式就越多；另外，底事件在最小割集中出現的次數越多，就越重要，一階最小割集中底事件的重要度要大于多階最小割集中底事件的重要度。

本故障樹中只有或門而沒有與門，所以故障樹中的所有底事件(X1～X26)均是最小割集，各最小割集的階數也均為1，即任何一項底事件的發生均會導致頂事件的發生。其中，X1、X3、X4底事件出現的次數為2次，其他底事件出現的次數均為1次。經分析，得到重要的最小割集為：X9燒寫參數錯誤、X14DA輸出值超范圍、X16-AD采集反饋值錯誤、X21-1553B總線發送擺角指令錯誤、X26程序版本號代碼和錯誤。后續，將通過單元測試、代碼走查、配置項測試、仿真試驗、綜合試驗、第三方評測等驗證措施及嚴格按型號進行軟件工程化管理等措施，來避免底事件的發生。

3 結 論

根據SFMEA及SFTA的分析結果，針對軟件設計中可能存在的薄弱環節和引發軟件失效的各底事件，在軟件設計階段應進行有針對性的設計，采取措施，以避免底事件的發生，從而降低頂事件的發生概率。同時，以此為依據進行基于軟件部件和單元的SFMEA和SFTA分析。通過分析可得，軟件中的參數燒寫、與硬件間的接口操作、中斷使用等都是軟件設計中的關鍵環節或關鍵事件，在后續的安全性設計中應加以重點考慮，并加強測試。