道路車輛功能安全審核及評估方法第2部分：概念階段和系統(tǒng)層面2023-11-27發(fā)布國家市場監(jiān)督管理總局國家標準化管理委員會IGB/T43253.2—2023 Ⅲ 12規(guī)范性引用文件 13術語和定義 14一般要求 15相關項定義 2 25.2審核及評估的輸入 25.3審核及評估的要求 26危害分析和風險評估 2 26.2審核及評估的輸入 36.3審核及評估的要求 37功能安全概念 4 47.2審核及評估的輸入 47.3審核及評估的要求 48技術安全概念 5 58.2審核及評估的輸入 68.3審核及評估的要求 69驗證和確認 8 89.2審核及評估的輸入 89.3審核及評估的要求 9附錄A(資料性)相關項定義 附錄B(資料性)危害分析和風險評估 附錄C(資料性)功能安全概念 附錄D(資料性)技術安全概念 附錄E(資料性)驗證和確認 參考文獻 Ⅲ本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規(guī)則》的規(guī)定起草。本文件是GB/T43253《道路車輛功能安全審核及評估方法》的第2部分。GB/T43253已經發(fā)布了以下部分：——第1部分：通用要求；——第2部分：概念階段和系統(tǒng)層面；——第3部分：軟件層面；——第4部分：硬件層面。請注意本文件的某些內容可能涉及專利。本文件的發(fā)布機構不承擔識別專利的責任。本文件由中華人民共和國工業(yè)和信息化部提出。本文件由全國汽車標準化技術委員會(SAC/TC114)歸口。本文件起草單位：中國汽車技術研究中心有限公司、中國第一汽車集團有限公司、深圳市大疆卓見科技有限公司、廣州汽車集團股份有限公司、上海機動車檢測認證技術研究中心有限公司、東軟睿馳汽車技術(上海)有限公司、中國長安汽車集團有限公司、知行汽車科技(蘇州)有限公司、北京地平線機器人技術研發(fā)有限公司、蔚來汽車科技(安徽)有限公司、舍弗勒(中國)有限公司、愛信(蘇州)汽車技術中心有限公司杭州分公司、重慶長安汽車軟件科技有限公司、北京國家新能源汽車技術創(chuàng)新中心有限公司。GB/T43253《道路車輛功能安全審核及評估方法》以GB/T34590《道路車輛功能安全》為基礎，適用于道路車輛上安全相關的電氣/電子(E/E)系統(tǒng)在安全生命周期內的審核及評估活動。安全是道路車輛開發(fā)的關鍵問題之一，車輛上包含的電氣、電子和軟件相關功能的數(shù)量不斷增加，強化了對功能安全的需求，以及對提供證據證明滿足功能安全目標的需求。為了確認電氣/電子(E/E)系統(tǒng)對于功能安全流程及功能安全要求的符合性，GB/T43253:a)提供了組織層面開展功能安全審核及評估的通用流程、實施方法及要求；b)提供了安全相關的電氣/電子(E/E)系統(tǒng)在概念階段、系統(tǒng)層面、軟件層面、硬件層面的功能安全審核及評估的過程、方法和要求；c)提供了功能安全審核及評估的檢查清單和參考示例。GB/T43253由4個部分構成。——第1部分：通用要求。目的是規(guī)定功能安全審核及評估活動在不同階段的通用要求?！?部分：概念階段和系統(tǒng)層面。目的是規(guī)定功能安全審核及評估活動在概念階段及系統(tǒng)層面的要求。——第3部分：軟件層面。目的是規(guī)定功能安全審核及評估活動在軟件層面的要求?！?部分：硬件層面。目的是規(guī)定功能安全審核及評估活動在硬件層面的要求。功能安全審核及評估活動伴隨功能安全開發(fā)過程的迭代，圖1為GB/T43253的整體架構，基于V模型為產品開發(fā)的不同階段、對象和范圍，提供審核及評估參考過程模型。1-5中核及產估氣共要求功能交全管班的宣核和評估1-6-1易能安全管理概念階裂的審核評信2-5E關頂定義2-6危害分析和風險評估系統(tǒng)層面的審核評估2-8技術安全境念開發(fā)2-9驗證和消認軟件層面的審核評估軟件層面的審核評估4-5碘科安全要采小父環(huán)城46碘設計3-6栽件實全縣求1-7傾外熱溝度量的評估3-7軟件架檢設計規(guī)范3-8軟件單元設計及實兀39軟什·單元測試3-7軟件架檢設計規(guī)范3-8軟件單元設計及實兀39軟什·單元測試3-10軟件典成手驗匯3-11能入式軟外澳試非肖安全口標句評估49原件集成不驗證3-12聯(lián)件標定和配氣管理/:產、送行、服務和報廢的審核評估{.、眼務和報廢支持過程的審核和評估3-13軟件糾件鑒定4-10硬件滅素已信1-67以汽車安全完整性等敘為導向和安全為導向的分析圖1功能安全審核及評估概覽IN1道路車輛功能安全審核及評估方法第2部分：概念階段和系統(tǒng)層面本文件規(guī)定了針對安全相關的電氣/電子(E/E)系統(tǒng)在概念階段和系統(tǒng)層面的功能安全相關活動和工作成果，開展功能安全審核及評估的要求和方法，以檢查和判斷開發(fā)過程及工作成果對于功能安全的符合性。本文件適用于安裝在除輕便摩托車外的量產道路車輛上的包含一個或多個電氣/電子(E/E)系統(tǒng)的與安全相關的系統(tǒng)。本文件不適用于特殊用途車輛上特定的電氣/電子(E/E)系統(tǒng)，例如，為殘疾駕駛者設計的車輛2規(guī)范性引用文件下列文件中的內容通過文中的規(guī)范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本(包括所有的修改單)適用于本文件。GB/T34590.1～34590.12—2022道路車輛功能安全GB/T43253.1—2023道路車輛功能安全審核及評估方法第1部分：通用要求GB/T43253.3—2023道路車輛功能安全審核及評估方法第3部分：軟件層面GB/T43253.4—2023道路車輛功能安全審核及評估方法第4部分：硬件層面3術語和定義GB/T34590.1—2022界定的術語和定義適用于本文件。4一般要求GB/T43253.1—2023中定義的審核及評估要求適用于本文件。概念階段和系統(tǒng)層面的功能安全審核及評估，主要涉及以下內容：——接受評估的相關項定義；——危害分析和風險評估；——功能安全概念開發(fā)；——技術安全概念開發(fā)；——驗證和確認。通過審核及評估，基于證據判斷功能安全概念及系統(tǒng)層面的功能安全開發(fā)，符合：——功能安全目標、功能安全概念和技術安全概念是恰當和完整的；——相關項設計實現(xiàn)了功能安全目標、功能安全概念和技術安全概念；——功能安全開發(fā)過程、方法及使用的工具是恰當?shù)摹?5相關項定義本章的目標是對作為功能安全開發(fā)對象的相關項的定義文檔進行審核及評估，以檢查其定義是否準確和充分，足以支持開展后續(xù)功能安全活動。5.2審核及評估的輸入為了開展本章規(guī)定的審核及評估過程，應具備以下輸入及其可能存在的驗證報告：——相關項定義文檔(含定義文檔及相關設計文檔的組合)。5.3審核及評估的要求對于相關項定義的審核及評估，應涵蓋表1中的檢查項。表1相關項定義的審核及評估檢查清單序號檢查清單1相關項需要滿足的標準及法規(guī)要求有哪些?2相關項在整車層面的功能行為是什么?3是否定義了相關項的運行場景和運行模式?4是否定義了相關項的非功能性需求?5是否定義了相關項的約束?6是否分析了相關項行為不足的潛在后果?7是否定義了執(zhí)行器的能力或假定了執(zhí)行器的能力?8是否清晰地定義了相關項的邊界、要素、接口及交互關系?9是否考慮了相關項的行為對整車影響的假設?是否考慮了其他相關項和要素要求本相關項提供的功能?是否考慮了本相關項要求其他系統(tǒng)和要素提供的功能?是否考慮了功能在所涉及的系統(tǒng)和要素間的分配?是否存在相關項定義的驗證報告?附錄A提供了針對相關項定義開展審核及評估的說明及示例。6危害分析和風險評估本章的目標是對危害分析和風險評估過程及分析結果進行審核及評估，以檢查：a)對電氣/電子(E/E)系統(tǒng)相關的功能異常表現(xiàn)引起的危害事件進行了完整識別和正確歸類；b)基于充分的理由，對識別出的危害事件進行了分級；c)針對分級后的危害事件，定義了充分的安全目標，以避免整車不合理的安全風險。36.2審核及評估的輸入為開展本章規(guī)定的審核及評估過程，應具備以下輸入及其可能存在的驗證報告：——包含電氣/電子(E/E)系統(tǒng)功能、運行場景、整車架構等內容的定義文檔；——危害分析和風險評估過程和結果報告；——針對危害分析和風險評估中相關假設、依據和結果的驗證確認計劃和結論。6.3審核及評估的要求對于危害分析和風險評估的審核及評估，應涵蓋表2和表3中的檢查項。表2危害分析和風險評估過程和結果的審核及評估檢查清單序號檢查清單1危害分析是否涵蓋了相關項的所有功能行為?是否與“相關項定義”階段的功能行為保持了一致性及可追溯性?2在危害分析和風險評估過程中，對相關項內部安全機制是否未作為評估依據?3對于相關項的功能異常表現(xiàn)導致的危害事件發(fā)生時所處的運行場景及運行模式是否進行了描述?是否考慮了可合理預見的誤用?4是否使用了系統(tǒng)性分析方法來確定危害?5是否在整車層面上，定義了由相關項的功能異常表現(xiàn)導致的危害?6危害分析過程中，是否識別出了因非電氣/電子(E/E)系統(tǒng)功能異常表現(xiàn)導致的危害?若有，是否具備組織的特定流程對其進行了妥善處理?7是否對危害相關的危害事件進行了充分描述?8是否正確、全面地識別了危害事件的后果，是否包含合理的連鎖反應后果?9運行場景列表的詳細程度和分類是否合理?是否存在人為降低了暴露概率的情況?針對所有已識別的因電氣/電子(E/E)系統(tǒng)功能異常表現(xiàn)引起的危害事件，是否都按照以下參數(shù)進行了分類：嚴重度等級S、運行場景的暴露概率等級E、可控性等級C?是否采取了保守分級的理念?針對嚴重度等級S的評級是否合理?是否有明確的評級原則，并基于原則給予了充分的理由說明?是否考慮到危害事件中全部的涉險人員?涉險人員是否考慮了目標市場中有代表性的樣本?針對運行場景本身會導致傷害的情況(例如事故),因電氣/電子(E/E)系統(tǒng)功能異常表現(xiàn)導致的危害，其嚴重度分級是否基于有無功能異常表現(xiàn)導致的傷害差異?是否存在SO評級的危害事件，若有，其評級理由是否充分?針對暴露概率等級E的評級是否合理?是否有明確的評級原則，并基于原則給予了充分的理由說明?在暴露概率評級時，是否排除了裝備相關項的車型數(shù)量的影響?是否存在場景評級為E0的危害事件，若有，其評級理由是否充分?針對可控性等級C的評級是否合理?是否有明確的評級原則，并基于原則給予了充分的理由說明?對于可控性的評級是否存在必要的確認?是否基于S、E、C分級，按照GB/T34590.1～34590.12—2022正確地確定了每個危害事件的ASIL等級?對于S3和C3,而ASIL評級為QM的危害事件，其暴露概率的評級是否有充分的理由?是否為每一個具有ASIL等級的危害事件都確定了其安全目標?合并后的安全目標的ASIL等級是否為其對應危害事件的最高ASIL等級?安全目標的屬性和特性定義、安全目標的管理是否符合安全要求定義和管理的要求?4表3針對危害分析和風險評估的驗證和確認的審核及評估檢查清單序號檢查清單1在進行危害分析和風險評估過程中，是否使用到了或從中得出了假設?若存在假設，是否在安全確認階段對這些假設進行了確認?2是否按照表6中關于驗證的檢查清單的要求對危害分析和風險評估包括安全目標進行了充分的驗證，且具備相應的證據?附錄B提供了針對危害分析和風險評估開展審核及評估的說明及示例。7功能安全概念7.1目標本章的目標是對功能安全概念開發(fā)過程及結果進行審核及評估，以檢查：a)對電氣/電子(E/E)系統(tǒng)與安全目標相關的功能行為、功能降級行為進行了完整的定義；b)針對電氣/電子(E/E)系統(tǒng)安全相關故障，定義了恰當?shù)牟呗曰虼胧?，以進行充分和及時的探測、約束和減輕；c)將識別出的策略和措施以及定義的功能安全要求，分配給系統(tǒng)架構設計或外部措施；d)針對上述過程開展了充分的驗證，并定義了合理的安全確認準則。7.2審核及評估的輸入為開展本章規(guī)定的審核及評估過程，應具備以下輸入及其可能存在的驗證報告：——包含電氣/電子(E/E)系統(tǒng)功能、運行場景、整車架構等內容的定義文檔；——危害分析和風險評估過程和結果報告；——系統(tǒng)架構設計文檔；——功能安全概念報告；——功能安全驗證和確認計劃和報告。7.3審核及評估的要求對于電氣/電子系統(tǒng)功能安全概念文檔內容的審核及評估，應涵蓋表4中的檢查項。表4功能安全概念的審核及評估檢查清單序號檢查清單1功能安全要求的屬性和特性、功能安全要求的管理是否符合安全要求定義和管理的要求?2功能安全要求是否由安全目標導出?在定義功能安全要求時，是否考慮了系統(tǒng)架構設計?3每個安全目標是否都可追溯到至少一項功能安全要求?4如果適用，在功能安全要求中是否定義了故障避免的策略?5如果適用，在功能安全要求中是否定義了故障探測的策略，以及對故障或其導致的功能異常表現(xiàn)的控制策略?6如果適用，在功能安全要求中是否定義了過渡到安全狀態(tài)的策略，及如果適用，過渡出安全狀態(tài)的策略?7如果適用，在功能安全要求中，是否定義了故障容錯的策略?5表4功能安全概念的審核及評估檢查清單(續(xù))序號檢查清單8如果適用，在功能安全要求中，是否定義了故障情況下的功能降級策略?是否定義了功能降級與駕駛員警告之間的交互策略?針對不同故障風險，駕駛員警告機制是否明確和有效?9如果適用，故障處理時間間隔的定義是否滿足故障容錯時間間隔的要求?如果適用，對于不同功能的多個控制請求，是否定義了仲裁策略，以避免或減輕可能導致的危害風險?是否進行了安全分析以得到完整有效的功能安全要求?行時間間隔及功能冗余?在功能安全要求中，是否定義了相應的一個或多個安全狀態(tài)以避免安全目標的違背?是否對相關項過渡到安全狀態(tài)的時間間隔進行了分析?對于不能在可接受的時間間隔內過渡到安全狀態(tài)的情況，是否定義了緊急運行?在功能安全概念中，是否對避免違反安全目標的駕駛員或其他人員的必要行動進行了假設?若存在，是否在功能安全概念中對其進行了定義，并定義了可供駕駛員或其他人員使用的足夠的方法和控制手段?是否將功能安全要求分配給了系統(tǒng)架構設計中的要素?ASIL等級等信息是否與安全目標保持一致?如果應用了ASIL等級分解，是否符合GB/T43253.1—2023中6.7關于ASIL等級分級的檢查清單的要求?承接功能安全要求的架構要素的開發(fā)是否符合這些安全要求的初始最高ASIL等級?若使用了ASIL等級分解，則承接初始安全要求的不同架構要素間的獨立性，是否根據GB/T43253.1—2023中表22要素共存的檢查清單的要求進行了證明?針對包含多個電氣/電子(E/E)系統(tǒng)的相關項，是否定義了各個電氣/電子(E/E)系統(tǒng)以及系統(tǒng)之間接口的功能安全要求?如果適用，是否在功能安全概念中為各個電氣/電子(E/E)系統(tǒng)分配了隨機硬件故障度量目標值?若存在功能安全要求的ASIL等級分解，是否符合GB/T43253.1—2023中6.7關于ASIL等級分解的檢查清單的要求?若功能安全概念的實現(xiàn)需要基于其他技術的要素，則針對這些其他技術要素，是否合理分配了功能安全要求及屬性?是否定義了與其他技術要素的接口相關的功能安全要求?這些要求及屬性的實現(xiàn)是否具備充分的措施保證，并進行了必要的驗證和確認?如果適用，在定義功能安全概念時，是否考慮了外部措施的功能安全要求?是否依據功能安全要求和安全目標定義了相關項安全確認的接受準則?是否按照本表檢查清單的要求對功能安全概念進行了充分的驗證，且具備相應的證據證明功能安全概念與安全目標的一致性和符合性，及功能安全概念減輕或避免危害的能力?附錄C提供了針對功能安全概念開展審核及評估的說明及示例。8技術安全概念本章的目標是對以技術安全概念和技術安全需求為核心的系統(tǒng)層面產品開發(fā)階段的相關工作成果進行審核及評估，以檢查其定義是否符合功能安全開發(fā)的需要。68.2審核及評估的輸入為開展本章規(guī)定的審核及評估過程，應具備以下輸入及其可能存在的驗證報告：——危害分析和風險評估報告；——功能安全概念；——其他涉及安全的相關項，對此相關項的要求(如果適用);——技術安全需求規(guī)范；——技術安全概念；——系統(tǒng)架構規(guī)范；——軟硬件接口(HSI)規(guī)范；——安全分析報告。8.3審核及評估的要求對技術安全概念開發(fā)的相關工作成果的審核及評估應涵蓋表5中的檢查項。注：由于技術安全概念開發(fā)設計工作成果較多，表5按照技術安全概念、架構設計方案、技術安全需求規(guī)范、軟硬件接口規(guī)范和生產、運行、服務和報廢的需求規(guī)范的順序組織檢查項。安全機制的設計檢查納入技術安全需求規(guī)范的檢查項中。表5技術安全概念開發(fā)活動的審核及評估檢查清單序號檢查清單1如果存在其他涉及安全的相關項對本系統(tǒng)的安全要求，是否作為系統(tǒng)層面開發(fā)階段技術安全概念的設計輸入?2是否存在包含系統(tǒng)層面開發(fā)階段的系統(tǒng)架構設計的系統(tǒng)架構規(guī)范?技術安全概念和該系統(tǒng)架構規(guī)范的系統(tǒng)架構設計描述是否基于相關項定義、功能安全概念和先前的系統(tǒng)架構設計?并保持一致?如果存在不一致，是否通過恰當?shù)幕顒舆M行迭代?3系統(tǒng)層面開發(fā)階段的系統(tǒng)架構設計是否能實現(xiàn)技術安全要求?4系統(tǒng)架構設計是否識別了安全相關要素及其內外部接口?是否具備恰當?shù)拇胧┐_保其他要素不會對這些安全相關要素產生不利的安全影響?5如果在系統(tǒng)層面開發(fā)階段的系統(tǒng)架構設計對安全要求進行ASIL等級分解，分解的實施是否符合GB/T43253.1—2023中6.7關于ASIL等級分解的檢查清單的要求?6是否根據對應的ASIL等級，按照GB/T34590.4—2022中表1的要求進行技術安全概念階段的系統(tǒng)架構設計的安全分析?7技術安全概念是否消除已識別出的引起失效的內部原因和外部原因，或在必要時減輕它們的影響?8技術安全概念是否復用值得信賴的系統(tǒng)設計原則?如果復用，是否對設計原則的適用性進行了分析并形成了文檔?9系統(tǒng)層面開發(fā)階段的系統(tǒng)架構設計是否具有以下特征?a)模塊化；b)適當?shù)念w粒度水平；7表5技術安全概念開發(fā)活動的審核及評估檢查清單(續(xù))序號檢查清單在安全分析或系統(tǒng)架構設計過程中，是否識別到新的尚未被安全目標涵蓋的危害?若有，是否更新到危害分析和風險評估(HARA)中?技術安全要求中定義的安全機制是否充分，以探測故障并防止或減輕出現(xiàn)在系統(tǒng)輸出端的、導致違反功能安全要求的失效?對于使相關項實現(xiàn)或維持安全狀態(tài)的每個安全機制的定義，是否完整?對于ASIL(A)、(B)、C和D等級，如果適用，是否定義了充分的安全機制，以防止隨機硬件故障的多點故障變?yōu)闈摲收?對于ASIL(A)、(B)、C和D等級，為了避免多點失效，用于探測多點故障的安全機制的診斷測試策略是否合理?對于ASIL(A)、(B)、C和D等級，專門用于防止雙點故障變成潛伏故障的安全機制的開發(fā)是否符合要求?是否根據系統(tǒng)架構設計，定義了充分地探測、控制或減輕隨機硬件失效的措施?對于ASIL(B)、C和D等級，針對隨機硬件失效導致違背安全目標的可能性是否定義了明確的目標值?是否按照GB/T34590.5—2022第9章的要求，使用備選分析方法中的一個方法進行了評估?對于ASIL(B)、C和D等級，如果適用，是否在要素層面定義了適當?shù)氖屎驮\斷覆蓋率的目標值要求?對于ASIL(B)、C和D等級，針對分布式開發(fā)，推導出的失效率和診斷覆蓋率的目標值是否通報給每個相關團隊?技術安全需求規(guī)范中安全機制的定義是否與安全分析的結果一致?是否按照功能安全概念、系統(tǒng)架構設計來定義技術安全要求?是否在技術安全要求中定義了系統(tǒng)對影響安全要求實現(xiàn)的激勵的響應(包括各種相關運行模式下和定義的系統(tǒng)狀態(tài)下，激勵與失效的組合)?除技術安全要求已定義的那些功能外，如果其他功能或要求也由該系統(tǒng)或其要素實現(xiàn)，是否定義了這些功能或要求，或者參考其規(guī)范?技術安全要求和非安全要求是否存在矛盾?技術安全要求是否全部分配給以系統(tǒng)、硬件或軟件作為實施技術的系統(tǒng)架構設計要素?技術安全要求的分配和分區(qū)決策是否符合系統(tǒng)架構設計?每個系統(tǒng)架構設計要素的ASIL等級是否繼承其實現(xiàn)的技術安全要求的最高的ASIL等級?如果系統(tǒng)架構要素中存在分配了不同ASIL等級的子要素(或部分子要素為非安全相關),是否全部子要素都按照要素的最高ASIL等級進行了開發(fā)?對于按照各自不同ASIL等級開發(fā)的子要素，他們是否符合第1部分表22關于要素共存的檢查清單的要求?對于分配了技術安全要求的具備可編程功能的定制化硬件要素，是否定義和實施了適當?shù)拈_發(fā)流程?如果適用，技術安全要求是否包含因實施ASIL等級分解而產生的獨立性要求?技術安全要求的定義和管理是否符合安全要求的定義和管理的要求?是否存在定義了硬件和軟件交互的軟硬件接口(HSI)規(guī)范作為工作成果?軟硬件接口(HSI)規(guī)范中考慮的軟硬件接口要素是否完善?并保持與技術安全概念一致?8表5技術安全概念開發(fā)活動的審核及評估檢查清單(續(xù))序號檢查清單軟硬件接口規(guī)范中考慮的軟硬件接口要素特性是否完善?是否定義了相關運行模式和配置參數(shù)?是否定義了確保要素間獨立性或支持軟件分區(qū)的硬件特性?是否定義了硬件資源的共用和專用?是否定義了硬件設備的訪問機制?是否由技術安全概念導出了時間約束?是否在軟硬件接口規(guī)范中定義硬件的相關診斷能力和軟件對其的使用?是否定義在系統(tǒng)架構設計過程中識別出的對生產、運行、服務和報廢的技術安全要求?是否定義需具備的診斷特性以提供對系統(tǒng)進行現(xiàn)場監(jiān)控所需的數(shù)據?是否定義診斷特性以便服務時能夠識別故障并對維護或修復的有效性進行檢查?是否對技術安全要求進行驗證，以提供其在給定系統(tǒng)邊界條件下的正確性、完整性和一致性的證據?是否按照GB/T34590.4—2022中表2要求的驗證方法，對技術安全概念、系統(tǒng)架構設計、軟硬件接口(HSI)規(guī)范以及生產、運行、服務和報廢的需求規(guī)范進行了驗證?附錄D提供了針對技術安全概念開展審核及評估的說明及示例。9驗證和確認本章的目標是對驗證和確認的相關工作成果進行審核及評估，以檢查：a)相關項要素的集成是否根據系統(tǒng)化的方法，完成軟硬件集成和驗證、系統(tǒng)集成和驗證、整車集成和驗證；b)驗證由系統(tǒng)架構層級安全分析定義的安全措施是否得到正確的實施；c)是否有證據表明所集成的系統(tǒng)要素滿足按照系統(tǒng)架構設計的安全要求；d)驗證工作成果是否符合相應的要求；e)是否有證據證明集成到目標車輛的相關項實現(xiàn)了其安全目標；f)是否有證據證明功能安全概念和技術安全概念對于實現(xiàn)相關項的功能安全是合適的。9.2審核及評估的輸入為了開展本章規(guī)定的審核及評估過程，應具備以下輸入及其可能存在的驗證報告：——功能安全概念；——技術安全概念；——架構設計規(guī)范；——軟硬件接口規(guī)范；——集成和測試策略；——集成和測試報告；——驗證計劃；——驗證規(guī)范；——驗證報告；——危害分析和風險評估報告；——包含安全確認環(huán)境描述的安全確認規(guī)范；9——安全確認報告。9.3審核及評估的要求對于驗證和確認的審核及評估，應涵蓋表6和表7中的檢查項。表6集成驗證活動的審核及評估檢查清單序號檢查清單1系統(tǒng)架構設計是否按照表5的檢查清單進行了審核評估，結果是否符合功能安全和技術安全要求?是否按計劃開展了集成測試活動?驗證以下方面：a)功能安全要求及技術安全要求是否正確實施；b)安全機制是否具有正確的功能性能、準確性和時序；c)接口是否具有一致性和正確實施；d)系統(tǒng)架構設計是否有足夠的魯棒性2定義集成和測試策略時是否考慮系統(tǒng)架構規(guī)范、功能安全概念和技術安全概念?a)是否有合適的能夠提供功能安全證據的測試目標；b)相關項的集成和測試是否有助于安全概念的驗證3a)相關項集成和測試策略的定義是否包括了軟硬件集成和測試規(guī)范；b)相關項集成和測試策略的定義是否包括系統(tǒng)和整車層面的集成測試規(guī)范。軟硬件驗證的未解決問題是否已處理；c)相關項集成和測試策略是否考慮車輛系統(tǒng)(相關項內部和外部)與環(huán)境之間的接口；d)若相關項集成了以獨立于環(huán)境的要素(SEooC)方式進行開發(fā)的系統(tǒng)或要素，在相關項集成和測試策略中是否考慮了對SEooC開發(fā)過程中做過的假設進行驗證?4系統(tǒng)或整車層面的驗證是否提供證據證明用于量產實施層面的配置符合安全要求?5在整個集成子階段，對于每條功能安全要求和技術安全要求的符合性，是否至少進行過一次驗證?6是否恰當?shù)囟x集成測試的測試用例?集成測試的測試用例是否使用合適的方法導出?7是否按照GB/T43253.3—2023和GB/T43253.4—2023檢查清單的要求進行軟硬件的開發(fā)?是否完成軟硬件的集成?是否對集成后的硬件和軟件進行測試?8是否通過測試證明了集成后的軟件和硬件符合軟硬件接口規(guī)范的要求?9對于軟硬件集成測試的目標，是否通過使用適當?shù)臏y試方法得到了實現(xiàn)?是否通過合適的測試方法(基于需求的測試、故障注入測試、背靠背測試等)來證明技術安全要求的安全相關功能和行為在軟硬件層面的正確執(zhí)行?對于ASIL(A)、B、C和D等級，是否通過合適的測試方法(背靠背測試、性能測試等)對安全機制在軟硬件層面的功能性能、準確性和時序進行論證?對于ASIL(A)、B、C和D等級，是否通過合適的測試方法(外部接口測試、內部接口測試、接口一致性檢查等)來證明外部和內部接口在軟硬件層面執(zhí)行的一致性和正確性?對于ASIL(A)、(B)、C和D等級，是否通過合適的測試方法(故障注入測試、錯誤猜測法測試等)對故障模型，硬件故障探測機制在軟硬件層面上的有效性進行論證?對于ASIL(A)、(B)、(C)和D等級，是否通過合適的測試方法(資源使用測試、壓力測試等)對要素在軟硬件層面的魯棒性水平進行論證?系統(tǒng)的各個要素是否按照系統(tǒng)架構設計進行集成?系統(tǒng)的各個要素是否按照系統(tǒng)集成測試規(guī)范進行測試?表6集成驗證活動的審核及評估檢查清單(續(xù))序號檢查清單對于系統(tǒng)集成測試的目標，是否通過使用適當?shù)臏y試方法得到了實現(xiàn)?是否通過合適的測試方法(基于需求的測試、故障注入測試、背靠背測試等)來證明功能安全和技術安全要求在系統(tǒng)層面的正確執(zhí)行?對于ASIL(A)、(B)、(C)和D等級，是否通過合適的測試方法(背靠背測試、故障注入測試、性能測試、錯誤猜測法測試、來自現(xiàn)場經驗的測試等)對安全機制在系統(tǒng)層面的正確功能性能、準確性、系統(tǒng)層面失效模式的覆蓋率、時序進行論證?是否通過合適的測試方法(外部接口測試、內部接口測試、接口一致性檢查、通信和交互測試等)來證明外部和內部接口在系統(tǒng)層面執(zhí)行的一致性和正確性?是否通過合適的測試方法(資源使用測試、壓力測試、特定環(huán)境條件下的抗干擾性和魯棒性測試等)對系統(tǒng)層面的魯棒性水平進行論證?是否將相關項集成到整車上?是否實施整車集成測試?是否對相關項與車內通信網絡以及車內供電網絡的接口規(guī)范進行驗證?整車集成測試的測試目標是否使用適當?shù)臏y試方法來實現(xiàn)?是否通過合適的測試方法(基于需求的測試、故障注入測試、長期測試、實際使用條件下的用戶測試等)對功能安全要求在整車層面的正確執(zhí)行進行論證?對于ASIL(A)、(B)、C和D等級，是否通過合適的測試方法(性能測試、長期測試、實際使用條件下的用戶測試、故障注入測試、錯誤猜測法測試、來自現(xiàn)場經驗的測試等)對安全機制在整車層面的正確功能性能、準確性和時序進行論證?對于ASIL(A)、(B)、C和D等級，是否通過合適的測試方法(內部接口測試、外部接口測試、通信和交互測試等)對整車層面內部和外部接口實現(xiàn)的一致性和正確性進行論證?對于ASIL(A)、(B)、C和D等級，是否通過合適的測試方法(資源使用測試、壓力測試、特定環(huán)境條件下的抗干擾性和魯棒性測試、長期測試等)對整車層面的魯棒性水平進行論證?是否針對安全生命周期的每個階段及子階段，制定了對應的驗證計劃?制定的驗證計劃中，是否包括了需驗證的工作成果內容?制定的驗證計劃中，是否包括了驗證的目的?制定的驗證計劃中，是否包括了用于驗證的方法?制定的驗證計劃中，是否包括了驗證通過和不通過的準則?如果適用，制定的驗證計劃中，是否包括了驗證環(huán)境、用于驗證的設備、用于驗證的資源?制定的驗證計劃中，是否包括了當探測出異常時需采取的行動?制定的驗證計劃中，是否包括了回歸策略?制定驗證計劃是否考慮到所適用驗證方法的充分性?是否考慮到需驗證的工作成果的復雜性?是否考慮到與驗證目標材料相關的前期經驗?是否考慮到所使用技術的成熟度，或使用這些技術的風險?驗證規(guī)范中是否對用于驗證的方法進行細化?細化的內容是否包含了評審或分析的檢查清單；或模擬場景；或測試用例、測試數(shù)據和測試目標?表6集成驗證活動的審核及評估檢查清單(續(xù))序號檢查清單對于測試，每條測試用例的定義是否包含以下內容：a)唯一的識別；b)需驗證的相關工作成果的版本的參考；c)前提條件和配置；d)環(huán)境條件(如果適用);e)輸入數(shù)據、數(shù)據時序及其值；f)期望的表現(xiàn)，包括輸出數(shù)據、輸出值的可接受范圍、時間表現(xiàn)和公差表現(xiàn)；g)確定測試用例通過和不通過的準則?對于測試，是否從所需的測試設備或測試環(huán)境、邏輯和時間的依賴性、資源這幾個方面考慮來按使用的測試方法對測試用例進行分組?對于測試，測試用例是否由與待驗證的工作成果的完成人不同的人進行評審?是否按照驗證計劃和驗證規(guī)范，執(zhí)行驗證?驗證是否由與待驗證的工作成果的完成人不同的人執(zhí)行?對驗證結果的評估是否包含以下信息：a)所驗證工作成果的唯一識別；b)驗證計劃和驗證規(guī)范的參考；c)如果適用，評估中用到的驗證環(huán)境配置、驗證工具及標定數(shù)據；d)驗證結果與期望結果的一致性水平；e)驗證通過或不通過的明確的陳述，如果驗證不通過，陳述應包含不通過的理由和對所驗證工作成果進行修改的建議；f)每個驗證步驟未執(zhí)行的理由?用于驗證的測試設備是否提供有效的和可重復的結果，并應按照所采用的質量管理體系進行管控?附錄E中的E.1提供了針對集成驗證活動開展審核及評估的說明及示例。表7確認活動的審核及評估檢查清單序號檢查清單1是否對整車層面的典型環(huán)境下所集成的相關項的安全目標進行確認?2是否考慮基于車型和車輛配置的典型車輛來定義典型環(huán)境?3對于危害分析和風險評估中考慮的、影響相關項技術特性的運行變化，在安全目標的確認過程中是否進行了考量?4是否定義安全確認規(guī)范，包括：a)待安全確認的相關項配置，包括其標定數(shù)據，按照GB/T34590.6—2022中的附錄C;b)安全確認流程、測試案例、駕駛操作和接受準則的定義；c)設備和要求的環(huán)境條件。5整車安全確認是否使用了恰當?shù)姆椒?若使用測試進行整車安全確認，是否對測試規(guī)范、測試的執(zhí)行和測試結果的評估進行了規(guī)范性檢查?表7確認活動的審核及評估檢查清單(續(xù))序號檢查清單6整車安全確認是否對可控性進行評估?整車安全確認是否對外部措施的有效性進行評估?整車安全確認是否對其他技術要素的有效性進行評估?整車安全確認是否對影響危害分析與風險評估中ASIL等級的假設進行評估?7整車層面的安全確認是否基于安全目標、功能安全要求和預期用途?每個安全目標的安全確認流程和測試用例，是否都包括詳細的通過/未通過準則?整車層面的安全確認是否考慮其應用范圍?8安全確認是否通過以下方法的適當組合予以實施?——定義了測試流程、測試案例和通過/未通過準則的可重復性測試；——安全分析方法；——長期測試；——基于實際使用條件的測試；——抽檢和盲測；——基于專家經驗的測試；——評審9安全確認的結果是否進行評估?安全確認的結果是否能夠提供證據證明已實施的安全目標實現(xiàn)了相關項的功能安全?E.2提供了針對確認活動開展審核及評估的說明及示例。(資料性)相關項定義相關項定義的審核及評估的說明及示例見表A.1。表A.1相關項定義的審核及評估的說明及示例序號檢查清單說明及示例1相關項需要滿足的標準及法規(guī)要求有哪些?對相關項需要滿足的法規(guī)、國家標準和國際標準進行描述，包含法規(guī)名稱、標準號、標準名稱、標準版本號、標準發(fā)布日期等2相關項在整車層面的功能行為是什么?如果適用，則：a)應從輸入、處理、輸出等方面對功能進行描述；b)應描述相關項的內部限制；例如：××相關項×××功能工作的速度范圍是55km/h～120km/h;c)應描述功能的使用場景3是否定義了相關項的運行場景和運行模式?運行場景的定義考慮功能的正常使用及可合理預見的誤用場景，還應與目標市場相關聯(lián)。定義運行模式，應包含如下內容。a)對于模式的定義。如模式名稱、模式的描述、該模式下允許及禁用的功能的定義。b)定義模式之間的轉換關系。包含當前模式、下一模式、模式跳轉的條件及時間約束、模式跳轉后要執(zhí)行的動作及時間約束等。為了使運行模式定義清晰明了，可采用模式流轉關系圖來表達，示例見圖A.14是否定義了相關項的非功能性需求?量要求等。例如：a)對于安裝要求，可描述出安裝位置、安裝方法等；的要求；機工作溫度范圍、電機額定轉矩、電機額定轉速等；5是否定義了相關項的約束?a)功能依賴性：如車道線檢測橫向誤差≤10cm,如LKA系統(tǒng)不具備處理復雜交通狀況或環(huán)境突變等特殊工況的能力，當LKA功能介入控制時，需要駕駛員對路面狀況保持警惕；b)其他相關項的依賴性：當EPS檢測到駕駛員的手力矩>3N·m時，退出對LKA的扭矩請求響應；c)運行環(huán)境：如功能適用的道路類型、相關項對于天氣、光照條件等的約束表A.1相關項定義的審核及評估的說明及示例(續(xù))序號檢查清單說明及示例6是否分析了相關項行為不足的潛在后果?如果適用，應列出已知的失效模式及潛在的危害后果，可采用HAZOP方法進行分析。如果適用，應總結之前類似或相關的相關項的經驗教訓7是否定義了執(zhí)行器的能力或假定了執(zhí)行器的能力?的力、運行速度、亮度、音量等的值或其估算值8是否清晰地定義了相關項的邊界、要素、接口及交互關系?如果適用，可采用初始架構框圖的形式展現(xiàn)，要求展現(xiàn)出相關項的各個要素及要素之間的連接交互關系。示例見圖A.2。參數(shù)指標、承擔的功能等。在描述相關項的接口及交互關系時，如果適用，可描述接口所傳遞的信號或數(shù)據、接口的形式、接口的收發(fā)關系、信號或數(shù)據的優(yōu)先順序等9是否考慮了相關項的行為對整車影響的假設?根據相關項的邊界及接口的定義，考慮本相關項的輸出對整車的影響。例如：采用分析、仿真和測試手段是否考慮了其他相關項和要素要求本相關項提供的功能?例如，LKA相關項要求EPS提供的功能，當EPS檢測到駕駛員的手力矩>3N·m時，EPS提供超控響應功能，即要求EPS退出對LKA的扭矩請求響應是否考慮了本相關項要求其他相關項和要素提供的功能?例如，EPS相關項要求制動電子控制系統(tǒng)相關項提供車速信號是否考慮了功能在所涉及的系統(tǒng)和要素間的分配?如果適用，可按照功能劃分，分別繪制各個功能的初始架構框圖，以表明功能在所涉及的系統(tǒng)和要素間的分配情況是否存在相關項定義的驗證報告?針對相關項的定義文檔及相關信息進行評審，以確保功能安全開發(fā)輸入的準確性和充分性啟動條件探測到故障探測到故障關閉條件初始化滿足初始化完成條件探測到故障運行故障消除滿足功能關閉條件滿足下電條件滿足下電完成條件關閉故障圖A.1模式流轉關系圖示例十十CAN總線傳感器采集模塊中央控制單元相關項邊異電機位置傳感器扭矩傳感器轉角傳感器電機驅轉向管柱圖A.2相關項架構框圖示例(資料性)危害分析和風險評估危害分析和風險評估的審核及評估的說明及示例見表B.1、表B.2。表B.1危害分析和風險評估的審核及評估的說明及示例序號檢查清單說明及示例1危害分析是否涵蓋了相關項的所有功能行為?是否與“相關項定義”階段的功能行為保持了一致性及可追溯性?2在危害分析和風險評估過程中，對相關項內部安全機制是否未作為評估依據?即在危害分析和風險評估過程中，不宜考慮將要實施或已經在先前相關項中實施的安全機制3對于相關項的功能異常表現(xiàn)導致的危害事件發(fā)生時所處的運行場景及運行模式是否進行了描述?是否考慮了可合理預見的誤用?a)在進行運行場景描述時，如果適用，參考GB/Z42285—景等)、車內外交通參與者(行人經過等)等方面進行描述。b)對于可合理預見的誤用，可從駕駛員潛在的錯誤識別、決定和操作入手，給出分析4是否使用了系統(tǒng)性分析方法來確定危害?a)FMEA方法和HAZOP適用于支持相關項層面的危害識別。這些可通過頭腦風暴、檢查表、質量歷史記錄和現(xiàn)場研究來支持。b)在進行HAZOP分析時，如果適用，可參考GB/Z42285—2022,從如下幾個方面對相關項功能進行分析，以確定危害：——功能喪失(在有需求時，不提供功能);——在有需求時，提供錯誤的功能(多于預期、少于預期、方向相反);——非預期的功能(在無需求時，提供功能);——輸出卡滯在固定值上(功能不能按照需求更新)5是否在整車層面上，定義了由相關項的功能異常表現(xiàn)導致的危害?可從車輛行為或人員可感受到的表現(xiàn)出發(fā)，描述整車層面的影響，例如，非預期的減速，而非非預期的制動壓力6危害分析過程中，是否識別出了因非電氣/電子(E/E)系統(tǒng)功能異常表現(xiàn)導致的危害?若有，是否具備組織的特定流程對其進行了妥善處理?a)由相關項非失效情況下的行為導致的危害，不屬于本文件的范圍。異常表現(xiàn)而引起的。c)若識別出上述范圍外的危害，應進行記錄，并明確組織處理流程、責任人、處理結果等表B.1危害分析和風險評估的審核及評估的說明及示例(續(xù))序號檢查清單說明及示例7是否對危害相關的危害事件進行了充分描述?a)危害事件應由運行場景和危害的相關組合確定。b)危害事件的定義應足夠，以支持我們在后續(xù)的風險評估中得到完整的、最危險的結果8是否正確、全面地識別了危害事件的后果，是否包含合理的連鎖反應后果?如果相關項層面的功能異常表現(xiàn)導致該相關項喪失多個功能，則場景分析和危害識別要考慮其綜合影響。示例1:制動電子控制系統(tǒng)的功能喪失可能導致駕駛輔助功能同步無效。示例2:整車供電系統(tǒng)的失效可能導致同時喪失一系列功能，包括發(fā)動機扭矩、助力轉向及前向照明9運行場景列表的詳細程度和分類是否合理?是否存在人為降低了暴露概率的情況?環(huán)境條件的運行場景列表，會使得用于危害事件分類的場景的顆粒度更為精細。這可更容易地評估可控性和嚴重度。然而，大量的不同運行場景可能導致相應地降低各自的暴露等級，從而導致不恰當?shù)亟档虯SIL等級。這可通過合并類似的場景來避免針對所有已識別的因電氣/電子(E/E)系統(tǒng)功能異常表現(xiàn)引起的危險事件，是否都按照以下參數(shù)進行了分類：嚴重度等級S、運行場景的暴露概率等級E、可控性等級C?是否采取了保守分級的理念?如果難以對一個給定的危害進行嚴重度(S)、暴露概率(E)或可合理的懷疑，就采用較高的S、E或C等級針對嚴重度等級S的評級是否合理?是否有明確的評級原則，并基于原則給予了充分的理由說明?是否考慮到危害事件中全部的涉險人員?涉險人員是否考慮了目標市場中有代表性的樣本?a)應制定明確的嚴重度S評級標準。評級原則和理由例如GB/T34590.3—2022中表B.1,及GB/Z42285—2022中表B.1基于碰撞速度的S分級原則。b)針對每一個危害事件，應依據評分標準，給出確定的理由來說明S0、S1、S2或S3確定的合理性。c)除引起危害事件的車輛的駕駛員或乘客，還需考慮其他潛在的處于風險中的人員，如騎自行車的人員、行人或其他車輛上的人員。d)對于涉險人員的代表性樣本，例如上海老齡化比例e)如果出現(xiàn)了SO嚴重度等級，則應提供足夠的證據，證明后果明顯僅限于物體損壞并不涉及對人員的傷害，此時無需分配ASIL等級針對運行場景本身會導致傷害的情況(例如事故),因電子/電氣(E/E)系統(tǒng)功能異常表現(xiàn)導致的危害，其嚴重度分級是否基于有無功能異常表現(xiàn)導致的傷害差異?功能。如果事故發(fā)生時安全氣囊未能正常打開，那么由碰撞導致的傷害可被確定。如果相同事故中安全氣囊正常打開可將傷害降低到一個較低的嚴重度等級，那么,在嚴重度評級時只需考慮兩者的差異。是否存在SO評級的危害事件，若有，其評級理由是否充分?相關項的功能異常表現(xiàn)的后果僅限于物損，不涉及人員傷害表B.1危害分析和風險評估的審核及評估的說明及示例(續(xù))序號檢查清單說明及示例針對暴露概率等級E的評級是否合理?是否有明確的評級原則，并基于原則給予了充分的理由說明?a)應制定明確的暴露概率E評分標準，包括基于場景的持續(xù)時間和基于場景發(fā)生的頻率兩種?？蓞⒖糋B/T34590.3—2022中表B.2～表B.5或目標市場運行場景的統(tǒng)計數(shù)據等，給出評級標準與GB/T34590.1～34590.12—2022暴露概率等級E0、E1、E2、E3或E4的對應關系。b)針對每一個危害事件，應依據評級標準，給出確定的理由來說明E0、E1、E2、E3或E4確定的合理性在暴露概率評級時，是否排除了裝備相關項的車型數(shù)量的影響?暴露概率的評估是基于假設每個車輛都配備有該相關項進行的。這意味著“因為該相關項未裝備在每臺車輛上(只有一些車輛裝備該相關項),所以暴露概率會降低”的觀點是不成立的是否存在場景評級為E0的危害事件，若有，其評級理由是否充分?如果出現(xiàn)了EO暴露概率等級，則應提供足夠的證據，證明該場景是不尋?；蛄钊穗y以置信的，此時無需分配ASIL等級。例如：a)極其不尋常的或不可能同時發(fā)生的情況，例如車輛涉及在高速公路上降落的飛機的事故。針對可控性等級C的評級是否合理?是否有明確的評級原則，并基于原則給予了充分的理由說明?對于可控性的評級是否存在必要的確認?a)應制定明確的可控性等級C的評級標準。可參考GB/T34590.3—2022中表B.6。b)針對每一個危害事件，應依據評分標準，給出確定的理由來說明C0、C1、C2或C3確定的合理性。c)如果出現(xiàn)了C0可控性等級，則應提供足夠的證據，證明危害不影響車輛的安全運行，或者可通過常規(guī)的駕駛員行為輔助系統(tǒng)不可用的危害。d)對于可控性的預估，應在驗證和確認階段對可控性分級的合理性進行檢查是否基于S、E、C分級，按照GB/T34590—2022正確地確定了每個危害事件的ASIL等級?見GB/T34590.3—2022中的表4對于S3和C3,而ASIL評級為QM的危害事件，其暴露概率的評級是否有充分的理由?如果幾種不太可能的場景組合導致暴露概率低于E1,即使危害事件達到S3和C3仍然可認定為QM示例1:對于高壓系統(tǒng)錯誤供電的功能異常，組合運行場景是：——導致安全氣囊點爆的碰撞；——車輛的一部分處于水中；——高壓系統(tǒng)部分暴露，沒有造成內部短路。示例2:對于燃油泵錯誤供應汽油的功能異常，組合運行場景是：——導致安全氣囊點爆的碰撞；——泵后面的油箱系統(tǒng)保持功能齊全；——泵的燃油管路破裂，以致汽油會滴在熱部件上；——泵的能源供應功能齊全。表B.1危害分析和風險評估的審核及評估的說明及示例(續(xù))序號檢查清單說明及示例是否為每一個具有ASIL等級的危害事件都確定了其安全目標?對于具有ASIL等級的危害，均應定義安全目標，且對于同類安全目標可合并危害，可將安全目標合并描述為：避免因EPS轉向扭矩異常導致車輛非預期的側向運動。合并后的安全目標的ASIL等級是否為其對應危害事件的最高ASIL等級?根據安全目標與危害事件的追溯關系，確認安全目標繼承了相關危害事件的最高ASIL等級安全目標的屬性和特性定義、安全目標的管理是否符合安全要求定義和管理的要求?a)安全目標的屬性：安全目標應具備唯一識別并保持不變、狀態(tài)、ASIL等級。b)安全目標的特性：安全目標應是明確的、可理解的、不可分施自由的、完整合規(guī)的。c)安全目標的管理：可追溯、可維護、合理地驗證表B.2針對危害分析和風險評估的驗證和確認的審核及評估的說明及示例序號檢查清單說明及示例1在進行危害分析和風險評估過程中，是否使用到了或從中得出了假設?若存在假設，是否在安全確認階段對這些假設進行了確認?a)如果適用，在HARA中考慮的假設包括：駕駛員或處于風險中的人員的假定行為以及外部措施的相關假設。b)參考GB/T34590.4—2022中8.4.3.2,影響危害分析與風險評估中ASIL等級的假設應在最終車輛上進行檢查。(E/E)系統(tǒng)的功能失效造成的潛在危害，那么這個機械組件防止或減輕危害的有效性應在整車層面進行確認2是否按照表6中關于驗證的檢查清單的要求對危害分析和風險評估包括安全目標進行了充分的驗證，且具備相應的證據?應提供證據，以證明：——場景和危害組合的代表性、適用性說明；——對相關項功能異常的識別充分涵蓋了相關項功能定義；——是否考慮了其他相關項HARA結果中與本相關項有關的——危害事件分析采用了系統(tǒng)化方法，分析具有完備性；——對于分配了ASIL等級的危害事件，其安全目標的定義能充分避免危害事件的發(fā)生。安全目標與所分配的ASIL等級以及相應的危害事件保持一致(資料性)功能安全概念功能安全概念的審核及評估的說明及示例見表C.1。表C.1功能安全概念的審核及評估的說明及示例序號檢查清單說明及示例1功能安全要求的屬性和特性、功能安全要求的管理是否符合安全要求定義和管理的要求?a)功能安全要求應具有如下屬性：功能安全要求應具備唯一識別并保持不變、狀態(tài)、ASIL等級。c)功能安全要求的管理：可追溯、可維護、合理地驗證2功能安全要求是否由安全目標導出?在定義功能安全要求時，是否考慮了系統(tǒng)架構設計?a)如果適用，應為每一條FSR指定其對應的SG,確保FSR與SG之間的雙向可追溯性；b)如果適用，考慮系統(tǒng)架構設計中各要素與安全目標之間的對應關系，通過對相關系統(tǒng)要素進行安全分析，得出功能安全要求3每個安全目標是否都可追溯到至少一項功能安全要求?a)每一條安全目標都具備承接的FSR;b)同一個功能安全要求可由幾個不同的安全目標導出4如果適用，在功能安全要求中是否定義了故障避免的策略?為避免隨機硬件故障，可參考FMEA、行業(yè)最佳實踐等的故障避免措施，例如：為避免短路采用ECU電路板熱熔膠工藝、為避免進水短路或腐蝕采用密封圈/密封膠工藝5如果適用，在功能安全要求中是否定義了故障探測的策略，以及對故障或其導致的功能異常表現(xiàn)的控制策略?如果適用，應依據安全分析系統(tǒng)性地得出違背安全目標的相關故障，并針對這些故障定義探測和控制策略。例如：根據EPS的FMEA分析，電源管理芯片應探測電源的過壓、欠壓、漂移、尖峰故障，當出現(xiàn)上述故障后，為避免可能導致非預期側向運動的轉向助力，系統(tǒng)應關閉部分或全部助力6如果適用，在功能安全要求中是否定義了過渡到安全狀態(tài)的策略，及如果適用，過渡出安全狀態(tài)的策略?定義了系統(tǒng)狀態(tài)機、各個狀態(tài)間的過渡過程和跳轉條件，在此過程中考慮跳轉條件和狀態(tài)的組合符合安全目標進入默認助力的安全狀態(tài)，同時發(fā)出駕駛員警示；當總線車速信號恢復后，助力柔和恢復至正常狀態(tài)，同時取消駕駛員警示。7如果適用，在功能安全要求中，是否定義了故障容錯的策略?力沉重或主動轉向功能非預期關閉),增加了冗余助力設計。8如果適用，在功能安全要求中，是否定義了故障情況下的功能降級策略?是否定義了功能降級與駕駛員警告之間的交互策略?針對不同故障風險，駕駛員警告機制是否明確和有效?a)針對“故障情況下的功能降級策略”,例如：當EPS的ECU電路板溫度超過110℃后，EPS將從正常助力狀態(tài)，平緩過渡到過溫條件發(fā)生后的降低助力狀態(tài)。b)針對“將風險暴露時間縮短到可接受時間所需的駕駛員警告”,例如：序號6中，安全狀態(tài)的警示為“轉向備份系統(tǒng)故障，10個點火循環(huán)后將關閉助力，請盡快維修”。降低助力時，駕駛員警告信息為“轉向助力降低，請控制方向”表C.1功能安全概念的審核及評估的說明及示例(續(xù))序號檢查清單說明及示例9如果適用，故障處理時間間隔的定義是否滿足故障容錯時間間隔的要求?a)針對不同類型的故障，應根據故障容錯時間間隔定義故障處理時間間隔，以確保故障探測和處理的及時性，避免危害風險。例如：針對EPS非預期轉向的探測和助力關斷時間，避免錯誤的助力可能使車輛產生非預期的側向運動。b)相關時間間隔的制定可基于測試、仿真或分析，并最終得到確認如果適用，對于不同功能的多個控制請求，是否定義了仲裁策略，以避免或減輕可能導致的危害風險?a)不同功能的控制請求可能來自內部功能(如EPS主動回正、摩擦補償功能)或外部功能(如車道保持LKA功能);b)仲裁策略可能是功能優(yōu)先級順序(如LKA功能優(yōu)先級高于主動回正功能)或功能約束限制(如為EPS主動回正和摩擦補償功能設置力矩上限)等是否進行了安全分析以得到完整有效的功能安全要求?a)為了制定一套完整有效的功能安全要求，可使用例如FMEA、FTA、STPA、HAZOP等分析方法；b)針對安全分析中識別出的故障和風險，都針對性制定了功能安全要求，并進行有效性的驗證確認在定義每項功能安全要求時，如果適用，是否考慮了相關項的運行模式、故障容錯時間間隔、安全狀態(tài)、緊急運行時間間隔及功能冗余?見表A.1中序號3運行模式，表C.1中序號9故障容錯時間間隔、序號6安全狀態(tài)、序號8緊急運行時間間隔及功能冗余的說明及示例在功能安全要求中，是否定義了相應的一個或多個安全狀態(tài)以避免安全目標的違背?維持助力到當前點火循環(huán)結束、維持助力到一定的點火循環(huán)結束、關閉部分輔助功能、關閉主動轉向功能等。是否對相關項過渡到安全狀態(tài)的時間間隔進行了分析?對于不能在可接受的時間間隔內過渡到安全狀態(tài)的情況，是否定義了緊急運行?駛員并關閉助力”,但在行車過程中，不能馬上進入到該安全狀態(tài)，為此，可采取的緊急運行是“提供有限的助力并警告駕駛員，直到車輛停止”,再進入安全狀態(tài)。在功能安全概念中，是否對避免違反安全目標的駕駛員或其他人員的必要行動進行了假設?若存在，是否在功能安全概念中對其進行了定義，并定義了可供駕駛員或其他人員使用的足夠的方法和控制手段?在功能安全概念中，針對EPS非預期轉向行為，可能假設和定義了駕駛員會施加必要的糾正力矩。為此，可能對EPS轉向力矩進行約束，同時在發(fā)生故障時，通過警示信息提醒駕駛員及時采取糾正操作是否將功能安全要求分配給了系統(tǒng)架構設計中的要素?ASIL等級等信息是否與安全目標保持一致?如果應用了ASIL等級分解，是否符合GB/T43253.1—2023中6.7關于ASIL等級分級的檢查清單的要求?a)對于每項功能安全要求，應將其分配給系統(tǒng)架構設計中一個或多個要素，確保功能安全要求與系統(tǒng)要素之間的雙向可追溯性。b)功能安全要求的ASIL等級及信息(運行模式、FTTI、安全狀態(tài)、緊急運行時間間隔、功能冗余等)應從安全目標中繼承得到。c)如果應用了ASIL等級分解，應符合GB/T34590.9—2022中第5章的要求表C.1功能安全概念的審核及評估的說明及示例(續(xù))序號檢查清單說明及示例系統(tǒng)架構中，承接了不同ASIL等級安全要求的架構要素之間，是否根據GB/T43253.1—2023中表22要素共存的檢查清單免于干擾的要求，若不符合，這些要素是否按照相關要求的最高ASIL等級進行了開發(fā)?根據功能安全要求與架構要素的雙向追溯關系，識別每個架構要素所需滿足的最高ASIL等級。對于系統(tǒng)架構中，承接了不同ASIL等級安全要求的要素，應明確相關要素之間是否存在可能導致違背安全要求的級聯(lián)失效，是否符合免于干擾的要求部),而內置的轉角傳感器分配了ASILB等級要求(來自車輛穩(wěn)定性控制功能要求),若不能證明該轉角傳感器與扭矩傳感器之間免于干擾(無級聯(lián)失效),則轉角傳感器也應按照ASILD等級要求開發(fā)針對包含多個電氣/電子(E/E)系統(tǒng)的相關項，是否定義了各個電氣/電子(E/E)系統(tǒng)以及系統(tǒng)之間接口的功能安全要求?a)功能安全概念文檔中，包含相關項架構，在該架構中能清楚識別組成相關項的全部電氣/電子(E/E)系統(tǒng)及其內外部接口。b)針對這些系統(tǒng)和接口定義功能安全要求，并將接口的要求也分配到相關系統(tǒng)中，避免實施遺漏像頭系統(tǒng)和EPS系統(tǒng)同時提出通信保護和監(jiān)控要求。如果適用，是否在功能安全概念中為各個電氣/電子系統(tǒng)分配了隨機硬件故障度量目標值?a)可根據組成相關項的各個電氣/電子(E/E)系統(tǒng)對危害行為和安全目標的貢獻，采用系統(tǒng)性分析手段，如FTA,對各個系統(tǒng)進行隨機硬件故障度量目標值的分配。b)分配的目標一方面是確保最終目標值的達成，同時也有利于在開發(fā)早期合理平衡開發(fā)難度。例如：對于成熟可靠的系統(tǒng)分配較高目標，而對于全新開發(fā)的復雜系統(tǒng)分配較低目標若存在功能安全要求的ASIL等級分解，是否符合GB/T43253.1—2023中6.7關于ASIL等級分解的檢查清單的要求?ASIL等級分解符合GB/T34590.9—2022第5章的要求，見ASIL等級分解檢查清單要求若功能安全概念的實現(xiàn)需要基于其他技術的要素，則針對這些其他技術要素，是否合理分配了功能安全要求及屬性?是否定義了與其他技術要素的接口相關的功能安全要求?這些要求及屬性的實現(xiàn)是否具備充分的措施保證，并進行了必要的驗證和確認?若適用：a)相關安全要求應包含針對其他技術要素的功能安全要求，其實現(xiàn)具備可追溯性；b)相關安全要求應包含相關項與其他技術要素的接口要求；c)對上述要求的實現(xiàn)，是否具備特定的措施保證；d)確認計劃中應包含上述安全要求的確認；e)對于分配給其他技術要素的功能安全要求無需分配ASIL等級，但對于承接了同一功能安全要求的相關項內部要素，可按照GB/T34590.9—2022第5章，使用ASIL等級分解，在此情況下，應在GB/T34590—2022的基礎上，定義實施和驗證規(guī)則要依靠車輛機械轉向系統(tǒng)保證，為此需要對機械轉向系統(tǒng)的轉向助力比值提出要求，以確保人員具備足夠的可控性，并應對整車實現(xiàn)效果進行驗證和確認。表C.1功能安全概念的審核及評估的說明及示例(續(xù))序號檢查清單說明及示例若功能安全概念的實現(xiàn)需要基于外部措施，則針對這些外部措施，是否定義并對其傳遞了功能安全要求?并確認了其實現(xiàn)?a)相關安全要求應包含相關項與外部措施的接口；b)若外部措施是由電氣/電子(E/E)系統(tǒng)實現(xiàn)，則對其要求的定義應符合GB/T34590.1～34590.12—2022;c)確認計劃中應包含外部措施實現(xiàn)安全要求的確認安全概念的實現(xiàn)，可依賴于通過ARS系統(tǒng)實施備份的主動轉向功能。為此，可導出針對ARS系統(tǒng)的接口需求，如ARS應監(jiān)控EPS功能狀態(tài)，若探測到故障，應激活主動轉向功能。是否依據功能安全要求和安全目標定義了相關項安全確認的接受準則?a)當相關項集成到整車時，應通過評估如下方面對相關項的功能安全實現(xiàn)進行確認，包括：——可控性；——外部措施的有效性；——其他技術要素的有效性；——影響危害分析與風險評估中ASIL等級的假設只能在最終車輛上進行檢查。b)安全確認不僅在V流程的安全確認活動(V流程的右側頂端)中執(zhí)行，也在開發(fā)階段中執(zhí)行(而不僅在開發(fā)結束時執(zhí)行)失效造成的潛在危害，那么這個機械組件防止或減輕危害的有效性應在整車層面進行確認，例如針對機械轉向可控性的確認。是否按照本表檢查清單的要求對功能安全概念進行了充分的驗證，且具備相應的證據證明功能安全概念與安全目標的一致性和符合性，及功能安全概念減輕或避免危害的能力?a)通過驗證，確保功能安全概念與安全目標的一致性和符合性；b)通過驗證，證明功能安全概念在減輕或避免危害上的能力示例：減輕或避免危害的能力，可通過測試、試運行或專家判斷來評估，可結合原型、研究報告、專項測試或仿真。(資料性)技術安全概念技術安全概念開發(fā)的審核及評估的說明及示例見表D.1。表D.1技術安全概念開發(fā)的審核及評估的說明及示例序號檢查清單說明及示例1如果存在其他涉及安全的相關項對本系統(tǒng)的安全要求，是否作為系統(tǒng)層面開發(fā)階段技術安全概念的設計輸入?例如，LKA相關項對EPS相關項提出了功能安全要求，當EPS檢測到駕駛員的手力矩>3N·m時，EPS提供超控響應功能，即要求EPS退出對LKA的扭矩請求響應。這個要求也應納入EPS的系統(tǒng)層面開發(fā)輸入2是否存在包含系統(tǒng)層面開發(fā)階段的系統(tǒng)架構設計的系統(tǒng)架構規(guī)范?技術安全概念和該系統(tǒng)架構規(guī)范的系統(tǒng)架構設計描述是否基于相關項定義、功能安全概念和先前的系統(tǒng)架構設計?并保持一致?如果存在不一致，是否通過恰當?shù)幕顒舆M行迭代?應對比和檢查技術安全概念/系統(tǒng)層面開發(fā)階段的架構設計/安全架構方案與相關項定義/功能安全概念階段使用的架構設計的一致性。例如：輸入輸出的接口定義、架構要素的描述、工作模式、對于不一致的地方，是否對功能安全概念階段的活動進行了迭代更新?3系統(tǒng)層面開發(fā)階段的系統(tǒng)架構設計是否能實現(xiàn)技術安全要求?應具備證據說明系統(tǒng)架構設計實現(xiàn)了技術安全要求，證據包括：——系統(tǒng)架構設計與技術安全要求的對應關系；——用于實現(xiàn)技術安全要求的軟硬件具備充分的技術——對于系統(tǒng)架構設計實現(xiàn)的技術安全要求可被驗證，且在系統(tǒng)集成過程中進行了測試4系統(tǒng)架構設計是否識別了安全相關要素及其內外部接口?是否具備恰當?shù)拇胧┐_保其他要素不會對這些安全相關要素產生不利的安全影響?恰當?shù)拇胧_保：——對系統(tǒng)架構中所有安全相關要素進行識別；——對安全相關要素，定義其內部和外部接口；——考慮其他要素對安全相關要素的影響，避免影響安全過程。5如果在系統(tǒng)層面開發(fā)階段的系統(tǒng)架構設計對安全要求進行ASIL等級分解，分解的實施是否符合GB/T43253.1—2023中6.7關于ASIL等級分解的檢查清單的要求?如果適用，應按照GB/T43253.1—2023中ASIL等級分解的審核評估檢查清單執(zhí)行6是否根據對應的ASIL等級，按照GB/T34590.4—2022中表1的要求進行技術安全概念階段的系統(tǒng)架構設計的安全分析?應提供證據證明安全分析開展符合ASIL等級的要求，安全分析的實施符合GB/T43253.1—2023中關于ASIL等級分解的檢查清單的要求，安全分析的評審記錄、開口項信息和版本信息，其相關狀態(tài)信息都應在技術安全概念的工作成果中存在相應記錄表D.1技術安全概念開發(fā)的審核及評估的說明及示例(續(xù))序號檢查清單說明及示例7技術安全概念是否消除已識別出的引起失效的內部原因和外部原因，或在必要時減輕它們的影響?應提供證據證明對于在安全分析中發(fā)現(xiàn)的，引起失效的內部原因和外部原因都有合適安全機制或緩解措施8技術安全概念是否復用值得信賴的系統(tǒng)設計原則?如果復用，是否對設計原則的適用性進行了分析并形成了文檔?值得信賴的系統(tǒng)設計原則可能包括：——值得信賴的技術安全概念的復用；——值得信賴的要素設計的復用，包括硬件和軟件組件；——值得信賴的探測和控制失效的機制的復用；——值得信賴的或標準化接口的復用。如果復用，需要提供設計原則的適用性或差異分析報告，以確保最終產品應用的一致性和適用性9系統(tǒng)層面開發(fā)階段的系統(tǒng)架構設計是否具有以下特征：a)模塊化；b)適當?shù)念w粒度水平；架構設計的模塊化，適當?shù)念w粒度水平和簡單原則可有效的避免系統(tǒng)失效；可通過分層設計、精確的接口定義、避免組件和接口的不必要的復雜性、可維護性和可驗證性之類的設計原則實現(xiàn)在安全分析或系統(tǒng)架構設計過程中，是否識別到新的尚未被安全目標涵蓋的危害?若有，是否更新到危害分析和風險評估(HARA)中?如果適用，提供更新的相關證據技術安全要求中定義的安全機制是否充分，以探測故障并防止或減輕出現(xiàn)在系統(tǒng)輸出端的、導致違反功能安全要求的失效?a)如果適用，在定義安全機制時，應包含：——與系統(tǒng)自身故障相關的安全機制；——與本系統(tǒng)有相互影響的其他外部要素中所發(fā)生故障的安全機制；——使系統(tǒng)實現(xiàn)或者維持在相關項的安全狀態(tài)的安全——定義和執(zhí)行報警和降級策略的安全機制；——防止故障處于潛伏狀態(tài)的安全機制。b)如果適用，在定義每一個安全機制時，宜考慮如下方面：——故障的探測，可定義探測何種故障，采用何種方法進行故障探測；-—故障的指示，描述當出現(xiàn)何種現(xiàn)象時，認為故障發(fā)生，包含對時間、周期等的描述；——故障的控制，當確認故障發(fā)生后，系統(tǒng)應如何響應以避免違背安全目標；——故障的恢復條件，定義在什么條件下，可認為故障恢復；——安全機制的有效性評估表D.1技術安全概念開發(fā)的審核及評估的說明及示例(續(xù))序號檢查清單說明及示例對于使相關項實現(xiàn)或維持安全狀態(tài)的每個安全機制的定義，是否完整?定義應包括：a)相關項可能所處的狀態(tài)與安全狀態(tài)間的轉換的定義，包括轉換過程中對執(zhí)行器的如何控制的要求；常的安全機制明確定義當監(jiān)測到激光發(fā)射功率超出安全標準時，激光LiDAR從正常工作狀態(tài)切換到錯誤工作狀態(tài)，而錯誤工作狀態(tài)也明確定義了會關閉激光發(fā)射。b)故障處理時間間隔的定義，該定義宜考慮架構層面的時間約束要求，以確保滿足相關安全目標的FTTI;c)若不能在FTTI允許的時間內進入相關項的安全狀態(tài)，則應定義緊急運行容錯時間間隔。該定義可基于整車測試或試驗示例1:進入安全狀態(tài)之前的降級運行持續(xù)時間。示例2:線控制動的供電安全機制，定義了備用電源或儲能設備，及其電能容量、啟動所需的時間、運行能持續(xù)的時間等。對于ASIL(A)、(B)、C和D等級，如果適用，是否定義了充分的安全機制，以防止隨機硬件故障的多點故障變?yōu)闈摲收?機制，用于驗證組件在不同運行模式(例如上電、下電、運行或額外的自檢模式)下的狀態(tài)。對于ASIL(A)、(B)、C和D等級，為了避免多點失效，用于探測多點故障的安全機制的診斷測試策略是否合理?用于探測多點故障的安全機制的針對測試策略宜考慮：a)診斷測試策略與被探測硬件組件的可靠性要求、該硬件組件在架構中的角色、其對多點失效的貢獻是否匹配?b)是否符合GB/T34590—2022第9章隨機硬件失效度量目標值的要求?c)與分配的ASIL等級(來自安全目標或上一級的安全要求)是否匹配?d)是否小于多點故障探測時間間隔?示例1:診斷測試策略可為時間驅動(例如使用診斷測試時間間隔)或者事件驅動(例如啟動測試)。示例2:系統(tǒng)或要素在運行過程中的周期性測試；要素在上下電時的自檢；系統(tǒng)或要素在維護時的測試。對于ASIL(A)、(B)、C和D等級，專門用于防止雙點故障變成潛伏故障的安全機制的開發(fā)是否符合要求?對于分配為ASILD等級的技術安全要求，為了防止雙點故障變成潛伏故障而實施的安全機制至少為ASILB等級。對于分配為ASILB等級和ASILC等級的技術安全要求，為了防止雙點故障變成潛伏故障而實施的安全機制至少為ASILA等級。對于分配為ASILA等級的技術安全要求了防止雙點故障變成潛伏故障而實施的安全機制至為QM等級求為ASILB等級。為了防止雙點故障變成潛伏故障，開發(fā)了專門用于測試該奇偶校驗機制在探測和指示內存故障的能力的自檢測試，對于該自檢測試的開發(fā)應至少滿足ASILA的要求。表D.1技術安全概念開發(fā)的審核及評估的說明及示例(續(xù))序號檢查清單說明及示例是否根據系統(tǒng)架構設計，定義了充分地探測、控制或減輕隨機硬件失效的措施?基于定量分析(例如FMEDA、FTA等),確定已定義的措施是否充分示例1:這些措施可能是硬件的診斷特性，通過軟件對其的使用來探測隨機硬件失效。示例2:隨機硬件失效發(fā)生時，不需要探測即可進入安全狀態(tài)的硬件設計(即：失效一安全的硬件設計)。對于ASIL(B)、C和D等級，針對隨機硬件失效導致違背安全目標的可能性是否定義了明確的目標值?是否按照GB/T34590.5—2022第9章的要求，使用備選分析方法中的一個方法進行了評估?GB/T34590.5—2022中表6隨機硬件失效目標值中選取。還宜考慮其他相關項對本相關項的隨機失效目標要求。例如：ADAS相關項對EPS相關項的轉向失效目標值要求，可能與EPS自身安全目標要求不同。潛在分析方法包括：隨機硬件失效概率度量(PMHF)的評估和通過對違背安全目標的每個原因