基于概率影響圖的軟件體系結構安全風險分析
2009-01-01 00:00:00王細娥任勝兵胡戈王國軍
計算機應用研究 2009年5期
(中南大學 信息科學與工程學院 長沙 410083)
摘 要：針對傳統安全分析方法過于復雜的問題，提出將概率影響圖引入體系結構的安全性風險分析中。該方法首先基于用例識別出系統功能故障，建立以系統安全性為目標節點的初級影響圖；再對系統功能故障進行分解，確定各構件功能故障模式，并從構件內部失效及輸入失效兩方面進行考慮；最后根據這些事件的相關性建立從系統安全風險到構件失效的概率影響圖，并開發了相應的基于概率影響圖的輔助分析工具。
關鍵詞：軟件體系結構； 安全性分析； 風險分析； 概率影響圖
中圖分類號：TP391文獻標志碼：A
文章編號：1001-3695(2009)05-1736-03
Safety risk analysis of software architecture
based on probabilistic influence diagram
WANG Xie REN Shengbing HU Ge WANG Guojun
(Academy of Information Science Engineering Central South University Changsha 410083 China)
Abstract:Aiming to the problem of complexity about traditional safety analysis techniques the paper presented a method for software architecture safety analysis based on probabilistic influence graph. First of all this method recognized system functional failure based on use cases and built a primary influence diagram regarding the system safety as the target node. Secondly confirmed the component functional failure modes with the decomposition of system functional failure and then considered them in these two aspects: internal failures and input failures of components. Finally built the probabilistic influence diagram from system safety risk to component failure according to the relationship among these events. Simultaneously it is natural to develop a assistantanalysis tool based probabilistic influence diagram.
Key words：software architecture; safety analysis; risk analysis; probabilistic influence diagram
軟件安全性（software safety）是指在軟件系統中運行而不致在系統工作中造成不可接受的風險的能力。當軟件復雜到一定程度后，其中的錯誤能夠躲過一系列的測試而在軟件系統中隱存下來，使其在某些特定的環境下運行時帶來危害[1]。為了減少因軟件失效或故障而引起的安全性事故所造成的損失，需要對軟件的安全性進行風險分析，然后在此基礎上有針對性地提出降低風險的措施。
安全性分析的經典方法主要有故障模式影響分析法（FMEA）[2]和故障樹分析法（FTA）[3]。在FMEA中，主要是分析在系統組件中出現的故障模式以及每種故障模式對整個系統的影響。而FTA方法是一種topdown方法，通過對不期望事件（系統的危險性故障，也叫頂事件）進行定性的分析，按樹狀結構，逐層細化故障；再在預測葉子節點故障發生概率的基礎上，通過邏輯關系最終得到所分析的系統故障事件的發生概率。進行故障樹分析時，需要對整個系統進行全盤考慮。這種方法很復雜，因而在分析過程中也很容易忽略某些故障而導致出錯。
基于概率影響圖在分析風險的不確定性及可視化方面的良好特性，本文將其應用到軟件安全性分析中，提出了一種基于概率影響圖的軟件體系結構的安全性風險分析方法。該方法在軟件體系結構設計階段進行，以體系結構中的用例為基礎，識別用例中的各種故障模式，并用影響圖表示出系統功能故障與系統安全性之間的關系；其次在特定系統功能故障下考慮各構件的功能，確定這些構件的各種功能故障模式，然后從各構件內部故障及其輸入偏差這方面考慮引起構件功能故障的原因，并根據它們之間的影響關系對系統功能故障進行分解，建立整個系統的概率影響圖用于安全風險分析，其邊界節點如構件內部失效事件可以由經驗數據或構件復雜性來確定其發生概率。本文同時利用所開發的工具實現了概率影響圖的建立。這樣一種結構化的方法不但可以提高分析的全面性和有效性，而且由于盡早識別了危險可以大量節省分析評估費用，更有利于開發階段的順利進行。
1 概率影響圖
影響圖是一種求解不確定性問題的工具。它的數學定義如下[4]：
定義1 一個影響圖G是由節點集合N和有向弧集合A構成的無環有向圖，G=(N，A)。節點集合劃分為機會節點集合C，決策節點集合D和價值節點V，即N=(C，D，V)，圖中每個節點i都有相應的值域Ωi及其映射，根據節點的類型分別為Πi、di、U。
定義2 僅含有機會節點和確定型節點的影響圖稱為概率影響圖。其中：代表隨機（或確定型）變量的機會節點與確定型節點間的有向弧表示可能存在的概率相關性；在每一節點上附加的數值是該節點的值和依賴前序節點可能狀態的條件概率。
概率影響圖表示它所包含變量聯合概率分布的一種可能的估計順序，利用它可進行概率推理、變量間條件獨立性判斷、條件概率引出等。
2 基于概率影響圖的安全風險分析
2.1 軟件體系結構
系統的軟件體系結構就是指由軟件構件、這些構件的外部可見屬性以及構件之間的相互關系所組成的系統結構[5]。軟件體系結構的描述方法有圖形表達工具、模塊連接語言、體系結構描述語言ADL等。為了增強安全性風險分析過程的可視化程度，本文采用統一建模語言UML對軟件體系結構進行統一建模，建立包括用例圖、類圖、順序圖等在內的模型。
從軟件體系結構的角度進行安全性風險分析有以下原因：
a）軟件體系結構設計是在早期進行的高層次抽象軟件設計。對軟件體系結構進行分析比對整個系統更容易些，同時對于獲取系統特性來說軟件體系結構也是至關重要的[6]。
b）軟件體系結構是風險承擔者進行交流的手段。它代表了系統公共的高層次抽象，因此軟件系統的各個風險承擔者如用戶、項目管理人員、開發人員等可以共同關注和協商系統的開發以滿足因需求錯誤而導致的一系列安全性問題。
2.2 系統級安全性分析
本文首先從軟件系統實現某種功能從而引發潛在的危險方面考慮，對軟件進行系統級的安全風險分析。
UML中的用例圖用于顯示若干角色以及這些角色與系統提供的用例之間的聯系關系，即站在系統外部查看系統功能。系統功能故障危險性分析可以通過考慮用例圖中的用例故障的后果來進行。
對系統功能故障的后果進行預測，即識別危險的功能故障情況，主要通過以下幾個方面考慮[7]：功能未完成、功能不按時和功能執行錯誤等。對于每一個用例確定其功能故障，每一個功能故障必須確定它所導致的系統安全性問題及安全性級別，這樣系統級的危險場景就全部識別出來了；然后以系統安全性事件為目標節點，根據系統功能故障與系統安全性之間的關系可建立初步的影響圖。
2.3 構件級安全性分析
隨著軟件體系結構模型的構建，需對功能故障進行進一步分解，分別針對以上功能故障找出引起這些事件產生的直接原因及影響，主要是從構件功能失效方面考慮。
構件在UML模型中可體現為對象圖中的對象，而UML中的順序圖反映的是若干個對象之間的動態協作關系，它可以表述系統功能故障與構件失效之間的關系。本文通過分析單一用例下的系統順序圖，分析構件的功能故障模式與系統功能故障之間的關系。
對系統功能故障進行分解之前，首先根據順序圖中各構件之間的協作關系，了解各構件的功能及與其他構件之間的依賴關系。對于功能失效分類在很多論文中都得到提及，本文主要采用Pumfrey的故障分類法從以下幾個方面進行考慮[8]：
a)功能的實現。沒有執行(omission)、錯誤執行(commission)。
b)功能實現的時間。出現時間過早(early)、出現時間過晚(late)。
c)功能實現輸出值。不正確但是可以被檢測出來(coarse incorrect)、不正確而且檢測不出來(subtle incorrect)。
本文從構件內部失效及錯誤輸入兩個方面考慮構件功能故障，且認為構件的錯誤輸入是由與該構件相連的構件失效輸出所造成的，根據它們之間的影響關系建立系統功能故障的影響圖。
2.4 概率影響圖的集成及計算
上述兩小節分別從體系結構的功能級到構件級分析了系統安全風險，并各自建立了影響圖。本節依據上述影響圖各機會節點所代表的事件之間的影響關系，為整個系統集成體系結構級的安全風險的影響圖。
為求出目標事件的概率，可以通過對影響圖進行一系列的一致性變換，不斷地修改圖形結構，實現從邊界節點的已知概率到目標事件的概率的推理過程。而對于作為邊界節點的構件內部故障事件，可參照專家意見及構件的復雜性用于度量其發生概率。下文通過一個假定的心臟起搏器的安全性分析對該方法進行了詳細的闡述。
3 實例分析
本文選擇文獻[9]中的一個假定的心臟起搏器作為實例對所提出的安全性風險分析方法進行分析。心臟起搏器是一個安全關鍵系統，設備軟件操作中的某一個錯誤就可能會導致病人的生命危險。因此，在體系結構設計階段就進行軟件安全性分析，對盡早消除心臟起搏器安全隱患與減少費用都有著重要意義。
3.1 體系結構的UML描述
統一建模語言UML是一個通用的可視化建模語言，適用于多種軟件開發方法及軟件生命周期的各個階段，本文采用UML對心臟起搏器的體系結構進行建模。
心臟起搏器是通過高能電池提供能量，以一定形式的脈沖電流刺激心臟引起心臟收縮，使其心率與排血量維持在正常范圍，是治療心動過緩等嚴重心律失常的一種設備。
圖1說明了心臟起搏器的各構件及它們之間的聯系，同時也給出了系統外部輸入/輸出接口。心臟起搏器通過編程來決定對心臟的感知或起搏，系統有以下基本對象：reed_switch(RS)，為避免編程時被電子噪聲干擾而設置的磁性開關，在編程操作前需關閉；coil_driver(CD)，向設備接收或發送脈沖，這些脈沖被數值化并組成字節向CG傳送；communication_gnome(CG)，為接收來自CD的搏動，檢驗其是否與命令相符，再送往心房或心室；ventricular_model(VT)和atrial_model(AR)為心室和心房，用于感知或起搏心臟。
一般來講，心臟起搏器可以在編程模式或其他操作模式下運行。運行編程模式是指程序員指定設備將要運行的操作模式；而操作模式主要依賴于心房(A)、心室(V)是否被感知或起搏，程序員同樣將指定起搏是否被禁止(I)、觸發(T)。例如，AVI操作模式代表由心房部分起搏心臟，心室部分感知心臟搏動，即當沒有從心室部分感知心臟搏動時起搏心房；AAI代表感知不到自身的心房搏動時起搏心房；AAT代表心房部分持續起搏；VVI代表感知不到自身的心室搏動時起搏心室；VVT代表心室部分持續起搏。每一種模式代表一個用例，則心臟起搏器的用例圖如圖2所示。
3.2 安全性風險分析
分析心臟起搏器系統的用例模型可知它包括六個用例，由于篇幅問題僅考慮心臟起搏器系統用例AVI中的安全性風險分析，其他用例可用同樣的方法進行分析。
在用例AVI中，需要執行的功能是當心室無法感知心臟跳動時則由心房起搏。由于心臟起搏器與病人的生命安全息息相關，本文首先應對心臟起搏器系統進行與病人相關的危險性識別。由2.2節考慮功能故障的方法可得到以下兩個危險性場景：S1，心室不能感知脈搏而心房也沒有起搏；S2，心房持續起搏。
參照AVI用例下的順序圖，考慮涉及到的心臟起搏器構件CG、AR、VT，為每個構件描述其所包含的功能，并根據Pumfrey的故障分類法對每個功能是否完成、完成時間、輸出是否正確這些方面的故障進行分類，并從構件內部故障和構件輸入兩方面考慮構件功能故障產生的原因。
以VT為例，在AVI用例下，VT若無法完成感知功能，或者不應期時間設置過長均有可能導致心室無法告知心房需要起搏，而產生這些的原因便是VT構件內部故障以及來自CG的輸入不正確。
依照上述各故障之間的聯系可建立影響圖，如圖3所示。
影響圖建立好之后，本文使用文獻[10]中定義的構件復雜性因子作為影響圖中的邊界節點，即構件內部故障的概率值。為了求得目標事件病人生命安全的發生概率，需對影響圖進行一系列的一致性變換，而這些圖變換過程中遵循的是文獻[4]中的約簡算法，最終使病人生命安全這個節點的風險只與構件內部故障這些已知概率的節點相關，從而由它們直接計算出目標事件的概率。本文基于Tiger工具就這些圖變換過程開發了一個編輯器，使概率影響圖的變化過程實現了半自動化的過程。至此，AVI用例下的心臟起搏器系統的安全性風險分析就完成了，其他用例下的安全性風險分析可以按照同樣的方法獲得，最終可得到整個系統完整的安全性風險分析。
4 結束語
在軟件系統設計的早期，對系統的安全性進行分析預測是十分必要的，本文提出在體系結構就進行安全性風險分析，針對大型系統的分析過于復雜的特點，提出一種從系統危險事件到構件功能故障再到構件內部失效的結構化的方法，減少分析整個系統的復雜性，而且能提高風險分析的可重用性。另外，概率影響圖可以明顯地表示變量之間的獨立關系與概率影響關系，其大小隨著問題規模呈線性增長，而且具有良好的可視化特性，基于這些傳統評估方法所不能比擬的優點，本文將概率影響圖引入安全性風險分析中，提高了分析過程的可視化程度。該方法對人為因素、硬件故障等都沒有進行考慮，需從這些方面進行改進。
參考文獻：
[1]WU Weihang KELLY T. Safety tactics for software architecture design[C]//Proc of the 28th Annual International Computer Software and Applications Conference.[S.l.]: IEEE Computer Society 2004:368-375.
[2]IEC 60812 Analysis techniques for system reliability:procedure for failure mode and effects analysis(FMEA)[S]. [S.l.]:International Electrotechnical Commission 1985.
[3]IEC 61025 Fault tree analysis (FTA)[S].[S.l.]: International Electrotechnical Commission 1990.
[4]詹原瑞. 影響圖理論方法與應用[M]. 天津：天津大學出版社 1995.
[5]BASS L CLEMENTS P KAZMAN R. Software architecture in practice[M].2nd ed.New Jersey:AddisonWesley 2003.
[6]CLEMENTS P KAZMAN R KLEIN M. Evaluating software architectures:methods and case studies[M].New Jersey: AddisonWesley 2002.
[7]WILKINSON P J KELLY T P. Functional hazard analysis for highly integrated aerospace systems[C]//Proc of IEEE Seminar on Certification of Ground/Air Systems. 1998:255-258.
[8]FENELON P MCDERMID J A PUMFREY D J et al. Towards integrated safety analysis and design[J]. ACM Applied Computing Reviews 1994，2(1):21-32.
[9]DOUGLASS B. Realtime UML: developing efficient objects for embedded systems[M].New Jersey: AddisonWesley 1998.
[10]YACOUB S M AMMAR H H. A methodology for architecturallevel reliability risk analysis[J]. IEEE Trans on Software Engineering 2002，28(6):529-547.
[11]GOSEVAPOPSTOJANOVA K HASSAN A AMMAR H et al. Architecturallevel risk analysis using UML[J]. IEEE Trans on Software Engineering，2003，29(10):946-959.
[12]OH Y J YOO J B CHA S D. Software safety analysis of function block diagrams using fault trees[J]. Reliability Engineering and System Safety 2005，88(3):215-228.
[13]LISAGOR O MCDERMID J A PUMFREY D J. Safety analysis of software architectures Lightweight PSSA[C]//Proc of the 22nd International System Safety Conference. 2004.
[14]MENS T. On the use of graph transformations for model refactoring[C]//Lecture Notes in Computer Science. Berlin: Springer 2006:219-257.
[15]PAPADOPOULOS Y MCDERMID J A. Hierarchically performed hazard origin and propagation studies[C]//Proc of the 18th International Conference on Computer Computer Safety Reliability and Security.London:SpringerVelug 1999:139-152.
[16]LISAGOR O MCDERMID J A PUMFREY D J. Towards a practicable process for automated safety analysis[EB/OL]. ftp://ftp.cs.york.ac.uk/pub/hise/Towards_a_PracticableProcess_for_Automated_Safety_Analysis.pdf.
