航電控制計算機系統軟件安全性框架研究

孫　媛，趙建軍，周偉祝

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

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

1　問題描述

本文以航空電子設備控制系統軟件為研究案例，分析軟件體系結構設計對安全的需求。航空電子系統是現代化飛機的一個重要組成部分，與飛機的作戰性能密切相關[2]。一些事故報道表明：航空電子系統的故障可能會導致災難性的后果，導致生命損失。通常航空電子設備控制系統必須滿足數以百計安全需求問題。表1為航空電子設備控制系統研究案例對安全性需求的子集。

表1為可能引起危險(Hazard)的因素，而軟件的安全性關注那些導致危險條件發生的失效，以及與該類失效相關的設計缺陷和外部輸入條件[4,6]。表2列出了危險可能出現的原因、危險類型和風險。其中，HZ1到HZ4的危險類型確定為災難性的，因為這些危險的可能后果是飛機墜毀。例如，如果一個高空顯示，不是正確的值時，會影響飛行員對高度的判斷，造成與地面碰撞，導致飛機墜毀，人員傷亡，系統損耗及環境破壞。HZ5危險類型確定為可忽略不計，因為這種危險的結果僅造成地面站的通信錯誤。

表1　航空電子設備控制系統研究案例對安全性需求的子集

表2　案例研究的危險識別

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

表3　HZ1的安全需求

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

應該注意的是，現有的通用視圖，包括圖1的組件圖并沒有直接涉及到安全問題。例如，關于一個組件是否是安全關鍵的信息是不明確的；安全關鍵部件沒有體現出來；相關的策略和模式也沒有體現。在這種情況下，所有的應用知識的安全性都是隱含的，將很難建立設計決策和分析的體系結構與安全問題之間的關系。為了解決安全問題，在圖1體系結構設計的基礎上，考慮安全工程領域的指導方針和策略，重塑圖1的體系結構。

2　軟件安全性元模型

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

3　軟件安全性視角定義

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

表4　危險視圖

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

表5　安全策略視圖

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

表6　安全關鍵視圖

4　體系框架的應用

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

4.1　危險視圖

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

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

確定的危險可能產生的后果是什么？如圖3所示，墜機是HZ1的可能后果。

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

錯誤描　　述錯誤描　　述[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　安全策略視圖

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

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

4.3　安全關鍵視圖

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

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

5　結論

本文針對現有的方法不直接專注于軟件安全問題的體系結構建模的缺陷，采用視圖的方法設計安全關鍵系統解決安全問題。為了這個目的，提出了基于一個元建模方法的軟件安全的體系結構框架，明確地解決了安全問題。這一方法為安全關鍵系統的詳細設計提供了分析和支持的基礎。

參考文獻：

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

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

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

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

[5]李學仁.軍用軟件質量管理學[M].北京：國防工業出版社,2012.

[6]徐文華,張育平.基于航電系統架構模型的安全性分析工具的設計與實現[J].計算機科學,2016,43(11A):527-538.

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

[8]王威華，王小潔，冷泳林，等.一種基于軟件定義的彈性網絡資源分配方案[J].重慶理工大學學報(自然科學)，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碼安全認證方案[J].兵工自動化，2017(6):24-27.