機載安全關(guān)鍵系統(tǒng)的安全性需求追蹤鏈建立和維護的方法
【專利摘要】本發(fā)明涉及一種機載安全關(guān)鍵系統(tǒng)的安全性需求追蹤鏈建立和維護的方法，包括：從系統(tǒng)分配到軟件時，預(yù)先定義軟件高層安全性需求模板；基于所述軟件高層安全性需求模板以及預(yù)定義的追蹤實體之間的追蹤關(guān)系，建立追蹤鏈；本發(fā)明在系統(tǒng)安全性需求分配到軟件高層安全性需求的過程中，保留了充足的信息；解決了當前軟件高層需求模板沒有對軟件安全性要素進行描述的問題；提出了建立追蹤鏈的模型，注意到了軟件不同層次(高層到低層)的需求與需求之間的追蹤關(guān)系，強調(diào)了分析過程中應(yīng)當追蹤的實體和關(guān)系；對于分析安全性需求的一致性和完整性、驗證安全性需求是否得到滿足提供了基礎(chǔ)。
【專利說明】
機載安全關(guān)鍵系統(tǒng)的安全性需求追蹤鏈建立和維護的方法
技術(shù)領(lǐng)域
[0001] 本發(fā)明設(shè)及計算機技術(shù)領(lǐng)域，尤其設(shè)及一種機載安全關(guān)鍵系統(tǒng)的安全性需求追蹤 鏈建立和維護的方法。
【背景技術(shù)】
[0002] 一般來說，軟件需求被記錄在需求規(guī)約(Requirement Specification)文檔中。需 求規(guī)約是由需求分析人員通過與用戶溝通而形成的從用戶視角說明系統(tǒng)功能和特性的文 檔。傳統(tǒng)的需求規(guī)約通常通過功能分解的方式來描述系統(tǒng)功能，即將系統(tǒng)功能自頂向下分 解，由各個模塊在細化為子模塊，進行詳細闡述，然后達到對整個系統(tǒng)的功能進行描述的目 的。
[0003] 安全性需求獲取過程：
[0004] 相關(guān)研究將軟件安全性過程分為=個階段：
[0005] (1)概念和體系結(jié)構(gòu)開發(fā)期，對飛機整體執(zhí)行飛機級功能危害分析和故障樹分析；
[0006] (2)初步設(shè)計期，執(zhí)行系統(tǒng)級功能危害分析和故障樹分析；
[0007] (3)詳細設(shè)計期，執(zhí)行項目級失效模式影響分析和故障樹分析等。
[000引通過初期功能危害分析，可W得到系統(tǒng)危害、系統(tǒng)安全性目標W及決策基本原理， 結(jié)合系統(tǒng)設(shè)計，通過系統(tǒng)安全性分析，可W得到系統(tǒng)安全性需求、系統(tǒng)失效、系統(tǒng)故障和系 統(tǒng)決策基本原理。隨著軟件開發(fā)的進行，軟件設(shè)計和軟件功能被不斷細化和實現(xiàn)，此時對應(yīng) 的安全性分析同時進行W獲得軟件安全性需求、軟件失效、軟件故障和軟件層基本決策原 理。
[0009] -些論文提出用形式化的方法對需求進行分析，如化P等人提出了用狀態(tài)圖W及 0化約束、圖形轉(zhuǎn)移法、可達性分析等一系列的限制對安全性需求進行描述。一些論文圍繞 了安全性需求描述方法開展研究，例如基于場景的安全性需求描述方法，該方法定義了一 種圖形化描述語言PSCXproperty sequence chads)來描述部件的線性時序邏輯特性;面 向目標的安全性規(guī)約W方法采用面向目標的方法來識別并說明安全性需求系統(tǒng)風(fēng)險，獲取 安全性目標，進而獲得安全性需求;分級的安全性需求描述方法W對不同的安全性需求的 重要性進行了區(qū)分;基于狀態(tài)機的安全性需求描述方法使用形式語言和狀態(tài)機來描述系統(tǒng) 的行為，通過添加安全性約束來描述系統(tǒng)的安全性需求。面向目標的需求描述方法，該方法 通過將人的意圖描述為目標，并細化目標描述需求，應(yīng)用于一個安全關(guān)鍵軟件一一某機器 人軟件控制系統(tǒng)中。RUCM(Res1:;ricted Use化36 Modeling)是來自挪威Simula研究所的研 究員岳濤博±提出的一種受約束的用例建模方法，北航的張弓在RUCM基礎(chǔ)上，添加了描述 實時性需求的概念和建模元素，吳雪WRUCM建模方法為基礎(chǔ)，通過擴展用例規(guī)約模板和限 制規(guī)則，添加故障描述模板W及數(shù)據(jù)描述模板，設(shè)計出一種基于結(jié)構(gòu)化模板和約束規(guī)則的 安全性需求規(guī)約等。關(guān)于安全性需求描述問題，一些研究雖然對安全性需求的描述從不同 角度提出了解決方案，但是仍然存在W下問題:第一，只對功能性需求進行約束，而沒有考 慮到安全性需求;第二，對于安全性需求的描述提出了研究，缺少軟件安全性相關(guān)標準中提 到的故障檢測、故障應(yīng)對等安全特性和前述安全性分析模型中關(guān)注的關(guān)鍵信息缺少明確對 應(yīng)的描述;第=，形式化的描述方式可W精確的描述需求并支持自動化驗證，但其易理解性 不強，普通需求分析人員和開發(fā)人員難W熟練掌握和應(yīng)用;第四，基于RUCM的半形式化的描 述方法，針對低層安全性需求的描述做出了較為完善的描述但是不適用于高層安全性需 求。
[0010] 關(guān)于追蹤關(guān)系的建立和維護，Ramesh和化rke調(diào)研了高端用戶和低端用戶的追蹤 性需求。低端用戶的任務(wù)是需求分解、分配、一致性檢驗和變更控制，因此他們對需求追蹤 的定義是由需求轉(zhuǎn)換到設(shè)計的文檔實體。高端用戶則要求覆蓋所有用戶，關(guān)屯、的是自決策 W及基本原理，因此他們對追蹤性的定義是能夠增加系統(tǒng)滿足客戶需求的能力。該研究關(guān) 注需求、設(shè)計、決策基本原理、驗證規(guī)則，并采用引用模型建立追蹤性模型。但是該項研究針 對的是一般性系統(tǒng)而非安全性系統(tǒng)中的追蹤性，因此未考慮性分析過程中的特殊實體等因 素。Katta基于化padopoulos and McDermid提出的系統(tǒng)開發(fā)、評估、認證通過過程和 IEC61508標準，建立了開發(fā)過程和分析過程的追蹤概念模型，并依據(jù)概念模型提出了一種 追蹤方法SaTr Ap Jatta等提出的概念模型涵蓋了系統(tǒng)安全性分析的全過程，但是未能考慮 軟件安全性到系統(tǒng)安全性的追蹤。此外，SaTrAp方法目前也僅僅考慮了系統(tǒng)安全性分析的 部分。Lee和化ward等人提出的SpecTRM方法分析了人員活動、系統(tǒng)安全性相關(guān)活動、系統(tǒng)開 發(fā)過程S類活動的關(guān)系。并使用了Intent Specification方法記錄了開發(fā)過程中的各種信 息，強調(diào)設(shè)計原因、假設(shè)記錄W及建立追蹤關(guān)系。該研究針對的是系統(tǒng)的整個開發(fā)過程，它 的不足是僅僅提供了一系列分析方法，并沒有強調(diào)在分析過程中應(yīng)當追蹤的實體和關(guān)系。 有技術(shù)人員經(jīng)過調(diào)研安全關(guān)鍵系統(tǒng)的追蹤鏈建立方法，認識到之前的研究常常忽略軟件失 效到系統(tǒng)危害的逆向追蹤和一些重要數(shù)據(jù)，人員、假設(shè)等，提出就此了構(gòu)建追蹤方法的一般 過程，并依據(jù)安全性標準，描述系統(tǒng)和軟件安全性分析過程，W系統(tǒng)危害分析為基礎(chǔ)，構(gòu)建 了安全性追蹤模型，并且分析了其中的重要的實體和關(guān)聯(lián)，完成了系統(tǒng)層到軟件層的安全 性需求獲取和追蹤鏈建立，但是她沒有提出軟件高層安全性需求到軟件低層安全性需求的 建立方法。關(guān)于軟件需求追蹤性的研究十分豐富，然而針對安全關(guān)鍵領(lǐng)域，安全性需求的追 蹤性研究的不足有W下幾點:第一，大部分追蹤性建立都是基于功能性需求的追蹤性，一小 部分研究雖然提到了非功能性需求的追蹤，但是也是就一般系統(tǒng)而言，并沒有就安全關(guān)鍵 系統(tǒng)中，安全性需求的追蹤展開討論，因此未考慮性分析過程中的特殊實體等因素;第二， 一些研究關(guān)注了需求與設(shè)計方案之間的追蹤，并沒有關(guān)注不同類別、不同層次之間需求與 需求之間的追蹤;第=，有的研究對于所要追蹤的要素考慮的比較全面并針對了是系統(tǒng)的 整個開發(fā)過程，但是僅僅提供了一系列分析方法，并沒有強調(diào)在分析過程中應(yīng)當追蹤的實 體和關(guān)系;第四，有的研究基于系統(tǒng)安全性分析過程和軟件安全性分析過程，建立了從系統(tǒng) 危害到軟件層安全性需求的雙向追蹤鏈，并關(guān)注了追蹤的實體和關(guān)系，但是就軟件層而言， 并沒有建立不同類別和層次的軟件安全性需求之間的追蹤關(guān)系，也沒有就軟件高層安全性 需求所關(guān)注的重要信息進行關(guān)聯(lián)分析。

【發(fā)明內(nèi)容】

[0011] 鑒于上述的分析，本發(fā)明旨在提供一種機載安全關(guān)鍵系統(tǒng)的安全性需求追蹤鏈建 立和維護的方法，用W解決現(xiàn)有軟件安全性需求追蹤存的問題。
[0012] 本發(fā)明的目的主要是通過W下技術(shù)方案實現(xiàn)的：
[0013] 本發(fā)明提供了一種機載安全關(guān)鍵系統(tǒng)的安全性需求追蹤鏈建立和維護的方法，包 括：
[0014] 從系統(tǒng)分配到軟件時，預(yù)先定義軟件高層安全性需求模板；
[0015] 基于所述軟件高層安全性需求模板W及預(yù)定義的追蹤實體之間的追蹤關(guān)系，建立 追蹤鏈。
[0016] 進一步地，所述軟件高層安全性需求模板至少包括下述一項或多項安全性需求要 素：
[0017] 安全性需求描述、運行上下文、相關(guān)部件列表、依據(jù)需求所要解決的故障來源分 類、依據(jù)需求解決故障的方式分類、依據(jù)需求的屬性分類、安全性等級、危害性等級、前置條 件、后置條件、上級需求/故障、下級需求、需求與需求或者故障之間的追蹤關(guān)系、對應(yīng)的假 設(shè)表。
[0018] 進一步地，所述追蹤實體包括:系統(tǒng)級安全性需求、系統(tǒng)故障、軟件故障、軟件高層 安全性需求、軟件低層安全性需求。
[0019] 進一步地，所述追蹤實體之間的追蹤關(guān)系包括：
[0020] 分解 Decomposed、派生 Derived、對稱symmetry、解決 Solve、保障 Assure。
[0021] 進一步地，在軟件安全性需求獲取和識別的過程中，基于所述軟件高層安全性需 求模板，對追蹤實體進行整理；
[0022] 如果在需求獲取和識別的過程中，追蹤實體之間存在預(yù)定關(guān)系，則在兩個相應(yīng)實 體之間建立下述單向或雙向的追蹤關(guān)系。
[0023] 進一步地，所述預(yù)定關(guān)系為W下之一：
[0024] (1)由系統(tǒng)故障分配到軟件的高層安全性需求，建立該需求解決系統(tǒng)故障的單向 關(guān)系；
[0025] (2)如果一個軟件完整安全性需求是為了保證一個軟件功能安全性需求，建立前 者保證后者的單向關(guān)系；
[0026] (3)軟件高層安全性需求如果是由系統(tǒng)安全性需求分解下來的，建立后者分解到 前者的單向關(guān)系；
[0027] (4)軟件低層安全性需求如果是由軟件高層安全性需求分解下來的，建立后者分 解到前者的單向關(guān)系；
[0028] (5) -個軟件安全性需求是在軟件設(shè)計過程當中，根據(jù)軟件功能部件的功能的失 效新識別出來的，不能追溯到系統(tǒng)失效，則軟件安全性需求與該故障建立單向解決關(guān)系；
[0029] (6) (5)中的軟件安全性需求與對應(yīng)的功能部件建立功能部件派生該需求的單向 關(guān)系；
[0030] (7)兩個安全性需求在一個接口的兩端相互對應(yīng)，內(nèi)容基本一樣，但是是相互對稱 的，建立兩個需求對稱的雙向關(guān)系；
[0031] (8)如果一個功能部件失效，可能引發(fā)一個軟件故障，則建立功能部件到軟件的引 發(fā)關(guān)系。
[0032] 進一步地，所述方法還包括：
[0033] 當追蹤實體被修改，對相應(yīng)的追蹤鏈進行維護。
[0034] 進一步地，如果追蹤實體被修改，則需要對追蹤鏈按照W下方式進行維護：
[0035] (1)增加系統(tǒng)故障之后，應(yīng)當對系統(tǒng)故障進行故障樹和失效模式影響分析，得出它 所對應(yīng)的軟件高層安全性需求，并建立解決追蹤關(guān)系;刪除系統(tǒng)故障后，應(yīng)當刪除與其有解 決關(guān)系的軟件高層安全性需求，除非該安全性需求仍然被別的非保證關(guān)系的追蹤關(guān)系指 向；
[0036] (2)增加系統(tǒng)安全性需求后，應(yīng)當對其進行功能樹分析，得出與其對應(yīng)的軟件高層 安全行需求，與該系統(tǒng)安全性需求建立解決關(guān)系;刪除系統(tǒng)安全性需求后，應(yīng)當刪除與其有 分解關(guān)系的軟件高層安全性需求，除非該安全性需求仍然被別的非保證關(guān)系的追蹤關(guān)系指 向；
[0037] (3)增加軟件高層安全性需求后，應(yīng)當對其進行功能樹分析，得出它所對應(yīng)的較低 層軟件安全性需求，并建立分解追蹤關(guān)系;刪除軟件高層安全性需求后，應(yīng)當刪除與其有解 決關(guān)系的較低層安全性需求，除非該較低層安全性需求仍然被別的非保證關(guān)系的追蹤關(guān)系 指向；
[0038] (4)增加一個安全完整性需求后，必須要建立它與對應(yīng)的安全功能性需求之前的 保證關(guān)系;刪除一個安全完整性需求后，必須刪除與它對應(yīng)的安全功能性需求之間的保證 關(guān)系;增加一個安全功能性需求后，不一定建立安全完整性需求W及追蹤關(guān)系;刪除一個安 全功能性需求后，必須刪除與它對應(yīng)的安全功能性需求W及它們之間的保證關(guān)系；
[0039] (5)增加一個故障節(jié)點，必須要將能解決該故障的安全性需求與其建立解決關(guān)系， 如果沒有安全性需求可W解決該故障，則需要根據(jù)失效故障影響分析，識別新的安全行需 求，并與該故障建立解決關(guān)系;刪除一個故障節(jié)點，必須要按照類似于刪除系統(tǒng)故障的方法 刪除與之有解決關(guān)系的安全性需求；
[0040] (6)增加一個功能部件，必須要根據(jù)失效故障影響分析，得出故障W及安全性需 求，并且建立解決、來源關(guān)系;刪除一個功能部件，必須要刪除與之相關(guān)的軟件故障，除非該 故障還可能被其他的功能部件引發(fā)。
[0041] 本發(fā)明有益效果如下：
[0042] 在系統(tǒng)安全性需求分配到軟件高層安全性需求的過程中，保留了充足的信息；解 決了當前軟件高層需求模板沒有對軟件安全性要素進行描述的問題;提出了建立追蹤鏈的 模型，注意到了軟件不同層次(高層到低層）的需求與需求之間的追蹤關(guān)系，強調(diào)了分析過 程中應(yīng)當追蹤的實體和關(guān)系；對于分析安全性需求的一致性和完整性、驗證安全性需求是 否得到滿足提供了基礎(chǔ)。
[0043] 本發(fā)明的其他特征和優(yōu)點將在隨后的說明書中闡述，并且，部分的從說明書中變 得顯而易見，或者通過實施本發(fā)明而了解。本發(fā)明的目的和其他優(yōu)點可通過在所寫的說明 書、權(quán)利要求書、W及附圖中所特別指出的結(jié)構(gòu)來實現(xiàn)和獲得。
【附圖說明】
[0044] 附圖僅用于示出具體實施例的目的，而并不認為是對本發(fā)明的限制，在整個附圖 中，相同的參考符號表示相同的部件。
[0045] 圖1為本發(fā)明實施例所述方法的流程示意圖；
[0046] 圖2為追蹤鏈模型的示意圖。
【具體實施方式】
[0047] 本發(fā)明提出了一套描述軟件高層安全性需求并建立和維護追蹤鏈的方法，使得作 為系統(tǒng)將安全性需求分配給軟件時，系統(tǒng)層和軟件層之間橋梁的軟件高層安全性需求的信 息得W較完整而有容易理解的保存;所建立的追蹤鏈是基于運個軟件高層安全性需求，針 對安全關(guān)鍵系統(tǒng)所關(guān)注的追蹤實體之間追蹤鏈的建立和維護。
[0048] 下面結(jié)合附圖來具體描述本發(fā)明的優(yōu)選實施例，其中，附圖構(gòu)成本申請一部分，并 與本發(fā)明的實施例一起用于闡釋本發(fā)明的原理。
[0049] 如圖1所示，圖1為本發(fā)明實施例所述方法的流程示意圖，具體可W包括如下步驟：
[0050] 步驟101:從系統(tǒng)分配到軟件時，預(yù)先定義軟件高層安全性需求模板，作為抽取接 口，為軟件高層安全性需求充分保留了必要信息。
[0051] 在執(zhí)行完常規(guī)安全性需求分析和提取操作后，可W得到系統(tǒng)級的安全性需求。在 系統(tǒng)結(jié)構(gòu)設(shè)計過程中，系統(tǒng)級安全性需求會被分配給軟件、硬件等系統(tǒng)的組成部分。其中分 配給軟件的成為軟件高層安全性需求。在分配過程中，要保證軟件安全性需求充分保留了 系統(tǒng)分配下來的必要信息。因此，針對復(fù)雜的、包含人員、硬件失效和故障等復(fù)雜因素的系 統(tǒng)，提供軟件高層安全性需求模板作為抽取接口。其中，安全性需求模板所需要保留的安全 性需求要素如下：
[0化2]
[0053] 其中第一列為要素 ID,第二列為要素描述，第=列是，當運個要素是可W枚舉的時 候，其枚舉值的取值范圍。
[0054] 軟件安全性需求名稱:簡短的帶定語名詞用來形容安全性需求名稱
[0055] 安全性需求描述:一句話描述該安全性需求是什么
[0056] 安全性需求上下文:一句話描述該安全性需求發(fā)生的上下文是什么，例如系統(tǒng)當 時處于什么狀態(tài)
[0057] 相關(guān)部件:與該安全性需求相關(guān)的部件列表。包括它自身屬于哪個部件/哪個功能 模塊，W及與它交互的部件/功能模塊，及其交互的接口。此處的相關(guān)部件列表應(yīng)當為列表 ID。對于最高層的軟件安全性需求，相關(guān)部件可W包括其他軟件、硬件、操作系統(tǒng)等等。
[005引對于軟件設(shè)計過程中被分解為較低層的軟件安全性需求或是在設(shè)計過程中識別 的軟件安全性需求，相關(guān)部件就是指與它直接相關(guān)的功能部件和其他功能部件。
[0059] 相關(guān)部件列表模板：
[0060]
[0061] 需求所要解決的故障來源分類:軟件的高層安全性需求的故障來源包括，交互性 故障處理（InteractionFault),指定故障處理（AssignedFault),自身故障處理 (InteriaWault)，軟件設(shè)計過程中識別的（SwDesignDerive)。
[0062] 交互性故障處理指的是軟件在系統(tǒng)中運行時，如果與其交互的軟件或硬件發(fā)生故 障，軟件該如何應(yīng)對已減輕該故障帶來的影響。
[0063] 指定故障處理指的是一些系統(tǒng)層需求經(jīng)過劃分，并沒有某個特定的軟件/硬件的 功能應(yīng)當包含解決運個系統(tǒng)層需求的部分，因此系統(tǒng)指定給某個軟件/硬件解決
[0064] 自身故障處理指的是軟件在系統(tǒng)中運行時，需要保證自身的功能運行正確，由此 得到的安全性需求。
[0065] 依據(jù)需求解決故障的方法分類:軟件高層安全性需求處理故障的方法包括故障避 免（!^iultAvoidance)、故障檢測（I^iultDetection)、故障容錯(F'aultTolerance)。
[0066] 故障避免類安全性需求是一種防患于未然的安全措施，系統(tǒng)識別出來可能發(fā)生的 失效，然后分析其發(fā)生原因（故障），將發(fā)生條件破壞掉使其不可能發(fā)生或者降低其發(fā)生概 率的安全性策略。故障避免類的安全性需求具體可細分成多種，主要包括分區(qū)、某些特定的 安全特性、多版本不相似軟件等。
[0067] 故障檢測類安全性需求主要用來檢測故障，從而能夠在故障發(fā)生后的較短時間內(nèi) 發(fā)現(xiàn)該故障，并采取措施阻止故障引發(fā)失效。采取的措施可能是故障容錯類的，例如采用備 份繼續(xù)運行，也可能是基本的故障響應(yīng)。故障檢測類安全性需求主要通過輸出數(shù)據(jù)控制、安 全監(jiān)控、多組數(shù)據(jù)表決等方法來檢測是否出現(xiàn)故障或異常。其中安全監(jiān)控應(yīng)用比較廣泛，主 要通過檢測某安全關(guān)鍵功能是否存在可能引起失效的故障、系統(tǒng)是否處于一種安全的狀態(tài) 等方式來保障系統(tǒng)安全。檢測的功能可能通過軟件來實現(xiàn)，也可通過硬件來實現(xiàn)，也可通過 軟硬件結(jié)合來實現(xiàn)。
[0068] 故障容錯類安全性需求主要用于確保系統(tǒng)即便出現(xiàn)了特定故障或者功能失效，也 能繼續(xù)正確執(zhí)行要求的功能，確保失效安全(faU-safe)。故障容錯類需求是對可靠性要求 較高時采取的保障手段。其主要方法是對系統(tǒng)進行保護，即在某些故障被觸發(fā)(發(fā)生)后，系 統(tǒng)仍然能夠保持在安全狀態(tài)。
[0069] 依據(jù)需求的屬性分類:軟件高層安全性需求根據(jù)自身的屬性可分為軟件功能性安 全需求（Functional safety requirement) W及軟件完整性安全需求（Integrity safety requirement)
[0070] 軟件功能安全性需求需要保證一個故障得到正確的處理。
[0071] 軟件完整安全性需求需要在軟件功能安全性需求的基礎(chǔ)上保證一個故障得處理 程度達到預(yù)期標準。例如失效率、安全性等級是否滿足。
[0072] 安全性等級：安全性等級采用D0178C的分類，取值分別為1~5,分別代表災(zāi)難的、 危害的/嚴重的、較重的、較輕的和無影響的，取值越小，安全性級別越高。
[0073] 危害等級：該安全性需求所有解決的危害、故障、失效中，影響最嚴重的等級。 Catastrophic(A),Critical(B),Major(C),Minor(D),Negligible化）
[0074] 前置條件:前置條件是一個軟件高層安全性需求發(fā)生的前提，必須是一個可W判 斷True or化136的狀態(tài)
[0075] 后置條件：后置條件是一個軟件高層安全性需求滿足后的結(jié)果，必須是一個可W 判斷True or化Ise的狀態(tài)
[0076] 上級需求列表:該安全性需求需要解決的危害、故障、失效等
[0077] 下級需求列表:該安全性需求被某個設(shè)計需求所實現(xiàn)
[0078] 追蹤關(guān)系:運里的追蹤關(guān)系是指兩個軟件高層需求之間的關(guān)系，表示運個高層安 全性需求與他的直接上級需求/故障之間的關(guān)系。包括分解(decomposed)、派生(Derived)、 復(fù)制（Copy)、解決（Solve)和保障（Assure)
[0079] 對應(yīng)的假設(shè)表:此外由于安全性分析的過程非常復(fù)雜，設(shè)及的概念和方法很多，現(xiàn) 有的一些研究常常為了降低研究的復(fù)雜性，設(shè)置了某些假設(shè)，從而簡化了問題，或者只側(cè)重 于問題的某個側(cè)面，然而卻沒有記錄運些假設(shè)，并忽略其中的另外一些重要信息。因此，目 前依然缺乏一套完整有效的軟件安全性需求獲取方法，所W此處要記錄假設(shè)列表。
[0080] 步驟102:基于上述軟件高層安全性需求模板W及追蹤實體之間的追蹤關(guān)系，建立 追蹤鏈；
[0081] 本發(fā)明所關(guān)注的追蹤實體包括：
[0082] 系統(tǒng)級安全性需求、系統(tǒng)故障、軟件故障、軟件高層安全性需求、軟件低層安全性 需求。
[0083] 其中系統(tǒng)級安全性需求，使用現(xiàn)有技術(shù)中的安全性需求分析和獲取方法獲得；系 統(tǒng)和軟件故障，使用現(xiàn)有技術(shù)中的故障描述模板進行描述;軟件高層安全性需求使用W上 提出的抽取方法，從系統(tǒng)級安全性需求中抽取出必要的、完整的信息，添加在軟件高層安全 性需求描述模版中；軟件低層安全性需求使用現(xiàn)有技術(shù)中的軟件低層安全性需求描述方法 描述。
[0084] 本發(fā)明中所關(guān)注的追蹤關(guān)系包括：
[0085] 分解Decomposed:-個軟件高層安全性需求是由系統(tǒng)安全性需求或更高層的軟件 安全性需求分解下來的
[0086] 派生Derived:-個軟件高層安全性需求是在軟件設(shè)計過程當中，根據(jù)軟件功能部 件的功能、其他需求新識別出來的，不能追溯到系統(tǒng)失效
[0087] 對稱symmetry:兩個需求在一個接口的兩端相互對應(yīng)，內(nèi)容基本一樣，但是是相互 對稱的，則稱為對稱。
[0088] 解決Solve:-個軟件高層安全性需求是在軟件設(shè)計過程中為了解決某個故障而 提出的，則在運個軟件高層安全性需求和故障之間建立解決關(guān)系。
[0089] 保障Assure:用于表示一個軟件完整安全性需求和軟件功能安全性需求之間的關(guān) 系。
[0090] 引發(fā)化use:用于表示一個功能部件失效后可能引發(fā)軟件故障。
[0091] 本發(fā)明認為，追蹤實體之間通過上述追蹤關(guān)系，建立追蹤鏈的方法具體包括：
[0092] 第一步、在軟件安全性需求獲取和識別的過程中，整理上述追蹤實體(系統(tǒng)安全行 需求、系統(tǒng)故障、軟件高層安全性需求、軟件低層安全性需求、功能部件、軟件故障），并且使 用本發(fā)明中規(guī)定的模板描述軟件高層安全性需求。
[0093] 第二步、如果在需求獲取和識別的過程中，追蹤實體之間存在如下關(guān)系，則在兩個 相應(yīng)實體之間建立下述單向或雙向的追蹤關(guān)系：
[0094] (1)由系統(tǒng)故障分配到軟件的高層安全性需求，建立該需求解決系統(tǒng)故障的單向 關(guān)系。
[00M] (2)如果一個軟件完整安全性需求是為了保證一個軟件功能安全性需求，建立前 者保證后者的單向關(guān)系。
[0096] (3)軟件高層安全性需求如果是由系統(tǒng)安全性需求分解下來的，建立后者分解到 前者的單向關(guān)系。
[0097] (4)軟件低層安全性需求如果是由軟件高層安全性需求分解下來的，建立后者分 解到前者的單向關(guān)系
[0098] (5) -個軟件安全性需求是在軟件設(shè)計過程當中，根據(jù)軟件功能部件的功能的失 效新識別出來的，不能追溯到系統(tǒng)失效，則軟件安全性需求與該故障建立單向解決關(guān)系。
[0099] (6) (5)中的軟件安全性需求與對應(yīng)的功能部件建立功能部件派生該需求的單向 關(guān)系。
[0100] (7)兩個安全性需求在一個接口的兩端相互對應(yīng)，內(nèi)容基本一樣，但是是相互對稱 的，則稱為對稱(運兩個安全性需求由于在一個接口的兩端，應(yīng)當為同一層的需求），建立兩 個需求對稱的雙向關(guān)系。
[0101] (8)如果一個功能部件失效，可能引發(fā)一個軟件故障，則建立功能部件到軟件的引 發(fā)關(guān)系。
[0102] 所建立的追蹤鏈模型如圖2所示。
[0103] 步驟103:如果追蹤實體被修改，例如，當發(fā)生增加追蹤實體(系統(tǒng)故障、安全性需 求…)或刪除、修改，則需要對追蹤鏈按照W下方式進行維護：
[0104] (1)增加系統(tǒng)故障之后，應(yīng)當對系統(tǒng)故障進行故障樹和失效模式影響分析，得出它 所對應(yīng)的軟件高層安全性需求，并建立解決追蹤關(guān)系;刪除系統(tǒng)故障后，應(yīng)當刪除與其有解 決關(guān)系的軟件高層安全性需求，除非該安全性需求仍然被別的非保證關(guān)系的追蹤關(guān)系指 向。
[0105] (2)增加系統(tǒng)安全性需求后，應(yīng)當對其進行功能樹分析，得出與其對應(yīng)的軟件高層 安全行需求，與該系統(tǒng)安全性需求建立解決關(guān)系;刪除系統(tǒng)安全性需求后，應(yīng)當刪除與其有 分解關(guān)系的軟件高層安全性需求，除非該安全性需求仍然被別的非保證關(guān)系的追蹤關(guān)系指 向。
[0106] (3)增加軟件高層安全性需求后，應(yīng)當對其進行功能樹分析，得出它所對應(yīng)的較低 層軟件安全性需求，并建立分解追蹤關(guān)系;刪除軟件高層安全性需求后，應(yīng)當刪除與其有解 決關(guān)系的較低層安全性需求，除非該較低層安全性需求仍然被別的非保證關(guān)系的追蹤關(guān)系 指向。
[0107] (4)增加一個安全完整性需求后，必須要建立它與對應(yīng)的安全功能性需求之前的 保證關(guān)系;刪除一個安全完整性需求后，必須刪除與它對應(yīng)的安全功能性需求之間的保證 關(guān)系。增加一個安全功能性需求后，不一定建立安全完整性需求W及追蹤關(guān)系;刪除一個安 全功能性需求后，必須刪除與它對應(yīng)的安全功能性需求W及它們之間的保證關(guān)系。
[0108] (5)增加一個故障節(jié)點，必須要將能解決該故障的安全性需求與其建立解決關(guān)系， 如果沒有安全性需求可W解決該故障，則需要根據(jù)失效故障影響分析，識別新的安全行需 求，并與該故障建立解決關(guān)系;刪除一個故障節(jié)點，必須要按照類似于刪除系統(tǒng)故障的方法 刪除與之有解決關(guān)系的安全性需求。
[0109] (6)增加一個功能部件，必須要根據(jù)失效故障影響分析，得出故障W及安全性需 求，并且建立解決、來源關(guān)系;刪除一個功能部件，必須要刪除與之相關(guān)的軟件故障，除非該 故障還可能被其他的功能部件引發(fā)。
[0110] 綜上所述，本發(fā)明實施例提供了一種機載安全關(guān)鍵系統(tǒng)的安全性需求追蹤鏈建立 和維護的方法，具體如下技術(shù)效果：
[0111] (1)在系統(tǒng)安全性需求分配到軟件高層安全性需求的過程中，保留了充足的信息， 例如把系統(tǒng)/軟件體系結(jié)構(gòu)中的相關(guān)部件放在高層安全性需求的列表當中，為W后的增刪 改、查詢維護服務(wù)。
[0112] (2)解決了當前軟件高層需求模板沒有對軟件安全性要素進行描述的問題。本發(fā) 明中提出的模板對于軟件安全關(guān)鍵信息有明確的描述，并且權(quán)衡了易理解性和自動化驗證 的支持，可通過軟件對軟件高層安全性需求的要素進行半自動化驗證。
[0113] (3)提出了建立追蹤鏈的模型，注意到了軟件不同層次(高層到低層）的需求與需 求之間的追蹤關(guān)系，強調(diào)了分析過程中應(yīng)當追蹤的實體和關(guān)系。并且追蹤鏈關(guān)注了軟件高 層安全性需求所包含重要信息。追蹤鏈的建立過程可W編寫成工具，為安全性需求之間的 追蹤鏈建立和維護的自動化提供基本條件。
[0114] (4)對于分析安全性需求的一致性和完整性、驗證安全性需求是否得到滿足提供 了基礎(chǔ)。追蹤鏈的建立過程可W編寫成工具，自動化的建立和維護追蹤鏈。安全性需求的一 致性驗證，舉例來說，當軟件安全性需求或故障被修改時，與其相關(guān)的需求和故障是否保持 了一致?安全性需求的完整性，舉例來說，是指一個需求規(guī)范中，是否有需求或故障缺失的 問題?運些驗證都可W W本發(fā)明中的追蹤鏈為基礎(chǔ)，例如通過追蹤鏈，可W查看修改一個追 蹤實體后，哪些其他的追蹤實體可能受影響，一個追蹤關(guān)系的兩端是否有追蹤實體缺失的 問題。
[0115] 本領(lǐng)域技術(shù)人員可W理解，實現(xiàn)上述實施例方法的全部或部分流程，可W通過計 算機程序來指令相關(guān)的硬件來完成，所述的程序可存儲于計算機可讀存儲介質(zhì)中。其中，所 述計算機可讀存儲介質(zhì)為磁盤、光盤、只讀存儲記憶體或隨機存儲記憶體等。
[0116] 雖然已經(jīng)詳細說明了本發(fā)明及其優(yōu)點，但是應(yīng)當理解在不超出由所附的權(quán)利要求 所限定的本發(fā)明的精神和范圍的情況下可W進行各種改變、替代和變換。而且，本申請的范 圍不僅限于說明書所描述的過程、設(shè)備、手段、方法和步驟的具體實施例。本領(lǐng)域內(nèi)的普通 技術(shù)人員從本發(fā)明的公開內(nèi)容將容易理解，根據(jù)本發(fā)明可W使用執(zhí)行與在此所述的相應(yīng)實 施例基本相同的功能或者獲得與其基本相同的結(jié)果的、現(xiàn)有和將來要被開發(fā)的過程、設(shè)備、 手段、方法或者步驟。因此，所附的權(quán)利要求旨在它們的范圍內(nèi)包括運樣的過程、設(shè)備、手 段、方法或者步驟。
[0117] W上所述，僅為本發(fā)明較佳的【具體實施方式】，但本發(fā)明的保護范圍并不局限于此， 任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明掲露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換， 都應(yīng)涵蓋在本發(fā)明的保護范圍之內(nèi)。
【主權(quán)項】
1. 一種機載安全關(guān)鍵系統(tǒng)的安全性需求追蹤鏈建立和維護的方法，其特征在于，包括： 從系統(tǒng)分配到軟件時，預(yù)先定義軟件高層安全性需求模板； 基于所述軟件高層安全性需求模板以及預(yù)定義的追蹤實體之間的追蹤關(guān)系，建立追蹤 鏈。2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述軟件高層安全性需求模板至少包括下 述一項或多項安全性需求要素： 安全性需求描述、運行上下文、相關(guān)部件列表、依據(jù)需求所要解決的故障來源分類、依 據(jù)需求解決故障的方式分類、依據(jù)需求的屬性分類、安全性等級、危害性等級、前置條件、后 置條件、上級需求/故障、下級需求、需求與需求或者故障之間的追蹤關(guān)系、對應(yīng)的假設(shè)表。3. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述追蹤實體包括:系統(tǒng)級安全性需求、系 統(tǒng)故障、軟件故障、軟件高層安全性需求、軟件低層安全性需求。4. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述追蹤實體之間的追蹤關(guān)系包括： 分解 Decomposed、派生 Derived、對稱symmetry、解決 Solve、保障 Assure。5. 根據(jù)權(quán)利要求1所述的方法，其特征在于， 在軟件安全性需求獲取和識別的過程中，基于所述軟件高層安全性需求模板，對追蹤 實體進行整理； 如果在需求獲取和識別的過程中，追蹤實體之間存在預(yù)定關(guān)系，則在兩個相應(yīng)實體之 間建立下述單向或雙向的追蹤關(guān)系。6. 根據(jù)權(quán)利要求5所述的方法，其特征在于，所述預(yù)定關(guān)系為以下之一： (1) 由系統(tǒng)故障分配到軟件的高層安全性需求，建立該需求解決系統(tǒng)故障的單向關(guān)系； (2) 如果一個軟件完整安全性需求是為了保證一個軟件功能安全性需求，建立前者保 證后者的單向關(guān)系； (3) 軟件高層安全性需求如果是由系統(tǒng)安全性需求分解下來的，建立后者分解到前者 的單向關(guān)系； (4) 軟件低層安全性需求如果是由軟件高層安全性需求分解下來的，建立后者分解到 前者的單向關(guān)系； (5) -個軟件安全性需求是在軟件設(shè)計過程當中，根據(jù)軟件功能部件的功能的失效新 識別出來的，不能追溯到系統(tǒng)失效，則軟件安全性需求與該故障建立單向解決關(guān)系； (6) (5)中的軟件安全性需求與對應(yīng)的功能部件建立功能部件派生該需求的單向關(guān)系； (7) 兩個安全性需求在一個接口的兩端相互對應(yīng)，內(nèi)容基本一樣，但是是相互對稱的， 建立兩個需求對稱的雙向關(guān)系； (8) 如果一個功能部件失效，可能引發(fā)一個軟件故障，則建立功能部件到軟件的引發(fā)關(guān) 系。7. 根據(jù)權(quán)利要求1到6中任意一項所述的方法，其特征在于，還包括： 當追蹤實體被修改，對相應(yīng)的追蹤鏈進行維護。8. 根據(jù)權(quán)利要求7所述的方法，其特征在于，如果追蹤實體被修改，則需要對追蹤鏈按 照以下方式進行維護： (1)增加系統(tǒng)故障之后，應(yīng)當對系統(tǒng)故障進行故障樹和失效模式影響分析，得出它所對 應(yīng)的軟件高層安全性需求，并建立解決追蹤關(guān)系;刪除系統(tǒng)故障后，應(yīng)當刪除與其有解決關(guān) 系的軟件高層安全性需求，除非該安全性需求仍然被別的非保證關(guān)系的追蹤關(guān)系指向； (2) 增加系統(tǒng)安全性需求后，應(yīng)當對其進行功能樹分析，得出與其對應(yīng)的軟件高層安全 行需求，與該系統(tǒng)安全性需求建立解決關(guān)系;刪除系統(tǒng)安全性需求后，應(yīng)當刪除與其有分解 關(guān)系的軟件高層安全性需求，除非該安全性需求仍然被別的非保證關(guān)系的追蹤關(guān)系指向； (3) 增加軟件高層安全性需求后，應(yīng)當對其進行功能樹分析，得出它所對應(yīng)的較低層軟 件安全性需求，并建立分解追蹤關(guān)系;刪除軟件高層安全性需求后，應(yīng)當刪除與其有解決關(guān) 系的較低層安全性需求，除非該較低層安全性需求仍然被別的非保證關(guān)系的追蹤關(guān)系指 向； (4) 增加一個安全完整性需求后，必須要建立它與對應(yīng)的安全功能性需求之前的保證 關(guān)系;刪除一個安全完整性需求后，必須刪除與它對應(yīng)的安全功能性需求之間的保證關(guān)系； 增加一個安全功能性需求后，不一定建立安全完整性需求以及追蹤關(guān)系；刪除一個安全功 能性需求后，必須刪除與它對應(yīng)的安全功能性需求以及它們之間的保證關(guān)系； (5) 增加一個故障節(jié)點，必須要將能解決該故障的安全性需求與其建立解決關(guān)系，如果 沒有安全性需求可以解決該故障，則需要根據(jù)失效故障影響分析，識別新的安全行需求，并 與該故障建立解決關(guān)系；刪除一個故障節(jié)點，必須要按照類似于刪除系統(tǒng)故障的方法刪除 與之有解決關(guān)系的安全性需求； (6) 增加一個功能部件，必須要根據(jù)失效故障影響分析，得出故障以及安全性需求，并 且建立解決、來源關(guān)系；刪除一個功能部件，必須要刪除與之相關(guān)的軟件故障，除非該故障 還可能被其他的功能部件引發(fā)。
【文檔編號】G06F21/52GK105955719SQ201610248057
【公開日】2016年9月21日
【申請日】2016年4月20日
【發(fā)明人】劉超, 鄧明麗, 楊海燕, 吳際
【申請人】北京航空航天大學(xué)