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

( 1. 上海航天控制技術(shù)研究所·上海·201109；2.上海伺服系統(tǒng)工程技術(shù)研究中心·上?！?01109)

0 引 言

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

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

本文以助推伺服控制軟件為例進(jìn)行了SFMEA和SFTA分析，該軟件安裝于三通道冗余伺服控制器中。三通道采用了同一版本的控制軟件，該軟件的功能為：接收1553B總線指令，回送伺服系統(tǒng)參數(shù)，通過CAN總線實(shí)現(xiàn)在3個(gè)DSP間交換數(shù)據(jù)進(jìn)行反饋和指令的“三取二”冗余表決功能，與三冗余伺服控制器硬件協(xié)同工作，控制伺服機(jī)構(gòu)推擺發(fā)動(dòng)機(jī)，實(shí)現(xiàn)伺服系統(tǒng)的閉環(huán)實(shí)時(shí)控制。

1 SFMEA分析

SFMEA是一種針對(duì)安全性、可靠性的分析與設(shè)計(jì)技術(shù)，用來分析、審查系統(tǒng)及其軟件的潛在故障模式，確定其對(duì)系統(tǒng)工作能力的影響，從而發(fā)現(xiàn)設(shè)計(jì)中潛在的薄弱環(huán)節(jié)，提出可能采取的預(yù)防改進(jìn)措施，以消除或減少故障發(fā)生的可能性，提升軟件和系統(tǒng)的安全性和可靠性水平。

基于軟件功能的SFMEA以SPHA為基礎(chǔ)，根據(jù)助推伺服控制軟件任務(wù)書對(duì)軟件功能、性能、可靠性、安全性的要求，按以下幾個(gè)步驟實(shí)施：

1)根據(jù)系統(tǒng)設(shè)計(jì)要求進(jìn)行軟件安全性需求分析；

2)確定助推伺服控制軟件的工作分解結(jié)構(gòu)；

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

1.1 根據(jù)系統(tǒng)設(shè)計(jì)要求進(jìn)行軟件安全性需求分析

1.1.1 系統(tǒng)安全性、可靠性設(shè)計(jì)要求

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

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

3)軟件具有健壯性，對(duì)系統(tǒng)所受的外界干擾、接口故障(非法輸入、常0/1故障)等具有適應(yīng)能力；安全關(guān)鍵功能必須具有強(qiáng)數(shù)據(jù)類型；不得使用1位的邏輯“0”或“1”來表示“安全”或“危險(xiǎn)”狀態(tài)。

4)軟件在設(shè)計(jì)過程中應(yīng)采取必要的可靠性措施?？筛鶕?jù)軟件的關(guān)鍵性及特點(diǎn)采取冗余設(shè)計(jì)、多數(shù)表決處理、軟件自檢等方法，以提高軟件的可靠性。軟件在完成設(shè)計(jì)后，應(yīng)進(jìn)行優(yōu)化處理，刪除多余的指令和內(nèi)容。

5)狀態(tài)信息的獲取，應(yīng)考慮采用在一個(gè)周期內(nèi)進(jìn)行多次查詢或在多個(gè)周期內(nèi)進(jìn)行連續(xù)查詢的濾波處理方式，濾除掉可能的干擾信號(hào)。

6)數(shù)據(jù)的存放應(yīng)考慮其安全性及需要便于軟件的優(yōu)化，重要的標(biāo)志應(yīng)安排在所有數(shù)組前面，確保即便在下標(biāo)超界的情況下，數(shù)組也不會(huì)對(duì)重要標(biāo)志造成破壞。對(duì)重要標(biāo)志應(yīng)盡量采用直接尋址的方式進(jìn)行尋址。

7)為確?？偩€數(shù)據(jù)傳輸?shù)挠行耘c完整性，應(yīng)為每幀數(shù)據(jù)后置CRC校驗(yàn)和，并且在總線超時(shí)未收到數(shù)據(jù)時(shí)，應(yīng)采取缺省值等必要措施。

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

9)對(duì)于控制軟件分支的重要判別標(biāo)志和軟件結(jié)構(gòu)，必須保證足夠的可靠性。

10)要處理好運(yùn)行過程中產(chǎn)生的極小值。

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

12)在軟件設(shè)計(jì)過程中, 對(duì)內(nèi)存的使用應(yīng)滿足20%的余量要求。特別是對(duì)動(dòng)態(tài)數(shù)據(jù)緩沖區(qū)及計(jì)算周期時(shí)間的余量，更應(yīng)準(zhǔn)確地進(jìn)行測(cè)算。

13)在軟件設(shè)計(jì)過程中, 應(yīng)注意收集有關(guān)助推伺服控制軟件的信息和數(shù)據(jù)，逐步對(duì)軟件進(jìn)行定量的可靠性分析。

14)對(duì)任務(wù)書中描述的公式、變量，其量綱、定義域和值域在軟件實(shí)現(xiàn)時(shí)要予以說明和仔細(xì)檢查。

15)要求助推伺服控制軟件周期監(jiān)視BU65170芯片的工作狀態(tài)，在發(fā)現(xiàn)異常后，對(duì)BU65170芯片重新進(jìn)行初始化設(shè)置。

1.1.2 軟件安全性需求分析

1.1.2.1 軟件性能的安全性需求

1)在助推伺服控制軟件中，對(duì)未使用中斷和野中斷(指在程序運(yùn)行過程中不期望發(fā)生的異常中斷)應(yīng)采取安全保護(hù)措施；盡量避免中斷嵌套的使用。在必須使用中斷嵌套完成對(duì)各項(xiàng)任務(wù)的調(diào)度時(shí)，需要對(duì)中斷嵌套在使用過程中引起的中斷沖突和資源競(jìng)爭(zhēng)進(jìn)行深入分析：

a)對(duì)程序運(yùn)行過程中不使用的中斷源用屏蔽字進(jìn)行屏蔽；

b)對(duì)不使用中斷編寫的空中斷處理程序，需使程序正確地返回到原來的斷點(diǎn)。在正常情況下，未使用中斷和野中斷不會(huì)出現(xiàn)，該處理程序不會(huì)執(zhí)行，因此，不會(huì)對(duì)程序運(yùn)行產(chǎn)生任何影響。只有在非正常狀態(tài)下，即未使用中斷和野中斷出現(xiàn)時(shí)，該處理程序才會(huì)起作用；

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

2)軟件應(yīng)滿足對(duì)時(shí)間、容量的使用預(yù)留20%余量的要求，對(duì)周期內(nèi)的運(yùn)行時(shí)間余量應(yīng)進(jìn)行準(zhǔn)確的測(cè)算：

a)如果軟件運(yùn)行時(shí)間不能滿足要求，一方面可優(yōu)化程序，一方面可根據(jù)計(jì)算精度適當(dāng)調(diào)整控制周期；

b)如果空間不能滿足要求，則需要進(jìn)行優(yōu)化處理。如果經(jīng)優(yōu)化后的軟件仍然超過有效范圍，導(dǎo)致程序不能正常執(zhí)行，則需要尋求新的途徑以解決問題。

3)軟件設(shè)計(jì)要考慮實(shí)時(shí)性要求：

a)上電后按任務(wù)書提出的時(shí)間要求完成系統(tǒng)的初始化設(shè)置；

b)在控制周期內(nèi)完成對(duì)伺服機(jī)構(gòu)的實(shí)時(shí)控制指令和位置反饋等信號(hào)的綜合、校正、濾波，將計(jì)算得到的誤差信號(hào)分別送達(dá)對(duì)應(yīng)的DA，以驅(qū)動(dòng)伺服機(jī)構(gòu)；

c)1553B總線周期應(yīng)滿足任務(wù)書要求；

d)上電或收到“啟動(dòng)自檢測(cè)”模式碼后，按任務(wù)書提出的時(shí)間要求完成自檢；

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

f)在收到“時(shí)間同步消息”后，在控制周期內(nèi)完成系統(tǒng)對(duì)時(shí)；

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

h)在控制周期內(nèi)完成1次遙測(cè)數(shù)據(jù)的更新上傳。

4)在軟件設(shè)計(jì)完成后，需對(duì)整個(gè)軟件的程序結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)進(jìn)行優(yōu)化和完善，刪除多余的語(yǔ)句、數(shù)據(jù)和注釋。

1.1.2.2 軟件功能的安全性需求

1)在收到時(shí)間同步碼后，不再響應(yīng)、啟動(dòng)自檢測(cè)模式碼和復(fù)位遠(yuǎn)程終端模式碼。

2)對(duì)擺角指令絕對(duì)值按任務(wù)書要求進(jìn)行限幅。

3)軟件中不允許出現(xiàn)不期望的死循環(huán)。

1.1.2.3 關(guān)鍵數(shù)據(jù)安全性需求

1)針對(duì)數(shù)據(jù)合理性檢測(cè)，需采取有效措施對(duì)關(guān)鍵數(shù)據(jù)、變量等進(jìn)行校核，例如對(duì)變量的值域進(jìn)行檢測(cè)。

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

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

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

1.1.2.4 接口安全性需求

1)軟件采用結(jié)構(gòu)化設(shè)計(jì)方法，應(yīng)合理劃分功能模塊，模塊設(shè)計(jì)需按高內(nèi)聚、低耦合的設(shè)計(jì)原則進(jìn)行，調(diào)用關(guān)系及輸入、輸出數(shù)據(jù)需明確。模塊和標(biāo)志間的接口應(yīng)盡可能簡(jiǎn)單。

2)對(duì)AD采樣數(shù)據(jù)和DA計(jì)算數(shù)據(jù)進(jìn)行限幅。

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

4)注意數(shù)據(jù)采樣的時(shí)間，避免出現(xiàn)死循環(huán)。

1.2 助推伺服控制軟件工作分解結(jié)構(gòu)

根據(jù)軟件任務(wù)書，繪制軟件功能流程圖，定義軟件約定層次結(jié)構(gòu)，確定不同角度的2種分法，如圖1所示。

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

1.2.1 主程序模塊

1)初始化功能

2)自檢功能

3)參數(shù)燒寫功能

1.2.2 毫秒中斷模塊

1)AD采集功能

2)DA輸出功能

3)“三取二”表決功能

4)差分方程計(jì)算功能

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

6)本機(jī)發(fā)送CAN數(shù)據(jù)功能

1.2.3 1553B中斷模塊

1)1553B消息解析功能

2)1553B消息執(zhí)行功能

1.2.4 CAN中斷模塊

1)接收另2機(jī)CAN數(shù)據(jù)的功能

1.3 軟件失效模式、影響分析及改進(jìn)措施

基于功能的軟件失效模式、影響及危害性分析大致可分為4類。軟件失效模式影響的嚴(yán)酷度等級(jí)的評(píng)分標(biāo)準(zhǔn)從1級(jí)(無影響)到10級(jí)(影響系統(tǒng)運(yùn)行的安全性)，共分為10級(jí)；發(fā)生的可能性從1級(jí)(無影響)到10級(jí)(影響極高)，共分為10級(jí)。

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

1)DSP初始化錯(cuò)誤；

2)65170芯片初始化錯(cuò)誤；

3)上電自檢功能錯(cuò)誤；

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

5)參數(shù)燒寫功能錯(cuò)誤。

第2類，為地面試驗(yàn)、發(fā)射前電氣系統(tǒng)試驗(yàn)可發(fā)現(xiàn)的錯(cuò)誤或火箭飛行時(shí)可能發(fā)生的錯(cuò)誤，但對(duì)火箭的飛行結(jié)果影響不大，軟件失效模式影響的嚴(yán)酷度等級(jí)評(píng)分為5～6分(系統(tǒng)仍能運(yùn)行，但影響使用的方便與舒適性)；發(fā)生的可能性較低，評(píng)分為3～4分，例如：

1)遙測(cè)消息更新上傳功能錯(cuò)誤；

2)本機(jī)發(fā)送CAN數(shù)據(jù)功能；

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

第3類，經(jīng)地面試驗(yàn)的充分考核，火箭在飛行時(shí)發(fā)生錯(cuò)誤的可能性低，但錯(cuò)誤一旦發(fā)生，會(huì)嚴(yán)重影響火箭控制系統(tǒng)的控制精度，對(duì)火箭飛行的成敗影響重大。軟件失效模式影響的嚴(yán)酷度等級(jí)的評(píng)分為8分(影響系統(tǒng)喪失主要功能而不能運(yùn)行)，但其發(fā)生的可能性很小，評(píng)分為2～3分，例如：

1)差分方程計(jì)算錯(cuò)誤；

2)程序版本號(hào)代碼和錯(cuò)誤；

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

第4類，火箭在飛行時(shí)可能發(fā)生的錯(cuò)誤，會(huì)影響火箭控制系統(tǒng)的控制精度，對(duì)火箭的飛行結(jié)果影響大。軟件失效模式影響的嚴(yán)酷度等級(jí)的評(píng)分為7～8分，發(fā)生的可能性評(píng)分為4分，例如：

1)DA輸出功能錯(cuò)誤；

2)AD采集功能錯(cuò)誤；

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

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

2 SFTA分析

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

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

1)軟件控制流分析；

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

3)對(duì)軟件故障樹進(jìn)行定性分析。

2.1 控制流分析

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

圖2 助推伺服控制軟件的層次關(guān)系圖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 故障樹模型的建立

軟件故障樹由一套邏輯和事件符號(hào)構(gòu)建而成，利用圖形化的方式直觀地標(biāo)識(shí)故障事件之間的邏輯關(guān)系。建立故障樹的基本流程是：選擇要分析的頂事件(即不希望發(fā)生的事件)作為故障樹的根，然后分析導(dǎo)致頂事件發(fā)生的直接原因，并用適當(dāng)?shù)倪壿嬮T與頂事件相連，作為故障樹的節(jié)(中間事件)，以此逐步深入，一直追溯到導(dǎo)致頂事件發(fā)生的全部原因(底層的基本事件)。這些底層的基本事件被稱為底事件，構(gòu)成故障樹的葉。

本軟件SFTA的過程為：首先，選擇故障樹的頂事件(根)為系統(tǒng)報(bào)廢、任務(wù)失敗，底事件(葉)則定義到軟件功能級(jí)的失效原因；其次，根據(jù)控制流程中各功能模塊間的調(diào)用關(guān)系，得到故障樹的結(jié)構(gòu)；再通過對(duì)各功能模塊的輸入數(shù)據(jù)進(jìn)行分析，得出故障樹的葉節(jié)點(diǎn)，從而繪制出完整的軟件故障樹模型，如圖7所示。

根據(jù)軟件故障樹模型，在進(jìn)行軟件設(shè)計(jì)時(shí)，應(yīng)對(duì)所有底事件中的失效原因進(jìn)行有針對(duì)性的安全性設(shè)計(jì)，從而防止中間事件和頂事件的發(fā)生，或降低其發(fā)生概率。

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

其中,符號(hào)的含義為：

T1：系統(tǒng)報(bào)廢、任務(wù)失敗；

M1：主程序模塊失效；

M2：毫秒中斷模塊失效；

M3：1553B中斷模塊失效；

M4：CAN中斷模塊失效；

M11：初始化功能錯(cuò)誤；

M12：自檢功能錯(cuò)誤；

M13：參數(shù)燒寫功能錯(cuò)誤；

M21：差分方程計(jì)算錯(cuò)誤；

M22：DA輸出功能錯(cuò)誤；

M23：AD采集功能錯(cuò)誤；

M24：遙測(cè)消息更新上傳功能錯(cuò)誤；

M31：1553B消息解析錯(cuò)誤；

M32：1553B消息執(zhí)行功能錯(cuò)誤；

M111：DSP初始化錯(cuò)誤；

M112：65170芯片初始化錯(cuò)誤；

M121：上電自檢功能錯(cuò)誤；

M122：總線自檢功能錯(cuò)誤；

X1：寄存器初始化錯(cuò)誤；

X2：中斷向量地址設(shè)置錯(cuò)誤；

X3：查詢表初始化錯(cuò)誤；

X4：數(shù)據(jù)塊地址初始化錯(cuò)誤；

X5：DSP內(nèi)存自檢錯(cuò)誤；

X6：65170芯片檢測(cè)錯(cuò)誤；

X7：機(jī)構(gòu)參數(shù)自檢錯(cuò)誤；

X8：獲取RT地址有誤；

X9：燒寫參數(shù)錯(cuò)誤；

X10：燒寫地址錯(cuò)誤；

X11：反饋輸入錯(cuò)誤；

X12：差分方程錯(cuò)誤；

X13：DA輸出地址錯(cuò)誤；

X14：DA輸出值超范圍；

X15：AD采集地址錯(cuò)誤

X16：AD采集反饋值錯(cuò)誤；

X17：AD采集遙測(cè)值錯(cuò)誤；

X18：總線消息解析錯(cuò)誤；

X19：總線消息有效位判斷錯(cuò)誤；

X20：時(shí)鐘同步錯(cuò)誤；

X21：總線消息發(fā)送錯(cuò)誤；

X22：CAN中斷標(biāo)志位判斷錯(cuò)誤；

X23：CAN郵箱讀取錯(cuò)誤；

X24：“三取二”表決錯(cuò)誤；

X25：CAN發(fā)送錯(cuò)誤；

X26：程序版本號(hào)代碼和錯(cuò)誤。

2.3 定性分析

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

當(dāng)故障樹建立并得出所有的最小割集后，應(yīng)對(duì)割集進(jìn)行定性比較，并將結(jié)果應(yīng)用于指導(dǎo)故障診斷或指出改進(jìn)方向。最小割集定性比較應(yīng)遵循以下原則：

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

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

3 結(jié) 論

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