Codeofchina.com is in charge of this English translation. In case of any doubt about the English translation, the Chinese original shall be considered authoritative.
GB/T 34590 consists of the following parts under the general title Road Vehicles - Functional Safety:
——Part 1: Vocabulary;
——Part 2: Management of Functional Safety;
——Part 3: Concept Phase;
——Part 4: Product Development at the System Level;
——Part 5: Product Development at the Hardware Level;
——Part 6: Product Development at the Software Level;
——Part 7: Production and Operation;
——Part 8: Supporting Processes;
——Part 9: Automotive Safety Integrity Level (ASIL)-oriented and Safety-oriented Analyses;
——Part 10: Guideline.
This part is Part 6 of GB/T 34590.
This part is developed in accordance with the rules given in GB/T 1.1-2009.
This part has been redrafted and modified in relation to ISO 26262-6:2011 Road Vehicles - Functional Safety - Part 6: Product Development at the Software Level.
There are technical deviations between this part and ISO 26262-6:2011. The technical deviations, together with their justifications, are as follows:
——the application scope of this part is modified from "ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3 500kg" to "This standard is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars";
——in order to adapt to the technical conditions in China, adjustment on technical deviations has been made in "Normative References" of this part, which is mainly reflected in Chapter 2 "Normative References" and detailed as follows:
? ISO 26262-1:2011 is replaced with GB/T 34590.1-2017 which is modified in relation to international standard;
? ISO 26262-2:2011 is replaced with GB/T 34590.2-2017 which is modified in relation to international standard;
? ISO 26262-4:2011 is replaced with GB/T 34590.4-2017 which is modified in relation to international standard;
? ISO 26262-5:2011 quoted in ISO 26262-6:2011 is replaced with GB/T 34590.5-2017 which is modified in relation to international standard;
? ISO 26262-8:2011 is replaced with GB/T 34590.8-2017 which is modified in relation to international standard;
? ISO 26262-9:2011 is replaced with GB/T 34590.9-2017 which is modified in relation to international standard.
The following editorial changes present in this part:
——the introduction and its expression as well as Figure 1 of international standard are modified.
This standard was proposed by and is under the jurisdiction of National Technical Committee on Automobiles of Standardization Administration of China (SAC/TC 114).
?
Introduction
ISO 26262 is prepared based on IEC 61508 to comply with needs specific to the application sector of electrical and/or electronic (E/E) systems within road vehicles.
GB/T 34590 is modified in relation to ISO 26262, it is applicable to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic and software components.
Safety is one of the key issues of future automobile development. New functionalities not only in areas such as driver assistance, propulsion, in vehicle dynamics control and active and passive safety systems increasingly touch the domain of system safety engineering. Development and integration of these functionalities will strengthen the need for safety-related system development processes and the need to provide evidence that all reasonable system safety objectives are satisfied.
With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures. GB/T 34590 includes guidance to avoid these risks by providing appropriate requirements and processes.
System safety is achieved through a number of safety measures, which are implemented in a variety of technologies (e.g. mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic) and applied at the various levels of the development process. Although GB/T 34590 is concerned with functional safety of E/E systems, it provides a framework within which safety-related systems based on other technologies can be considered. GB/T 34590:
a) provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases;
b) provides an automotive-specific risk-based approach to determine Automotive Safety Integrity Levels (ASIL);
c) uses ASILs to specify applicable requirements of GB/T 34590 so as to avoid unreasonable residual risk;
d) provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved;
e) provides requirements for relations with suppliers.
Functional safety is influenced by the development process (including such activities as requirements specification, design, implementation, integration, verification, validation and configuration), the production and service processes as well as the management processes.
Safety issues are intertwined with common function-oriented and quality-oriented development activities and work products. GB/T 34590 addresses the safety-related aspects of development activities and work products.
Figure 1 shows the overall structure of this edition of GB/T 34590. GB/T 34590 is based upon a V-model as a reference process model for the different phases of product development. Within the figure:
——the shaded "V"s represent the interconnection between GB/T 34590.3-2017, GB/T 34590.4-2017, GB/T 34590.5-2017, GB/T 34590.6-2017 and GB/T 34590.7-2017;
——the specific clauses are indicated in the following manner: “m-n”, where “m” represents the number of the particular part and “n” indicates the number of the chapter within that part.
Example: "2-6" represents Chapter 6 of GB/T 34590.2-2017.
Figure 1 Overview of GB/T 34590-2017
Road Vehicles - Functional Safety - Part 6: Product Development at the Software Level
1 Scope
This part of GB/T 34590 specifies the requirements for product development at the software level for automotive applications, including the following:
——requirements for initiation of product development at the software level;
——specification of the software safety requirements;
——software architectural design;
——software unit design and implementation;
——software unit testing;
——software integration and testing; and
——verification of software safety requirements.
This standard is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars.
This standard does not address unique E/E systems in special purpose vehicles such as vehicles designed for drivers with disabilities.
Systems and their components released for production, or systems and their components already under development prior to the publication date of this standard, are exempted from the scope. For further development or alterations based on systems and their components released for production prior to the publication of this standard, only the modifications will be developed in accordance with this standard.
This standard addresses possible hazards caused by malfunctioning behavior of E/E safety-related systems, including interaction of these systems. It does not address hazards related to electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar hazards, unless directly caused by malfunctioning behavior of E/E safety-related systems.
This standard does not address the nominal performance of E/E systems, even if dedicated functional performance standards exist for these systems (e.g. active and passive safety systems, brake systems, adaptive cruise system).
2 Normative References
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition (including any amendment) applies to this document.
GB/T 34590.1-2017 Road Vehicles - Functional Safety - Part 1: Vocabulary (ISO 26262-1:2011, MOD)
GB/T 34590.2-2017 Road Vehicles - Functional Safety - Part 2: Management of Functional Safety (ISO 26262-2:2011, MOD)
GB/T 34590.4-2017 Road Vehicles - Functional Safety - Part 4:Product Development at the System Level (ISO 26262-4:2011, MOD)
GB/T 34590.5-2017 Road Vehicles - Functional Safety-Part 5:Product Development at the Hardware Level (ISO 26262-5:2011, MOD)
GB/T 34590.8-2017 Road Vehicles - Functional Safety - Part 8: Supporting Processes (ISO 26262-8:2011, MOD)
GB/T 34590.9-2017 Road Vehicles - Functional Safety - Part 9: Automotive Safety Integrity Level(ASIL)-oriented and Safety-oriented Analyses (ISO 26262-9:2011, MOD)
3 Terms, Definitions and Abbreviations
For the purposes of this document, the terms, definitions and abbreviated terms given in GB/T 34590.1-2017 apply.
4 Requirements
4.1 General Requirements
When claiming compliance with GB/T 34590-2017, each requirement shall be complied with, unless one of the following applies:
a) tailoring of the safety activities in accordance with GB/T 34590.2-2017 has been planned and shows that the requirement does not apply, or
b) a rationale is available that the non-compliance is acceptable and the rationale has been assessed in accordance with GB/T 34590.2-2017.
Information marked as a “Note” or “Example” is only for guidance in understanding, or for clarification of the associated requirement, and shall not be interpreted as a requirement itself or as complete or exhaustive.
The results of safety activities are given as work products. “Prerequisites” are information which shall be available as work products of a previous phase. Given that certain requirements of a clause are ASIL-dependent or may be tailored, certain work products may not be needed as prerequisites.
“Further supporting information” is information that can be considered, but which in some cases is not required by GB/T 34590-2017 as a work product of a previous phase and which may be made available by external sources that are different from the persons or organizations responsible for the functional safety activities.
4.2 Interpretations of Tables
Tables are normative or informative depending on their context. The different methods listed in a table contribute to the level of confidence in achieving compliance with the corresponding requirement. Each method in a table is either
a) a consecutive entry (marked by a sequence number in the leftmost column, e.g. 1, 2, 3), or
b) an alternative entry (marked by a number followed by a letter in the leftmost column, e.g. 2a, 2b, 2c).
For consecutive entries, all methods shall be applied as recommended in accordance with the ASIL. If methods other than those listed are to be applied, a rationale shall be given that these fulfill the corresponding requirement.
For alternative entries, an appropriate combination of methods shall be applied in accordance with the ASIL indicated, independent of whether they are listed in the table or not. If methods listed with different degrees of recommendation for an ASIL, the methods with the higher recommendation should be preferred. A rationale shall be given that the selected combination of methods complies with the corresponding requirement.
Note: a rationale based on the methods listed in the table is sufficient. However, this does not imply a bias for or against methods not listed in the table.
For each method, the degree of recommendation to use the corresponding method depends on the ASIL and is categorized as follows:
——“++” indicates that the method is highly recommended for the identified ASIL;
——“+” indicates that the method is recommended for the identified ASIL;
——“o” indicates that the method has no recommendation for or against its usage for the identified ASIL.
4.3 ASIL-dependent Requirements and Recommendations
The requirements or recommendations of each subclause shall be complied with for ASIL A, B, C and D, if not stated otherwise. These requirements and recommendations refer to the ASIL of the safety goal. If ASIL decomposition has been performed at an earlier stage of development, in accordance with GB/T 34590.9-2017, Chapter 5, the ASIL resulting from the decomposition shall be complied with.
If an ASIL is given in parentheses in GB/T 34590-2017, the corresponding subclause shall be considered as a recommendation rather than a requirement for this ASIL. This has no link with the parenthesis notation related to ASIL decomposition.
5 Initiation of Product Development at the Software Level
5.1 Objectives
The objective of this subclause is to plan and initiate the functional safety activities for the subphases of the software development.
5.2 General
The initiation of the software development is a planning activity, where software development subphases and their supporting processes (see GB/T 34590.8-2017 and GB/T 34590.9-2017) are determined and planned according to the extent and complexity of the item development. The software development subphases and supporting processes are initiated by determining the appropriate methods in order to comply with the requirements and their respective ASIL. The methods are supported by guidelines and tools, which are determined and planned for each subphase and supporting process.
Note 1: tools used for software development can include tools other than software tools.
Example: tools used for testing phases.
The planning of the software development includes the coordination with the product development at the system level (see GB/T 34590.4-2017) and the hardware level (see GB/T 34590.5-2017).
Note 2: Table A.1 in Annex A provides an overview on objectives, prerequisites and work products of the particular phases of production and operation.
Foreword i
Introduction iii
1 Scope
2 Normative References
3 Terms, Definitions and Abbreviations
4 Requirements
4.1 General Requirements
4.2 Interpretations of Tables
4.3 ASIL-dependent Requirements and Recommendations
5 Initiation of Product Development at the Software Level
5.1 Objectives
5.2 General
5.3 Inputs to this Chapter
5.4 Requirements and Recommendations
5.5 Work Products
6 Specification of Software Safety Requirements
6.1 Objectives
6.2 General
6.3 Inputs to this Chapter
6.4 Requirements and Recommendations
6.5 Work Products
7 Software Architectural Design
7.1 Objectives
7.2 General
7.3 Inputs to this Chapter
7.4 Requirements and Recommendations
7.5 Work Products
8 Software Unit Design and Implementation
8.1 Objectives
8.2 General
8.3 Inputs to this Chapter
8.4 Requirements and Recommendations
8.5 Work Products
9 Software Unit Testing
9.1 Objectives
9.2 General
9.3 Inputs to this Chapter
9.4 Requirements and Recommendations
9.5 Work Products
10 Software Integration and Testing
10.1 Objectives
10.2 General
10.3 Inputs to this Chapter
10.4 Requirements and Recommendations
10.5 Work Products
11 Verification of Software Safety Requirements
11.1 Objectives
11.2 General
11.3 Inputs to this Chapter
11.4 Requirements and Recommendations
11.5 Work products
Annex A (Informative) Overview of and Workflow of Management of Product Development at the Software Level
Annex B (Informative) Model-based Development
Annex C (Normative) Software Configuration
Annex D (Informative) Freedom from Interference between Software Elements
Bibliography
道路車輛功能安全
第6部分:產品開發：軟件層面
1范圍
GB/T 34590的本部分規定了車輛在軟件層面產品開發的要求，包括：
——啟動軟件層面產品開發；
——軟件安全要求的定義；
——軟件架構設計；
——軟件單元設計及實現；
——軟件單元測試；
——軟件集成和測試;及
——軟件安全要求的驗證。
本標準適用于安裝在量產乘用車上的包含一個或多個電子電氣系統的與安全相關的系統。
本標準不適用于特殊用途車輛上特定的電子電氣系統，例如，為殘疾駕駛者設計的車輛。
本標準不適用于已經完成生產發布的系統及其組件或在本標準發布日期前開發的系統及其組件。對于在本標準發布前完成生產發布的系統及其組件進行進一步的開發或變更時，僅修改的部分需要按照本標準開發。
本標準針對由電子電氣安全相關系統的故障行為而引起的可能的危害，包括這些系統相互作用而引起的可能的危害。本標準不針對與觸電、火災、煙霧、熱、輻射、毒性、易燃性、反應性、腐蝕性、能量釋放等相關的危害和類似的危害，除非危害是直接由電子電氣安全相關系統的故障行為而引起的。
本標準不針對電子電氣系統的標稱性能，即使這些系統(例如，主動和被動安全系統、制動系統、自適應巡航系統)有專用的功能性能標準。
2規范性引用文件
下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件，僅注日期的版本適用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改單)適用于本文件。
GB/T 34590.1-2017 Road vehicles-Functional safety- Part 1:Vocabulary (ISO 26262-1:2011, MOD)
GB/T 34590.2-2017 Road vehicles-Functional safety- Part 2:Management of functional safety (ISO 26262-2:2011, MOD)
GB/T 34590.4-2017 Road vehicles-Functional safety- Part 4:Product development at the system level (ISO 26262-4:2011, MOD)
GB/T 34590.5-2017 Road vehicles-Functional safety-Part 5:Product development at the hardware level (ISO 26262-5:2011, MOD)
GB/T 34590.8-2017 Road vehicles-Functional safety- Part 8:Supporting processes (ISO 26262-8:2011, MOD)
GB/T 34590.9-2017 Road vehicles-Functional safety-Part 9:Automotive Safety Integrity Level(ASIL)-oriented and safety-oriented analyses (ISO 26262-9:2011, MOD)
3術語、定義和縮略語
GB/T 34590.1—2017界定的術語、定義和縮略語適用于本文件。
4要求
4.1 一般要求
如聲明滿足GB/T 34590—2017的要求時，應滿足每一個要求，除非有下列情況之一：
a) 按照GB/T 34590.2—2017的要求，已經計劃了安全活動的剪裁并表明這些要求不適用；或
b)不滿足要求的理由存在且是可接受的，并且按照GB/T 34590.2—2017對該理由進行了評估。
標有“注”或“示例”的信息僅用于輔助理解或闡明相關要求，不應作為要求本身且不具備完備性。
將安全活動的結果作為工作成果。應具備上一階段工作成果作為“前提條件”的信息。如果章條的某些要求是依照ASIL定義的或可剪裁的，某些工作成果可不作為前提條件。
“支持信息”是可供參考的信息，但在某些情況下，GB/T 34590—2017不要求其作為上一階段的工作成果，并且可以是由不同于負責功能安全活動的人員或組織等外部資源提供的信息。
4.2表的詮釋
表屬于規范性表還是資料性表取決于上下文。在實現滿足相關要求時，表中列出的不同方法有助于置信度水平。表中的每個方法是：
a) 一個連續的條目（在最左側列以順序號標明，如1、2、3);或
b) 一個選擇的條目（在最左側列以數字后加字母標明，如2a、2b、2c)。
對于連續的條目，全部方法應按照ASIL等級推薦予以使用。除了所列出的方法外，如果應用所列出方法以外的其他方法，應給出滿足相關要求的理由。
對于選擇性的條目，應按照指定的ASIL等級，對這些方法進行適當的組合，不依賴于這些方法是否在表中列出。如果所列出的方法對于一個ASIL等級來說具有不同的推薦等級，宜采用具有較高推薦等級的方法。應給出所選的方法組合滿足相關要求的理由。
注：表中所列出的方法的理由是充分的。但是，這并不意味著有傾向性或對未列到表中的方法表示反對。
對于每種方法，應用相關方法的推薦等級取決于ASIL等級，分類如下：
——“ + + ”表示對于指定的ASIL等級，高度推薦該方法；
——“ + ”表示對于指定的ASIL等級，推薦該方法；
——“o”表示對于指定的ASIL等級，不推薦也不反對該方法。
4.3基于ASIL等級的要求和建議
若無其他說明，對于ASIL A、B、C和D等級，應滿足每一子章條的要求或建議。這些要求和建議參照安全目標的ASIL等級。如果在項目開發的早期對ASIL等級完成了分解，按照GB/T 34590.9—2017第5章，應遵循分解后的ASIL等級。
如果GB/T 34590—2017中ASIL等級在括號中給出，則對于該ASIL等級，相應的子章條應被認為是推薦而非要求。這里的括號與ASIL等級分解無關。
5啟動軟件層面產品開發
5.1目的
本子章條的目的是計劃并啟動軟件開發子階段的功能安全活動。
5.2總則
軟件開發的啟動是一項計劃活動，即按照相關項開發的范圍和復雜度確定并計劃軟件開發中各子階段及其支持過程(參見GB/T 34590.8—2017和GB/T 34590.9—2017)。通過確定適當的方法，啟動軟件開發各子階段和支持過程，以滿足要求及其相應的ASIL等級。這些方法得到指南和工具的支持，這些指南和工具是為每個子階段和支持過程而確定和計劃的。
注1:用于軟件開發的工具可包括其他非軟件工具。
示例:用于測試階段的工具。
軟件開發計劃包括協調系統層面（參見GB/T 34590.4—2017)和硬件層面（參見GB/T 34590.5—2017)的產品開發。
注2:附錄A中表A.1提供了對軟件層面產品開發特定子階段的目的、前提條件和工作成果的概覽。
5.3本章的輸入
5.3.1前提條件
應具備下列信息：
——項目計劃（細化的），按照GB/T 34590.4—2017的5.5.1;
——安全計劃（細化的），按照GB/T 34590.4—2017的5.5.2;
——技術安全概念，按照GB/T 34590.4—2017的7.5.1;
——系統設計規范，按照GB/T 34590.4—2017的7.5.2;及
——相關項集成和測試計劃（細化的），按照GB/T 34590.4—2017的8.5.1。
5.3.2支持信息
可考慮下列信息：
——經鑒定合格的軟件工具(參見GB/T 34590.8—2017第11章）；
——可用的經鑒定合格的軟件組件(參見GB/T 34590.8—2017第12章）；
——用于建模語言和編程語言的設計和編碼指南(來自外部）；
——方法應用的指南(來自外部）；及
——工具應用的指南(來自外部）。
5.4要求和建議
5.4.1應對軟件層面產品開發的活動和適當方法的確定進行計劃。
5.4.2應按照GB/T 34590.2—2017的6.4.5,并基于圖2給出的參考階段模型，為軟件層面產品開發進行生命周期的剪裁。
5.4.3如果開發可配置軟件，應按照附錄C。
5.4.4包括生命周期階段、方法、語言和工具在內的相關項軟件開發流程，應在軟件生命周期的所有子階段保持一致，并與系統和硬件開發階段兼容，由此，所需的數據可被正確的轉化。
注：相關項軟件的各階段、任務和活動（包括迭代步驟）的順序，用于確保軟件相關工作成果與硬件層面產品開發(參見GB/T 34590.5—2017)及系統層面產品開發（參見GB/T34590.4—2017)保持一致。
注：圖中GB/T 34590— 2017每部分的特定章用以下方式標示，“m”代表部分號，“n”代表章號，例如“4-7”代表 GB/T 34590.4—2017 第 7 章。
圖2軟件開發參考階段模型
5.4.5應為軟件開發的每個子階段進行如下選擇，包括其應用的指南：
a) 方法；及
b) 相應的工具。
5.4.6當選擇一種合適的建模語言或編程語言時，應考慮準則：
a) 無歧義的定義；示例：語言的語法和語義。
b) 為嵌人式實時軟件和運行時錯誤處理提供的支持;及
c) 為模塊化、抽象化和結構化的構建提供的支持。
對于通過語言本身不能充分說明的準則應由相應的指南或開發環境來覆蓋。
注1：所選擇的編程語言(如ADA、C、C+ +Java、匯編或圖形化的建模語言）支持5.4.7中給出的通則。可應用編程指南或建模指南以滿足這些通則。
注2：匯編語言可用于那些不適合使用高級語言的軟件部分，如與硬件接口的底層軟件、中斷處理程序、或對時間敏感的算法。
5.4.7為了支持設計和實現的正確性，建模語言或編程語言的設計和編碼指南應按照表1所列出的通則。
注1:對不同的編程語言，編碼指南通常是不同的。
注2:對基于模型的開發，編碼指南可以是不同的。附錄B描述了基于模型的開發的概念。
注3:對特定相關項的開發，可對現有編碼指南進行修改。
示例：MISRA C[3]和MISRA AC AGC[4]是C語言的編碼指南。
表1建模和編碼指南涵蓋的通則
通則 ASIL等級
A B C D
1a 強制低復雜性a + + + + + + + +
1b 語言子集的使用b + + + + + + + +
1c 強制強類型c + + + + + + + +
1d 防御式實現技術的使用 o + + + + +
1e 已建立的設計原理的使用 + + + + +
1f 無歧義圖形化表示的使用 + + + + + + +
1g 風格指南的使用 + + + + + + +
1h 命名慣例的使用 + + + + + + + +
a可能需要將該通則與GB/T 34590此部分中其他方法進行恰當的折中。
b方法1b的目的是：
——避免使用定義模糊的語言結構，不同的建模器、編碼器、代碼生成器或編譯器可能導致對語言結構的不同
解釋。
——避免從經驗上來講容易導致錯誤的語言結構，例如:局部和全局變量的條件分配或相同命名。
——避免可導致未處理過的運行時錯誤的語言結構。
c方法1c的目的是利用在語言中非固有的強類型的原理。
5.5工作成果
5.5.1安全計劃（細化的），由5.4.1?5.4.7的要求得出。
5.5.2軟件驗證計劃，由5.4.1?5.4.5和5.4.7的要求得出。
5.5.3模型語言和編程語言的設計和編碼指南，由5.4.6和5.4.7的要求得出。
5.5.4工具應用指南，由5.4.5和5.4.6的要求得出。
6軟件安全要求的定義
6.1目的
該子階段的第一個目的是定義軟件安全要求。軟件安全要求來源于技術安全概念和系統設計規范。
第二個目的是對GB/T 34590.4—2017第7章建立的軟硬件接口要求進行細化。
第三個目的是驗證軟件安全要求和軟硬件接口要求與技術安全概念和系統設計規范的一致性。
6.2總則
應在GB/T 34590.4—2017第7章定義的系統設計階段中將技術安全要求細化并分配給硬件和軟件。軟件安全要求的定義考慮硬件約束及其對軟件的影響。該子階段包括軟件安全要求的定義，以支持后續設計階段。
6.3本章的輸入
6.3.1前提條件
應具備下列信息：
——技術安全概念，按照GB/T 34590.4—2017的7.5.1;
——系統設計規范，按照GB/T 34590.4—2017的7.5.2;
——軟硬件接口規范，按照GB/T 34590.4—2017的7.5.3;
——安全計劃（細化的），按照5.5.1;
——軟件驗證計劃，按照5.5.2。
6.3.2支持信息
可考慮下列信息：
——硬件設計規范(參見GB/T 34590.5—2017的7.5.1);
——方法應用指南(來自外部）。
6.4要求和建議
6.4.1軟件安全要求應針對每個基于軟件的功能，這些功能的失效可能導致違背分配到軟件的技術安全要求。
示例：失效可能導致違背安全要求的功能可以是：
——使系統達到或維持安全狀態的功能；
——與安全相關硬件要素的故障探測、指示和處理相關的功能；
——與軟件自身故障的探測、通知和減輕相關的功能；
注1:這些功能包括操作系統中軟件的自身監控及應用層特定的軟件自身監控，以探測、指示和處理應用軟件中的系統性故障。
——與車載測試和非車載測試相關功能；
注2:車載測試可以在車輛運行過程、預運行階段和運行后階段內，由系統自身或通過車載網絡內的其他系統執行。
注3:非車載測試參照生產或服務階段對安全相關的功能或屬性的測試。
——允許在生產和服務過程中對軟件進行修改的功能;及
——與性能或對時間敏感的運行相關的功能。
6.4.2軟件安全要求的定義應由符合GB/T 34590.4—2017中7.4.1和7.4.5的技術安全概念和系統設計得出，并應考慮：
a) 安全要求的定義和管理，按照GB/T 34590.8—2017第6章；
b) 已定義的系統和硬件的配置；
示例1:配置參數可包括增益控制、帶通頻率和時鐘分頻。
c) 軟硬件接口規范；
d) 硬件設計規范的相關要求；
e) 時間約束；
示例2:由系統層面要求的響應時間得出執行或反應時間。
f) 外部接口；及
示例3:通訊和用戶接口。
g) 對軟件有影響的車輛、系統或者硬件的每個運行模式。
示例4:硬件裝置的運行模式可包括默認模式、初始化模式、測試模式和高級模式。
6.4.3如果對軟件安全要求進行了 ASIL分解，應滿足GB/T 34590.9—2017第5章的要求。
6.4.4在GB/T 34590.4—2017第7章初步定義的軟硬件接口規范，應細化到可以正確控制和使用硬件的程度，并應描述硬件和軟件間每個與安全相關的依賴性。
6.4.5除與6.4.1定義的安全要求相關的功能外，如果嵌入式軟件執行了其他功能，則應對這些功能進行定義，或參考其規范。
6.4.6應按照GB/T 34590.8—2017第9章，計劃對軟件安全要求和細化的軟硬件接口規范的驗證。
6.4.7應由負責系統開發、硬件開發和軟件開發的人員共同驗證細化的軟硬件接口規范。
6.4.8應按照GB/T 34590.8—2017第6章和第9章，對軟件安全要求和細化的軟硬件接口要求進行
驗證，以展示它們：
a) 與技術安全要求的符合性和一致性；
b) 與系統設計的符合性;及
c) 與軟硬件接口的一致性。
6.5工作成果
6.5.1軟件安全需求規范，由6.4.1?6.4.3和6.4.5的要求得出。
6.5.2軟硬件接口規范(細化的），由6.4.4的要求得出。
注：該工作成果參照GB/T 34590.5—2017中6.5.2相同的工作成果。
6.5.3軟件驗證計劃（細化的），由6.4.6的要求得出。
6.5.4軟件驗證報告，由6.4.7和6.4.8的要求得出。
7軟件架構設計
7.1目的
該子階段的第一個目的是開發實現軟件安全要求的軟件架構設計。
該子階段的第二個目的是驗證軟件架構設計。
7.2總則
軟件架構設計描述全部軟件組件及其在層次結構中的交互。靜態方面，如所有軟件組件間的接口和數據路徑;動態方面，如進程順序和時序行為，都得到描述。
注：軟件架構設計不必局限于某個微控制器或電控單元，它關系到技術安全概念和系統設計。每個微控制器的軟件架構也在本章討論。
為開發既實現軟件安全要求又實現非安全要求的軟件架構設計，在此子階段，安全和非安全性要求應在同一開發過程中處理。
軟件架構設計提供了實施軟件安全要求和管理軟件開發復雜性的方法。
7.3本章的輸入
7.3.1前提條件
應具備下列信息：
——安全計劃（細化的），按照5.5.1；
——用于建模及編程語言的設計和編碼指南，按照5.5.3；
——軟硬件接口規范，按照GB/T 34590.4—2017的7.5.3；
——軟件安全需求規范，按照6.5.1；
——軟件驗證計劃（細化的），按照6.5.3;及
——軟件驗證報告，按照6.5.4。
7.3.2支持信息
可考慮下列信息：
——技術安全概念(參見GB/T 34590.4—2017的7.5.1);
——系統設計規范（參見GB/T 34590.4—2017的7.5.2);
——可用的經鑒定合格的軟件組件(見GB/T 34590.8—2017第12章）；
——工具應用指南，按照5.5.4;及
——應用方法指南(來自外部）。
7.4要求和建議
7.4.1為確保軟件架構設計獲取必要信息以允許后續開發活動得到正確且有效的執行，應使用表2中列出的軟件架構設計的標記法，對軟件架構設計進行恰當抽象層級的描述。
表2軟件架構設計的標記法
方法 ASIL等級
A B C D
1a 非形式記法 + + + + + +
1b 半形式記法 + + + + + + +
1c 形式記法 + + + +
7.4.2在軟件架構設計開發中應考慮下述方面：
a) 軟件架構設計的可驗證性；
注：這表明軟件架構設計和軟件安全要求之間的雙向可追溯性。
b) 可配置軟件的適用性；
c) 軟件單元設計和實現的可行性；
d) 軟件集成測試中，軟件架構的可測性;及
e) 軟件架構設計的可維護性。
7.4.3為避免因高度復雜性導致的失效，應通過使用表3列出的原則，使軟件架構設計具有以下屬性:
a) 模塊化；
b) 封裝性;及
c) 簡單性。
