GBT 28808-2012 軌道交通 通信、信號和處理系統(tǒng)控制和防護系統(tǒng)軟件

中華人民共和國國家質(zhì)量監(jiān)督檢驗檢疫總局I Ⅲ 1 1 2 5 5 5 5 6 6 6 7 7 7 9 9 9 98.4要求 9軟件結(jié)構(gòu) 9.3輸出文檔 1GB/T28808—2012/IEC62279:200212軟件/硬件集成 2015.2輸人文檔 20 16.3輸出文檔 21 22 22 23附錄A(規(guī)范性附錄)技術(shù)和措施的選擇準則 附錄B(資料性附錄)技術(shù)參考資料 附錄NA(資料性附錄)與規(guī)范性引用國際文件有關(guān)的我國文件 m本標準采用翻譯法等同采用IEC62279:2002《軌道交通通信、信號和處理系統(tǒng)控制和防護系第2章規(guī)范性引用文件中；——修改了IEC62279:2002中第2章的腳注1,因為IEC62278已發(fā)布；腳注1改為對ISO9000、——采用等同采用IEC62425:2007的GB/T28809—2012代替ENV5本標準確定了從最低0級到最高4級的5個軟件安全完整性等級的技術(shù)和措施。其中1級～4級指的是安全相關(guān)軟件，0級指的是非安全相關(guān)軟件。將0級包括進本標準是為了讓非安全相關(guān)系統(tǒng)軟級要求的技術(shù)和措施。在本版本中，1級和2級的技術(shù)要求相同，3級和4級的要求相同。本標準沒有軟件安全功能的分配由GB/T21562(IEC62278)和GB/T28809—2012(IEC62425:2007,本標準規(guī)定了滿足這些需求的必要措施。該過程見圖1。e)規(guī)劃、監(jiān)督和控制那些把系統(tǒng)安全需求規(guī)范變成安全性能(或安全這些原則以及相關(guān)的其他原則應正確應用。本標準規(guī)定了在每個軟件安全完整性等級下證明其VGB/T28808—2012/IEC62279:安全策略的架構(gòu)(第5章、第8章和第9章)。c)在目標硬件上集成軟件(第12章)。d)確認軟件(第13章)。證(第15章)。給出了從事軟件開發(fā)人員能力的需求(第6章)。本標準沒有強制要求使用特定的軟件開發(fā)生命周期，但是給出了推薦的生命周期和文檔集(第71軌道交通通信、信號和處理系統(tǒng)控制和防護系統(tǒng)軟件1.1本標準規(guī)定了軌道交通控制和防護設(shè)備應用中可編程電子系統(tǒng)開發(fā)所需的規(guī)程和技術(shù)要求，適用于任何有隱含安全性的領(lǐng)域。這些應用系統(tǒng)的范圍涵蓋了從安全苛求系統(tǒng)(如安全信號系統(tǒng))到非安全苛求系統(tǒng)(如管理信息系統(tǒng))。這些系統(tǒng)可能通過采用專用微處理器，可編程邏輯控制器，分布式多處理器系統(tǒng)，大規(guī)模集中處理器系統(tǒng)或者其他結(jié)構(gòu)來實現(xiàn)。1.2本標準只適用于軟件以及軟件和系統(tǒng)之間的交互作用。1.30級以上的軟件安全完整性等級用于失效可導致人員死亡后果的系統(tǒng)。然而，從經(jīng)濟或環(huán)境因素方面考慮也能采用高級別的安全完整性等級。1.4本標準適用干軌道交通控制和防護系統(tǒng)開發(fā)和實現(xiàn)中的所有軟件，包括——應用程序設(shè)計；——操作系統(tǒng)：——固件。應用程序設(shè)計包括高級程序設(shè)計，低級程字設(shè)計和專用程序設(shè)計(如可編程邏輯控制器梯形邏輯)。1.6本標準還對由應用數(shù)據(jù)配置的系統(tǒng)提出了要求。1.7本標準并不步及商務(wù)問顆言這些向題宜作為合同的基本部分提出但本標準中的所有條款在任何商務(wù)活動中都需被子細考慮。1.8本標準不是追期性的，主要應用于所的開發(fā)這下既有系統(tǒng)，僅當進行大的修改時才進行全面應2規(guī)范性引用文件下列文件對于本文件的應用是必不可少的。凡是注日期的到用文件，僅注日期的版本適用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改單)適用于本文件。GB/T28809—2012軌道交通通銷信號和處理系統(tǒng)信號用安全相關(guān)電子系統(tǒng)(IEC62425:cabulary(IEV)—Chapter191:DependabilityandqualityIEC62278軌道交通可靠性、可用性、可維修性和安全性(RAMS)規(guī)范及示例[Railwayapplica-tions—Specificationanddemonstrationofreliability,availability,maintainabilitIEC62280-1鐵路設(shè)施通信、信號和處理系統(tǒng)第1部分：在封閉的傳輸系統(tǒng)中有關(guān)通信安全(Railwayapplications—Communication,signallingandprocessingsIEC62280-2鐵路設(shè)施通信、信號和處理系統(tǒng)第2部分：在開放的傳輸系統(tǒng)中有關(guān)通信安全(Railwayapplications—Communication,signallingandprocessings2ISO9000:2000質(zhì)量管理體系基礎(chǔ)和術(shù)語(Qualitymanagementsystems—FundamentalsISO9000-3;1997)質(zhì)量管理和質(zhì)量保證標準第3部分：ISO9001:1994應用于計算機軟件開fortheapplicationofISO9001:1994tothedevelopment,supply,installationandmaintenanceofISO9001:19941質(zhì)量系統(tǒng)設(shè)計、開發(fā)、生產(chǎn)、安裝和維修中的質(zhì)量保證模型(Qualitysystems—Modelforqualityassuranceinde34GB/T28808—2012/IEC62279:2002負責證實安全相關(guān)系統(tǒng)適于工作并符合法令、規(guī)章規(guī)定的安全需求的實體。負有安全責任的軟件。從軟件構(gòu)思開始到軟件停用為業(yè)的時期內(nèi)發(fā)生的活動。典型的軟件生命周期包括需求階段、開發(fā)軟件維護softwaremaintenance在軟件被最終用戶接收后所進行的活動或話動集合，的目的在于改善、增加或組正軟件的功能。軟件安全完整性等級softwaresafetyintegrityleve一組分級數(shù)字，它確定了為將殘余軟件故障降低到一個適當水平所應采用的技術(shù)和措施。系統(tǒng)安全完整性等級sstemsatetyintegrityleya表示系統(tǒng)能滿足規(guī)定安全特性的置信度的數(shù)字能在開發(fā)過程中確定兩個或者多個產(chǎn)品之間關(guān)系的程度，尤其是那些與其仙產(chǎn)品構(gòu)成前/后代或主通過測試和分析，表明產(chǎn)品在各個方面符合規(guī)定需求的證明行為。被委派來做確認工作的人或者代理。通過測試和分析，表明系統(tǒng)生命周期各階段的輸出符合前一階段需求的一種判定行為。被委派來做驗證工作的人或代理。5GB/T28808—2012/IEC6224目標和一致性4.1在以下每項條款中，將詳細地描述其目標和要求。4.2為與本標準一致，應證明軟件滿足安全完整性等級規(guī)定的每項要求，從而表明實現(xiàn)了條款目標。4.3如果一個需求含有“達到軟件安全完整性等級的要求”的語句，則表示可用一系列的技術(shù)和措施來4.4在4..3的前提下，宜使用本標準給出的詳細表格來幫助選擇合適的技術(shù)和措施，達到軟件安全完整性等級要求。4.5如果在表格中列為極力推薦(HR)的某一技術(shù)或措施不被采用，那么軟件質(zhì)量保證計劃或軟件質(zhì)量保證計劃參考的其他文件宜詳細說明不使用該技術(shù)的理由并有相應記錄。如果使用了表格認可的技4.6如果一項表格未提及的技術(shù)或措施被建議使用，那么應論證相應技難或措施是否能有效地實現(xiàn)特定要求和整體目標，并在軟件質(zhì)量保證計劃中或其引用的其他文件中作相應的記錄。4.7應通過檢查本標準所要求的文檔、其他客觀證據(jù)、審核和見證測試來評估是否符合特殊條款的要求和表格中詳細列出的技術(shù)和措施要求。4.8本標準需要使用一組技術(shù)并正確應用它們。這些技術(shù)是表格中所要求的并在參考材料中詳細5軟件安金完整性等級定義軟件的安全完整性等級的設(shè)置?！到y(tǒng)安全需求規(guī)范；—一系統(tǒng)結(jié)構(gòu)播述——系統(tǒng)安全計劃——安全功能；——硬件可靠性需求；—-安全完整性需求。軟件安全完整性等級應達到IEC62278規(guī)定的安全完整性等級的一般流程確定。5.2.2應在系統(tǒng)中軟件應用的風險等級和系統(tǒng)安全完整性等級的基礎(chǔ)上，決定需要的軟件安全完整性5.2.3如沒有進一步防范措施，軟件安全完整性等級不應低于系統(tǒng)安全完整性等級。然而，如果有在軟件模塊失效時能避免系統(tǒng)進入不安全狀態(tài)的防護機制，則可降低模塊的軟件安全完整性等級。5.2.4應考慮可能導致以下危害后果的風險：65.2.6在軟件需求規(guī)范中應規(guī)定軟件安全完整性等級(見第8章)。如果不同的軟件組件有不同的軟6.2.6應為軟件指定獨立評估員。同時執(zhí)行6.2.10和14.4.1?！褴浖踩暾缘燃?和2:驗證員和確認員可是同一人，但他們不應又是設(shè)計者/實現(xiàn)7●軟件安全完整性等級3和4:有兩種允許的安排?！趄炞C員和確認員是同一人，但他們不應又是設(shè)計人員明。圖3和圖4給出了兩種生命周期模型的例子。8GB/T28808—2012/IEC62279:20027.2.7所有文檔內(nèi)容應以適合于操作、處理和存儲的形式來記錄。7.2.8根據(jù)軟件安全完整性等級的要求，應完成文檔交叉索引表(見表1)中所列文檔。7.2.9根據(jù)開發(fā)軟件的規(guī)模、復雜性和生命周期，需要完成的各類文件數(shù)目有所不同。對于規(guī)模較小的項目，一些文件可合并在一起(在這過程中不應丟失需要的細節(jié)),而對于大規(guī)模項目、必要時宜將所列文檔(以層次方式)再分成一些更便于管理的子文檔。由獨立團隊或?qū)嶓w完成的文檔不應合并成單一7.2.10第7章確定的各種參考文檔之間的關(guān)系可用文檔交叉素引表來定義。對于表1中“文檔”欄所列的每個文檔、從標有符號“■”的單元格對應的行和列中可找到與創(chuàng)建文檔有關(guān)的階段和條款。從標有符號“◆”的單元格對應的列中可找到應用文檔的階段。文檔的條款或?qū)ζ涠x的其他引用可在“定義出處”欄中找到。在給出條款的地方，宜核對后續(xù)條款，因為后續(xù)條款可能包含進一步信息。值得注意的是，軟件配置管理計劃需要的參考文獻列在括號內(nèi)，這是因為該條款僅參考了ISO9000:2000。表1文檔交叉索引表章條編號檔階段系統(tǒng)活水規(guī)范系統(tǒng)安全需求展范中B.2.4中B.2.1系統(tǒng)安全計劃軟件計劃“軟件質(zhì)量保征計劃軟件配置管理詐劃軟件驗證計劃軟件集成測試計劃軟件/硬件集成測試計劃軟件確認計劃軟件維護計劃數(shù)據(jù)準備計劃數(shù)據(jù)測試計劃軟件需求驗證報告989階段”軟件結(jié)構(gòu)規(guī)范軟件設(shè)計規(guī)范軟件模塊測試規(guī)范軟件模塊驗證報告軟件源代碼驗證報告軟件模塊測試報告數(shù)據(jù)測試報告軟件/硬件集成軟件確認報告評估(軟件評估報告維護8軟件需求規(guī)范8.1.1描述一個文檔。為滿足所有系統(tǒng)需求，該文檔根據(jù)軟件安全完整性等級規(guī)定了一整套的軟件需求。它是對每個軟件工程師均適用的綜合性文檔，因此軟件工程師不必再從其他文檔中了解需求。8.1.2用于描述軟件需求測試規(guī)范。8.2輸入文檔輸人文檔有：a)系統(tǒng)需求規(guī)范；b)系統(tǒng)安全需求規(guī)范；c)系統(tǒng)結(jié)構(gòu)描述；d)軟件質(zhì)量保證計劃。8.3輸出文檔輸出文檔有：——效率9.4.3軟件結(jié)構(gòu)規(guī)范應明確、評價和詳述所有硬件/軟件交互的重要性。正如IEC62278和GB/Tb)如果商業(yè)通用軟件使用于軟件安全完整性等級1或2,則它應被包含在軟件確認過程中；c)如果商業(yè)通用軟件使用于軟件安全完整性等級3或4,則應采取以下防范措施：1)商業(yè)通用軟件應進行確認測試；3)應確定一個策略來檢測商業(yè)通用軟件的失效并防護系統(tǒng)免受這些失效影響；5)應有錯誤日志并對其進行評價；6)就實用性而言，應僅使用商業(yè)通用軟件的最簡單功能。10軟件設(shè)計和實現(xiàn)使目標系統(tǒng)及其軟件易于測試a)軟件需求規(guī)范c)軟件質(zhì)量保證計劃。GB/T28808—2012/Ia)追溯到軟件結(jié)構(gòu)的軟件組件及其安全完整性等級；b)軟件組件和環(huán)境的接口；c)軟件組件間的接口；d)數(shù)據(jù)結(jié)構(gòu)；e)劃分組件需求；f)主要算法和排序；g)圖表。10.4.5軟件模塊設(shè)計規(guī)范應說明(每個模塊有一個軟件模塊設(shè)計規(guī)范):a)確定追溯到上一層次的最底層的所有組件(現(xiàn)有標準稱“組件”為“模塊”);b)與環(huán)境和其他模塊間附有詳細輸人和輸出的細化接c)模塊的安全完整性等級；d)細化的算法和數(shù)據(jù)結(jié)構(gòu)。每個軟件模塊設(shè)計規(guī)范官是自充分的，并且允許進行相應模塊的編碼。10.4.6每個軟件模塊都應是可讀的、可理解的和可測試的。10.4.7根據(jù)整個軟件生命周期內(nèi)所要求的軟件安全完整性等級，選擇一套包括設(shè)計方法、語言和編譯器的合適工具10.4.8只要適用就應使用自動測試工具和集成開發(fā)工具。工具應考慮驗證員和確認員的需求。10.4.9根據(jù)選定的軟件安全完整性等級的要求，所選程序設(shè)計語言應具有翻譯器編譯器，該翻譯器/編譯器應具備下述條件之一a)公以的國家/國際標準的認可證書b)詳述其適合用途的評估報告；c)基于冗余簽名控制的進行翻譯錯誤檢測的過程10.4.10所選語言應滿足以下要求a)所選語言應具有便于識別編程錯誤的特性；b)所選吾言應支持與設(shè)計方法相四配的特性10.4.11如果不能滿足10.4.10,那么在軟件結(jié)構(gòu)規(guī)范或軟件質(zhì)量保證計劃中應記家對更替語言的論證并詳述其用途的適用性。10.4.12制定編碼標準，并將其應用于所有軟件的開發(fā)。編碼標準應在載件質(zhì)量保證計劃中給出參考(見15.4.5)。10.4.13編碼標準應明確良好的編程習慣、排除非安全語言特性并描述編寫源代碼文檔的規(guī)程。每個程序模塊至少應在源代碼中包括但不限于以下指定的信息：推薦使用這些信息的標準形式。該標準形式對所有模塊來說宜是相同的。10.4.14軟件模塊測試；每個模塊應有作為模塊測試依據(jù)的軟件模塊測試規(guī)范。這些測試應表明每個模塊實現(xiàn)了預定的功能，軟件模塊測試規(guī)范應定義需要的測試覆蓋率。應形成軟件模塊測試報告，其中應包括以下特性：a)描述測試結(jié)果以及每個模塊是否滿足它的軟件模塊設(shè)計規(guī)范的需求；b)描述每個模塊的測試覆蓋率，以表明所有源代碼指令至少執(zhí)行一次；c)應以可審核的形式；d)測試案例和它們的結(jié)果應以機器可讀的形式記錄下來，以利于后續(xù)分析。測試應是可重復的，如果可行的話，宜以自動方式進行。GB/T28808—2012/IEC b)設(shè)計對象到實現(xiàn)對象的可追溯性。a)軟件驗證計劃GB/T28808—2012/IECGB/T28808—2012/IEC62279:11.4.16對于軟件硬件集成.見12.4.BGB/T28808—2012/Ih)軟件模塊設(shè)計規(guī)范；i)軟件模塊測試規(guī)范；j)軟件源代碼和支持文檔；k)硬件文檔。12.3輸出文檔輸出文檔包括：a)軟件/硬件集成測試計劃；b)軟件/硬件集成測試報告。12.4要求12.4.1對于安全完整性等級大于0的軟件，應在開發(fā)生命周期早期形成軟件/硬件集成測試計劃，以使集成活動能受到適當?shù)闹笇В⑦m當提供特殊的設(shè)計或其他集成需求。在開發(fā)階段(依賴于系統(tǒng)規(guī)模),計劃可劃分成許多子文檔，面且隨著硬件和軟件設(shè)計的不斷改進以及細化的集成需求逐步清晰，計劃內(nèi)容也隨之增加。12.4.2軟件/硬件集成測試計劃應對如下內(nèi)容作文字說明：a)測試案例和調(diào)試數(shù)據(jù)；b)實施的測試類型，c)測試環(huán)境，包括工具支持軟作和配置描述；d)測試準則，依此來判定測試的完整性。12.4.3軟件/硬件集成測試計劃應區(qū)分可開發(fā)者自出場地進行的活動和需要在用戶場地進行的12.4.4軟件/硬件集成測試計劃應區(qū)分以下活動：a)將軟件融入目標硬件b)系統(tǒng)集成12.4.5宜在計劃可行的第一時間內(nèi)取得軟件硬件集成測試計劃確定的工具和設(shè)備。12.4.6在軟件/硬體集成過程中，對已集成系統(tǒng)的任何修改或變更均應研究影響范目，該研究應確定所有受影響的模塊和必要的再驗證活動。12.4.7記錄測試案例及其結(jié)果，為了后續(xù)分析，最好用機器可讀形式記錄12.4.8軟件/硬件集成測試報告應按以下要求形成：a)軟件/硬件集成測試報告應表明測試結(jié)果以及是否滿足軟件/硬件渠成測試計劃的目標和準則。如果存在失效，則應記錄失效原因b)軟件/硬件集成測試報告應以能審核的形式編寫。c)記錄測試案例及其結(jié)果，為了后續(xù)分析，最好用機器可讀形式記錄。d)軟件/硬件集成測試報告應有驗證員對該報告充分性滿意的證據(jù)，該報告是依據(jù)軟件/硬件集成測試計劃而完成的測試記錄。e)軟件/硬件集成測試報告應用文件來表明所有涉及部分的標識和配置。13軟件確認分析和測試已集成系統(tǒng)，以確保其符合軟件需求規(guī)范，并注重安全完整性等級對功能和安全性的特b)靜態(tài)或/和動態(tài)技術(shù)——軟件需求規(guī)范——軟件設(shè)計規(guī)范13.4.8用于確認的計量設(shè)備應被適時地校準，用于確認的任何工具、硬件或軟件都應GB/T28808—2012/IEC614.4.1軟件安全完整性等級0;a)評估員只需要證實此軟件安全完整性等級是合適的；b)供應商和用戶可能在投標時對此軟件安全完整性等級達成一致。14.4.5評估員應評估系統(tǒng)軟件符合預期的目的，并對系統(tǒng)安全需求規(guī)范的安全性要求作出正確的14.4.11若軟件不適合預期或未達到要求的軟件安全完整性等級，那么評估員應在軟件評估報告中僅報告不符合項，不應給出技術(shù)解決方案。15軟件質(zhì)量保證15.1.1確定、監(jiān)控所有保證軟件達到要求的質(zhì)量需采取的技術(shù)和管理活動。為有效開展驗證和確認活動，需提供針對系統(tǒng)性故障所需的定性防護并形成審核記錄。15.1.2提供證據(jù)來證明以上活動已被完成。15.2輸入文檔生命周期的每個階段使用的所有文檔。15.3輸出文檔輸出文檔包括：a)軟件質(zhì)量保證計劃；b)軟件配置管理計劃所有上述計劃均在項目開始時制定，并在生命周期過程中修改。15.4.1供量商和/或開發(fā)商至少應擁有和使用一個符各18O9000系列的質(zhì)量保證體系，以支持本標15.4.2按整Iso9000-3:1907的指南，供應商和/或開發(fā)商以及客戶對于軟件開發(fā)少應執(zhí)行ISO9001:1994的相關(guān)部分。15.4.3供應商和或開發(fā)商應逐個項目策劃軟生質(zhì)量保證計劃并形成文檔以完成/15.41和15.4.215.4.4軟件質(zhì)量保證計劃應有文字來規(guī)定在整個15.4.5ISO90003:1997和本標準的所有章節(jié)(包括附錄A)中要求的活動操作和文件等均應在軟件質(zhì)量保證計劃中規(guī)定或參考，并適應特定的開發(fā)。為了確保覆蓋軟件中和選定軟件安全完整性等級有關(guān)的所有安全方面，除軟件安全完整性等級0外，在軟件質(zhì)量保證計好中至少應包括以下條款：a)生命周期模型定義每個階段定義包括：——各階段的輸入和輸出；——各階段的主要質(zhì)量活動；——對每個活動和基本任務(wù)負責的組織部門。b)需求可追溯性；c)文檔結(jié)構(gòu)可追溯性；e)系統(tǒng)集成規(guī)程；f)使用的編碼標準；g)對確認測試的評估；h)對產(chǎn)品和過程進行度量(定量測量)的定義。為了實現(xiàn)軟件產(chǎn)品度量，應參照ISO/IEC9126定義的質(zhì)量特征和評估指南。15.4.6按照ISO9000-3:1997,至少應實行配置管理。每個軟件在發(fā)布首個認可版本之前，其文檔應受配置管理的控制。在已用文檔記錄的模塊開始測試之前，軟件源代碼應受配置管理的控制。配置管理控制不允許對任何部分進行任何未經(jīng)認可的修改。在儲存、轉(zhuǎn)移、傳輸或復制過程中，應采取預防措施以防止或檢測機器可讀的代碼中出現(xiàn)的錯誤。配置管理不應局限于嚴格的產(chǎn)品開發(fā)和維護，它還應覆蓋整個生命周期中使用的環(huán)境。這一對開發(fā)的再現(xiàn)性和維護活動所必需的擴充應包括計算機配置文件、匯編、編譯、調(diào)試器以及所有其他用到的15.4.7應考察軟件驗證計劃的充分性和結(jié)果。15.4.8供應商和/或開發(fā)者應建立、用文件描述和維護對外部供應商控制的規(guī)程，其中包括：—確保外部供應商提供的軟件滿足已有需求的方法。應保證前期開發(fā)的軟件符合軟件安全完整性等級和可信性。新軟件應按供應商的軟件質(zhì)量保證計劃或與其協(xié)調(diào)一致的外部供應商的特定軟件質(zhì)量保證計劃來進行開發(fā)和維護?！_保提供給軟件外部供應商的需求是充分的、完備的。15.4.9供應醇和/或開發(fā)者應建立，用文件描述并維護問題報告和糾正行為的規(guī)程。這些規(guī)程作為質(zhì)量保證系統(tǒng)的一部分，應實施ISO9000:2000的相關(guān)部分，特別至少應覆蓋以下兒個方面：——為Ⅱ給責任管理部目反饋意見，應規(guī)定問題報告和或糾正行為所需的文檔；—規(guī)定在問題報告中收集到的信息的分析方法以判斷其原因——規(guī)定在開發(fā)階段和軟件維護過程中很告、追蹤和間題解決應遵循的措施； 規(guī)定與所要求的軟件安全完整性等級相對應的等級處理問題的預防行為； 規(guī)定有關(guān)開發(fā)和軟件維護的特定組織的職責 規(guī)定如何實施控制確保糾正行為已被采取并有效——規(guī)定使用的表格；——規(guī)定再測式、再驗證、再確認和再評估的需求在軟件集成之后正式的軟件確認開始之前的軟件生命周期中，至少應實施向題報告和糾正活動的管理，而且要覆蓋軟件維護整個階段。16軟件維護確保軟件按要求執(zhí)行，并在對軟件自身作糾正，功能增強和修改時保持軟件安全完整性等級和可信性。16.2輸入文檔所有文檔。16.3輸出文檔輸出文檔包括：a)軟件維護計劃；b)軟件修改記錄；c)軟件維護記錄。16.4.2軟件系統(tǒng)設(shè)計應考慮可維護性，特別是應遵循第10章。宜采用ISO/IEC9126要求和驗證最統(tǒng)。對于軟件安全完整性等級3或4,合同發(fā)包方應在開始任何修改工作前，判斷維護工作是主要的還是次要以及系統(tǒng)維護方法是否充分。而對于軟件安全完整性等級0、1或2,同樣的判斷應由供應商來GB/T28808—2012/IEC義一個文檔結(jié)構(gòu)。這些文檔應與17.4.1中描述的數(shù)據(jù)準備生命周期模型有關(guān)。計劃中應規(guī)定為滿足全完整性等級應來源于要求的系統(tǒng)安全完整性等級和其他人工或自動化的規(guī)程檢查每個工具輸出的所有數(shù)據(jù)和有美文檔應符合第15章的配置管理需求。配置管理記錄要列出能運行設(shè)計數(shù)應用數(shù)排配置的系統(tǒng)中使用的通用軟體的開發(fā)應遵循第1章=16章的要求，同時還厘避守以下附在軟件需求規(guī)范階段，應確定每個系統(tǒng)和子系統(tǒng)中哪些功能將使用應用數(shù)據(jù)。分配給每個4243210——4:非常高風險水平，無防護措圖1安全相關(guān)系統(tǒng)的完整性等級GB/T28808—2012/IE獲取系統(tǒng)需求規(guī)范獲取系統(tǒng)需求規(guī)范系統(tǒng)安全性需求規(guī)范、系統(tǒng)結(jié)構(gòu)描述和系繞安全計劃明確所有分配給軟件的安全性功能評審所有分配給軟件的安全性功能并決定軟件安全完整性等級形成軟件需求規(guī)范和軟件結(jié)構(gòu)規(guī)范按照軟件質(zhì)量保證計劃、軟件安全完整性等級和軟件生命周期進行設(shè)計、開發(fā)和驗證/測試軟件實施軟件確認并移交給系統(tǒng)工程師系統(tǒng)運行生命階段軟件維護圖2軟件安全路線圖編碼編碼圖3開發(fā)生命周期1GB/T28808—2012/1EC設(shè)計者/實現(xiàn)者、驗證員、確認員設(shè)計者/實現(xiàn)者驗證員、確認員評估員設(shè)計者/實現(xiàn)者驗證員確認員注=可以是同一個人：=可以是同一個公司：圖5軟件安全完整性等級和獨立性的關(guān)系書工廠確書圖6通用系統(tǒng)開發(fā)和應用開發(fā)之間的關(guān)系從第7章~第16章的每個條款都有一個相關(guān)的條款表格來說明實現(xiàn)符合的方法。其中有低等級每個軟件安全完整性等級(SWSIL)(1級～4級和非安全相關(guān)的0級)都對表格中每項技術(shù)或措施性等級3和4對于每項技術(shù)的要求也是一樣的。這些要求是：——“HR”,表示該技術(shù)或措施在該安全完整性等級下是極力推薦的。如果該技術(shù)或措施沒有使條款表格見表A.1～表A.11。表A.1生命周期和文檔(第7章)等級11.軟件計劃文檔R2.軟件需求文檔R3.軟件設(shè)計文檔5.源代碼和文檔R6.軟件測試報告7.軟件和硬件集成測8.軟件確認報告R10.軟件維護是錄RR要求：符合900i03:1997維消千對于各種獻作安全完整控等級都要形成充是的文檔。對于軟催安全完整性等圾0,最計者應選擇適當?shù)奈臋n類型。等級3等級4等級0等級1TOS、OBJ.時序邏輯VDM、Z和BRRRRRSDL,SSADM和Your-R1)軟件需求規(guī)范要求用自然語言和能表示應用的必要的數(shù)學符號來描述問題；2)本表描述了清楚而準確地定義規(guī)范的附加需求。應選擇表中一些技術(shù)米滿足使用的軟件安全完整性等級GB/T28808—2012/IEC62279:2表A.3軟件結(jié)構(gòu)(第9章)整性等級0整性等級)整性等級2整性等級31.防御性編程 RRRR3.糾錯碼一RRRRRRR7.軟件多樣化 RRR RRRRRR10.正向恢復11.重試故障保復機制RRRR12.存儲執(zhí)行實例RR13.人工智能故障糾正14.軟件動態(tài)再配置15.軟件錯誤影電分析RR16.故障樹分析RRR1)對于軟件安全完整性等級3和4,認可的技術(shù)組合如下所b)1、4和5;c)1、4和12;d)1、2和4;e)1和4和15和16之一。2)除了3、9、10、13和14外，應選擇表中一些技術(shù)以滿足軟件安全完整性等級1和2的需求；4)糾錯碼的使用應符合IEC62280-1和IEC62280-2的需求。GB/T28808—2012/IEC62279:2002表A.4軟件設(shè)計和實施(第10章)整性等級11.形式化方法，包括CCS、時序邏輯、VDM、Z和BRRR3.結(jié)構(gòu)化方法，包括JSD、SSADM和YourdonRMMMMMM7.強類型編程語言RR9.編程語言R10.語言子集11.經(jīng)認證的翻譯器R12.經(jīng)使用證明的翻譯器13.可信的/經(jīng)驗證的軟件RRRRR14.功能和黑箱測試MM15.性能測試16.接口測試17.數(shù)據(jù)記錄和分析18.模糊邏輯19.面向?qū)ο缶幊蘎RRR要求：1)應根據(jù)軟件安全完整性等級選擇合適的技術(shù)集2)在軟件安全完整性等級3或4.認可的技術(shù)集應包括1.2或3中之意見處理。GB/T28808—2012/IEC62279:20表A.5驗證和測試(第11章)整性等級0整性等級1整性等級2整性等級31.形式證明RR一RRRRRRRR7.軟件錯誤影響分析RR1)對于軟件安全完整性等級3或4,認可的技術(shù)組合應a)1和4;b)3和4;c)4、6和7。2)對于軟件安全完整性等級1或2,認可的技術(shù)應1或4.表A.6軟件/硬件集成(第12章)整性等級0整性等級1整性等級21.功能和黑箱測試RR1)對于軟件安全完整性等級0,技術(shù)1應是認可的技術(shù)；2)對于軟件安全完整性等級1、2、3或4,認可的技術(shù)組合應是1和2。表A.7軟件確認(第13章)整性等級11.概率測試RRMMMMRRRR要求；對于軟件安全完整性等級1、2、3或4.認可的技術(shù)組合應是2和3。表A.8需評估的條款需評估的條款整性等級11.軟件安全完整性等級52.人員和職責6RR3.生命周期和文檔78R5.軟件結(jié)構(gòu)9RRRRRR10.質(zhì)量保證11.維護R條日軟件安全完軟件安全完整性等級1軟件安全完軟件安全完1.檢查表RRR4.因果圖RRRRRRRRRRRRRR一RRRRRR10.可靠性方框圖 RRRR11.交付前現(xiàn)場試驗R要求：應選擇表中一些技術(shù)來滿足選用的較件安全完整性等級。參考條目整性等級1RMMMMM3.公司質(zhì)量體系MMMMMMMMMM表A.11軟件維護(第16章)參考條目整性等級1整性等級2整性等級31.影響分析RMMMM整性等級0整性等級31.存在編碼標準RRRRRRRR6.限制使用遞歸RR7.沒有無條件跳轉(zhuǎn)1)技術(shù)3、4和5作為已確認編譯器或翻譯器的一部分是可接受的：表A.13第11章和第14章參考的動態(tài)分析和測試(DT.2)整性等級11.通過邊界值分析來執(zhí)行測試案例測試案例RRRRR3.通過錯誤播種來執(zhí)行測試案例RRRRRR5.等價類和輸人分區(qū)RRRR1)測試案例分析是在子系統(tǒng)層并基于規(guī)范和/或規(guī)范和代碼進行的：2)應根據(jù)軟件安全完整性等級來選擇適當表A.14第10章、第12章、第13章和第14章參考的功能/黑箱測試(DT.3)整性等級0整性等級1整性等級21.通過因果圖來執(zhí)行測試案例RR2.原型設(shè)計/動畫RRR4.等價類和輸人分區(qū)R5.過程模擬RRRRR1)模擬的完備性依賴于軟件安全完整性等級、2)應根據(jù)軟件安全完整性登記來選擇適當表A.15第10章參考的程序語言(DT.4)整性等級1RRRRRRRRRRRRRR5.C或C++(非受限)RRRRRRRRRR9.匯編語言RRR 10.梯形圖RRRRR11.功能方框圖RRRRR12.語句列表RRRRR要求：1)當軟件安全完整性等級為3和4時，如選用1、2、3和4語言子集，則“R”改為“HR”;2)對于某些應用，可能只能選用語言7和9。當軟件安全完整性等級為3和4時，因沒有“H議為將選項升級為“R”,應有這些語言的子集和編碼標準的精確集合；3)有關(guān)評估編程語言適用性的信息，見B.62中“適用的編程語言”;4)如果某特定的語言不在表中，并不意味著被自動排除在外。但是應遵守B.62。表A.16第13章參考的建模(DT.5)整性等級11.數(shù)據(jù)流圖RRRRRRRR5.時間Petri網(wǎng)6.原型設(shè)計/動畫RRRR7.結(jié)構(gòu)圖RR要求：應根據(jù)軟件安全完整性等級選擇一個適用的技術(shù)集合。整性等級11.雪崩/過載測試RR表A.18第8章和第10章參考的半形式化方法(DT,7)整性等級0整性等級1整性等級21.邏輯/功能方框圖RRR2.順序圖RRR3.數(shù)據(jù)流圖RRRRR換圖RR5.時間Petri網(wǎng)RR6.判定表(真值表)RRR要求：應根據(jù)軟件安全完整性等級選擇一個適用整性等級11.邊界值分析RRRRRR5.錯誤推測RRRRRRRRRR9.走查、設(shè)計復審要求：應根據(jù)軟件安全完整性等級選擇一個適用的技術(shù)集合。表A.20第10章參考的模塊化方法(DT.8)整性等級11.模塊規(guī)模限制RR3.參數(shù)個數(shù)限制RRRRR單出R5.完全定義的接口MM要求：應根據(jù)軟件安全完整性等級選擇一個適用的技術(shù)集合。B.1人工智能故障糾正(供第9章參考)B.1.2描述B.2可分析的程序(供第10章參考)-—不同類型映射之間的邊界應簡單。B.2.3參考文獻[17Verification—ThePncticalProblems,B.J.T.WeNov.1987,Altmmehrem,England,EsevierApplicdScience,ISBN1-85165-167-0,1987.[2]AmEperiena?imDesigniamndValidationofSofGB/T28808—2012/IEC62279:2B.3雪崩/過載測試(供DT.6參考)為了給測試對象加上一個異常的高工作負載以便顯示測試目標可正常地承受額定的工作負荷。雪崩/應力測試可在采用各種不同的測試條件。這些試驗條件有以下幾種：——如果測試對象工作在請求模式下，則單位時間內(nèi)測試對象的請求數(shù)比正常情況下多；——如果數(shù)據(jù)庫的規(guī)模在這當中充當一個重要角色，則會比正常情況下有所增加；—有影響的裝置各自調(diào)到他們的最大速度或最低的速度；——在極端情況下，盡可能在同一時間，把所有的影響因素設(shè)置到邊界條件。在這些測試條件下可評估測試對象的時間行為。還可觀察負載變化的影響，并能檢查內(nèi)部緩沖區(qū)B.4邊界值分析(供DT.2、DT.3和DT.8參考)為了檢測發(fā)生在參數(shù)極限值或邊界值處的軟件錯誤。程序的輸入域被劃分成一定數(shù)量的輸人類，測試宜包括每個類的界限和臨界點。測試檢查規(guī)范的輸入域的邊界值與程序的是否一致。在直接和間接翻譯中使用值0經(jīng)常容易出錯，需特別留意：——以0為除數(shù)；——空的ASCII字符；——表輸入為空。通常情況下，輸人的邊界值都有相應的輸出值的范圍。設(shè)計的測試案例就宜使每個輸出在該范圍之內(nèi)。同時還需考慮，是否需要設(shè)計一個測試案例使它的輸出超出規(guī)格邊界值的。如果輸出是數(shù)據(jù)序列(例如一張打印的表),宜特別留意表的第一個和最后元素和空的列表以及只有1個或者2個元素的列表單。B.4.3參考文獻[1]TheArtofSoftwareTesting,G.Myers,Wiley&.Sons,NewYork,USA,1979.B.5反向恢復(供第9章參考)在出現(xiàn)一個或更多故障時提供正確的功能操作。GB/T28808—2012/IEC明。這個方法意味著在明確定義的檢查點頻繁保留內(nèi)部狀態(tài)。保留可以是完整方式(存儲整個數(shù)據(jù)庫B.6因果圖(供第14章和DT.3參考)結(jié)果。括延時。這些情況都可用故障樹來描述。傳播路徑可能與邏輯符號相結(jié)合，從而使圖變的更加簡潔。B.6.3參考文獻B.7經(jīng)認證的工具和經(jīng)認證的翻譯器(供第10章參考)據(jù)這些工具輸出的正確性來預設(shè)某級置信度只有編譯(翻譯)器正式經(jīng)受過檢驗規(guī)程，它們由國家的認證團體擬定。并且根據(jù)國際標準(比如Ada[1]PascalValidationSuite,UKdistributor:BSI[2]AdaValidationSuite,UKdistriburor:NationalComGB/T28808—2012/IEC62279:2B.8檢查表(供第14章和DT.8參考)為系統(tǒng)各個方面的關(guān)鍵證性評價提供促進因素而不用制定具體的要求。由執(zhí)行檢查表的人來回答一系列問題。許多問題具有普遍性，評估員對這些問題應視為最適合于正在評估的特定系統(tǒng)那樣來解釋它們。為了適應正在確認的系統(tǒng)繁多的類型，大多數(shù)檢查表包含了能適用于許多系統(tǒng)類型的一些問題。對于一個特定的系統(tǒng)需要補充一個標準的檢查表，這個表包含的問題是專門針對正在討論的系統(tǒng)的。在任何情況下，使用檢查表的關(guān)鍵取決于工程師選擇和應用檢查表的專門知識和判斷能力。工程師選擇檢查表所采取的決定和任何附加的或者多余的問題都應全部編入文檔并證明是合理的。目的是要保證能對檢查表的應用進行評審并保證使用相同的判據(jù)都能達到同樣的結(jié)果。在完成一份檢查表時，對象要盡可能簡潔。當需要擴充證明時，應通過引用附加文檔來進行這種擴潔大大簡化了獲得有關(guān)檢查表評估結(jié)果的全部結(jié)論的程序。B.8.3參考文獻[1]ProgrammableElectronieSystemninSa[2]GuidelinesfortheAssessmentoftheSafetyandReliabilityofHighputerSystem.EWICSTC7,WP489,6t[3]TheArtofSoftwareTesting.G.Myers,Wiley&.Sons,NewYork,USA,[4]IEC60880.1986.SoftwareforB.9控制流分析(供DT.8參考)為了檢測差的和潛在的有錯誤的程序結(jié)構(gòu)?？刂屏鞣治鰴z查代碼中有嫌疑沒有遵循好的編程實踐的代碼區(qū)域。按以下原則形成可分析的有——不可訪問的代碼，例如：由于無條件的跳轉(zhuǎn)導致代碼塊不可達；——尺度代碼是具有良好結(jié)構(gòu)的代碼，它的控制圖是可簡化的，它可通過連續(xù)的圖形減少規(guī)則到單個節(jié)點。而結(jié)構(gòu)差的代碼只能被簡化到由幾個點組成的結(jié)上。B.9.3參考文獻[1]RXVP80—TheVerificationandValidationGeneralResearchCorporation,Santa[2]InformationFlowandDataFlowofWhilePrograms,JTrans.OnProg.Lang.andSyst.,1985.B.10共因失效分析(供第14章參考)B.10.2描述[1]ReviewofCommonCauseFailuresReliability,WigshawLane,WA34NE,England,NCSRR27,July1981.[2]Common-ModeFailurTechnology,Vol.46,De.1979.B.11數(shù)據(jù)流分析(供DT.8參考)B.11.2描述數(shù)據(jù)流分析結(jié)合了從控制流分析中獲得的信息和代碼的不同的部分中變量的讀寫信息。分析可 有一個數(shù)據(jù)流分析的擴展稱作信息流分析，其中用數(shù)據(jù)流(程序內(nèi)和程序外)與設(shè)計意圖相比較。信息流分析中的實際數(shù)據(jù)與設(shè)計意圖的比較一般通過計算機化的工具來實現(xiàn)。理想的數(shù)據(jù)流的定義可由該工具讀出。B.11.3參考文獻.[1]RXVP80—TheVerificationandValidationSystemGeneralResearchCorporatio[2]InformationFlowandDataFlowofWhilePrograms,Trans.OnProg.Lang.andSysB.12數(shù)據(jù)流圖(供DT.5和DT.7參考)為了以圖的形式描述輸入到程序的數(shù)據(jù)流。數(shù)據(jù)流圖描述了數(shù)據(jù)輸入如何經(jīng)過轉(zhuǎn)變變成數(shù)據(jù)輸出，圖的每個階段表示一個獨立的轉(zhuǎn)換。數(shù)據(jù)流動圖由三部分組成：—帶注釋的箭頭：代表轉(zhuǎn)換中心的數(shù)據(jù)流進出，帶有注釋定義了這些數(shù)據(jù)是什么;——帶有注釋的泡：代表轉(zhuǎn)換中心，帶有注釋定義了這個轉(zhuǎn)換；——操作符(AND、XOR):這些操作符用來連接帶有注釋的箭頭。數(shù)據(jù)流動圖描述了數(shù)據(jù)輸入轉(zhuǎn)變?yōu)檩敵龅倪^程。它不包含也不宜包含控制信息或順序信息。每個泡可看成是一個單獨的黑箱，只要它的輸入正確，就把輸入轉(zhuǎn)變成相應的輸出。數(shù)據(jù)流圖最大的優(yōu)點是顯示轉(zhuǎn)換，而不需要做這個轉(zhuǎn)變是如何完成的假定。準備數(shù)據(jù)流圖需考慮系統(tǒng)輸入和相應的輸出。每一個泡代表特定的轉(zhuǎn)換——在某些方式下，輸入應與輸出不同。沒有規(guī)定如何確定圖的整體結(jié)構(gòu)的規(guī)則，因而構(gòu)建數(shù)據(jù)流圖是系統(tǒng)設(shè)計中一個創(chuàng)造性的方面。與所有設(shè)計一樣，也是提煉在每個階段中早期的嘗試從而最終生成數(shù)據(jù)流圖的迭代過程。B.12.3參考文獻[1]SoftwareEngineering,I.Sommerville,Addison-Wesley,ISBN0-201-13795-X,1982.B.13數(shù)據(jù)記錄和分析(供第10章和第16章參考)在軟件項目中為了便于驗證、確認、評估和維護較容易，軟件項目中的所有記錄數(shù)據(jù)、判斷和基本原理都編成文檔。在一個項目實施期間，保持詳細的記錄文檔。例如、工程師會被要求保留以下所有記錄：.—-各個模塊擴展的功能；——各個模塊測試的結(jié)果；——決定和對應的理論基礎(chǔ)；GB/T28808—2012/IEC6項目里程碑的成就；B.14判定表(真值表)(供第14章和DT.7參考)B.14.2描述本方法使用二維表來簡潔地描述程序中布爾變量之間的邏輯關(guān)系。B.15防御性編程(供第9章參考)B.15.2描述有防御技術(shù)的兩個重疊區(qū)域。設(shè)計的固有出錯—安全軟件可適應它本身設(shè)計上的缺陷，這些缺[1]DependabilityofCriticalComputerSystems--Parii.E.F.RedmiScience,1988.[2]DependabilityofCriticalComputersystems—PariScience,1988.[3]SofrwareEngineeringAspectsofReaCtimeProgrammingConcepts,E.SchoComputerPhysicsCommunications41,NorthHolland,Amsterdam,1986.B.16設(shè)計和編碼標準(供DT.1參考)B.16.2描述 B.17軟件多樣化(供第9章參考)在多樣化編程中，給定的一個程序規(guī)范說明將以不同的方式實現(xiàn)N次。給N個版本以相同B.17.3參考文獻[1]DependableComputing:FromConcepts[2]ATheoreticalBasisfortheAnalysisofMulti-versionSoftures,D.E.EckhardtandL.D.Lee,IEEETrans.SE-I1,No.12,1985.B.18動態(tài)再配置(供第9章參考)為保持系統(tǒng)的功能性而忽視一個內(nèi)部故障。系統(tǒng)的邏輯結(jié)構(gòu)應能被映射到系統(tǒng)可用資源的子集上。體系結(jié)構(gòu)應能檢測物理資源的失效，然后重新將邏輯結(jié)構(gòu)映射回剩下的還在起作用的受限資源上。盡管這種想法傳統(tǒng)上僅限于失效硬件單元的不重要，它也適用于有故障的軟件單元。盡管這項技術(shù)傳統(tǒng)上適用于硬件，但正在拓展它并應用到軟件上在系統(tǒng)設(shè)計的第一階段應考慮使用這項技術(shù)。B.18.3參考文獻[1]CriticalissuesintheDesignofaReconfigureableControlCoR.NaroandK.Weir,FTCS,14June[2]AssigningProcessestoProcessors:AFault-toleraC.N.Nikolaou,WatsonResearchB.19等價類和輸入分區(qū)測試(供DT,2和DT.3參考)為了使用最小量的測試數(shù)據(jù)充分測試軟件。測試數(shù)據(jù)是通過選擇輸入域的分割來獲得的，輸人域是用于訓練軟件的。B.19.2描述測試策略基于輸入的等價關(guān)系，這種關(guān)系決定了輸入域的一個分割。選擇測試案例要覆蓋所有分割子集。每個等價類都至少選用一個測試案例。輸入分割有兩種基本的可能性如下：——等價類可在規(guī)范說明中定義。規(guī)范說明的解釋可能面向輸入，例如選擇的值使用同種方式處理，也可能是面向輸出的，例如一系列值導向相同的——在等價類結(jié)果決定于程序靜態(tài)分析的情況下，等價類可在程序內(nèi)部結(jié)構(gòu)中定義。例如一系列值導向相同的執(zhí)行路徑。B.19.3參考文獻[1]TheArtofSoftwareTesting,G.Myers,Wiley&.Soms,NewYork,USA,1979.GB/T28808—2012/IEC[1]TheTechnologyofErrorCorrectingCodes,E.R.Berlekamp,Proc.oftheIEEE,65,1980.[2]AShortCourseonErrorCorrectiB.21錯誤推測(供DT.2和DT.8參考)B.23事件樹分析(供第14章參考)建立模型，以圖表形式描述事件序列在初始化事件后在系統(tǒng)中的發(fā)展，指明會有多嚴重的后果圖表頂部記錄著緊隨起始事件之后的相繼事件有關(guān)的序列條件，初始化事件B.23.3參考文獻[1]EventTreesandtheirTreatmentB.24Fagan(菲根)檢查法(供DT,8參考)B.24.3參考文獻B.25失效斷言編程(供第9章參考)為了執(zhí)行一個程序的過程中檢測軟件設(shè)計的剩余故障，從而防止系統(tǒng)安全苛求失效并持續(xù)高可靠程序設(shè)計聲明方法遵循的理念是檢驗一個先決條件(在執(zhí)行一個語句序列之前，為驗證有效性需要檢查初始條件)和一個后續(xù)條件(在執(zhí)行一個語句序列之后的結(jié)果檢查)的思想。無論是先決條件聲明<先決條件>;行動1;.行動x;聲明<后續(xù)條件>;B.25.3參考文獻[1]ADisciplineofProgramrning,E.W.Dijkstra,PrenticeHall,1976.[2]TheScienceofProgramming,D.Grie[3]SoftwareDevelopment—ARigorousApproach,C.B.26SEEA軟件錯誤影響分析(供第9章、第11章和14章參考需的確認量。分析分三個階段完成，—重要軟件模塊確認；對于每個軟件模塊，根據(jù)模塊規(guī)范說明決定軟件模塊需要的分析深度(在單指令行、指令組、模塊等水平上);●違反的安全準則：●錯誤危害程度；●建議的錯誤檢測方法；●如果檢測方法被執(zhí)行將會違反的準則；●檢測方法執(zhí)行后的殘余危害程度。B.26.3參考文獻[1]RailwayfixedequipmentaAdaptedmethodsforsoftwaresafety[2]SAFETYSYSTEMVALIDATIONwithregardtocrossaccepGB/T28808—2012/IEC62bytherailways,IRSEIntemationalTechnicalCommitteeReportNo.1.logicieldehautesécurite,P.ThireauBiarritz,France,1986.[4]SoftwarefailuresmodesandVol.R28,No.3,pages247/249,August[5]ThesoftwareerroreffectsaonSoftwareReliability,J.R.FragolaandJ.F.Spamm,paB.27故障檢測和診斷(供第9章參考)檢測一個系統(tǒng)中的故障(因為故障可能會導致失效),因此故障檢測就提供了對策的基礎(chǔ)，對策意在最小化失效后果。B.27.2描述故障檢測是檢查一個系統(tǒng)錯誤狀態(tài)的程序[正如前文的解釋，錯誤狀態(tài)是被檢查(子)系統(tǒng)中的一個故障引起的]。故障檢測的基本目標是抑制錯誤結(jié)果的影響。一個交付正確結(jié)果或者根本不交付結(jié)果故障檢測是基于冗余原理(主要用于檢測硬件故障)和相異性(軟件故障)。為決定結(jié)果的正確性需要某種表決機制。特定的適用方法就是聲明式程序設(shè)計，例如：N-版本程序設(shè)計、安全包技術(shù)、在硬件通過在不同等級[特別是物理級(溫度、電壓等)、邏輯級(檢錯編碼)、功能級(聲明)或外部級(合理性檢查)]上實現(xiàn)值域或時域檢查確定可達到故障檢測的目標。這些檢查結(jié)果可被儲存起來，并和影響復雜系統(tǒng)是由子系統(tǒng)組成的。故障檢測，診斷和補償?shù)男嗜Q于子系統(tǒng)之間交互作用的復雜度，因為復雜度影響了錯誤傳播。故障診斷隔離了可被識別的最小子系統(tǒng)。更小的子系統(tǒng)允許更細化的故障診斷(錯誤狀態(tài)的識B.28故障樹分析(供第9章和第14章參考)對會導向危害或者嚴重后果的事件或復合事件的分析提供支持。B.28.2描述從一個可能是危害或嚴重后果直接原因的事件開始(頂事件)沿著一個樹路徑實施分析。復合原因以邏輯運算符(與、或等)的形式描述。中間原因以相同方式分析，如此直到基本事件才終止分析。方法是圖形化的，采用一套標準化符號畫出故障樹。它主要是用于硬件系統(tǒng)分析，但是也有人嘗試將這種方法應用于軟件失效分析。B.28.3參考文獻[1]SystemReliabilityEngineeringMethodology:ADiscussionoftheStateofGB/T28808—2012/IEC62279:20Fusseland,J.S.Arend,NuclearSafety,20(5),1979.[2]FaultTreeHandbook,W.E.VeselyeOfficeofNuclearReactorRegulation,US.NuclearRegulatoryCommission,Washington,DC20555,1981.[3]ReliabilityTechnology,A.E.GreeneandA.J.Bourne,Wiley-InterscieB.29有限狀態(tài)機/狀態(tài)轉(zhuǎn)換圖(供DT.5和DT.7參考)定義或?qū)崿F(xiàn)一個系統(tǒng)的控制結(jié)構(gòu)。B.29.2描述將會執(zhí)行動作A并轉(zhuǎn)換到狀態(tài)S2。通過描述一個系統(tǒng)處于每種狀態(tài)中時，每個輸入導致該系統(tǒng)產(chǎn)生的動作，我們就能徹底地描述一個系統(tǒng)。產(chǎn)生的系統(tǒng)模型稱為有限狀態(tài)機(FSM)。通常它被畫成所謂的數(shù)是狀態(tài)和輸人，矩陣元包含當系統(tǒng)處于給定狀態(tài)中時，由接受輸入導致的動作和新狀態(tài)。系統(tǒng)復雜或者系統(tǒng)具有一個自然結(jié)構(gòu)的情況下，可被反映成分層有限狀態(tài)機的形式?？梢詸z驗表示成一個有限狀態(tài)機的規(guī)范或者設(shè)計的完備性(系統(tǒng)在每種狀態(tài)下對于每種輸入都有一個動作和新狀態(tài))、一致性(每個狀態(tài)/輸入對只描述一個狀態(tài)變化)和可達到性(是否通過任何輸入序列從一個狀態(tài)到達另一個狀態(tài))。它們是關(guān)鍵系統(tǒng)的重要屬性，容易開發(fā)支持這些檢查的工具。也存在用于驗證一個有限狀態(tài)機實現(xiàn)或制作一個有限狀態(tài)機模型的動畫算法，這種算法允許自動生成測試實例。B.29.3參考文獻[1]IntroductiontothetheoryofFiniteSrateMachines,A.Gil]l,McGraw-Hill,1962.B.30形式化方法(供第8章、第10章和DT.5參考)以基于數(shù)學的方法研發(fā)軟件。它包括形式化設(shè)計和形式化編碼技術(shù)。形式化方法提供了一種用于在系統(tǒng)開發(fā)規(guī)范，設(shè)計和編碼中的某些階段描述系統(tǒng)的方法。為了檢測各種類型的不一致性或者錯誤，編成的描述采用了一種數(shù)學形式并容易進行數(shù)學分析。此外，在某些情況，下還能用機器分析該描述，機器分析精確地相似于使用一個編譯器對一個源代碼程序進行語法檢查；或者為了顯示所描述的系統(tǒng)各方面的行為，在某些情況下還能把該描述制作成動畫。動畫能為系統(tǒng)滿足實際要求以及在形式上所規(guī)定的要求提供額外的置信度。形式化方法通常會提供一種符號表示法(離散數(shù)學中常用的某種形式),用來在該表示法中推導描述的一種技術(shù)，以及用來檢查各種屬性正確性描述的各種分析形式。在下面的參考中，給出了幾個形式化方法的例子。所描述的形式化方法有CCS、CSP、HOL、LO-B.30.3CCS——通信系統(tǒng)的計算CCS是一種用于描述和推理并發(fā)系統(tǒng)、交互進程的行為的方法。B.30.3.2描述與CSP相似，CCS是一種與系統(tǒng)行為相關(guān)的數(shù)學演算。系統(tǒng)以一種依次執(zhí)行的獨立程序網(wǎng)絡(luò)的形式?；蛘呤遣⑿行问浇?。進程可通過端口交互(與CSP的通道相似),交互只發(fā)生在當兩個進程就終變成一個交互進程的組合，組合的整體行為符合對整個系統(tǒng)的行為要求。生系統(tǒng)的屬性。B.30.3.3參考文獻[1]ACalculusofCommunicatingSystems,R.Milner,ReportnumberECS-LFCS-86-7,Labo-ratoryforFoundationsofComputerScience,DepartmentofComputerScience,UniversityofEdin-burgh,UK.[2]ThespecificationofComplexSystems.B.Cohen,W.T.Hawood,M.I.]ackson,Addison-B.30.4CSP——通信順序過程CSP是一種用于描述并行軟件系統(tǒng)(并行運行的通信進程系統(tǒng))的規(guī)范的一種技術(shù)?？稍试S的事件序列)提供了證明。系統(tǒng)建模為一個獨立進程的網(wǎng)絡(luò)。每個進程都以順序或者并行組合的進程形式建模。進程可通過通道通信(同步或者交換數(shù)據(jù)),并且只有當兩個進程都就緒的時候才能進行通信。事件的相關(guān)時序也能建模。CSP的理論直接應用于INMOS傳送機體系結(jié)構(gòu)中，CSP指定系統(tǒng)允許直接在傳送機網(wǎng)絡(luò)上執(zhí)行OCCAM語言。B.30.4.3參考文獻[1]CommunicatingSequentialProcesses,C.A.R.Hoare,PrenticeB.30.5HOL——高階邏輯這是一種作為硬件規(guī)范說明和驗證基礎(chǔ)的形式化語言。B.30.5.2描述HOL是指一種特殊的邏輯符號和它的機器支持系統(tǒng)，二者都是在劍橋大學計算機實驗室研發(fā)的。邏輯符號主要取自Church的類型簡單理論，機器支持系統(tǒng)是基于LCF(可算函數(shù)邏輯)系統(tǒng)。B.30.5.3參考文獻[1]HOL:AMachineOrientatedFormulationofHigherOrderofCambridgeTechnicalReport,Number-68.LOTOS是一種關(guān)于并發(fā)系統(tǒng)行為和進程行為的描述和推理方法。LOTOS(時序規(guī)范語言)基于CCS的，附加了一些源自相關(guān)的代數(shù)學如CSP和CIRCAL(電路微積分)特征。它通過結(jié)合另外一個基于抽象數(shù)據(jù)類型語言ACTONE的組件克服了CCS在數(shù)據(jù)結(jié)構(gòu)處理和值表達方面的缺點。然而，LOTOS的過程定義組件可與其他的形式一起用于描述抽象數(shù)據(jù)類型。B.30.6.3參考文獻[1]InformationProcscriptionTechniquebasedontheTemporalOrderingofObservational20,1987.在系統(tǒng)實現(xiàn)之前提供一種精確的帶有用戶反饋的系統(tǒng)規(guī)約和系統(tǒng)驗證。B.30.7.2描述OBJ是一種代數(shù)規(guī)范語言。用戶以代數(shù)表達式的形式指定需求。系統(tǒng)的行為，或構(gòu)造，特征是根據(jù)抽象數(shù)據(jù)類型(ADT)進行操作的形式說明。一個ADT像ADA包一樣，操作行為是可見的同時實現(xiàn)細節(jié)是隱藏的。每份OBJ規(guī)范說明以及相應的逐步實現(xiàn)，與其他的形式化方法都服從相同的形式驗證技術(shù)。此外，因為規(guī)范說明的構(gòu)造方面是可機器可執(zhí)行的，從規(guī)范說明本身就可直接完成系統(tǒng)確認。執(zhí)行本質(zhì)上是通過等式替換(重寫)實現(xiàn)的函數(shù)功能的評估，直到得到特定的值等式替換才會停止。這種可執(zhí)行性使得可視系統(tǒng)的最終用戶可獲得在系統(tǒng)規(guī)范說明階段就獲得最終系統(tǒng)的一個視圖，而無須熟悉底層的形式化規(guī)范說明技術(shù)。當與其他的ADT技術(shù)一起使用時，OBJ只適用于順序系統(tǒng)，或者是并發(fā)系統(tǒng)的順序方面。OBJ廣泛的應用于大小規(guī)模的工業(yè)應用中的規(guī)范說明。andJ.Tardo,specificationofReliableTechniques,N.Gehani,A.McGettrick(eds),Addison-Wesley,1985.[2]Algebraicspecificationfo[3]AnAlgebraicApproachtotheStandardizationandCetfificationGnatz,ComputerGraphicsForum2(2/3),1983.[4]DTISTARTSGuide,1987,NCB.30.8時序邏輯B.30.8.2描述B.30.8.3參考文獻[1]TemporalLogicofPrograms,8,SpringerVerlag,1987.[2]DesignforSafetyusingTemporalLogic,J.Go[3]LogicsforComputerProgrammVDM主要是用在規(guī)范說明階段但是也可用于設(shè)計和實現(xiàn)階段生[1]SoftwareDevelopment--ARigorous[2]FormalSpecificationand[3]SystematicSoftwareDevelopmentusingV[4]TheSpecficationoson-Wesley,1986.GB/T28808—2012/IEZ是一種用于順序系統(tǒng)的規(guī)范符號語言，在將一個Z規(guī)范轉(zhuǎn)化成可執(zhí)行算法的過程中，允許開發(fā)人員根據(jù)規(guī)范來證明它們正確性的一種技術(shù)。Z主要應用于規(guī)范階段但也是一種可實現(xiàn)從規(guī)范到設(shè)計、實現(xiàn)階段的方法。它最適宜于面向數(shù)據(jù)的順序系統(tǒng)。B是一種相關(guān)的方法。就像VDM,這種規(guī)范技術(shù)建模于系統(tǒng)狀態(tài)以集合理論結(jié)構(gòu)建模，常量(謂詞)定義在結(jié)構(gòu)上，對于狀態(tài)的操作的方式是以系統(tǒng)狀態(tài)形式說明它們的前提和后置條件?？勺C實操作保留了系統(tǒng)常量因此證實了它們的一致性。規(guī)范的形式化部分被分成計劃形式，計劃允許通過精煉構(gòu)架規(guī)范。Z的規(guī)格是一種典型的形式化Z和基于自然語言的非形式化解釋文本的混合體。與VDM不同，乙是一種符號而不是一種完整的方法。但是一種相關(guān)的方法(稱之B)已經(jīng)發(fā)展成可和Z聯(lián)合使用。B方法是基于逐步求精的原則。[1]TheBNotat