（高清版）GBT 41295.2-2022 功能安全應用指南 第2部分：設計和實現(xiàn)

功能安全應用指南第2部分：設計和實現(xiàn)2022-03-09發(fā)布2022-10-01實施國家標準化管理委員會IGB/T41295.2—2022 2規(guī)范性引用文件 13術語和定義 14縮略語 25總則 26安全生命周期 7系統(tǒng)設計 48系統(tǒng)架構設計 69系統(tǒng)詳細設計和實現(xiàn) 710軟件設計和實現(xiàn) 11系統(tǒng)集成 12系統(tǒng)運行和維護規(guī)程 13系統(tǒng)的確認 14生命周期各個階段的驗證 16功能安全系統(tǒng)評估評測 參考文獻 圖1系統(tǒng)實現(xiàn)過程的安全生命周期 3圖2系統(tǒng)設計要求規(guī)范與系統(tǒng)安全要求規(guī)范的關系 4圖3系統(tǒng)設計要求規(guī)范的分解 5圖4過程工業(yè)SIL目標分配示例 5圖5安全確認計劃內容 6Ⅲ本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規(guī)則》的規(guī)定起草。本文件是GB/T41295《功能安全應用指南》的第2部分。GB/T41295已經發(fā)布了以下部分：——第1部分：危害辨識和需求分析；——第2部分：設計和實現(xiàn)；——第3部分：測試驗證；——第4部分：管理和維護。請注意本文件的某些內容可能涉及專利。本文件的發(fā)布機構不承擔識別專利的責任。本文件由中國機械工業(yè)聯(lián)合會提出。本文件由全國工業(yè)過程測量和控制標準化技術委員會(SAC/TC124)歸口。本文件起草單位：上海辰竹儀表有限公司、機械工業(yè)儀器儀表綜合技術經濟研究所、國能智深控制技術有限公司、浙江中控技術股份有限公司、北京康吉森技術有限公司、上海辰竹安全科技有限公司。自GB/T20438(所有部分)發(fā)布以來，電氣/電子/可編程電子系統(tǒng)已經越來越多的應用于國內各個領域的安全控制和安全防護，包括石油、化工、電力、軌道交通、汽車、電梯/扶梯等。近年來隨著智能制造的興起，智能化設備(主要由電氣/電子/可編程電子為技術基礎)的安全問題逐漸成為一個新的研究方向和焦點，進一步提升了對功能安全技術的需求。GB/T20438(所有部分)給出了實現(xiàn)功能安全的基本框架和結構，作為等同轉化的標準，與國內企業(yè)的管理體系和設計思路未能完全切合，加之很多國內工程技術人員都是初次接觸功能安全技術，對于功能安全概念一時難以理解，這就造成雖然國際功能安全標準提出了非常好的安全理念和設計措施，但技術人員難以清楚的理解和認識。GB/T20438(所有部分)發(fā)布10多年來，國內一些領先的科研院所和企業(yè)已經基于標準要求開展了很多工作，并積累了一定的經驗。因此，基于國內目前已有的功能安全評估、功能安全設計、功能安全測試和功能安全管理實踐形成本文件，以更好地指導功能安全相關系統(tǒng)GB/T41295擬制定4個部分： 第1部分：危害辨識和需求分析。目的在于給出功能安全系統(tǒng)設計初期的危害辨識內容和需求如何產生的方法；——第2部分：設計和實現(xiàn)。目的在于給出功能安全系統(tǒng)的軟硬件設計和實現(xiàn)方法和實施指南；——第3部分：測試驗證。目的在于給出功能安全系統(tǒng)在生命周期過程各個階段的測試導則和測試方法解讀；——第4部分：管理和維護。目的在于給出功能安全系統(tǒng)管理和維護過程的導則。1功能安全應用指南第2部分：設計和實現(xiàn)本文件給出了設計和實現(xiàn)功能安全系統(tǒng)的指導措施，面向的對象包括安全傳感器、安全邏輯控制器、安全通信總線和安全執(zhí)行器等。本文件適用于功能安全系統(tǒng)研發(fā)團隊(如制造商),就開發(fā)出符合相應安全完整性能力的安全產品給出規(guī)范性指導；系統(tǒng)集成商、評估機構和用戶用于對適當功能安全系統(tǒng)的選型和評價參照執(zhí)行。2規(guī)范性引用文件下列文件中的內容通過文中的規(guī)范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本(包括所有的修改單)適用于本文件。GB/T19001—2016質量管理體系要求GB/T20438.1—2017電氣/電子/可編程電子安全相關系統(tǒng)的功能安全第1部分：一般要求GB/T20438.2—2017電氣/電子/可編程電子安全相關系統(tǒng)的功能安全第2部分：電氣/電子/可編程電子安全相關系統(tǒng)的要求GB/T20438.3—2017電氣/電子/可編程電子安全相關系統(tǒng)的功能安全第3部分：軟件要求GB/T20438.4—2017電氣/電子/可編程電子安全相關系統(tǒng)的功能安全第4部分：定義和縮略語GB/T20438.6—2017電氣/電子/可編程電子安全相關系統(tǒng)的功能安全第6部分：GB/T20438.2和GB/T20438.3的應用指南GB/T34040—2017工業(yè)通信網絡功能安全現(xiàn)場總線行規(guī)通用規(guī)則和行規(guī)定義GB/T41295.3功能安全應用指南第3部分：測試驗證IEC61508-3-1電氣/電子/可編程電子安全相關系統(tǒng)的功能安全第3-1部分：軟件要求重復使用預先存在的軟件元素來實現(xiàn)全部或部分安全功能(Functionalsafetyofgrammableelectronicsafety-relatedsystems—Part3-1:Softwarerequirements—Reuseofpre-existingsoftwareelementstoimplementallorpartofasafetyfunction)3術語和定義GB/T20438.4—2017界定的以及下列術語和定義適用于本文件。功能安全系統(tǒng)functionalsafetysystem執(zhí)行安全相關功能的系統(tǒng)，具有功能安全相關的特性，滿足特定的安全完整性等級(SIL)。注：這里的系統(tǒng)是一個廣義的概念，包括不同的層次，如安全部件、安全設備或安全控制系統(tǒng)等。在實際的工業(yè)過程中，功能安全系統(tǒng)可能是一個變送器、繼電器、安全可編程序控制器或安全儀表系統(tǒng)。2功能安全系統(tǒng)研發(fā)團隊teamforfunctionalsafetysystemresearchanddevelopment執(zhí)行功能安全系統(tǒng)設計研發(fā)的責任主體。注：包括功能安全系統(tǒng)硬件開發(fā)人員、軟件開發(fā)人員、驗證測試人員、功能安全管理人員等。執(zhí)行功能安全系統(tǒng)生產制造的責任主體，它可能包括功能安全系統(tǒng)制造過程的裝配人員、測試人注：為保證系統(tǒng)的安全功能正確制造，功能安全系統(tǒng)制造團隊需要得到來自功能安全系統(tǒng)研發(fā)團隊的有效協(xié)助。故障插入測試faultinjectiontest人為地在功能安全系統(tǒng)中產生一種故障模式，驗證系統(tǒng)在故障狀態(tài)下的響應情況是否符合安全要求的一種測試方法。4縮略語下列縮略語適用于本文件。ASIC:專用集成電路(ApplicationSpecificIntegratedCircuit)CMMI:能力成熟度模型集成(CapabilityMaturityModelIntegration)CPLD:復雜可編程邏輯器件(ComplexProgrammableLogicDevice)DC:診斷覆蓋率(DiagnosticCoverage)FMEA:失效模式與影響分析(Failuremodeandeffectanalysis)FMEDA:失效模式、影響與診斷分析(Failuremode,effectanddiagnosticanalysis)FPGA:現(xiàn)場可編程門陣列(FieldProgrammableGateArray)FTA:故障樹分析(Faulttreeanalysis)HFT:硬件故障裕度(HardwareFaultTolerance)MooN:N取M通道架構(MoutofNchannelarchitecture)PFDavg:要求時危險失效平均概率(AverageProbabilityofdangerousFailureonDemand)PFH:危險失效平均頻率(Averagefrequencyofdangerousfailure)SFF:安全失效分數(shù)(SafeFailureFraction)SIL:安全完整性等級(SafetyIntegrityLevel)5總則5.1功能安全系統(tǒng)的研發(fā)設計過程需要按照GB/T20438.2—2017和GB/T20438.3—2017等相關功能安全基礎標準的要求開展功能安全系統(tǒng)研發(fā)和驗證工作。為保證預期的SIL目標和要求得以切實實現(xiàn)，本文件給出了相關的應用指南。注：某些領域有其特定領域的功能安全標準，這些領域的功能安全標準繼承了GB/T20438.2—2017和GB/T20438.3—2017的整體架構和核心理念，因此在符合這些領域功能安全要求時，也可參考本文件的相關內容。5.2功能安全系統(tǒng)還宜滿足其產品標準中關于基本安全(如電氣安全)、環(huán)境適應性以及可靠性/穩(wěn)定性的特定要求，這些要求是實現(xiàn)相應安全完整性的前提。5.3功能安全系統(tǒng)的生產制造過程需要考慮第15章或相關領域功能安全標準中的規(guī)定。36安全生命周期6.1一般原則6.1.1功能安全系統(tǒng)研發(fā)團隊需要在安全研發(fā)的初期建立功能安全管理體系和定義安全生命周期階段。6.1.2功能安全管理體系和安全生命周期的建立需要結合功能安全標準要求以及研發(fā)團隊的已有經驗。6.2應用考慮6.2.1功能安全管理體系需要考慮GB/T20438.1—2017中第6章的要求，功能安全研發(fā)部門可以參考公司已有的質量/安全管理體系來建立功能安全管理體系。注：GB/T19001—2016或CMMI等體系的構建和實施是實現(xiàn)功能安全管理的有力保障。6.2.2功能安全管理體系需要包含系統(tǒng)或軟件變更的需求，需要考慮GB/T20438.2—2017中7.8和GB/T20438.3—2017中7.8的要求。當變更發(fā)生后，宜按照制定的變更規(guī)程執(zhí)行影響分析，留存變更記錄。6.2.3典型的安全生命周期過程需要考慮GB/T20438.2—2017和GB/T20438.3—2017中第7章的要求，功能安全系統(tǒng)研發(fā)團隊按照該章的要求建立滿足自己研發(fā)特性的安全生命周期。6.2.4功能安全系統(tǒng)實現(xiàn)過程的安全生命周期需求包括：系統(tǒng)設計要求規(guī)范(包括軟件安全要求規(guī)范)、系統(tǒng)的架構設計、系統(tǒng)的詳細設計和實現(xiàn)、軟件設計和實現(xiàn)、系統(tǒng)集成(包括子系統(tǒng)軟硬件集成和子系統(tǒng)間集成)、系統(tǒng)運行和維護規(guī)程(包括用戶手冊、安全手冊等)、系統(tǒng)的安全確認(包括軟件確認)、系統(tǒng)的制造。功能安全系統(tǒng)的安全生命周期見圖1。8系統(tǒng)架構設計系統(tǒng)詳細設計和實現(xiàn)安全確認計劃11系統(tǒng)集成12系統(tǒng)運行和維護規(guī)程13系統(tǒng)的安全確認生命周期各個階段的驗證軟件設計和實現(xiàn)功能安全管理評估評測9圖1系統(tǒng)實現(xiàn)過程的安全生命周期6.2.5對系統(tǒng)的修改和驗證的要求貫穿干以上生命周期的所有階段。7系統(tǒng)設計7.1一般原則7.1.1功能安全系統(tǒng)設計要求規(guī)范的基本要求需要考慮GB/T20438.2—2017中7.2和B.1的要求。7.1.2系統(tǒng)設計要求規(guī)范中需要包括系統(tǒng)的所有設計要求，包括安全相關要求和非安全相關要求。宜將安全相關要求和非安全相關要求明確區(qū)分開來，對于非安全相關要求可以不必按照生命周期后續(xù)活動執(zhí)行。7.1.3對與某些與應用聯(lián)系非常緊密的產品(例如，軌道交通產品，汽車電子產品),安全要求和非安全要求的界定需要根據具體的應用加以分析，并將分析過程文檔化。7.1.4宜對所有的安全要求保持追溯，典型的追溯方法包括：采用專業(yè)的要求管理工具，采用特定的編號系統(tǒng)等。7.1.5在系統(tǒng)設計要求規(guī)范和軟件安全要求規(guī)范編制完成后，需要按照GB/T20438.2—2017中圖2和GB/T20438.3—2017中圖6的V模型，在每一階段開展對其的驗證，驗證形式包括內部測試、外部測試、會議審查、專家評定或建模分析等。驗證完成后形成正式的驗證記錄。7.1.6需要按照GB/T20438.2—2017中7.3編制系統(tǒng)安全確認計劃。7.2應用考慮7.2.1系統(tǒng)設計要求與系統(tǒng)安全要求的關系，如圖2所示。整體安全要求及分配整體安全要求及分配GB/T20438.1—2017中7.5和7.6非安全相關要求規(guī)范，如非安全相關通信接π要求系統(tǒng)設計要求規(guī)范GB/T20438.22017小7.2和本章來白用戶、國家/行業(yè)標準等的要求，如可用性要求系統(tǒng)安全要求規(guī)范軟件安全要求規(guī)范圖2系統(tǒng)設計要求規(guī)范與系統(tǒng)安全要求規(guī)范的關系7.2.2一般情況下，系統(tǒng)設計要求規(guī)范可以包括功能級的要求和單獨的硬件要求，對于復雜的系統(tǒng)也可以單獨編制硬件安全要求規(guī)范。7.2.3系統(tǒng)設計要求規(guī)范宜進行如圖3的分解。5系統(tǒng)設計要求規(guī)范保持追溯：安全和關要求非安全和關要求日的：基于信息執(zhí)行要求的安全功能安全功能相關的設計要求符合文檔結構化要求和關的設計要求口的：基于信息，實現(xiàn)規(guī)定的安全完整性等級和口標失效量●安全功能的描述●安全狀態(tài)的定義●響應時問的要求●外部接π電源/輸入/輸出/通信等●系統(tǒng)運行模式低要求/高要求/連續(xù)●每個子系統(tǒng)的架構應滿足硬件安全完整性的架構●預期實現(xiàn)的SIL日標●口標失效量(PFDavg/PFTI)●檢驗測試頻率●診斷發(fā)現(xiàn)危險時所采用的行動●要求的抗電做干擾等級●其他要求圖3系統(tǒng)設計要求規(guī)范的分解7.2.4對于所有要求規(guī)范的描述避免直接進入具體的軟硬件設計細節(jié)(這些設計細節(jié)將在后續(xù)架構設計和詳細設計完成)。注：要求規(guī)范規(guī)定系統(tǒng)預期要實現(xiàn)的安全要求，而不給出設計方案，例如“系統(tǒng)應對寄存器單元進行周期性自診斷”是一項安全要求，“系統(tǒng)將采用漫步位方法對寄存器單元進行周期性自診斷”是一項設計方案。7.2.5規(guī)定功能安全系統(tǒng)預期實現(xiàn)的SIL目標(SIL1/SIL2/SIL3/SIL4)。如果系統(tǒng)內的安全功能有不同的SIL目標宜分別詳細規(guī)定。7.2.6如果整個安全回路是由多個功能安全系統(tǒng)組成，對于預期的SIL目標，每個功能安全系統(tǒng)的目標失效量(PFDavg或PFH)宜不超過規(guī)定的百分比，這個百分比規(guī)定下的PFDavg或PFH目標應作為要求規(guī)范中一條要求明確提出，這個百分比可來自：——在整體要求規(guī)范或安全要求規(guī)范中已經明確的了對各個部分功能安全系統(tǒng)的目標失效量，特定功能安全系統(tǒng)研發(fā)單位直接采用該數(shù)值；——如果在整體要求規(guī)范或安全要求中沒有明確給出，則需要按照行業(yè)的通常做法，例如，在典型過程工業(yè)中會有圖4的推薦分配。注1:例如，邏輯控制器保證不超過10%的回路目標失效量，假設要求的SIL目標是SIL3,按照SIL3在低要求運行模式下滿足PFDavg小于10E-3,那么對于預期實現(xiàn)SIL3應用的邏輯控制器其PFDavg目標至少小于10E-4。注2:圖2更加適用于過程工業(yè)，不同行業(yè)可能可能安全回路的構成有顯著差異，其他行業(yè)宜結合自身的行業(yè)特性確認SIL分配目標。整個安全回路傳感器邏輯控制器執(zhí)行器其他部件安全通信<30%<10%<50%圖4過程工業(yè)SIL目標分配示例7.2.7其他部件也是執(zhí)行整個安全回路的必要組成部分，如安全柵、安全繼電器等；其他部件不包括與安全功能執(zhí)行沒有直接相關的部分。67.2.8安全確認計劃宜包含的內容見圖5。系統(tǒng)設計要求規(guī)范系統(tǒng)設計要求規(guī)范驗證后立即實施目標：驗證每個安全功能是否符合系統(tǒng)設計要求規(guī)范T2/T3類工具安全生命周期不同階段均需制定安全確認計劃。各階段執(zhí)行確認后輸出安全生命周期各階段開展確認活動用到的若用到T2/T3類軟件離線工具，除滿足常規(guī)工具要求，需額外進行論證，并提供：●工具的約束條件；內部審核外部審核走在驗證活動中用到的工具驗證確認計劃內容安全確認計劃常規(guī)工具圖5安全確認計劃內容7.2.9確認計劃在系統(tǒng)設計要求規(guī)范和軟件安全要求規(guī)范驗證完成后立即實施，需要針對要求規(guī)范的每一條要求規(guī)劃確認策略。典型的確認策略包括：——建模分析；——內部測試；——外部測試；——會議審查；——專家評定。8系統(tǒng)架構設計8.1一般原則8.1.1需要基于系統(tǒng)設計要求規(guī)范開展系統(tǒng)(硬件)架構設計。8.1.2對于相對簡單的功能安全系統(tǒng)，系統(tǒng)架構設計可以合并到系統(tǒng)設計要求規(guī)范階段實施，但單獨的軟件架構設計是必要的。8.1.3對于相對復雜的功能安全系統(tǒng)，宜建立單獨的系統(tǒng)架構設計階段。8.1.4架構設計需要考慮GB/T20438.2—2017中7.4的適用要求。8.1.5需要考慮對架構設計開展驗證。8.1.6需要考慮基于架構設計內容編制集成測試計劃。8.2架構設計應用考慮8.2.1架構設計在保障功能安全上面需要考慮如下方面：——保證系統(tǒng)足夠的健壯性；——保證不同模塊之間適當?shù)莫毩⑿?，避免復雜的耦合關系和共因失效；——保證非安全相關模塊不會對安全相關模塊造成負面影響。78.2.2需要對架構設計的靜態(tài)特性進行規(guī)范性描述(例如，架構框圖),對組成系統(tǒng)架構的每個模塊和模塊間接口進行描述。8.2.3架構設計宜避免對每個模塊內部的實現(xiàn)細節(jié)進行描述，這些細節(jié)是后續(xù)詳細設計的內容。8.2.4可以考慮采用多通道的MooN表決結構來實現(xiàn)高安全或高可用設計?？梢栽诓煌瑢哟紊蠈崿F(xiàn)8.2.5需要明確區(qū)分MooN表決結構和備用結構之間的差異，一般情況下備用結構是用于提高可用性而非安全性。8.2.6需要在完成架構設計驗證之后，制定集成測試計劃，其中包括對所有架構特性和接口特性的測試策略。9系統(tǒng)詳細設計和實現(xiàn)9.1一般原則9.1.1功能安全系統(tǒng)設計和研發(fā)的基本要求需要考慮GB/T20438.2—2017中7.4、附錄A和B.2的要求。9.1.2需要考慮編制硬件詳細設計相關文件，并基于詳細設計實現(xiàn)硬件電路。9.2應用考慮9.2.1隨機硬件失效的要求9.2.1.1功能安全系統(tǒng)最終的隨機硬件失效量小于或等于第7章所規(guī)定的目標(PFDavg或PFH數(shù)值),并通過合理的建模和計算證明該目標得以實現(xiàn)。9.2.1.2隨機硬件失效估算的范圍是功能安全系統(tǒng)中所有安全相關的部分。9.2.1.3需要考慮按照GB/T20438.6—2017中附錄B開展PFDavg或PFH的估算，如果采用該方法，確保實際的待分析系統(tǒng)滿足規(guī)定的所有假設條件。如果采用其他方法，宜有符合數(shù)學邏輯的合理性證明。注：某些文獻資料給出了非常簡化的公式，對于簡化公式的應用要更加小心，因為簡化條件可能和當前實際的項目要求不符，這會導致簡化公式的錯誤。9.2.1.4需要考慮使用適當?shù)脑骷?失效模型數(shù)據庫作為計算的輸入，可以來自：——國際標準或國家標準、行業(yè)標準，如I——領域內廣泛認可的商用數(shù)據庫；——具有專門收集系統(tǒng)的現(xiàn)場反饋數(shù)據，保證統(tǒng)計置信度≥70%。9.2.1.5同一系統(tǒng)的計算宜使用一個同一來源的失效率/失效模式數(shù)據庫。只有能證明數(shù)據在共同條件下得到時，才能使用多個來源的數(shù)據。9.2.1.6某些計算的輸入參數(shù)，如檢驗測試周期(T1)、平均修復時間(MTTR)和平均維修時間(MRT)等不是由功能安全系統(tǒng)研發(fā)設計單位決定的，因此需要基于產品預期的應用情況預設一個數(shù)值參與計算，數(shù)值的合理性需要經過專門的分析和論證，在功能安全系統(tǒng)后續(xù)的產品手冊中宜明確說明這些預設的數(shù)值。9.2.1.7當系統(tǒng)架構包含多個通道，如loo2或2oo3架構時，需要考慮共因失效對隨機硬件失效的影響，宜采用GB/T20438.6—2017的方法對共因失效因子進行估算。9.2.1.8如果使用第三方的軟件工具開展計算，需要對工具的適用性進行分析，并開展完備的工具驗證。9.2.1.9為盡可能減小元器件發(fā)生隨機硬件失效的可能性，需要對安全相關的元器件開展降額設計，電8氣特性的降額因子不宜高于67%,對于溫度的降額宜不小于10℃。9.2.1.10需要形成文檔性的分析材料，以證明降額設計的合理性，宜開展測試對降額的實現(xiàn)情況進行驗證。9.2.2硬件失效分析要求9.2.2.1為對9.2.1所要求的隨機硬件失效進行PFD/PFH估算，需要開展元器件級的硬件失效分析，常用的分析方法包括FMEDA、FTA等。9.2.2.2基于元器件失效后對模塊的影響以及是否能夠被診斷到，失效分析宜將每種失效分類為以下幾種類別之一：——可診斷到的安全失效(λsp);——不可診斷到的安全失效(λsu);——可診斷到的危險失效(λpp);——不可診斷到的危險失效(λpu);——無影響失效。注：對于架構設計階段已經界定為安全無關的模塊，可以不對其元器件開展詳細的失效分析，這些部件的失效在GB/T20438(所有部分)中被定義為無關失效。9.2.2.3對于復雜的子系統(tǒng)或元器件，如果其失效后安全或危險難以判定，可以將其按照50%安全，50%危險的方式進行劃分。注：在一個有效的分析過程中，不宜簡單的將大部分的元器件按照50%的方式劃分，這會導致最終的PFDavg,PFH,SFF等參數(shù)非常差，甚至連SIL1都達不到，這樣的分析是沒有意義的。9.2.2.4需要注意區(qū)分安全失效和無影響失效，不能將無影響失效納入安全失效之中。9.2.2.5基于硬件失效分析的結論需要對已有安全設計進行復審，確保所有關鍵故障都得到有效控制或避免。9.2.2.6需要仔細判斷每個診斷功能的有效性，無效的診斷不能將對應的失效歸類為可診斷的，無效的診斷包括但不限于：——診斷測試間隔過長，不滿足過程安全時間的要求；——如果采用多通道設計，單純的通道間表決不能作為單個通道內器件失效的診斷措施；——診斷到故障后沒有適當?shù)墓收享憫驁缶?.2.3診斷覆蓋率的判定需要仔細判斷每個診斷功能的覆蓋率，一般按照如下考慮進行判定?！獙τ诤唵卧骷?，如果診斷測試能夠診斷到它的某種失效模式，則該器件這種失效模式的診斷覆蓋率為100%,否則為0%,簡單器件例子：電阻、電容、三極管、二極管、光耦等?！獙τ趶碗s的器件，原則上基于GB/T20438.2—2017中A.1～A.14的要求。如果有更高診斷覆蓋率的申明或者采用了GB/T20438.2—2017中附錄A沒有規(guī)定的技術，采用測試的方法證明所實現(xiàn)診斷覆蓋率的真實性。復雜元器件的例子：中央處理器(CPU)、模數(shù)轉換(ADC)——對同一器件或模塊，可使用兩種或更多種診斷方法來診斷相同的失效模式，這種方式可以實現(xiàn)比GB/T20438.2—2017中附錄A規(guī)定的更高診斷覆蓋率。但這些不同方法一定是獨立的，且不具有共因失效的可能。9.2.4診斷功能及診斷覆蓋率(DC)9.2.4.1對于功能安全系統(tǒng)設計的足夠的自診斷措施，設計是否足夠的判定需要考慮如下：9——系統(tǒng)遵循了單一失效原則；——PFDavg/PFH滿足了目標失效量的要求；——SFF滿足了架構約束的要求。注：足夠的診斷功能可以更加利于以上要求的實現(xiàn)，但并不是單單依靠診斷功能，例如，失效率高低和檢驗測試間隔長短對于PFDavg/PFH是否滿足要求也有重大影響。當這些要求無法滿足時，可以考慮是否通討提高診斷能力進行改善。9.2.4.2診斷功能的設計滿足檢測到故障后系統(tǒng)的行為要求。9.2.4.3需要但不限于在如下兩個階段執(zhí)行診斷：——在系統(tǒng)初始化時，診斷重點是所有的硬件，內部或外部數(shù)據通路等；——正常運行時周期中執(zhí)行診斷功能，診斷重點包括硬件、軟件、軟錯誤、數(shù)據通路等。9.2.4.4宜基于系統(tǒng)的運行周期和所有診斷功能實現(xiàn)的時間，確定所有診斷的間隔時間，即診斷測試間隔(Tp)。9.2.4.6某些診斷功能為避免頻繁的誤動作，可能會采取多次判斷后診斷決策的機制，需要考慮到這種多次判斷和重試可能會導致進入到某種死循環(huán)或無法實現(xiàn)所規(guī)定的診斷能力。9.2.5.1架構約束的基本要求需要考慮滿足GB/T20438.2—2017中7.4.4。9.2.5.2宜優(yōu)先選用GB/T20438.2—2017中7.4.4的路線1(1H),即通過硬件故障裕度(HFT)和安全失效分數(shù)(SFF)的確定來給出架構約束滿足的SIL目標。9.2.5.3HFT的確定需要仔細分析采用的冗余方式，某些冗余的方式不能保證硬件故障裕度的提升。注：例如采用一用一備的方式實現(xiàn)冗余，正常時只有一個通道執(zhí)行要求的處理功能，故障時切換到另一個通道，這種情況下的HFT=0。9.2.5.4合理的估算系統(tǒng)的SFF需要考慮：——不將無影響失效納入SFF的計算之中；——診斷部分失效導致誤動不能納入SFF的計算之中。9.2.5.5安全失效分數(shù)的確定需要考慮到某些失效率很大的部件，如果該部件是安全失效，那么可能會導致在沒有執(zhí)行足夠的診斷情況下，SFF指標滿足架構約束要求，這個是不符合安全準則的。9.2.6硬件部分系統(tǒng)性失效的避免和控制9.2.6.1為了避免硬件開發(fā)期間的系統(tǒng)性失效，需要考慮使用GB/T20438.2—2017中附錄B的技術和措施。9.2.6.2在驗證和確認階段，需要有足夠的證據證明這些技術和措施的確在研發(fā)過程得到了實施，并對證據文檔化。9.2.6.3為控制系統(tǒng)性故障，系統(tǒng)設計需要考慮GB/T20438.2—2017中A.15～A.18的要求，以滿足安全數(shù)據通信過程中對于系統(tǒng)性故障控制。9.2.6.4在設計和開發(fā)活動中需要考慮可維護性和可測試性，以便在組合的最終安全相關系統(tǒng)中實現(xiàn)這些特性。系統(tǒng)的設計需要考慮人員的能力和限制，并且能夠分配給操作員和維護人員實施。所有接口的設計宜考慮人員因素，并適應操作員可能具有的培訓或意識等級，例如，大批量生產應用中操作員可能僅接受過有限的培訓。注：設計目標是通過可能的設計或在完成前進行再次確認，來防止或消除由操作員或維護人員產生的可預見的關鍵錯誤。9.2.7檢測到故障時系統(tǒng)行為9.2.7.1需要考慮GB/T20438.2—2017中7.4.8的所有內容。9.2.7.2在系統(tǒng)初始化時檢測到危險故障，需要停止啟動并給出相應的報警指示。9.2.7.3在系統(tǒng)運行期間檢測到關鍵性危險故障，需要導致：——在制造商規(guī)定的故障響應時間內，通過內置措施(如硬件或嵌入式軟件)將所有受故障影響的輸出切換到定義的安全狀態(tài)；或——在制造商所規(guī)定的故障響應時間內，向應用措施(如應用程序)通知(報警)故障，從而應用措施(如應用程序)可采取適當?shù)膭幼鱽肀３职踩?；——當以上任何一種情況發(fā)生后如果還沒有進入安全狀態(tài)，就意味著系統(tǒng)已經處于降級運行，系統(tǒng)是否設計為當降級運行后在規(guī)定的時間內如果沒有維修處理好需要自動的輸出安全值，將過程導入安全狀態(tài)，降級后自動進入安全狀態(tài)的功能不能被現(xiàn)場運行人員手動關閉；規(guī)定的時間作為平均維修時間(MTTR)的影響因素之一納入失效計算。注1:關鍵性危險故障的定義在危險和風險分析時確定，通常來說是指那些無法執(zhí)行安全功能且短時間內無法自動恢復的危險故障。注2:何種動作合適取決于應用，功能安全系統(tǒng)研發(fā)團隊可以將其設計為可配置的方式。9.2.7.4故障需要被檢測并通知(報警)給應用程序，除非以下兩種情況：——通過設計，該故障不可能在系統(tǒng)中發(fā)生；——由書面的技術評估證明故障可忽略。9.2.8安全數(shù)據通信9.2.8.1系統(tǒng)一般有兩種類型的數(shù)據通信，一種是安全相關通信，另一種是非安全相關通信，對于安全相關通信需要考慮符合GB/T20438.2—2017中7.4.11的要求。9.2.8.2可以采用黑色通道和白色通道兩種方式實現(xiàn)安全通信，對于工業(yè)控制領域宜按照GB/T34040—2017的要求采用黑色通道的方式。9.2.8.3除了對殘余差錯率進行估算之外，還需要考慮通過測試的方式證明安全通信的檢錯能力，具體的測試方法按照GB/T41295.3的規(guī)定。9.2.8.4內部通信路徑可以不按照GB/T34040—2017的要求實施，但也需要有足夠的傳輸錯誤檢測能力。注：典型的內部通信路徑包括：內部芯片之間的數(shù)據通信(如IC等)、同一個模塊內兩塊板卡之間接口通信。9.2.8.5實現(xiàn)安全通信協(xié)議的安全層軟件需要考慮符合第10章。9.2.8.6ASIC組件安全設計：如果系統(tǒng)中包含ASIC組件(如FPGA、CPLD等),其開發(fā)過程需要考慮符合GB/T20438.2—2017中附錄F的要求。9.2.8.7需要考慮基于硬件詳細設計對硬件進行實現(xiàn)。10軟件設計和實現(xiàn)10.1.1軟件設計和實現(xiàn)包括軟件安全要求規(guī)范、軟件架構設計和軟件詳細設計和實現(xiàn)。10.1.2安全相關軟件包括：系統(tǒng)的嵌入式固件、系統(tǒng)所應用的操作系統(tǒng)、系統(tǒng)所應用的安全數(shù)據庫、在線支持工具等。10.1.3安全軟件設計和實現(xiàn)的一般原則宜符合GB/T20438.3—2017。10.1.4基于已經完成的軟件安全要求規(guī)范和軟件架構設計來實施軟件詳細設計和實現(xiàn)。10.1.5按照GB/T20438.3—2017中7.3的要求編制軟件確認計劃。10.2應用考慮10.2.1.1需要考慮基于系統(tǒng)設計要求規(guī)范編制軟件安全要求規(guī)范。10.2.1.2需要考慮對軟件安全要求規(guī)范進行持續(xù)追蹤以確保所有要求得以正確實現(xiàn)。10.2.2.1需要對軟件架構設計的靜態(tài)特性進行規(guī)范性描述(例如，架構框圖),宜對組成系統(tǒng)架構的每個模塊和模塊間接口進行描述。10.2.2.2軟件架構設計需要避免對每個模塊內部的實現(xiàn)細節(jié)進行描述(如函數(shù)的參數(shù)),這些細節(jié)是后續(xù)詳細設計的內容。10.2.2.3需要對軟件的動態(tài)特性進行規(guī)范性描述，包括軟件可能處于的運行狀態(tài)描述，以及狀態(tài)之間的轉移關系。10.2.2.4在軟件架構設計中，宜適當?shù)膶?shù)據規(guī)范、數(shù)據流、內存分配及存儲空間余量方案等進行描述。10.2.2.5在對架構設計進行驗證時，需要考慮至少采用一種規(guī)范性的分析方法(如系統(tǒng)級/模塊級FMEA),通過該方法以證明：——非安全相關的模塊不會對安全相關模塊造成負面影響；——足夠的健壯性以保證在數(shù)據傳輸錯誤等情況發(fā)生時，系統(tǒng)不會進入危險狀態(tài)。10.2.3.1軟件相關的離線支持工具包括：代碼編輯器、編譯器和連接器、模型化設計工具、軟件文檔編輯工具、軟件測試工具、配置管理工具等。10.2.3.2需要按照GB/T20438.3—2017中7.4.4的要求考慮對離線支持工具的分類，包括：——T1:不產生可直接或間接影響安全相關系統(tǒng)的可執(zhí)行代碼(包括數(shù)據)的輸出；——T2:支持設計或可執(zhí)行代碼的測試或驗證，工具中的錯誤不能發(fā)現(xiàn)可執(zhí)行軟件的缺陷，但不會在可執(zhí)行軟件中直接產生錯誤；——T3:產生可直接或間接影響安全相關系統(tǒng)的可執(zhí)行代碼的輸出。注1:T1的示例包括：文本編輯器或沒有自動代碼生成能力的需求或設計支持工具；配置控制工具。注3:T3的示例包括：源代碼程序和生成的目標代碼之間的關系不明顯的優(yōu)化編譯器；將一個可執(zhí)行運行時軟件包組合到可執(zhí)行代碼的編譯器。注4:此分類基于GB/T20438.4—2017中3.2.11。10.2.3.3對于按照GB/T20438.3—2017已經開展了符合性評估的離線支持工具，設計人員可以考慮直接按照工具手冊的要求應用工具。10.2.3.4對于沒有按照GB/T20438.3—2017開展符合性評估的離線支持工具，設計人員需要對工具的適用性和正確性進行論證，并形成論證報告。10.2.4.1選用符合產品特性和適于軟件設計人員的編程語言。10.2.4.2針對特定的編程語言需要考慮編制適當?shù)木幋a規(guī)則來規(guī)范和約束代碼的實現(xiàn)，編碼規(guī)則需要考慮至少規(guī)定規(guī)范化的編碼風格和可以使用和不能使用的編碼形式?！髽I(yè)的已有類似項目的編碼經驗，公司規(guī)定等；——國際和國內通用的且被認可的編碼規(guī)則或標準，如MirsaC/C++等；——待實施項目的特殊情況，如編譯環(huán)境或測試工具的特殊情況。10.2.5.1對SIL1和SIL2的軟件宜開展軟件失效分析，對于SIL3和SIL4的軟件需要考慮開展軟件失效分析。10.2.5.2軟件失效分析的典型方法有：軟件FMEA、軟件危險與可操性分析(HAZOP)、軟件形式化建模分析等。10.2.5.3軟件失效分析的結果保證所有安全相關模塊的可預見故障都能得到相應的安全控制。10.2.6.1對于某些軟件模塊，在執(zhí)行本次功能安全系統(tǒng)設計之前就已經存在，并一直良好運行(例如，應用在之前類似系統(tǒng)上的通用軟件模塊),如果將這些軟件模塊復用于本次功能安全系統(tǒng)執(zhí)行特定的組件安全功能，這些軟件模塊符合GB/T20438.3—2017中7.4.2.12。10.2.6.2對于復用的軟件組件為了保證其安全性，采用以下三種方式之一進行安全設計和論證?！肪€1s:符合性開發(fā)。按照GB/T20438.3—2017和第10章的所有內容對該已有軟件組件進行一次完全符合性的設計開發(fā)?！肪€2s:經使用證明。符合IEC61508-3-1的相關要求?！肪€3s:非符合性開發(fā)。符合GB/T20438.3—2017中7.4.2.13。10.2.6.3如果采用路線2s,最高適用于SIL2的安全組件，并需要足夠的已有運行經驗。10.2.7組件組合提高系統(tǒng)性能力10.2.7.1可以考慮通過組合安全組件來提高系統(tǒng)性能力，見GB/T20438.2—2017中7.4.3。10.2.7.2組合組件提高系統(tǒng)性能力的前提是組件之間具有足夠的獨立性，例如，兩個通道之間的軟件是異構配置的。10.2.8.1可以考慮通過分析或測試的方法來對軟件開展驗證。10.2.8.2采用走查或審查等方式對軟件代碼或詳細設計文件進行檢查。10.2.9軟件部分避免系統(tǒng)性失效10.2.9.1為了避免軟件開發(fā)期間的系統(tǒng)性失效，使用GB/T20438.3—2017中附錄A、附錄B和附錄C的相關技術和措施。10.2.9.2在驗證和確認階段，需要有足夠的證據證明這些技術和措施的確在研發(fā)過程得到了實施，對證據文檔化。11.1.1不同復雜度的系統(tǒng)可能有不同的集成考慮，對于簡單的系統(tǒng)可能只有軟硬件集成，對于復雜的系統(tǒng)還存在一個到多個層次的子系統(tǒng)集成，宜在生命周期早期階段明確系統(tǒng)的集成方式。11.1.2功能安全系統(tǒng)集成考慮符合GB/T20438.2—2017中7.5(子系統(tǒng)集成)和GB/T20438.3—2017中7.5(軟硬件集成)。11.1.3在硬件和軟件架構設計階段編制集成測試計劃。11.2應用考慮11.2.1在集成階段執(zhí)行故障插入測試。11.2.2故障插入測試用例的設計和執(zhí)行參考GB/T41295.3。11.2.3故障插入測試的執(zhí)行得到第三方獨立機構見證，并產生基于見證結論的故障插入測試報告。12系統(tǒng)運行和維護規(guī)程12.1.1功能安全系統(tǒng)研發(fā)團隊宜基于產品的基本功能和應用特性編制用戶手冊，包括安裝、維護要求等；功能安全系統(tǒng)研發(fā)團隊還需要基于產品的功能安全屬性編制安全手冊，包括安全配置方式、危險失效參數(shù)等。12.1.2用戶手冊和安全手冊從形式上可以是一個或多個文檔。12.1.3安全手冊的內容至少需要考慮GB/T20438.2—2017和GB/T20438.3—2017中附錄D的要求。12.1.4用戶手冊和安全手冊需要考慮隨功能安全系統(tǒng)在發(fā)貨時移交給集成單位或用戶單位。12.2應用考慮12.2.1安全手冊中對于安全應用的限制條件需要在手冊中詳細說明，包括安全模塊的應用范圍，響應時間約束等；12.2.2除了12.1.3的規(guī)定外，安全手冊還需要考慮如下適用內容：——安全功能可使用的那些功能和接口的規(guī)范，如應用限制、通信限制；——可導致危險的系統(tǒng)失效，并能被診斷測試檢測到的隨機硬件失效率的估計；——可導致危險的系統(tǒng)失效，并不能被診斷測試檢測到的隨機硬件失效率的估計；——對保持失效率有效性的環(huán)境限制；——預期系統(tǒng)所處的機械和氣候環(huán)境(如振動、沖擊、溫度、濕度);——制造商聲明的系統(tǒng)最大使用壽命，該壽命應等于或小于20年，除非系統(tǒng)制造商能提供證據證明更長的壽命，這些證據基于計算，表明其可靠性數(shù)據對于更長壽命是有效的；注：系統(tǒng)中的有些單個元件已知壽命小于20年。典型示例包括：電池、電解電容、LED等。如有必要，對這些元件的定期更換作為系統(tǒng)制造商規(guī)定的常規(guī)維護規(guī)程的一部分。定義最大20年使用壽命是為了覆蓋大部分未知壽命的系統(tǒng)元件?！ㄆ跈z驗測試方法、時間間隔和/或維護要求；——系統(tǒng)內部的診斷覆蓋率；——系統(tǒng)內部的診斷測試間隔；——如適用，平均恢復時間(MTTR)和平均維修時間(MRT);——安全失效分數(shù)(SFF);——硬件故障裕度；——為避免系統(tǒng)性失效建議的應用限制；——所用元件的降額；——適宜使用系統(tǒng)的安全相關系統(tǒng)的可聲明SIL;——系統(tǒng)的硬件版本；——系統(tǒng)已得到確認的文檔證據。13系統(tǒng)的確認13.1.1系統(tǒng)的確認需要符合GB/T20438.2—2017中7.7和GB/T20438.3—2107中7.7。13.1.2系統(tǒng)的確認方法可以考慮包括分析或測試。13.2.1保證安全要求規(guī)范中的所有內容都得到了確認，宜建立確認項與安全要求規(guī)范條款的對應關系矩陣，以清楚的顯示所有的確認關系。13.2.2確認的部分項目可以考慮在功能安全系統(tǒng)研發(fā)團隊內部進行(如功能測試),也可以考慮通過外部第三方實驗室開展(如型式試驗)。與確認相關的功能安全測試按照GB/T41295.3進行。14生命周期各個階段的驗證在執(zhí)行以上功能安全系統(tǒng)生命周期過程中，在每個階段的工作完成后，需要考慮開展對該階段的驗證工作。每個系統(tǒng)生命周期階段交付內容的驗證工作需要計劃、執(zhí)行和文檔化。這些驗證需要考慮到基于生命周期各階段輸入的規(guī)定。驗證所使用的技術/工具包括，例如：——階段性文檔的復審；——設計復審；——功能測試；——環(huán)境測試。注：驗證不要與校準和確認相混淆。15.1對功能安全系統(tǒng)制造的主要目的是保證制造過程的功能安全目標能夠得到保持。15.2功能安全系統(tǒng)制造團隊宜符合GB/T19001—2016的質量管理體系要求，包括設定質量負責人等崗位，編制質量計劃等文檔。注：本文件中對于功能安全系統(tǒng)的制造要求其核心在于所有的安全功能和安全完整性在制造過程能夠保持，而不是對于單純制造質量或生產效率提升的考慮，雖然GB/T19001—2016是對于質量體系的規(guī)定，但是很多基于良好工作實踐的規(guī)定可以避免制造過程的錯誤。15.3功能安全系統(tǒng)制造團隊編制功能安全系統(tǒng)的制造計劃，并至少考慮以下內容：——基本的生產要求，如工藝流程、裝配方案等；——安全相關的要求，如為了保證器件失效率而采取的篩選或老化測試的措施；——開發(fā)過程最后發(fā)布的產品配置情況；——預期制造裝備、測試設備和相關人員能力的要求；——對系統(tǒng)或系統(tǒng)內的組件的追溯方法(例如，編號、二維碼等)。15.4對于存在嵌入式軟件的系統(tǒng)，需要考慮制定相應規(guī)程，以保證在制造時將正確版本的嵌入式軟件下裝到系統(tǒng)中，包括下裝前的人工核對，下裝后的一致性檢查等。注：可以采用的措施包括校驗和比對，回讀比較等。15.5對于SIL3和SIL4應用的功能安全系統(tǒng)生產過程，需要考慮開展適當?shù)氖Х治觯治錾a