安全關(guān)鍵軟件的需求遞階層次結(jié)構(gòu)

郭 蕾， 褚文奎， 田 松， 張鳳鳴

(1.空軍裝備研究院航空研究所，北京 100076;2.空軍工程大學工程學院，西安 710038)

0 引言

美國宇航局在標準 NASA-STD-8719.13B［1］中將“直接指揮、控制關(guān)鍵硬件或危險源”以及“監(jiān)視關(guān)鍵硬件或危險源的狀態(tài)”的軟件稱為安全關(guān)鍵軟件(Safety Critical Software，SCS)。這類軟件一旦故障或失效，將導致生命、財產(chǎn)或環(huán)境等方面難以承受的災(zāi)難性后果。

文獻［2］分析了20世紀90年代發(fā)生的5起航天器事故，結(jié)論歸咎于軟件存在安全性問題;文獻［3］對國外發(fā)生在1980～1996年間的8起災(zāi)難性事故進行分析，結(jié)果表明軟件需求缺陷是導致這些事故的主要因素;文獻［4］搜集的證據(jù)表明，單元測試發(fā)現(xiàn)的軟件缺陷和錯誤中，需求錯誤占70%;文獻［5］的研究數(shù)據(jù)表明，軟件需求缺陷導致的安全性問題已占到了60%～80%。這些數(shù)據(jù)無一例外地說明了一個事實，即需求缺陷是導致事故發(fā)生的主要根源。

采用基于模型的開發(fā)(Model-Based Development，MBD)方法［6］進行安全關(guān)鍵軟件開發(fā)時，上述結(jié)論將得到進一步印證和鞏固。在MBD方法中，引入了軟件自動編碼、自動集成、自動測試、自動配置等自動實現(xiàn)技術(shù)，這些技術(shù)的引入有效地避免了人為錯誤，同時也使得軟件工程師將工作重心由編碼實現(xiàn)轉(zhuǎn)向需求模型的構(gòu)建。隨著軟件自動實現(xiàn)技術(shù)的日益成熟，以及人們對安全問題的日益重視，安全關(guān)鍵軟件在編碼實現(xiàn)、集成測試等階段引入的足以導致危險后果的錯誤日益減少。相對應(yīng)地，因需求規(guī)約缺陷所導致的安全性問題所占比重日益上升，并逐漸占據(jù)了主導地位。從這個意義上也可以說，在MBD軟件開發(fā)方法中，軟件開發(fā)能否成功或者運行是否安全，更多地取決于軟件需求模型的構(gòu)建而不是編碼實現(xiàn)。

從需求工程視角而言，軟件需求(可視為目標)的模糊特征使其可以在不同的抽象級別上進行求精，并最終形成一個引導系統(tǒng)設(shè)計的目標結(jié)構(gòu)圖。兩種比較具有代表性的基于目標的方法是自動規(guī)約中的知識采集(Knowledge Acquisition in Automated Specification，KAOS)［7］和 非 功 能 性 需 求 框 架 (Non-Functional Requirement Framework，NFRF)［8］。

KAOS以目標結(jié)構(gòu)的形式支持需求工程。在這種目標結(jié)構(gòu)中，高級目標由目標系統(tǒng)(包括軟件系統(tǒng)及其環(huán)境)的初始文檔中析出得到，然后反復求精，直到分配到某個智能體(比如操作者、硬件設(shè)備、軟件)上。其中，目標求精通過合并自上而下的AND/OR分解模板或領(lǐng)域特定的求精模板得以實現(xiàn)。KAOS方法的缺點在于它將所有的目標都當作了硬目標，只能以形式化方式進行規(guī)約和實現(xiàn)。實際上很多質(zhì)量屬性如可靠性、安全性只能以可接受的標準(即軟目標)進行實現(xiàn)［9］。

NFRF主要用于質(zhì)量需求的表達和分析。它將非功能需求作為可能會被違反的軟目標，并認為只有通過特定的設(shè)計技術(shù)才能予以實現(xiàn)。除了質(zhì)量需求之外，該框架還將設(shè)計方案的選擇決策和背后的原理作為目標。由此，該框架提供了一個統(tǒng)一模型，能夠利用圖形結(jié)構(gòu)求精并實現(xiàn)質(zhì)量需求。NFRF的缺點一是不能提供有效的機制闡明質(zhì)量需求，二是缺乏負面需求開發(fā)方面的實踐指南［9］。

除此，美國麻省理工學院的Leveson教授帶領(lǐng)的團隊還開發(fā)了一種意圖規(guī)約［10］結(jié)構(gòu)。該結(jié)構(gòu)分為7級，每一級都從人、系統(tǒng)、環(huán)境、驗證與有效性確認(Verification and Validation，V＆V)的角度設(shè)計、管理系統(tǒng)規(guī)約，不僅說明了系統(tǒng)規(guī)約的內(nèi)容及如何規(guī)約，也說明了相應(yīng)的原因。與目標層次化分解方法不同，意圖規(guī)約的每一級并不是對上一級信息的精煉細化，而是從一個新視角重新審視系統(tǒng)，但上一級包含了對下一級的約束。

假設(shè)在安全性關(guān)鍵系統(tǒng)和安全性關(guān)鍵軟件開發(fā)過程中，已經(jīng)開發(fā)出了大量的軟件需求。本文著重探討一種有別于上述方法的新的軟件需求管理方法，避免由于軟件需求的無序性導致需求缺陷的生成。

1 層次分析法的啟示

1.1 層次分析法

層次分析法(Analytic Hierarchy Process，AHP)［11］由美國運籌學家Saaty于20世紀70年代提出，致力于利用定性與定量相結(jié)合的方式解決復雜的項目評價問題。

該方法應(yīng)用的首要一步是分解項目評價問題，按支配關(guān)系建立項目評價問題的遞階層次結(jié)構(gòu)。這種結(jié)構(gòu)一般分為3層，如圖1所示。

圖1 AHP中的遞階層次結(jié)構(gòu)示意Fig.1 Hierarchy used in AHP method

最高層表達的是分析問題的預(yù)定目標或期望實現(xiàn)的理想結(jié)果;中間層是指為實現(xiàn)目標而涉及的中間環(huán)節(jié)，包括所需考慮的準則、子準則等，可以細分為若干層;最底層表示為實現(xiàn)目標可供選擇的各種解決方案、具體措施等。

1.2 啟示

由層次分析法建立的這種遞階層次結(jié)構(gòu)明確表達了目標(包括子目標)、準則(包括子準則)、方案等各種要素之間的聯(lián)系，具有直觀清晰性。

從需求工程的視角看，如果將軟件需求不斷逐層分解為各種精細的子需求，而子需求可以通過相應(yīng)方案予以直接實現(xiàn)，那么這種遞階層次結(jié)構(gòu)將有助于合理管理軟件需求特別是安全性需求，這對于消除軟件需求缺陷大有裨益。

2 軟件需求的遞階層次結(jié)構(gòu)

2.1 聯(lián)合與匯聚支持模式

在建立軟件需求的遞階層次結(jié)構(gòu)之前，首先考慮軟件需求上下兩個層次之間的支持關(guān)系。

一項軟件需求可以在下一層次上分解為一至多項子需求。上層軟件需求是通過下層所有子需求得到滿足從而得以滿足的。如果下層子需求有任何一項得不到滿足，那么上層需求就無法得到滿足。本文將這種下層子需求支持上層需求的模式稱之為聯(lián)合支持。

實踐過程中，一項軟件需求可以由一到多種方案予以滿足。如果將這些解決方案看作是上層需求的子需求，那么這意味著上層需求可以由任一下層子需求得到滿足從而得以實現(xiàn)。本文將這種下層子需求支持上層需求的模式稱之為匯聚支持。兩種支持模式分別用如圖2所示的符號進行表示，其中，箭頭代表需求分解方向。

圖2 遞階層次結(jié)構(gòu)中的聯(lián)合和匯聚支持模式Fig.2 AND and OR support modes in hierarchy

2.2 需求遞階層次結(jié)構(gòu)

假設(shè)已經(jīng)開發(fā)出了所有軟件需求，借鑒AHP的遞階層次結(jié)構(gòu)思想以及圖2所示的符號，可以建立軟件需求的遞階層次結(jié)構(gòu)，如圖3所示。

圖3 軟件需求的遞階層次結(jié)構(gòu)示意Fig.3 Software requirement hierarchy

相關(guān)要素說明如下:

SRi，j，…，n表示遞階層次結(jié)構(gòu)中第 i/i+j/j+ … +n/n層的某項軟件需求。

SRi，j=Ri，j，k表示遞階層次結(jié)構(gòu) 中第 i/i+j/j層軟件需求SRi，j可以在第i/i+j/j+k/k層分解為m個部分，由這些部分共同構(gòu)成軟件需求SRi，j。比如對于安全性需求“構(gòu)件A和構(gòu)件B之間的交互是安全的”，可以細化求精為需求“所有的危險都已識別”和“識別的每個危險都已得到充分減輕”。

SRi，j=SRi，j，k表示遞階層次結(jié)構(gòu)中第 2 層軟件需求SRi，j可以在第3層求精為r項軟件需求的任何一項。比如，安全性需求“構(gòu)件A和構(gòu)件B之間的交互是安全的”既可以求精為“危險從不會發(fā)生”，也可以求精為“危險后果已得到充分減輕”。

下層需求得到滿足后，在“與”、“或”邏輯關(guān)系作用下，將能夠確保上層需求同樣得以滿足。

3 遞階層次結(jié)構(gòu)在軟件安全性需求管理中的應(yīng)用

3.1 危險場景與安全性需求

危險場景描述了軟構(gòu)件之間交互背離正常行為的場景，這種交互行為將實現(xiàn)非期望的結(jié)果，可以稱之為反目標。比如，戰(zhàn)機飛行員擬投射巡航導彈，卻將飛機的副油箱意外投射出去，這種異常行為將致戰(zhàn)機于無充足返航油量的危險境地。

規(guī)避反目標得以實現(xiàn)的根本措施在于消除危險場景。防止系統(tǒng)進入危險場景、導致危險后果的軟件需求即是軟件安全性需求。在軟件安全性需求的具體技術(shù)實現(xiàn)上，可以有不同的方案或措施，這些一般統(tǒng)稱為危險規(guī)避或減輕措施。

3.2 軟件安全性需求的遞階層次結(jié)構(gòu)

如果將反目標看作是頂層需求，將危險場景看作是實現(xiàn)反目標的準則，將軟件安全性需求看作是規(guī)避危險場景的準則，將危險規(guī)避或減輕措施視為規(guī)避反目標的解決方案，那么可以建立軟件安全性需求的遞階層次結(jié)構(gòu)，如圖4所示。該結(jié)構(gòu)同時也說明了軟件安全性需求與反目標、危險場景、危險規(guī)避或減輕策略之間的關(guān)系。

圖4 安全性需求與反目標之間的聯(lián)系Fig.4 Relations between safety requirements and anti-goals

相關(guān)要素解釋如下:

1)AGi，i=1，…，m，表示第 i個具有危險后果的反目標。

2)NSi，j，j=1，…，n，表示能夠?qū)崿F(xiàn) AGi的第 j個危險場景。

3)SRi，j表示由 NSi，j派生的安全性需求(當然一個危險場景可以派生多個安全性需求，圖4中僅給出一個示意)。

4)MSi，j，k，k=1，…，r，表示遵循安全性需求 SRi，j的危險規(guī)避或減輕策略。

由上述要素，給出下述條件。

條件1 任何一個風險不可接受的危險場景存在，將導致系統(tǒng)滿足具有危險后果的反目標。換言之，如果系統(tǒng)不處于任何風險不可接受的負面場景中，那么系統(tǒng)將能夠規(guī)避反目標得以實現(xiàn)的場景?？梢员磉_為

條件2 安全性需求必須有效規(guī)避危險場景的出現(xiàn)。即

?i∈［1，m］，?j∈［1，n］，即

條件3 對于每個安全性需求，至少存在一個危險規(guī)避或減輕策略可以實現(xiàn)安全性需求，即

比如，針對圖4有

推論1 如果條件1、條件2、條件3同時成立，那么實現(xiàn)所有的危險減輕策略(即 MSi，j，k，i=［1，m］，j=［1，n］，k=［1，r］)將能確保反目標 AGi不會發(fā)生。

推論1可以采用上述條件的傳遞性進行證明。

4 案例研究

懸掛物管理系統(tǒng)［12］(Stores Management System，SMS)是現(xiàn)代戰(zhàn)機遂行對空對地作戰(zhàn)任務(wù)不可或缺的重要航空電子系統(tǒng)。它的一項基本功能是發(fā)射或投放導彈、炸彈、副油箱等懸掛物，從質(zhì)量屬性的視角看應(yīng)確保這一投射功能是安全的。

如果將“安全投射懸掛物”作為一項基本的安全性需求，記為S1，1，將“戰(zhàn)機在炸彈爆炸殺傷半徑范圍內(nèi)投射炸彈”作為反目標，記為AG1，1，那么考慮兩種可能危險場景，一是戰(zhàn)機在地面滑行或靜止時意外投射懸掛物，這個后果足以對飛機和地面人員造成災(zāi)難性后果，記為NS1，1;二是戰(zhàn)機在攻擊投射炸彈時的飛行高度小于炸彈爆炸殺傷半徑，如此行為將對己方戰(zhàn)機和飛行員造成危險后果，記為NS1，2。對于這兩種場景，衍生兩項安全性需求，一是禁止戰(zhàn)機在地面投射懸掛物，記為S2，1;二是警告飛行高度過低投放懸掛物，記為S2，2。這兩項安全性需求可以初步采用下述危險減輕策略予以解決，針對S2，1，以起落架是否有載荷作為炸彈投射的使能條件，如果起落架有載荷，說明戰(zhàn)機在地面上，此時禁止投射功能，記為 MS3，1，1;針對 S2，2，如果起落架沒有載荷，此時比較飛機飛行高度和該型炸彈的爆炸殺傷半徑，若前者小于后者，予以告警，提示飛行員爬升，記為 MS3，2，1。

由上述需求分析，利用本文的需求層次化分解思想，可以建立這些需求的遞階層次結(jié)構(gòu)，如圖5所示。

圖5 安全性需求遞階層次結(jié)構(gòu)及其與反目標之間的聯(lián)系Fig.5 Safety requirements and relations to anti-goals

圖5 中:MS3，1，1SR2，1;MS3，2，1SR2，2;(SR2，1∧SR2，2)SR1，1;(MS3，1，1∧MS3，2，1)SR1，1。

5 討論

傳統(tǒng)的軟件需求多以自然語言形式進行表達，難以理清系統(tǒng)需求、軟件需求、軟構(gòu)件需求等不同層次需求之間的關(guān)系。

本文建立的軟件需求遞階層次結(jié)構(gòu)，有助于進行橫向檢查(比如圖 3 中由 SR2，2，1到 SR2，2，n)確保同一層次的軟件需求之間不相互沖突。同時這種結(jié)構(gòu)也有助于進行縱向檢查(比如圖 3 中由 SR2，1到 SR2，1，1)確保不同層次的軟件需求之間的一致性，從而維護了安全性關(guān)鍵系統(tǒng)的安全性。

由軟件需求的遞階層次結(jié)構(gòu)，能夠建立軟件需求的可達矩陣和鄰接矩陣［13］。由此，對某項軟件需求進行修改或求精時，易于觀察其影響范圍，這有助于確保軟件需求的可溯性。

在軟件需求的遞階層次結(jié)構(gòu)中，下一層次的軟件需求是對上一層次軟件需求的求精和細化，或者說下一層次軟件需求是上一層次軟件需求在遵循某些規(guī)則的前提下的具體實現(xiàn)。從軟件認證的角度看，下一層次軟件需求是上一層次軟件需求的實現(xiàn)證據(jù)，支撐了上一層次軟件需求的實現(xiàn)。由此，軟件需求的遞階層次結(jié)構(gòu)有利于支持構(gòu)建一個完整的、連貫的軟件認證案例，從而為后續(xù)認證和維護活動提供了幫助。

如果為每項軟件需求分配相應(yīng)的權(quán)重表示可信性，那么利用這種軟件需求遞階層次結(jié)構(gòu)將不僅能夠從眾多候選軟件需求以及危險減輕策略中篩選最佳的安全性需求及危險減輕策略，也能夠評估最終實現(xiàn)的安全性需求的可信性。

6 結(jié)論

采用自然語言描述的軟件需求容易導致軟件需求之間關(guān)系的不明確性、無序性。為避免由此引入軟件需求缺陷，本文提出層次化管理軟件需求的思想，建立了軟件需求的遞階層次結(jié)構(gòu)。該結(jié)構(gòu)一方面清晰明確地表達了不同層次軟件需求之間的關(guān)系，結(jié)合其他工作，這種軟件需求遞階層次結(jié)構(gòu)有助于增強軟件需求的一致性、可溯性等屬性;另一方面該結(jié)構(gòu)突出表達了軟件安全性需求及其與危險場景之間的聯(lián)系，有助于消除或降低軟件安全性需求缺陷，從而提高軟件安全性，這對于軟件需求的后期維護管理和軟件認證都有益處。

［1］National Aeronautics and Space Administration.NASA-STD-8719.13B—2004 Software safety NASA technical standard［S］.Washinton D C:National Aeronautics and Space Administration,2004.

［2］LEVESON N.The role of software in spacecraft accidents［J］.AIAA Journal of Spacecraft and Rockets,2004,41(4):1-27.

［3］楊仕平.分布式任務(wù)關(guān)鍵實時系統(tǒng)的防危(safety)技術(shù)研究［D］.成都:電子科技大學，2004.

［4］MCDERMID J A.Software safety:where's the evidence?［C］//6th Australian Workshop on Industrial Experience with Safety Critical Systems and Software(SCS 2001),Brisbane:Australian Computer Society,2001:1-6.

［5］LUTZ R R.Analyzing software requirements errors in safetycritical,embedded systems［C］//Proceedings of the International Conference on Software Requirements IEEE,1992:53-65.

［6］BIGLARI H.Past,present and future of safety-critical realtime embedded software development［M］.NEW YORK:Fairchild Control Corporation,2008.

［7］LAMSWEERDE A,DARDENNE A,FICKAS S.Goal-directed requirements acquisition［J］.Science of Computer Programming,1993，20:43-50.

［8］MYLOPOULOS J,CHUNG L.Representing and using nonfunctional requirements:a process-oriented approach［J］.IEEE Trans on Software Engineering,1992,18(6):497-499.

［9］WU W.Architectural reasoning for safety-critical software applications［D］.Heslington:University of York,2007.

［10］LEVESON N G.An approach to designing safe embedded software［M］.London:Springer Verlag,2002,LNCS 2491:15-29.

［11］汪應(yīng)洛.系統(tǒng)工程［M］.4版.北京:機械工業(yè)出版社，2008:120-130.

［12］張鳳鳴，褚文奎，樊曉光，等.綜合模塊化航空電子體系結(jié)構(gòu)研究［J］.電光與控制，2009，16(9):47-51.

［13］王映輝，張世琨，劉瑜，等.基于可達矩陣的軟件體系結(jié)構(gòu)演化波及效應(yīng)分析［J］.軟件學報，2004，15(8):1107-1115.