GB/T 34590.6-2022英文版 道路車輛功能安全第6部分：產品開發(fā)：軟件層面

GB/T 34590.6-2022英文版

?

1 范圍
GB/T 34590的本部分規(guī)定了車輛在軟件層面產品開發(fā)的要求，包括：
——軟件層面產品開發(fā)的概述；
——軟件安全要求的定義；
——軟件架構設計；
——軟件單元設計和實現(xiàn)；
——軟件單元驗證；
——軟件集成和驗證；及
——嵌入式軟件測試。 本文件規(guī)定了使用可配置軟件的相關要求。
本文件適用于安裝在除輕便摩托車外的量產道路車輛上的包含一個或多個電氣/電子系 統(tǒng)的與安全相關的系統(tǒng)。
本文件不適用于特殊用途車輛上特定的電氣/電子系統(tǒng)，例如，為殘疾駕駛者設計的車
輛。
注：其他專用的安全標準可作為本文件的補充，反之亦然。
已經(jīng)完成生產發(fā)布的系統(tǒng)及其組件或在本文件發(fā)布日期前正在開發(fā)的系統(tǒng)及其組件不 適用于本文件。對于在本文件發(fā)布前完成生產發(fā)布的系統(tǒng)及其組件進行變更時，本文件基于 這些變更對安全生命周期的活動進行裁剪。未按照本文件開發(fā)的系統(tǒng)與按照本文件開發(fā)的系 統(tǒng)進行集成時，需要按照本文件進行安全生命周期的裁剪。
本文件針對由安全相關的電氣/電子系統(tǒng)的功能異常表現(xiàn)而引起的可能的危害，包括這 些系統(tǒng)相互作用而引起的可能的危害。本文件不針對與觸電、火災、煙霧、熱、輻射、毒性、 易燃性、反應性、腐蝕性、能量釋放等相關的危害和類似的危害，除非危害是直接由安全相 關的電氣/電子系統(tǒng)的功能異常表現(xiàn)表現(xiàn)而引起的。
本文件提出了安全相關的電氣/電子系統(tǒng)進行功能安全開發(fā)的框架，該框架旨在將功能 安全活動整合到企業(yè)特定的開發(fā)框架中。本文件規(guī)定了為實現(xiàn)產品功能安全的技術開發(fā)要 求，也規(guī)定了組織應具備相應功能安全能力的開發(fā)流程要求。
本文件不針對電氣/電子系統(tǒng)的標稱性能。

2 規(guī)范性引用文件
下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件，僅所注日期的版本 適用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。
GB/T 34590.1，道路車輛 功能安全 第1部分：術語(ISO 26262-1:2018，MOD) GB/T 34590.2，道路車輛 功能安全 第2部分：功能安全管理(ISO 26262-2:2018，MOD)
GB/T 34590.3，道路車輛 功能安全 第3部分：概念階段(ISO 26262-3:2018,MOD) GB/T 34590.4 ， 道 路 車 輛 功 能 安 全 第 4 部 分 ： 產 品 開 發(fā) ： 系 統(tǒng) 層 面 (ISO 26262-4:2018，MOD)
GB/T 34590.5 ， 道 路 車 輛 功 能 安 全 第 5 部 分 ： 產 品 開 發(fā) ： 硬 件 層 面 (ISO 26262-5:2018，MOD)
GB/T 34590.7，道路車輛 功能安全 第7部分：生產、運行、服務和報廢(ISO 26262-7:2018,MOD)
GB/T 34590.8，道路車輛 功能安全 第8部分：支持過程(ISO 26262-8:2018，MOD)
GB/T 34590.9，道路車輛 功能安全 第9部分：以汽車安全完整性等級為導向和以 安全為導向的分析(ISO 26262-9:2018，MOD)

3 術語、定義和縮略語
GB/T 34590.1界定的術語、定義和縮略語適用于本文件。

4 要求
4.1 目的
本章規(guī)定了：
a) 如何符合 GB/T 34590；
b) 如何解釋 GB/T 34590 中所使用的表格；及
c) 如何解釋各章條基于不同的 ASIL 等級的適用性。
4.2 一般要求
如聲明滿足GB/T 34590的要求時，應滿足每一個要求，除非有下列情況之一：
a) 按照 GB/T XXXXX.2 的要求，安全活動的剪裁已經(jīng)實施并表明這些要求不適用； 或
b) 不滿足要求的理由存在且是可接受的，并且按照 GB/T XXXXX.2 的要求對該理 由進行了評估。
標有“注”或“示例”的信息僅用于輔助理解或闡明相關要求，不應作為要求本身且不 具備完備性。
將安全活動的結果作為工作成果。應具備上一階段工作成果作為“前提條件”的信息。 如果章條的某些要求是依照ASIL定義的或可剪裁的，某些工作成果可不作為前提條件。
“支持信息”是可供參考的信息，但在某些情況下，GB/T 34590不要求其作為上 一階段的工作成果，并且可以是由不同于負責功能安全活動的人員或組織等外部資源提供的 信息。
4.3 表的詮釋
本文件中的表是規(guī)范性或資料性取決于上下文。在滿足相關要求時，表中列出的不同方 法有助于置信度水平。表中的每個方法是：
a) 一個連續(xù)的條目（在最左側列以順序號標明，如 1、2、3）；或
b) 一個選擇的條目（在最左側列以數(shù)字后加字母標明，如 2a、2b、2c）。 對于連續(xù)的條目，高度推薦和推薦的方法按照ASIL等級推薦予以使用。高度推薦或推薦
的方法允許用未列入表中的其它方法替代,此種情況下，應給出滿足相關要求的理由。如果 可以給出不選擇所有條目也能符合相應要求的理由，則不需要對缺省方法做進一步解釋。
對于選擇性的條目，應按照指定的ASIL等級對這些方法進行適當?shù)慕M合，而與這些方法 在表中是否列出無關。如果所列出的方法對于一個ASIL等級來說具有不同的推薦等級，宜采 用具有較高推薦等級的方法。應給出選擇組合方法或選擇單一方法滿足相應要求的理由。
注：在表中所列出方法的理由是充分的。但是，這并不意味著有傾向性或對未列到表中的方法表示反 對。
對于每種方法，應用相關方法的推薦等級取決于ASIL等級，分類如下：
——“++每表示對于指定的ASIL等級，高度推薦該方法；
——“+—對表示對于指定的ASIL等級，推薦該方法；
——“o—對表示對于指定的ASIL等級，不推薦也不反對該方法。 4.4 基于 ASIL 等級的要求和建議
若無其它說明，對于ASIL A、 B、 C和D等級，應滿足每一章條的要求或建議。這些要 求和建議參照安全目標的ASIL等級。如果在項目開發(fā)的早期對ASIL等級完成了分解，按照 GB/T XXXXX-9第5章的要求，應遵循分解后的ASIL等級。
如果GB/T 34590中ASIL等級在括號中給出，則對于該ASIL等級，相應的章條應被 認為是推薦而非要求。這里的括號與ASIL等級分解無關。
4.5 摩托車的適用性
對于適用于GB/T XXXXX.12要求的摩托車的相關項或要素，GB/T XXXXX.12的要求替代本 文件和GB/T XXXXX.2的相應要求。
4.6 卡車、客車、掛車和半掛車的適用性
對卡車、客車、掛車和半掛車的特殊規(guī)定以（T&B）來表示。

5 軟件層面產品開發(fā)概述
5.1 目的
本章的目的是：
a) 確保合適且一致的軟件開發(fā)流程；及
b) 確保合適的軟件開發(fā)環(huán)境。
5.2 總則
圖2給出了軟件開發(fā)階段的參考模型。附錄C中提供了可配置軟件處理的詳細信息。
注：圖中 GB/T 34590 每部分的特定章用以下方式標示：“m-n”，“m”代表部分號，“n”代表章 號，例如，“4-7”代表 GB/T 34590.4 的第 7 章。
圖 2 軟件層面產品開發(fā)階段參考模型
注1：敏捷軟件開發(fā)的方式和方法也可以適用于安全相關軟件的開發(fā)，但是如果安全活動按照該方式 剪裁，應該考慮GB/T 34590.2，6.4.5。然而，敏捷方式和方法的使用不能省略安全措施 或忽略實現(xiàn)功能安全所必需的基本文檔、流程或嚴格的產品安全完整性要求。
示例1：由測試驅動的開發(fā)可用于提高要求的質量和可測試性。 示例2：基于自動化構建系統(tǒng)的持續(xù)集成可以支持各個子階段的一致性并促進回歸測試。這種構建系
統(tǒng)通常執(zhí)行代碼生成、編譯和鏈接、靜態(tài)代碼分析、文檔生成、測試和打包。根據(jù)工具鏈和 工具配置，該系統(tǒng)允許重復生成以及在變更后生成可比較的軟件、文檔和測試結果。
注2：開發(fā)特定相關項的嵌入式軟件時，也可以考慮信息安全，見GB/T 34590.2，5.4.2.3。為 了能夠開發(fā)軟件，本章中討論了關于要使用的建模、設計和/或編程語言以及指南和工具應用的 特定主題。
注3：用于軟件開發(fā)的工具，包括軟件工具以外的工具。 示例3：測試階段使用的工具。
5.3 本章的輸入
5.3.1 前提條件
無。
5.3.2 支持信息
可考慮下列信息：
——經(jīng)鑒定合格的軟件工具（見 GB/T 34590.8，第 11 章）；
——用于建模、設計和編程語言的設計和編碼指南（來自外部）；
——方法應用的指南（來自外部）；及
——工具應用的指南（來自外部）。 5.4 要求和建議
5.4.1 在開發(fā)相關項的軟件時，使用的軟件開發(fā)過程和軟件開發(fā)環(huán)境應：
a) 適用于開發(fā)安全相關的嵌入式軟件，包括方法、指南、語言和工具；
b) 支持軟件開發(fā)生命周期中的各跨子階段和各自工作成果的一致性；及
c) 與系統(tǒng)和硬件開發(fā)階段在所需的交互和信息交換的一致性方面兼容。
注1：相關項軟件開發(fā)的階段、任務和活動的排序，包括迭代步驟，目的是為了確保相應的工作成果 與硬件層面的產品開發(fā)（本文件GB/T 34590.5）和系統(tǒng)層面的產品開發(fā)（本文件GB/T 34590.4） 保持一致。
注2：軟件工具準則評估報告（本文件GB/T 34590.8，11.5.1）或軟件工具的鑒定報告（本文件 GB/T 34590.8，11.5.2）可以為工具的使用提供輸入。
5.4.2 當選擇一種設計語言、建模語言或編程語言時，應考慮準則：
a) 明確易理解的定義； 示例：語法和語義的明確定義或對開發(fā)環(huán)境配置的限制。
b) 如果建模用于需求工程和管理，定義和管理安全要求（按照 GB/T 34590.2 第 8 章）的適用性；
c) 支持模塊化、抽象化和封裝化的實現(xiàn)；及
d) 支持結構化構造的使用。
注：匯編語言能用于那些不適合使用高級編程語言的軟件部分，如與硬件接口的底層軟件、中斷處理 程序、或對時間敏感的算法。然而，使用匯編語言可能需要對所有軟件開發(fā)階段進行適當?shù)膽?或剪裁（例如，第 8 章的要求）。
5.4.3 考慮到表 1 中列出的主題，相應的指南或者開發(fā)環(huán)境應涵蓋適合于建模、設計或者 編程語言（見 5.4.2）的準則，并且這些準則并不完全由語言自身決定。
示例 1：MISRA C（見參考文獻[3]）是編程 C 語言的編碼指南，并包括自動生成代碼的指南。
示例 2：在具有自動代碼生成功能的基于模型的開發(fā)中，可以在模型層面以及代碼層面中應用該準則。 可以考慮適當?shù)慕ｏL格指南，包括 MISRA AC 系列。商業(yè)工具的風格指南也可作為可能的 指南。
注：可以為特定的相關項開發(fā)修改現(xiàn)有的編碼指南和建模指南。
5.5 工作成果
5.5.1 軟件開發(fā)環(huán)境文檔，由 5.4.1～5.4.3 和 C.4.1～C.4.11 的要求得出。
6 軟件安全要求的定義
6.1 目的
該子階段的目的是：
a) 定義或細化由技術安全概念和系統(tǒng)架構設計規(guī)范導出的軟件安全要求； b) 定義軟件實現(xiàn)所需的安全相關功能和特性；
c) 細化在 GB/T 34590.4 第 6 章最初定義的軟硬件接口要求；及
d) 驗證軟件安全要求和軟硬件接口要求是否適用于軟件開發(fā)，及驗證它們與技術安全 概念和系統(tǒng)架構設計規(guī)范的一致性。
6.2 總則
在GB/T 34590.4，第6章定義的系統(tǒng)架構設計階段中，技術安全要求被細化并分配 給硬件和軟件。軟件安全要求的定義特別考慮硬件約束及其對軟件的影響。該子階段包括軟 件安全要求的定義，以支持后續(xù)設計階段。
6.3 本章的輸入
6.3.1 前提條件
應具備下列信息：
——技術安全要求規(guī)范，按照 GB/T 34590.4，6.5.1；
——技術安全概念，按照 GB/T 34590.4，6.5.2；
——系統(tǒng)架構設計規(guī)范，按照 GB/T 34590.4，6.5.3；
——軟硬件接口規(guī)范，按照 GB/T 34590.4，6.5.4；及
——軟件開發(fā)環(huán)境文檔，按照 5.5.1。
6.3.2 支持信息
可考慮下列信息：
——硬件設計規(guī)范(見 GB/T 34590.5，7.5.1)；及
——軟件非安全相關功能和特性的定義（來自外部）。
6.4 要求和建議
6.4.1 軟件安全要求得出時，應考慮所需的安全相關的軟件功能和特性，其失效可能違背 分配給軟件的技術安全要求。
注 1：軟件安全要求或者直接來源于分配給軟件的技術安全要求，或者是對軟件功能和特性的要求（這 些要求如果不滿足可能違背分配給軟件的技術安全要求）。
示例 1：軟件安全相關功能可以是：
——使標稱功能可以安全執(zhí)行的功能；
——使系統(tǒng)達到或維持安全狀態(tài)或降級狀態(tài)的功能；
——與安全相關硬件要素故障探測、指示和減輕相關的功能；
——與操作系統(tǒng)、基礎軟件或應用軟件本身失效探測、指示和減輕有關的自檢或監(jiān)控功能；
——在生產、運行、服務和報廢過程中與車載測試和非車載測試相關的功能；
——允許在生產和服務過程中對軟件進行修改的功能；或
——與性能或對時間敏感的操作相關的功能。
示例 2：安全相關的特殊特性包括對錯誤輸入的魯棒性、不同功能之間的獨立性或免于干擾、或軟件 的容錯能力。
注 2：安全導向分析（本文件 7.4.10 或 7.4.11）可用于識別額外的軟件安全要求或為其實現(xiàn)提供證據(jù)。
6.4.2 軟件安全要求的定義應按照 GB/T 34590.4，6.4.1 和 6.4.3 的技術安全要求、 技術安全概念和系統(tǒng)架構設計得出，并應考慮如下內容：
a) 安全要求的定義和管理，按照 GB/T 34590.8，第 6 章；
b) 已定義的系統(tǒng)和硬件的配置；
示例 1：配置參數(shù)可包括增益控制、帶通頻率和時鐘分頻。
c) 軟硬件接口規(guī)范；
d) 硬件設計規(guī)范的相關要求；
e) 時間約束；
f) 示例 2：由系統(tǒng)層面要求的響應時間得出執(zhí)行或反應時間。
g) 外部接口；及
示例 3：通訊和用戶接口。
h) 對軟件有影響的車輛、系統(tǒng)或者硬件的每個運行模式以及運行模式之間的轉換。
示例 4：運行模式包括下電或休眠、初始化、正常運行、降級和用于測試或刷新的其他高級模式。
6.4.3 如果對軟件安全要求進行了 ASIL 等級分解，應滿足 GB/T 34590.9，第 5 章的 要求。
6.4.4 在 GB/T 34590.4 第 6 章初步定義的軟硬件接口規(guī)范，應細化到可以通過軟件 正確控制和使用硬件的程度，并應描述硬件和軟件間每個與安全相關的依賴性。
6.4.5 如果嵌入式軟件除了執(zhí)行 6.4.1 定義的安全要求的功能外，還執(zhí)行了其他功能，則 應按照所應用的質量管理體系的要求提供這些功能及其特性的規(guī)范。
6.4.6 應由負責系統(tǒng)開發(fā)、硬件開發(fā)和軟件開發(fā)的人員共同驗證細化后的軟硬件接口規(guī)范。
6.4.7 應按照 GB/T 34590.8 第 6 章和第 9 章的要求，對軟件安全要求和細化后的軟 硬件接口規(guī)范進行驗證，以提供證據(jù)證明：
a) 軟件開發(fā)的適用性；
b) 與技術安全要求的符合性和一致性；
c) 與系統(tǒng)設計的符合性；及
d) 與軟硬件接口的一致性。
6.5 工作成果
6.5.1 軟件安全需求規(guī)范，由 6.4.1～6.4.3 和 6.4.5 的要求得出。
6.5.2 軟硬件接口規(guī)范（細化的），由 6.4.4 的要求得出。
注：該工作成果參照 GB/T 34590.5，6.5.2 相同的工作成果。
6.5.3 軟件驗證報告，由 6.4.6 和 6.4.7 的要求得出。
7 軟件架構設計
7.1 目的
該子階段的目的是：
a) 開發(fā)滿足軟件安全要求和其他軟件要求的軟件架構設計；
b) 驗證軟件架構設計適合滿足所要求 ASIL 等級的軟件安全要求；及
c) 支持軟件的實現(xiàn)與驗證。
7.2 總則
軟件架構設計以層次結構的形式表示軟件架構要素以及他們的交互方式。描述了靜態(tài)方 面，如軟件組件之間的接口、和動態(tài)方面，如進程序列和時序行為。
注：軟件架構設計并不一定局限于某個微控制器或 ECU。每個微控制器的軟件架構也在此子條中論述。
軟件架構設計既能滿足軟件安全要求，又能滿足其他軟件要求。因此，在該子階段中， 與安全相關和非安全相關的軟件要求在同一個開發(fā)過程中處理。
軟件架構設計提供了實現(xiàn)軟件要求和 ASIL 等級所需的軟件安全要求的方法，也提供了 管理軟件詳細設計和實現(xiàn)復雜度的方法。
7.3 本章輸入
7.3.1 前提條件
應具備下列信息：
——軟件開發(fā)環(huán)境文檔，按照 5.5.1；
——軟硬件接口規(guī)范(細化的)，按照 6.5.2；及
——軟件安全需求規(guī)范，按照 6.5.1。
7.3.2 支持信息
可考慮下列信息：
——技術安全概念（見 GB/T 34590.4，6.5.2）；
——系統(tǒng)架構設計規(guī)范（見 GB/T 34590.4，6.5.3）；
——可用的經(jīng)鑒定合格的軟件組件（見 GB/T 34590.8，第 12 章）；及
——軟件非安全相關功能和特性的定義以及其他軟件要求的定義，按照 6.4.5（來自外 部）。
7.4 要求和建議
7.4.1 為避免軟件架構設計和后續(xù)開發(fā)活動中的系統(tǒng)性故障，軟件架構設計的描述應滿足
表 2 中列出的軟件架構設計標記法所支持的特征：
a) 可理解性；
b) 一致性；
c) 簡單性；
d) 可驗證性；
e) 模塊化；
f) 抽象性；
注：抽象性可以通過使用層次化結構、分組方案或視圖來支持，以涵蓋架構設計的靜態(tài)、動態(tài)或 部署方面。
g) 封裝性；及
h) 可維護性。