《道路車輛 功能安全 第9部分：以汽車安全完整性等級為導向和以安全為導向的分析》征求意見稿

ICS43.430

CCST35

中華人民共和國國家標準

GB/T34590.9—XXXX

代替GB/T34590.9-2017

`

道路車輛功能安全

第9部分：以汽車安全完整性等級為導向

和安全為導向的分析

Roadvehicles—Functionalsafety—Part1:AutomotiveSafetyIntegrityLevel(ASIL)-

orientedandsafety-orientedanalyses

(ISO26262-9:2018，MOD)

（征求意見稿）

（本草案完成時間：2021年4月1日）

GB/T34590.9—XXXX

前言

本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規(guī)則》的規(guī)定

起草。

GB/T34590-XXXX《道路車輛功能安全》分為以下部分：

——第1部分：術語；

——第2部分：功能安全管理；

——第3部分：概念階段；

——第4部分：產品開發(fā)：系統(tǒng)層面；

——第5部分：產品開發(fā)：硬件層面；

——第6部分：產品開發(fā)：軟件層面；

——第7部分：生產、運行、服務和報廢；

——第8部分：支持過程；

——第9部分：以汽車安全完整性等級為導向和以安全為導向的分析；

——第10部分：指南；

——第11部分：半導體應用指南；

——第12部分：摩托車的適用性。

本部分為GB/T34590-XXXX的第9部分。

本文件代替GB/T34590.9-2017《道路車輛功能安全第9部分：以汽車安全完整性等級為導向和安

全為導向的分析》,與GB/T34590.9-2017相比，除結構調整和編輯性改動外，主要技術變化如下：

——修改了標準適用范圍，由“量產乘用車”擴大到“除輕便摩托車外的量產道路車輛”；

——新增了對商用車輛的相關要求和示例、對摩托車的適應性要求等；

——修改了關于ASIL等級剪裁的要求分解目的（見5.1）；

——修改了關于ASIL等級剪裁的要求分解總則（見5.2）；

——修改了初始安全需求應分解為冗余安全需求的內容（見5.4.3）；

——修改了每個分解初始安全要求自身應符合初始安全要求的內容（見5.4.4）；

——刪除了“如果不能通過將要素關閉來阻止對初始安全要求的違背，則應展示執(zhí)行分解后安全

要求的充分獨立要素具備足夠的可用性”內容（見2017版的5.4.8）；

——修改了要素共存準則的總則內容（見6.2）；

——刪除了“應用本章之前應將安全要求分配給要素的子要素”內容（見2017版的6.4.2）；

——修改了如果同一要素中存在執(zhí)行不同ASIL等級要求的內容（見6.4.4）；

——修改了相關失效分析的目的（見7.1）；

——修改了相關失效分析的總則（見7.2）；

——修改了相關失效分析的前提條件（見7.3.1）；

——修改了“維修錯誤”為“服務錯誤”（見7.4.4e））；

——增加了“老化和磨損”（見7.4.4i））；

——增加了相關失效分析的細節(jié)程度和嚴格程度的內容（見7.4.8）；

——增加了相關失效分析的驗證依據條款（見7.4.9）；

——增加了相關失效分析驗證報告（見7.5.2）；

——修改了安全分析目的內容（見8.1）；

——修改了安全分析的要求和建議內容（見8.4.1）；

——增加了安全分析驗證報告（見8.5.2）；

III

GB/T34590.9—XXXX

——增加了附錄B要素共存和要求分解的架構示例（見附錄B）；

——增加了附錄C識別相關失效的框架（見附錄C）。

本文件使用重新起草法修改采用了ISO26262-9：2018《道路車輛功能安全第9部分：術語》。

本文件與ISO26262-9：2018的技術性差異及其原因如下：

——關于規(guī)范性引用文件，本部分做了具有技術性差異的調整，以適應我國的技術條件，調整的

情況集中反映在第2章“規(guī)范性引用文件”中，具體調整如下：

?用修改采用國際標準的GB/T34590.1-XXXX代替ISO26262-1：2018；

?用修改采用國際標準的GB/T34590.2-XXXX代替ISO26262-2：2018；

?用修改采用國際標準的GB/T34590.1-XXXX代替ISO26262-3：2018；

?用修改采用國際標準的GB/T34590.4-XXXX代替ISO26262-4：2018；

?用修改采用國際標準的GB/T34590.1-XXXX代替ISO26262-5：2018；

?用修改采用國際標準的GB/T34590.6-XXXX代替ISO26262-6：2018；

?用修改采用國際標準的GB/T34590.7-XXXX代替ISO26262-7：2018；

?用修改采用國際標準的GB/T34590.8-XXXX代替ISO26262-8：2018；

本文件做了下列編輯性修改：

——將國際標準中的“本國際標準”改為“本文件”；

——刪除國際標準的前言；

——修改國際標準的引言及其表述。

本文件由中華人民共和國工業(yè)和信息化部提出。

本文件由全國汽車標準化技術委員會（SAC/TC114）歸口。

本文件起草單位：

本文件主要起草人：

本文件所代替文件的歷次版本發(fā)布情況為：

——GB/T34590.9-2017年首次發(fā)布。

IV

GB/T34590.9—XXXX

引言

ISO26262是以IEC61508為基礎，為滿足道路車輛上電氣/電子系統(tǒng)的特定需求而編寫。

GB/T34590修改采用ISO26262，適用于道路車輛上由電子、電氣和軟件組件組成的安全相關系統(tǒng)

在安全生命周期內的所有活動。

安全是道路車輛開發(fā)的關鍵問題之一。汽車功能的開發(fā)和集成強化了對功能安全的需求，以及對提

供證據證明滿足功能安全目標的需求。

隨著技術日益復雜、軟件和機電一體化應用不斷增加，來自系統(tǒng)性失效和隨機硬件失效的風險逐漸

增加，這些都在功能安全的考慮范疇之內。GB/T34590通過提供適當的要求和流程來降低風險。

為了實現功能安全，GB/T34590-XXXX（所有部分）：

a)提供了一個汽車安全生命周期（開發(fā)、生產、運行、服務、報廢）的參考，并支持在這些生命

周期階段內對執(zhí)行的活動進行剪裁；

b)提供了一種汽車特定的基于風險的分析方法，以確定汽車安全完整性等級（ASIL）；

c)使用ASIL等級來定義GB/T34590中適用的要求，以避免不合理的殘余風險；

d)提出了對于功能安全管理、設計、實現、驗證、確認和認可措施的要求；及

e)提出了客戶與供應商之間關系的要求。

GB/T34590針對的是電氣/電子系統(tǒng)的功能安全,通過安全措施(包括安全機制)來實現。它也提供

了一個框架，在該框架內可考慮基于其它技術（例如，機械、液壓、氣壓）的安全相關系統(tǒng)。

功能安全的實現受開發(fā)過程（例如，包括需求規(guī)范、設計、實現、集成、驗證、確認和配置）、生

產過程、服務過程和管理過程的影響。

安全問題與常規(guī)的以功能為導向和以質量為導向的活動及工作成果相互關聯。GB/T34590涉及與

安全相關的開發(fā)活動和工作成果。

圖1為GB/T34590的整體架構。GB/T34590基于V模型為產品開發(fā)的不同階段提供參考過程模

型：

————陰影”V”表示GB/T34590.3-XXXX、GB/T34590.4-XXXX、GB/T34590.5-XXXX、GB/T34590.6-

XXXX、GB/T34590.7-XXXX之間的相互關系；

————對于摩托車：

?GB/T34590.12-XXXX的第8章支持GB/T34590.3-XXXX；

?GB/T34590.12-XXXX的第9章和第10章支持GB/T34590.4-XXXX。

————以“m-n”方式表示的具體章條中，“m”代表特定部分的編號，“n”代表該部分章的編號。

示例：“2-6”代表GB/T34590.2-XXXX的第6章。

V

GB/T34590.9—XXXX

1.術語

2.功能安全管理

2-7生產、運行、服務、報廢的安

2-5整體安全管理2-6項目相關的安全管理

全管理

生產、運行、

3.概念階段4.產品開發(fā)：系統(tǒng)層面7.

服務和報廢

4-7系統(tǒng)及相關項集成

3-5相關項定義4-5系統(tǒng)層面產品開發(fā)概述

和測試7-5生產、運行、

3-6危害分析和風險評估服務和報廢計劃

4-6技術安全概念4-8安全確認

7-6生產

3-7功能安全概念

7-7運行、服務和

報廢

12.摩托車的適用性5.產品開發(fā)：硬件層面6.產品開發(fā)：軟件層面

12-5摩托車的適用性總

5-5硬件層面產品開發(fā)概述6-5軟件層面產品開發(fā)概述

則

12-6安全文化5-6硬件安全要求的定義6-6軟件安全要求的定義

12-7確認措施5-7硬件設計6-7軟件架構設計

6-8軟件單元設計和實現

12-8危害分析和風險評估5-8硬件架構度量的評估

6-9軟件單元驗證

5-9隨機硬件失效導致違背

整車集成和測試

12-9安全目標的評估6-10軟件集成和驗證

12-10安全確認5-10硬件集成和驗證6-11嵌入式軟件測試

8.支持過程

8-5分布式開發(fā)的接口8-9驗證8-13硬件要素的評估

在用證明

8-6安全要求的定義和管理8-10文檔管理8-14

8-15GB/T34590標準適用范圍之外應用

8-7配置管理8-11使用軟件工具的置信度的接口

8-16未按照根據GB/T34590開發(fā)的安全

8-8變更管理8-12軟件組件的鑒定相關系統(tǒng)的集成

9.以汽車安全完整性等級為導向和以安全為導向的分析

9-5關于ASIL等級剪裁的要求分解9-7相關失效分析

9-6要素共存的準則9-8安全分析

10.指南

11.半導體應用指南

圖1GB/T34590-XXXX概覽

VI

GB/T34590.9—XXXX

道路車輛功能安全

第9部分：以汽車安全完整性等級為導向和安全為導向的分析

1范圍

GB/T34590的本部分規(guī)定了以汽車安全完整性等級為導向和以安全為導向的分析的要求，包括：

——關于ASIL剪裁的要求分解；

——要素共存的準則；

——相關失效分析；及

——安全分析。

本文件適用于安裝在除輕便摩托車外的量產道路車輛上的包含一個或多個電氣/電子系統(tǒng)的與安全

相關的系統(tǒng)。

本文件不適用于特殊用途車輛上特定的電氣/電子系統(tǒng)，例如，為殘疾駕駛者設計的車輛。

注：其他專用的安全標準可作為本文件的補充，反之亦然。

已經完成生產發(fā)布的系統(tǒng)及其組件或在本文件發(fā)布日期前正在開發(fā)的系統(tǒng)及其組件不適用于本文

件。對于在本文件發(fā)布前完成生產發(fā)布的系統(tǒng)及其組件進行變更時，本文件基于這些變更對安全生命周

期的活動進行裁剪。未按照本文件開發(fā)的系統(tǒng)與按照本文件開發(fā)的系統(tǒng)進行集成時，需要按照本文件進

行安全生命周期的裁剪。

本文件針對由安全相關的電氣/電子系統(tǒng)的功能異常表現而引起的可能的危害，包括這些系統(tǒng)相互

作用而引起的可能的危害。本文件不針對與觸電、火災、煙霧、熱、輻射、毒性、易燃性、反應性、腐

蝕性、能量釋放等相關的危害和類似的危害，除非危害是直接由安全相關的電氣/電子系統(tǒng)的功能異常

表現表現而引起的。

本文件提出了安全相關的電氣/電子系統(tǒng)進行功能安全開發(fā)的框架，該框架旨在將功能安全活動整

合到企業(yè)特定的開發(fā)框架中。本文件規(guī)定了為實現產品功能安全的技術開發(fā)要求，也規(guī)定了組織應具備

相應功能安全能力的開發(fā)流程要求。

本文件不針對電氣/電子系統(tǒng)的標稱性能。

2規(guī)范性引用文件

下列文件中的內容通過文中的規(guī)范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，

僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本

文件。

GB/T34590-XXXX（所有部分）道路車輛功能安全（ISO26262:2018，MOD）

3術語、定義和縮略語

GB/T34590.1界定的術語、定義和縮略語適用于本文件。

4要求

目的

7

GB/T34590.9—XXXX

本章規(guī)定了：

a)如何符合GB/T34590-XXXX；

如何解釋GB/T34590-XXXX所使用的表格；及

如何解釋各章條基于不同的ASIL等級的適用性。

一般要求

如聲明滿足GB/T34590-XXXX的要求時，應滿足每一個要求，除非有下列情況之一：

a)按照GB/T34590.2-XXXX的要求，安全活動的剪裁已經實施并表明這些要求不適用；或

不滿足要求的理由存在且是可接受的，并且按照GB/T34590.2-XXXX的要求對該理由進行了評估。

標有“注”或“示例”的信息僅用于輔助理解或闡明相關要求，不應作為要求本身且不具備完備性。

將安全活動的結果作為工作成果。應具備上一階段工作成果作為“前提條件”的信息。如果章條的

某些要求是依照ASIL定義的或可剪裁的，某些工作成果可不作為前提條件。

“支持信息”是可供參考的信息，但在某些情況下，GB/T34590-XXXX不要求其作為上一階段的工

作成果，并且可以是由不同于負責功能安全活動的人員或組織等外部資源提供的信息。

表的詮釋

本文件中的表是規(guī)范性或資料性取決于上下文。在滿足相關要求時，表中列出的不同方法有助于置

信度水平。表中的每個方法是：

a)一個連續(xù)的條目（在最左側列以順序號標明，如1、2、3）；或

一個選擇的條目（在最左側列以數字后加字母標明，如2a、2b、2c）。

對于連續(xù)的條目，高度推薦和推薦的方法按照ASIL等級推薦予以使用。高度推薦或推薦的方法允許

用未列入表中的其它方法替代,此種情況下，應給出滿足相關要求的理由。如果可以給出不選擇所有條

目也能符合相應要求的理由，則不需要對缺省方法做進一步解釋。

對于選擇性的條目，應按照指定的ASIL等級對這些方法進行適當的組合，而與這些方法在表中是否

列出無關。如果所列出的方法對于一個ASIL等級來說具有不同的推薦等級，宜采用具有較高推薦等級的

方法。應給出選擇組合方法或選擇單一方法滿足相應要求的理由。

注：在表中所列出方法的理由是充分的。但是，這并不意味著有傾向性或對未列到表中的方法表示反對。

對于每種方法，應用相關方法的推薦等級取決于ASIL等級，分類如下：

——“++”表示對于指定的ASIL等級，高度推薦該方法；

——“+”表示對于指定的ASIL等級，推薦該方法；

——“o”表示對于指定的ASIL等級，不推薦也不反對該方法。

基于ASIL等級的要求和建議

若無其它說明，對于ASILA、B、C和D等級，應滿足每一章條的要求或建議。這些要求和建議參

照安全目標的ASIL等級。如果在項目開發(fā)的早期對ASIL等級完成了分解，按照GB/TXXXXX-9第5章的要

求，應遵循分解后的ASIL等級。

如果GB/T34590-XXXX中ASIL等級在括號中給出，則對于該ASIL等級，相應的章條應被認為是推薦

而非要求。這里的括號與ASIL等級分解無關。

摩托車的適用性

對于適用于GB/T34590.12要求的摩托車的相關項或要素，GB/T34590.12的要求替代本部分和GB/T

34590.2的相應要求。

卡車、客車、掛車和半掛車的適用性

8

GB/T34590.9—XXXX

對卡車、客車、掛車和半掛車的特殊規(guī)定以（T&B）來表示。

5關于ASIL等級剪裁的要求分解

目的

本章的目的是，如果使用了ASIL等級分解，則：

a)確保安全求在下一個更細層面上分解成冗余的安全要求，并將這些要求分配給了充分獨立的

設計要素；及

根據允許的ASIL等級分解方案應用ASIL等級分解。

注：本章中所提到的獨立性是指技術獨立性，而不是組織獨立性（參見GB/T34590.1-XXXX的3.78）。

總則

所開發(fā)相關項的安全目標的ASIL等級貫穿整個相關項的開發(fā)。從安全目標開始，在各開發(fā)階段得出

并細化安全要求。作為安全目標的一個屬性，ASIL等級由后續(xù)每個安全要求來繼承。安全要求被分配

給架構要素，從分配給系統(tǒng)架構設計要素的功能安全要求開始，最終得出分配給硬件和/或軟件要素的

安全要求。

ASIL等級分解是在概念和各個開發(fā)階段進行ASIL等級剪裁的一種方法。在安全要求分配過程中，可

從包括存在充分獨立的架構要素的架構決策中獲得益處，這提供了以下機會：

——通過這些獨立的架構要素冗余實現安全要求；及

——分配一個可能更低的ASIL等級給這些（或其中一部分）分解后的安全要求。

如果架構要素不是充分獨立的，則冗余要求和架構要素繼承初始的ASIL等級。

ASIL等級分解是一種ASIL等級剪裁方法，可用于相關項或要素的功能安全要求、技術安全要求、硬

件安全要求或軟件安全要求。

通常，ASIL等級分解允許將安全要求的ASIL等級在多個用來確保同一安全目標的同一安全要求的

要素間進行分配。在特定條件下，允許在預期功能及其相應的安全機制間進行ASIL等級分解（參見5.4.7）。

針對隨機硬件失效的要求，包括硬件架構度量的評估和由于隨機硬件失效導致違背安全目標的評

估（參見GB/T34590.5-XXXX，第8章和第9章），在ASIL等級分解后仍保持不變。

附錄B給出了一個架構分解的示例。

本章的輸入

5.3.1前提條件

應具備下列信息：

——ASIL等級分解所在整車、系統(tǒng)、硬件或軟件層面的安全要求，按照GB/T34590.3-XXXX的

7.5.1、GB/T34590.4-XXXX的6.5.1、GB/T34590.5-XXXX的6.5.1或GB/T34590.6-XXXX

的6.5.1；及

——ASIL等級分解所在整車、系統(tǒng)、硬件或軟件層面的架構信息，按照GB/T34590.3-XXXX的

7.5.1、GB/T34590.4-XXXX的6.5.3、GB/T34590.5-XXXX的7.5.1或GB/T34590.6-XXXX

的7.5.1。

5.3.2支持信息

可考慮下列信息：

——相關項定義（參見GB/T34590.3-XXXX的5.5.1）；及

——包含在危害分析和風險評估報告中的安全目標（參見GB/T34590.3-XXXX的6.5.1）。

9

GB/T34590.9—XXXX

要求和建議

5.4.1如果應用ASIL等級分解，應滿足本章的所有要求。

5.4.2進行ASIL等級分解時，應分別考慮每一個初始的安全要求。

注：對不同初始安全要求的ASIL等級分解，可能導致將幾個安全要求分配給相同的獨立要素。

5.4.3初始安全要求應分解為冗余安全要求，并由充分獨立要素實現。如果相關失效分析（參見第7

章）沒有找到導致違反初始安全要求的合理原因，或者根據初始安全要求的ASIL等級，所識別的相關

失效的每個原因都被充分的安全措施控制，則這些要素具有充分的獨立性。

注1：一條被分解的要求可能是幾個初始安全要求分解的結果。

注2：使用同構冗余來實現分解的要求（例如，通過復制的設備或復制的軟件）并不能解決硬件和軟件系統(tǒng)性失效。

除非相關失效的分析（參見第7章）提供了充分的獨立性證據（參見GB/T34590.1-XXXX的3.78）或存在潛在共因可

進入安全狀態(tài)的證據，否則不允許ASIL等級的降低。因此，在沒有針對特定系統(tǒng)應用背景的相關失效分析的支持下，

單靠同構冗余通常不足以降低ASIL等級。

注3：ASIL等級分解通常不適用于在多通道架構設計中確保通道選擇或通道切換的要素。

5.4.4每個分解后的安全要求自身應符合初始安全要求。

注1：此要求通過定義提供了冗余。

注2：如果將分解后的安全要求分配給安全機制，則應在評估分解后的要求是否符合初始安全要求時，考慮該安全機

制的有效性。

示例：分配給指定ECU的ASILD要求，可能被輕易的分解為分配給ECU中簡單看門狗的ASILD要求和該ECU微處

理器的QM安全要求。然而，這個簡單的看門狗不足以覆蓋ASILD要求的微處理器的失效模式。在這種情況下，該看門

狗不能有效地滿足初始的安全要求。

5.4.5按照GB/T34590.5，對硬件架構度量的評估要求和對由于隨機硬件失效導致違背安全目標的評

估要求應在ASIL等級分解后保持不變。

5.4.6如果在軟件層面應用ASIL等級分解，應在系統(tǒng)層面對實施分解后要求的要素間的充分獨立性

進行驗證。如果有必要，應在軟件層面、硬件層面或系統(tǒng)層面采取額外的措施來實現充分的獨立性。

5.4.7如果對初始安全要求的ASIL等級分解導致將分解后的要求分配給預期功能及相關安全機制，

則：

a)相關安全機制宜被分配分解后的較高ASIL等級；及

注1：通常，與預期功能相比，安全機制具備較低的復雜度和更小的規(guī)模。

安全要求應被分配給預期功能，并按照相應分解后的ASIL等級實現。

注2：如果選擇了分解方案ASILx(x)+QM(x)，則QM(x)意味著質量管理體系足以實現預期功能要素安全要求的開

發(fā)。

5.4.8對安全要求應用ASIL等級分解時：

a)應按照5.4.9應用ASIL等級分解；

ASIL等級分解的應用可多一次（在這種情況下，中間的需求分配步驟可以省略）；及

應通過在括號中給出安全目標的ASIL等級，對每個分解后的ASIL等級做標注。

示例：如果一個ASILD的要求分解成一個ASILC的要求和一個ASILA的要求，則應標注成“ASILC(D)”和“ASIL

A(D)”。如果ASILC(D)的要求進一步分解成一個ASILB的要求和一個ASILA的要求，則應使用安全目標的ASIL等級

將其標注為“ASILB(D)”和“ASILA(D)”。

5.4.9應按照分解前的ASIL等級選擇下列分解方案中的一種（如圖2所示）。也可使用得出較高ASIL

等級的分解方案。

注1：從所選分解方案的一個層面到相鄰較低層面的步驟定義了ASIL等級的一個分解。

a)應按照下列之一對一個ASILD的要求進行分解：

1)一個ASILC(D)的要求和一個ASILA(D)的要求；或

10

GB/T34590.9—XXXX

2)一個ASILB(D)的要求和一個ASILB(D)的要求；或

3)一個ASILD(D)的要求和一個QM(D)的要求。

應按照下列之一對一個ASILC的要求進行分解：

4)一個ASILB(C)的要求和一個ASILA(C)的要求；或

5)一個ASILC(C)的要求和一個QM(C)的要求。

應按照下列之一對一個ASILB的要求進行分解：

6)一個ASILA(B)的要求和一個ASILA(B)的要求；或

7)一個ASILB(B)的要求和一個QM(B)的要求。

如果需要，ASILA只應被分解為一個ASILA(A)的要求和一個QM(A)的要求。

11

GB/T34590.9—XXXX

分解之前

要求.X要求.X要求.X

ASILDASILDASILD

要素.E要素.E要素.E

5.4.9節(jié)5.4.9節(jié)5.4.9節(jié)

分解方案

要求.X.1要求.X.2要求.X.1要求.X.2要求.X.1要求.X.2

ASILD(D)ASILQM(D)ASILC(D)ASILA(D)ASILB(D)ASILB(D)

要素.E.1要素.E.2要素.E.1要素.E.2要素.E.1要素.E.2

ASILDASIL

分解之后

分解之前

要求.X要求.X

ASILCASILC

要素.E要素.E

5.4.9節(jié)5.4.9節(jié)

分解方案

要求.X.1要求.X.2要求.X.1要求.X.2

ASILC(C)ASILQM(C)ASILB(C)ASILA(C)

要素.E.1要素.E.2要素.E.1要素.E.2

ASILCASIL

分解之后

分解之前

要求.X要求.X

ASILBASILB

要素.E要素.E

5.4.9節(jié)5.4.9節(jié)

分解方案

要求.X.1要求.X.2要求.X.1要求.X.2

ASILB(B)ASILQM(B)ASILA(B)ASILA(B)

要素.E.1要素.E.2要素.E.1要素.E.2

ASILBASIL

分解之后

分解之前

要求.X

ASILA

要素.E

5.4.9節(jié)

分解方案

要求.X.1要求.X.2

ASILA(A)ASILQM(A)

要素.E.1要素.E.2

ASILAASIL

分解之后

圖2ASIL等級分解方案

要點：要求XASILD→要素.E表示具有ASILD屬性的要求X被分配給要素E。

示例：5.4.7中描述的案例，即：QM分配給預期功能、與初始ASIL等級相同的ASIL等級分配給相關安全機制，如

12

GB/T34590.9—XXXX

最左列所示。

注2：每個分解步驟最上面框內的值代表分解前的ASIL等級。

注3：構架要素E.1和E.2充分獨立，符合5.4.3。

5.4.10當使用5.4.9中給出的任何分解方案時，應具備分解后要素充分獨立性的證據（參見5.4.3）。

5.4.11應至少按照GB/T34590.4和GB/T34590.6中（分解后的）ASIL等級要求，在系統(tǒng)層面和軟

件層面開發(fā)分解后的要素。應至少按照GB/T34590.5中（分解后的）ASIL等級要求，在硬件層面開發(fā)

分解后的要素，但硬件架構度量的評估和因隨機硬件失效導致違背安全目標的評估除外（參見5.4.5）。

5.4.12在應用了分解的設計過程的每個層面,對分解后的要素的相關集成活動及后續(xù)活動，包括驗

證和認可措施，應按照分解前的ASIL等級的要求開展。

工作成果

5.5.1架構信息的更新，由5.4得出。

5.5.2作為安全要求和要素的屬性的ASIL等級更新，由5.4得出。

6要素共存的準則

目的

本章提供了以下子要素在同一要素內共存的準則:

a)安全相關的子要素與非安全相關的子要素;及

分配了不同ASIL等級的安全相關子要素。

總則

通常，當某個要素由幾個子要素組成時，按照適用于該要素的最高ASIL等級（即分配給要素的安全

要求的最高ASIL等級）的相應措施開發(fā)每個子要素。

在未分配ASIL等級或分配了不同ASIL等級的子要素共存情況下，或與安全無關的子要素和與安全

相關的子要素共存情況下，避免將要素的ASIL等級分配給全部子要素可能是有益的。為達到該目的，本

章為確定不同ASIL等級的子要素是否能在同一要素下共存提供了指導。本章以要素中各個子要素與其

余子要素間的干擾分析為基礎。

在本章的上下文中，干擾是從未分配ASIL等級的子要素或分配了較低ASIL等級的子要素，到分配了

較高ASIL等級的子要素之間存在級聯失效，從而導致違背了要素的安全要求（參見GB/T34590.1-XXXX

的3.65）。

當確定要素中子要素的ASIL等級時，應關注級聯失效的相關失效分析（參見第7章），此分析為免

于干擾提供了依據。

本章的輸入

6.3.1前提條件

應具備下列信息：

——開展分析所在系統(tǒng)、硬件或軟件層面的安全要求，按照GB/T34590.3-XXXX的7.5.1、GB/T

34590.4-XXXX的6.5.1、GB/T34590.5-XXXX的6.5.1或GB/T34590.6-XXXX的6.5.1；

——開展分析所在系統(tǒng)、硬件或軟件層面的要素架構信息，按照GB/T34590.3-XXXX的7.5.1、

GB/T34590.4-XXXX的6.5.3、GB/T34590.5-XXXX的7.5.1或GB/T34590.6-XXXX的

7.5.1；及

——將安全要求分配給所考慮的要素和子要素。

13

GB/T34590.9—XXXX

6.3.2支持信息

無。

要求和建議

6.4.1本章適用于設計過程中任何改進步驟，并行于架構要素和子要素的安全要求分配。

注：按照GB/T34590.4、GB/T34590.5或GB/T34590.6，通常在系統(tǒng)設計、硬件設計或軟件架構設計時考慮共存準

則。

6.4.2分析要素時應考慮下列內容：

a)分配到要素的每個安全要求；及

要素包含的每個子要素。

6.4.3如果非安全相關的子要素和安全相關子要素共同存在于同一要素中,如果能證明非安全相關的

子要素不直接或間接地違背分配給該要素的任何安全要求,即:非安全子要素不干擾要素中安全相關的

任何子要素,則應僅視其為非安全相關的子要素。

注1：這意味著從該子要素到安全相關子要素的級聯失效是不存在的。

注2：可通過設計措施獲得，諸如考慮軟件的數據流和控制流，或硬件的輸入/輸出信號及控制線。

否則,在不具備免于干擾證據的情況下,應將共存安全相關子要素的最高ASIL等級分配給該子要素。

6.4.4如果同一要素中存在執(zhí)行不同ASIL等級要求，包括QM(x)（參見5.4.9）的安全相關子要素，

僅當能證明對分配給要素的每個安全要求，所考慮的子要素不會直接或間接的違反分配給執(zhí)行更高

ASIL等級要求的子要素的任何安全要求時，才能視所考慮的子要素為較低ASIL等級的子要素。否則，

由于不具備免于干擾的證據，應將共存安全相關子要素的最高ASIL等級分配給該子要素。

注：對免于干擾的評估應與分配給共存的子要素的最高ASIL等級要求相匹配（參見7.4.8）。

工作成果

6.5.1要素中各子要素的ASIL等級屬性的更新，由6.4得出。

7相關失效分析

目的

本章的目的是：

a)通過分析其潛在原因或引發(fā)因素，確認設計中充分實現了要求的獨立性或免于干擾；及

如有必要，定義安全措施，以減輕可能的相關失效。

總則

相關失效分析的范圍可能受給定要素的技術（例如軟件要素、硬件要素或硬件和軟件要素的組合），

以及所涉及的安全要求影響。

14

GB/T34590.9—XXXX

圖3不同類型相關失效之間的關系

圖3描述了相關失效、免于干擾和技術獨立性之間的關系。

免于干擾是用于證明分配了不同ASIL等級的，或者無ASIL等級和有ASIL等級的要素可以共存（參見

第6章）。

免于干擾和不存在共因失效，是用于證明在進行ASIL等級分解時的獨立性（參見第5章）。

注1：其他系統(tǒng)屬性也可能要求獨立性，從而不存在相關失效。例如：相關失效分析可被用于論證避免單點故障和潛

伏故障的安全機制的有效性（參見GB/T34590.5-XXXX,第8章）。

注2：相關失效分析可應用于系統(tǒng)或相關項的各種設計層面。

相關失效分析考慮架構特征，例如：

——相似的和不相似的冗余要素；

——由相同的軟件或硬件要素實現的不同功能；

——功能及其相關安全機制；

——功能的分割或軟件要素的分隔；

——硬件要素間的物理間距，有隔離或無隔離；

——共同的外部資源。

獨立性受到共因失效和級聯失效的威脅，而免于干擾僅受級聯失效的威脅。

示例1：高強度電磁場會導致不同電子設備失效，失效方式取決于電子設備的設計或使用，該失效是一個共因失效。

示例2：錯誤的車速信息傳遞給其它車輛功能并影響其行為，是一個級聯失效。

示例3：如果被設計用來探測功能異常表現的監(jiān)控和被監(jiān)控的功能兩者受相同事件或原因的影響，則該監(jiān)控可能在

被監(jiān)控功能失效前的某個時刻失效，是一個共因失效。

附錄C提供了一個識別相關失效的框架示例。

本章的輸入

7.3.1前提條件

應具備下列信息：

——應用相關失效分析的系統(tǒng)、硬件或軟件層面的獨立性要求，按照GB/T34590.3-XXXX的

7.5.1、GB/T34590.4-XXXX的6.5.1、GB/T34590.5-XXXX的6.5.1或GB/T34590.6-XXXX

的6.5.1；

15

GB/T34590.9—XXXX

——應用相關失效分析的系統(tǒng)、硬件或軟件層面的免于干擾要求，按照GB/T34590.3-XXXX的

7.5.1、GB/T34590.4-XXXX的6.5.1、GB/T34590.5-XXXX的6.5.1或GB/T34590.6-XXXX

的6.5.1；

——應用相關失效分析的系統(tǒng)、硬件或軟件層面的架構信息，按照GB/T34590.3-XXXX的

7.5.1、GB/T34590.4-XXXXX的6.5.3、GB/T34590.5-XXXX的7.5.1或GB/T34590.6-XXXX

的7.5.1；及

注1：架構信息用于確定相關失效分析的邊界。

——安全計劃，按照GB/T34590.2-XXXX的6.5.3。

注2：相關失效分析的目的和范圍取決于執(zhí)行分析的子階段和抽象層。在進行分析前，對這些信息進行定義，例如在

安全計劃中。

7.3.2支持信息

無。

要求和建議

7.4.1應按照第8章安全分析的結果識別出相關失效的潛在可能性。

注1：系統(tǒng)性失效和隨機硬件失效都有可能成為相關失效。

注2：對相關失效的潛在可能性的識別可基于演繹分析法，例如，割集檢查或者FTA中重復的相同事件。

注3：歸納分析法也可支持相關失效的潛在可能性的識別，例如，在FMEA中多次出現的具有相似失效模式的相似元器

件或組件。

注4：應用于半導體的相關失效分析的示例可參考GB/T34590.11-XXXX，4.7章。

7.4.2應評估每個識別出的相關失效的潛在可能性，以判定其合理性，即是否存在導致相關失效并違

背給定要素間所要求的獨立性或免于干擾的合理可預見原因。

注：為進行隨機硬件失效導致違背安全目標的評估，而需要對隨機硬件失效進行量化時（參見GB/T34590.5），因

不存在通用且充分可靠的量化方法，共因失效和級聯失效的影響是在定性基礎上預估的。

7.4.3此評估應考慮所分析相關項或要素的運行工況，也應考慮其各種運行模式。

7.4.4此評估應考慮以下適用的內容：

注1：合適的檢查清單（例如：基于現場經驗的檢查清單）可支持對潛在相關失效合理性的評估。檢查清單為分析員

提供了根本原因和耦合因素（例如：相同的設計、相同的過程、相同的組件、相同的接口、相近的距離）的代

表性示例。附錄C可作為建立此類檢查清單的基礎。

注2：也可由是否遵守了旨在防止引入可導致相關失效的根本原因和耦合因素的過程指南來支持此評估。

a)隨機硬件失效；

示例1：共用模塊的失效，例如大規(guī)模集成電路（微控制器、ASIC等）的時鐘、測試邏輯和內部電壓調節(jié)器的失效。

開發(fā)錯誤；

示例2：需求錯誤、設計錯誤、實施錯誤、因使用新技術導致的錯誤和做更改時引入的錯誤。