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) 简单性。
