航電控制計(jì)算機(jī)系統(tǒng)軟件安全性框架研究

孫　媛，趙建軍，周偉祝

(海軍航空工程學(xué)院, 山東 煙臺　264001)

安全關(guān)鍵系統(tǒng)(safety-critical system,SCS)[1-2]，泛指具有潛在破壞力的一類系統(tǒng)，此系統(tǒng)一旦失敗，就能夠造成嚴(yán)重后果，比如：人員傷亡，財(cái)產(chǎn)損失或環(huán)境破壞等。在軟件體系結(jié)構(gòu)設(shè)計(jì)中的一個(gè)常見的做法是從模型和文檔不同的體系結(jié)構(gòu)的視角進(jìn)行軟件體系結(jié)構(gòu)設(shè)計(jì)。一個(gè)體系結(jié)構(gòu)視圖用一組系統(tǒng)類和它們之間相互關(guān)系來表示[3]，同時(shí)采用多個(gè)視圖從不同的角度加以補(bǔ)充，形成一個(gè)完整的軟件系統(tǒng)體系結(jié)構(gòu)。而安全關(guān)鍵系統(tǒng)的軟件架構(gòu)建模，除上述的軟件體系結(jié)構(gòu)建模外，還應(yīng)包括安全工程相關(guān)模型，如故障樹、故障模式[6]和影響分析等。

1　問題描述

本文以航空電子設(shè)備控制系統(tǒng)軟件為研究案例，分析軟件體系結(jié)構(gòu)設(shè)計(jì)對安全的需求。航空電子系統(tǒng)是現(xiàn)代化飛機(jī)的一個(gè)重要組成部分，與飛機(jī)的作戰(zhàn)性能密切相關(guān)[2]。一些事故報(bào)道表明：航空電子系統(tǒng)的故障可能會導(dǎo)致災(zāi)難性的后果，導(dǎo)致生命損失。通常航空電子設(shè)備控制系統(tǒng)必須滿足數(shù)以百計(jì)安全需求問題。表1為航空電子設(shè)備控制系統(tǒng)研究案例對安全性需求的子集。

表1為可能引起危險(xiǎn)(Hazard)的因素，而軟件的安全性關(guān)注那些導(dǎo)致危險(xiǎn)條件發(fā)生的失效，以及與該類失效相關(guān)的設(shè)計(jì)缺陷和外部輸入條件[4,6]。表2列出了危險(xiǎn)可能出現(xiàn)的原因、危險(xiǎn)類型和風(fēng)險(xiǎn)。其中，HZ1到HZ4的危險(xiǎn)類型確定為災(zāi)難性的，因?yàn)檫@些危險(xiǎn)的可能后果是飛機(jī)墜毀。例如，如果一個(gè)高空顯示，不是正確的值時(shí)，會影響飛行員對高度的判斷，造成與地面碰撞，導(dǎo)致飛機(jī)墜毀，人員傷亡，系統(tǒng)損耗及環(huán)境破壞。HZ5危險(xiǎn)類型確定為可忽略不計(jì)，因?yàn)檫@種危險(xiǎn)的結(jié)果僅造成地面站的通信錯(cuò)誤。

表1　航空電子設(shè)備控制系統(tǒng)研究案例對安全性需求的子集

表2　案例研究的危險(xiǎn)識別

危險(xiǎn)識別確定之后，需要確定安全需求(SRn)。表3中列出了與HZ1相關(guān)的安全需求。

表3　HZ1的安全需求

針對上述問題的描述，采用UML組件圖，進(jìn)行了研究案例的架構(gòu)設(shè)計(jì)[5，7]，如圖1所示。通常一個(gè)航空電子設(shè)備控制系統(tǒng)軟件由前臺的顯示系統(tǒng)類G1、G2，平臺控制系統(tǒng)類P，通信系統(tǒng)類C和導(dǎo)航系統(tǒng)類N組成。P負(fù)責(zé)接收燃料傳感器提供的飛機(jī)燃油數(shù)據(jù)Fuel1和Fuel2；N接收高度表提供的高度數(shù)據(jù)Alti1和Alti2、陀螺儀提供的飛機(jī)姿態(tài)數(shù)據(jù)Gyro1和Gyro2以及GPS提供的飛機(jī)位置數(shù)據(jù)GPS1和GPS2；C主要接收射頻數(shù)據(jù)Radio；G1、G2中顯示P、C、N中的飛機(jī)的高度、姿態(tài)、位置、燃料和射頻數(shù)據(jù)信息并顯示出來。

應(yīng)該注意的是，現(xiàn)有的通用視圖，包括圖1的組件圖并沒有直接涉及到安全問題。例如，關(guān)于一個(gè)組件是否是安全關(guān)鍵的信息是不明確的；安全關(guān)鍵部件沒有體現(xiàn)出來；相關(guān)的策略和模式也沒有體現(xiàn)。在這種情況下，所有的應(yīng)用知識的安全性都是隱含的，將很難建立設(shè)計(jì)決策和分析的體系結(jié)構(gòu)與安全問題之間的關(guān)系。為了解決安全問題，在圖1體系結(jié)構(gòu)設(shè)計(jì)的基礎(chǔ)上，考慮安全工程領(lǐng)域的指導(dǎo)方針和策略，重塑圖1的體系結(jié)構(gòu)。

2　軟件安全性元模型

鑒于上述分析，提出了軟件安全性元模型，如圖2所示，用于分析軟件安全性問題。圖2重用現(xiàn)有元模型的共同概念，提供了一個(gè)集成模型。它由3個(gè)部分構(gòu)成：相關(guān)危險(xiǎn)、安全策略和安全關(guān)鍵模型。元模型的底部為相關(guān)危險(xiǎn)，主要用來描述存在情況潛在危險(xiǎn)所造成或?qū)е碌氖鹿省Ｆ渲?，安全需求來自危險(xiǎn)識別，危險(xiǎn)識別產(chǎn)生相應(yīng)的后果；根據(jù)危險(xiǎn)識別生成故障樹的結(jié)點(diǎn)，故障樹分析[8]中主要是“與”、“或”的布爾邏輯操作；故障樹分析的目標(biāo)是分析設(shè)計(jì)系統(tǒng)中可能的故障。元模型的中間部分為與設(shè)計(jì)應(yīng)用相關(guān)的安全策略，主要包括：故障避免，故障檢測和故障容錯(cuò)3種策略。其中，故障避免策略旨在防止故障發(fā)生。當(dāng)發(fā)生故障時(shí)，故障是通過施加故障檢測策略進(jìn)行檢測[9-11]。故障容錯(cuò)策略是系統(tǒng)時(shí)發(fā)生故障，以正確地繼續(xù)并保持一個(gè)安全的操作條件的能力。元模型的頂部部分包含呈現(xiàn)在體系結(jié)構(gòu)的設(shè)計(jì)類。這些類包括：被監(jiān)控類M、安全關(guān)鍵類SC和非安全關(guān)鍵類NSC。其中，體系結(jié)構(gòu)類F是它們的父類。一個(gè)F可以讀取另一體系結(jié)構(gòu)元數(shù)據(jù)，寫數(shù)據(jù)到另一個(gè)F中，并控制另一個(gè)F。監(jiān)控類可以通過檢查其狀態(tài)監(jiān)控一個(gè)或多個(gè)SC。如果有一個(gè)SC出了問題，它可以通過停止/啟動/重新啟動/初始化等相關(guān)的操作做出反應(yīng)。SC又包含SC。其中一個(gè)SC可以是另一個(gè)SC的子類。SC可以將發(fā)生故障通報(bào)給其他安全的關(guān)鍵要素。SC有狀態(tài)類進(jìn)行狀態(tài)描述。如果檢測到故障，可能導(dǎo)致發(fā)生危險(xiǎn)，但該類危險(xiǎn)是可以防范的，這時(shí)SC可以切換其狀態(tài)到安全狀態(tài)。SC中不應(yīng)該包括那些沒有安全關(guān)鍵操作的類。因此，NSC的定義來表示為不包括安全關(guān)鍵操作的類。一個(gè)NSC可以是另一個(gè)NSC的子類。M或SC能夠保證系統(tǒng)的安全性安全策略實(shí)現(xiàn)。SC可以提供所需功能實(shí)現(xiàn)一個(gè)或多個(gè)安全需求類(SR)。

3　軟件安全性視角定義

圖2給出了軟件安全元模型，主要包括：危險(xiǎn)、安全策略和安全關(guān)鍵模型3個(gè)部分，本節(jié)針對這3個(gè)部分，提出其安全性視圖。表4給出了危險(xiǎn)視圖。其目的是支持的危險(xiǎn)辨識過程，顯示每一個(gè)危險(xiǎn)的故障樹，能夠引起的危險(xiǎn)，相關(guān)的安全需求和可能的危險(xiǎn)后果。

表4　危險(xiǎn)視圖

表5提出了安全策略視圖，用于確定危險(xiǎn)的安全策略。安全策略分為故障避免，故障檢測和故障容錯(cuò)策略。在前面，定義了故障檢測和故障容錯(cuò)策略的關(guān)系，通常一個(gè)故障可以處理不同的安全策略，這里定義了一個(gè)處理故障的安全策略類應(yīng)具有的屬性，并構(gòu)建安全策略和故障之間的關(guān)系，而不是將每個(gè)處理的故障作為一個(gè)類。這種方法提高了可讀性的視圖，并能體現(xiàn)故障和安全策略之間的可追溯性。

表5　安全策略視圖

表6為安全關(guān)鍵視圖。在元模型的定義，定義了一個(gè)M和SC及其安全策略。一個(gè)安全策略可以通過不同的M或SC實(shí)現(xiàn)。因此，定義了一個(gè)實(shí)現(xiàn)策略的屬性，這個(gè)視圖中，以M、SC、NSC為核心，同時(shí)還能夠修改SC和SR之間的關(guān)系。

表6　安全關(guān)鍵視圖

4　體系框架的應(yīng)用

前面已經(jīng)采用了觀圖的方法來描述在第2節(jié)中描述的案例研究。下面的小節(jié)說明定義的視圖在案例研究中的應(yīng)用。

4.1　危險(xiǎn)視圖

圖3是HZ1危險(xiǎn)視圖。為簡單起見，其他危險(xiǎn)被排除。以接受的危險(xiǎn)作為參數(shù)，并表示出了僅與指定的危險(xiǎn)相關(guān)的故障和安全需求。這種視圖反映了案例研究以下幾個(gè)問題：

哪些安全需求是來自于哪些危險(xiǎn)？與HZ1相關(guān)的安全需求在圖3中顯示。這些安全需求在表3中定義。

確定的危險(xiǎn)可能產(chǎn)生的后果是什么？如圖3所示，墜機(jī)是HZ1的可能后果。

哪些故障能引起哪些危險(xiǎn)？通過使用故障樹分析能引起HZ1故障，這是一種公知的方法[7]中產(chǎn)生的故障樹葉節(jié)點(diǎn)。故障編號從F1到F13。它們的定義在表7中的FTA節(jié)點(diǎn)的名稱中給出。N1和N2注明“Alti1丟失”和“Alti2丟失”。N3和N4代表“，在Alti1故障”和“Alti2故障”。當(dāng)發(fā)生下列條件之一的，可以顯示錯(cuò)誤的測高數(shù)據(jù)：當(dāng)Alti1丟失并且在Alti2(N5)，錯(cuò)誤時(shí)Alti2丟失并且在Alti1(N6)，錯(cuò)誤時(shí)有錯(cuò)誤在這兩個(gè)高度計(jì)和它們之間的差不小于閾值(N7)，當(dāng)在G1的故障和G2失敗(N8)，當(dāng)G2在的誤差更大和G1發(fā)生故障(N9)所示，G失敗。

錯(cuò)誤描　　述錯(cuò)誤描　　述[F1]Alti1丟失[F9]G1故障[F2]與Alti1的通信丟失[F10]G2故障[F3]Alti2丟失[F11]Alti1失敗[F4]與Alti2的通信丟失[F12]Alti2通信丟失[F5]Alti1故障[F13]N失敗[F6]與Alti1通信故障[F14]G1失敗[F7]Alti2故障[F15]G2顯示失敗[F8]與Alti2通信故障

4.2　安全策略視圖

安全策略視圖顯示了在體系結(jié)構(gòu)中實(shí)現(xiàn)的安全策略以及處理故障的策略。圖4顯示了處理相關(guān)的故障的典型策略。故障容錯(cuò)策略的命名為T1、T4、T5、T8、T9。T1是高度數(shù)據(jù)冗余策略，主要指從兩個(gè)不同的Alti接收到的高度數(shù)據(jù)。運(yùn)用策略T1，處理從F1到F8故障。T5顯示高度數(shù)據(jù)冗余策略。高度數(shù)據(jù)顯示在兩個(gè)不同的顯示系統(tǒng)上。策略T5處理F9、F10故障。T4是高度數(shù)據(jù)預(yù)警的策略，包括：一個(gè)高度警告時(shí)產(chǎn)生的有兩個(gè)高度值；從兩個(gè)不同的高度計(jì)接收之間的差異；或當(dāng)海拔數(shù)據(jù)是從唯一的高度計(jì)接收，或當(dāng)海拔數(shù)據(jù)不能從高度計(jì)接收時(shí)(不同的警告產(chǎn)生區(qū)分這些情況)。運(yùn)用策略T4，處理從F1到F8故障。T8是N恢復(fù)策略，主要指當(dāng)N故障時(shí)，重新恢復(fù)。策略T8處理F11、F12和F13故障。T9是G恢復(fù)策略，主要指當(dāng)一個(gè)G故障時(shí)，重新恢復(fù)。策略T9處理F14、F15故障。

命名為T2、T3、T6和T7的策略是故障檢測策略。T2是一個(gè)比較策略，比較來自兩個(gè)不同的測高設(shè)備接收的高度值并檢測是否有差別。策略T2處理從F5到F8故障。T3是一個(gè)比較策略，它將接收的高度值，其最大值和最小值來檢測范圍的高度值。運(yùn)用策略的T3處理從F5到F8的故障。T6是一種監(jiān)測策略，監(jiān)控G管理的失敗。策略T6處理F14、F15故障。T7是一個(gè)監(jiān)控策略，監(jiān)控N管理的失敗。策略T7處理F11、F12和F13故障。

4.3　安全關(guān)鍵視圖

案例研究的安全關(guān)鍵視圖如圖5所示。該視圖顯示了安全關(guān)鍵類和危險(xiǎn)之間的關(guān)系的一個(gè)例子。其中，N讀取Alti1和Alti2高度數(shù)據(jù)。G1和G2從N讀取高度數(shù)據(jù)。如果N產(chǎn)生一個(gè)警告，通過命令關(guān)系通知G1和G2。如果Alti1和Alti2發(fā)生故障，則通過故障報(bào)告發(fā)送給N。NMonitor監(jiān)控Alti1，Alti2和N，當(dāng)其中一個(gè)發(fā)生故障并從故障中恢復(fù)停止/啟動/初始化失敗時(shí)，NMonitor可以檢測到故障。同樣，GMonitor監(jiān)控 G1和G2，其中一個(gè)故障并從故障中恢復(fù)停止/啟動/初始化失敗時(shí)，GMonitor就可以檢測到故障。

如從圖5可以觀察到，N是故障樹單點(diǎn)，一旦失效會造成全部系統(tǒng)出現(xiàn)問題。為解決圖5的單點(diǎn)故障，提供另一種更復(fù)雜的設(shè)計(jì)方案，如圖6所示，其中冗余技術(shù)是通過定義兩個(gè)N1，N2；NMonitor控制N1和N2；引入叫AltiMonitor的新監(jiān)控控制Alti1和Alti2。引入的兩個(gè)新的策略監(jiān)控，稱為高度健康檢查(T10)和高度恢復(fù)(T11)。通過對N的冗余策略，解決了故障問題的單點(diǎn)問題。本設(shè)計(jì)提高了系統(tǒng)的安全性。同時(shí)，新的監(jiān)控和管理器還增加了相關(guān)模塊之間的關(guān)系，提高系統(tǒng)的性能。

5　結(jié)論

本文針對現(xiàn)有的方法不直接專注于軟件安全問題的體系結(jié)構(gòu)建模的缺陷，采用視圖的方法設(shè)計(jì)安全關(guān)鍵系統(tǒng)解決安全問題。為了這個(gè)目的，提出了基于一個(gè)元建模方法的軟件安全的體系結(jié)構(gòu)框架，明確地解決了安全問題。這一方法為安全關(guān)鍵系統(tǒng)的詳細(xì)設(shè)計(jì)提供了分析和支持的基礎(chǔ)。

參考文獻(xiàn)：

[1]HAVVA GULAY GURBUZ.Architecture framework for software safety[J].SAM,2014,LNCS 8769： 64-79.

[2]洪亮,張福光.軍用軟件全面質(zhì)量管理[J].四川兵工學(xué)報(bào),2009(6):47-48.

[3]谷青范,張麗花,等.綜合化航空電子系統(tǒng)安全性研究[J].第六屆中國航空學(xué)會青年科技論壇,2014:1366-1371.

[4]STOREY N R.Safety critical computer system[M].Boston:Addison-Wesley Longman publishing Co.,Inc.,1996.

[5]李學(xué)仁.軍用軟件質(zhì)量管理學(xué)[M].北京：國防工業(yè)出版社,2012.

[6]徐文華,張育平.基于航電系統(tǒng)架構(gòu)模型的安全性分析工具的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)科學(xué),2016,43(11A):527-538.

[7]王維鋒,孫敬德,肖慶.一種基于構(gòu)件的軍用軟件故障診斷方法[J].四川兵工學(xué)報(bào),2014(5):102-105.

[8]王威華，王小潔，冷泳林，等.一種基于軟件定義的彈性網(wǎng)絡(luò)資源分配方案[J].重慶理工大學(xué)學(xué)報(bào)(自然科學(xué))，2017(7):145-150.

[9]LEVESON N G.Safeware:System Safety and Computers[M].New York:Addison-Wesley,1995.

[10] CLEMENTS P,BACHMANN F,BASS L.Documenting software architectures:Views and beyond[M].Boston:Addison-Wesley,2003.

[11] KAISER B,GRAMLICH C,FORSTER M.State-event-fault-trees-a safety analysis model for software controlled systems[M].Reliability Engineering & System Safety,Berlin:Springer Berlin Heidelberg,2004,LNCS 3219:195-209.

[12] 杜軼焜，何福，陸柏村，等. 基于VCCP的QR碼安全認(rèn)證方案[J].兵工自動化，2017(6):24-27.