GB∕T 34590.6-2017
基本信息
标准号： GB∕T 34590.6-2017
中文名称：道路车辆 功能安全 第6部分：产品开发：软件层面
标准类别：国家标准(GB)
标准状态：现行
出版语种：简体中文
下载格式：.rar .pdf
下载大小：3060KB
标准分类号
关联标准
出版信息
相关单位信息
标准简介
GB∕T 34590.6-2017 道路车辆 功能安全 第6部分：产品开发：软件层面
GB∕T34590.6-2017
标准压缩包解压密码：www.bzxz.net
标准图片预览
标准内容
ICS43.040
中华人民共和国国家标准
GB/T34590.6—2017
道路车辆
功能安全
第6部分：产品开发：软件层面
Road vehicles-Functional safety-Part 6:Product development at the software level(ISO26262-6:2011.MOD)
2017-10-14发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
2018-05-01实施
规范性引用文件
术语、定义和缩略语
一般要求
表的诠释
基于ASIL等级的要求和建议
5启动软件层面产品开发
5.3本章的输人
要求和建议
工作成果
6软件安全要求的定义
本章的输人
要求和建议
工作成果
7软件架构设计
本章的输人
要求和建议
工作成果
8软件单元设计和实现
目的·
总则·
8.3本章的输人
要求和建议
工作成果·
软件单元测试·
............
GB/T34590.6—2017
GB/T34590.6—2017
本章的输人
要求和建议
工作成果
软件集成和测试
本章的输人
要求和建议
工作成果
软件安全要求验证
本章的输人
要求和建议
工作成果
附录A（资料性附录）
产品开发软件层面管理的概览和工作流程·附录B（资料性附录）
基于模型的开发
附录C（规范性附录）
软件配置
附录D（资料性附录）避免软件要素间的相互干扰参考文献
GB/T34590《道路车辆功能安全》分为以下部分：第1部分：术语；
第2部分：功能安全管理；
第3部分：概念阶段；
一第4部分：产品开发：系统层面；第5部分：产品开发：硬件层面；第6部分：产品开发：软件层面：一第7部分：生产和运行；
第8部分：支持过程；
第9部分：以汽车安全完整性等级为导向和以安全为导向的分析；第10部分：指南。
本部分为GB/T34590的第6部分。本部分按照GB/T1.1—2009给出的规则起草。GB/T34590.6—2017
本部分使用重新起草法修改采用1IS026262-6：2011《道路车辆功能安全第6部分：产品开发：软件层面》。
本部分与ISO26262-6：2011的技术性差异及其原因如下：修改了本部分的适用范围，由原文的“适用于安装在最大总质量不超过3.5t的量产乘用车上的包含一个或多个电子电气系统的与安全相关系统”改为“适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统”；一关于规范性引用文件，本部分做了具有技术性差异的调整，以适应我国的技术条件，调整的情况集中反映在第2章“规范性引用文件”中，具体调整如下：●用修改采用国际标准的GB/T34590.1—2017代替ISO26262-1:2011；?用修改采用国际标准的GB/T34590.2—2017代替ISO26262-2：2011：·用修改采用国际标准的GB/T34590.4—2017代替ISO26262-4：2011；?用修改采用国际标准的GB/T34590.5一2017代替ISO26262-6：2011引用的ISO262625:2011
·用修改采用国际标准的GB/T34590.8—2017代替ISO26262-8：2011；●用修改采用国际标准的GB/T34590.9—2017代替ISO26262-9：2011本部分还做了下列编辑性修改：修改了国际标准的言及其表述和图1的内容本部分由全国汽车标准化技术委员会（SAC/TC114）提出并归口。本部分负责起草单位：中国汽车技术研究中心、上海海拉电子有限公司、舍弗勒投资（中国）有限公司，泛亚汽车技术中心有限公司、博世汽车部件（苏州）有限公司、中国第一汽车股份有限公司、北京兴科迪科技有限公司、联合汽车电子有限公司、东软集团股份有限公司、北京经纬恒润科技有限公司、上汽大众汽车有限公司，上海汽车集团股份有限公司商用车技术中心本部分参加起草单位：重庆长安汽车股份有限公司，浙江尤奈特电机有限公司、上汽通用五菱汽车股份有限责任公司、本田技研工业（中国）投资有限公司，碧智三维公司、东风汽车有限公司东风日产乘用车公司、爱德克斯（常州）管理有限公司、AW（杭州）信息技术有限公司、京滨电子装置研究开发（上GB/T34590.6—2017
海）有限公司
本部分主要起草人：李波、蒋军、薛剑波、杨虎、尚世亮、童菲、曲元宁、张立君、蒋云、史晓密、刘北、常平、陈伟、明月、付越、吴含冰、张乐敏、宋锦明、周宏伟、刘姿汝、褚静娟、匡小军、盛一芝、王轶群、韩子凯、张小帆、徐寅、李钟、储小勤、徐惠忠。IV
GB/T34590.6—2017
ISO26262是以IEC61508为基础，为满足道路车辆上电子电气系统的特定需求而编写。GB/T34590修改采用ISO26262，适用于道路车辆上由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动。安全是未来汽车发展的关键问题之一，不仅在驾驶辅助和动力驱动领域，而且在车辆动态控制和主被动安全系统领域，新的功能越来越多地触及到系统安全工程领域。这些功能的开发和集成将强化对安全相关系统开发流程的需求，并且要求提供满足所有合理的系统安全目标的证明。随着技术日益复杂、软件和机电一体化应用不断增加，来自系统性失效和随机硬件失效的风险逐渐增加。GB/T34590通过提供适当的要求和流程给出了避免风险的指导。系统安全是通过一系列安全措施实现的。安全措施通过各种技术（例如，机械、液压、气压、电子、电气、可编程电子等）实现且应用于开发过程中的不同层面。尽管GB/T34590针对的是电子电气系统的功能安全，但是它也提供了一个框架，在该框架内可考虑基于其他技术的与安全相关系统。GB/T34590：
a）提供了一个汽车安全生命周期（管理、开发、生产、运行、服务、报废），并支持在这些生命周期阶段内对必要活动的剪裁；
提供了一种汽车特定的基于风险的分析方法，以确定汽车安全完整性等级（ASIL）；b）
应用汽车安全完整性等级（ASIL）定义GB/T34590中适用的要求，以避免不合理的残余c）
风险；
提供了对于确认和认可措施的要求，以确保达到一个充分、可接受的安全等级；e）提供了与供应商相关的要求。功能安全受开发过程（例如，包括需求规范、设计、实现、集成、验证、确认和配置）、生产过程、服务过程和管理过程的影响。bZxz.net
安全问题与常规的以功能为导向和以质量为导向的开发活动及工作成果相互关联。GB/T34590涉及与安全相关的开发活动和工作成果。图1为GB/T34590的整体架构。GB/T34590基于V模型为产品开发的不同阶段提供参考过程模型：
阴影“V”表示GB/T34590.3—2017、GB/T34590.4—2017、GB/T34590.5—2017、GB/T34590.6—2017、GB/T34590.7—2017之间的相互关系；以“m-n”方式表示的具体章条中，“m\代表特定部分的编号，“n\代表该部分章的编号。示例：“2-6代表GB/T34590.2—2017第6章。GB/T34590.6—2017
2-5整体安全管理
3.概念阶段
3-5相关项定义
3-6安全生命周期启动
3-7危害分析和风险评估
3-8功能安全概念
8-5分布式开发的接口
8-6安全要求的定义和管理
8-7配置管理
8-8变更管理
8-9验证
2.功能安全管理
2-6概念阶段和产品开发过程中的安全管理4.产品开发：系统层面
4-5启动系统层面产品开发
4-6技术安全要求的定义
4-7系统设计
5.产品开发：硬件层面
5-5启动硬件层面产品开发
5-6硬件安全要求的定义
5-7硬件设计
5-8硬件架构度量的评估
5-9随机硬件失效导致违背
安全目标的评估
5-10硬件集成和测试
8.支持过程
4-11生产发布
2-7相关项生产发布后的安全管理7.生产和运行
7-5生产
4-10功能安全评估
4-9安全确认
4-8相关项集成和测试
6.产品开发：软件层面
6-5启动软件层面产品开发
6-6软件安全要求的定义
6-7软件架构设计
6-8软件单元设计和实现
6-9软件单元测试
6-10软件集成和测试
6-11软件安全要求验证
8-10文档
8-11使用软件工具的置信度
8-12软件组件的鉴定
8-13硬件组件的鉴定
8-14在用证明
9.以汽车安全完整性等级为导向和以安全为导向的分析9-5关于ASIL剪裁的要求分解
9-6要素共存的准则
9-7相关失效分析
9-8安全分析
10.指南
GB/T34590—2017概览
7-6运行、服务
（维护与维修）
和报度
1范围
道路车辆功能安全
第6部分：产品开发：软件层面
GB/T34590的本部分规定了车辆在软件层面产品开发的要求，包括：启动软件层面产品开发：
软件安全要求的定义；
软件架构设计；
软件单元设计及实现；
软件单元测试；
软件集成和测试；及
软件安全要求的验证。
GB/T34590.6—2017
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。本标准不适用于特殊用途车辆上特定的电子电气系统，例如，为残疾驾驶者设计的车辆。本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时，仅修改的部分需要按照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害，包括这些系统相互作用而引起的可能的危害。本标准不针对与触电、火灾，烟雾、热，辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由电子电气安全相关系统的故障行为而引起的。本标准不针对电子电气系统的标称性能，即使这些系统（例如，主动和被动安全系统、制动系统、自适应航系统）有专用的功能性能标准。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T34590.1—2017道路车辆功能安全第1部分：术语（ISO26262-1:2011，MOD）GB/T34590.2—2017道路车辆功能安全第2部分：功能安全管理（ISO26262-2：2011，MOD）GB/T34590.4—2017道路车辆功能安全第4部分：产品开发：系统层面（ISO26262-4：2011，MOD)
GB/T34590.5—2017
道路车辆功能安全第5部分：产品开发：硬件层面（ISO26262-5：2011，MOD)
GB/T34590.8一2017道路车辆功能安全第8部分：支持过程（ISO26262-8：2011，MOD）GB/T34590.9一2017道路车辆功能安全第9部分：以汽车安全完整性等级为导向和以安全为导向的分析（ISO26262-9：2011，MOD）3术语、定义和缩略语
GB/T34590.1一2017界定的术语、定义和缩略语适用于本文件。1
GB/T34590.6—2017
4要求
4.1一般要求
如声明满足GB/T34590一2017的要求时，应满足每一个要求，除非有下列情况之一：a）按照GB/T34590.2一2017的要求，已经计划了安全活动的剪裁并表明这些要求不适用；或b）不满足要求的理由存在且是可接受的，并且按照GB/T34590.2一2017对该理由进行了评估。标有“注”或“示例”的信息仅用于辅助理解或阐明相关要求，不应作为要求本身且不具备完备性。将安全活动的结果作为工作成果。应具备上一阶段工作成果作为“前提条件”的信息。如果章条的某些要求是依照ASIL定义的或可剪裁的，某些工作成果可不作为前提条件。“支持信息”是可供参考的信息，但在某些情况下，GB/T34590一2017不要求其作为上一阶段的工作成果，并且可以是由不同于负责功能安全活动的人员或组织等外部资源提供的信息。4.2表的诠释
表属于规范性表还是资料性表取决于上下文。在实现满足相关要求时，表中列出的不同方法有助于置信度水平。表中的每个方法是：a）一个连续的条目（在最左侧列以顺序号标明，如1、2、3)；或b）一个选择的条目（在最左侧列以数字后加字母标明，如2a、2b、2c）。对于连续的条目，全部方法应按照ASIL等级推荐予以使用。除了所列出的方法外，如果应用所列出方法以外的其他方法，应给出满足相关要求的理由。对于选择性的条目，应按照指定的ASIL等级，对这些方法进行适当的组合，不依赖于这些方法是否在表中列出。如果所列出的方法对于一个ASIL等级来说具有不同的推荐等级，宜采用具有较高推荐等级的方法。应给出所选的方法组合满足相关要求的理由。注：表中所列出的方法的理由是充分的。但是，这并不意味着有倾向性或对未列到表中的方法表示反对。对于每种方法，应用相关方法的推荐等级取决于ASIL等级，分类如下：_“十十”表示对于指定的ASIL等级，高度推荐该方法；一“十”表示对于指定的ASIL.等级，推荐该方法；一“o”表示对于指定的ASIL等级，不推荐也不反对该方法4.3基于ASIL等级的要求和建议
若无其他说明，对于ASILA、B、C和D等级，应满足每一子章条的要求或建议。这些要求和建议参照安全目标的ASIL等级。如果在项目开发的早期对ASIL等级完成了分解，按照GB/T34590.9一2017第5章，应遵循分解后的ASIL等级如果GB/T34590一2017中ASIL等级在括号中给出，则对于该ASIL等级，相应的子章条应被认为是推荐而非要求。这里的括号与ASIL等级分解无关。5启动软件层面产品开发
5.1目的
本子章条的目的是计划并启动软件开发子阶段的功能安全活动2
5.2总则
GB/T34590.6—2017
软件开发的启动是一项计划活动，即按照相关项开发的范围和复杂度确定并计划软件开发中各子阶段及其支持过程（参见GB/T34590.8—2017和GB/T34590.9—2017）。通过确定适当的方法，启动软件开发各子阶段和支持过程，以满足要求及其相应的ASIL等级。这些方法得到指南和工具的支持这些指南和工具是为每个子阶段和支持过程而确定和计划的。注1：用于软件开发的工具可包括其他非软件工具。示例：用于测试阶段的工具。
软件开发计划包括协调系统层面（参见GB/T34590.4一2017）和硬件层面（参见GB/T34590.52017)的产品开发
注2：附录A中表A.1提供了对软件层面产品开发特定子阶段的目的、前提条件和工作成果的概览5.3本章的输入
5.3.1前提条件
应具备下列信息：
项目计划（细化的），按照GB/T34590.4—2017的5.5.1：安全计划（细化的），按照GB/T34590.4—2017的5.5.2；技术安全概念，按照GB/T34590.42017的7.5.1；系统设计规范，按照GB/T34590.4—2017的7.5.2；及相关项集成和测试计划（细化的），按照GB/T34590.4一2017的8.5.1。5.3.2支持信息
可考虑下列信息：
经鉴定合格的软件工具（参见GB/T34590.8一2017第11章）；—可用的经鉴定合格的软件组件（参见GB/T34590.8一2017第12章）；用于建模语言和编程语言的设计和编码指南（来自外部）；一方法应用的指南（来自外部）；及工具应用的指南（来自外部）。5.4要求和建议
应对软件层面产品开发的活动和适当方法的确定进行计划。5.4.1
5.4.2应按照GB/T34590.2一2017的6.4.5，并基于图2给出的参考阶段模型，为软件层面产品开发进行生命周期的剪裁。
5.4.3如果开发可配置软件，应按照附录C。5.4.4包括生命周期阶段、方法，语言和工具在内的相关项软件开发流程，应在软件生命周期的所有子阶段保持一致，并与系统和硬件开发阶段兼容，由此，所需的数据可被正确的转化注：相关项软件的各阶段、任务和活动（包括选代步骤）的顺序，用于确保软件相关工作成果与硬件层面产品开发（参见GB/T34590.5一2017）及系统层面产品开发（参见GB/T34590.4一2017）保持一致。3
GB/T34590.6—2017
4-7系统设计
设计阶段的
6-6软件安全要求的
设计过程
第六部乡
设计阶段的
6-7软件架构
设计阶段的
相关项测试
测试阶段的验证
软件测试
测试阶段的验证
软件测试
测试阶段的验证
6-8软件单元设计和
软件测试
测试阶段
的验证
4-8相关项集成和
6-11软件安全要求验
6-10软件集成
和测试
6-9软件单元
注：图中GB/T34590一2017每部分的特定章用以下方式标示：“m-n\，“m\代表部分号，“n\代表章号，例如\4-7\代表GB/T34590.4—2017第7章。
图2软件开发参考阶段模型
5.4.5应为软件开发的每个子阶段进行如下选择，包括其应用的指南：a）方法；及
b）相应的工具。
5.4.6当选择一种合适的建模语言或编程语言时，应考虑准则：a）无歧义的定义；
示例：语言的语法和语义
为嵌入式实时软件和运行时错误处理提供的支持；及b)
为模块化、抽象化和结构化的构建提供的支持。对于通过语言本身不能充分说明的准则应由相应的指南或开发环境来覆盖。注1：所选择的编程语言（如ADA，CC十十，Java，汇编或图形化的建模语言）支持5.4.7中给出的通则。可应用编程指南或建模指南以满足这些通则。注2：汇编语言可用于那些不适合使用高级语言的软件部分，如与硬件接口的底层软件、中断处理程序、或对时间敏感的算法。
5.4.7为了支持设计和实现的正确性，建模语言或编程语言的设计和编码指南应按照表1所列出的通则。
注1：对不同的编程语言，编码指南通常是不同的。注2：对基于模型的开发，编码指南可以是不同的。附录B描述了基于模型的开发的概念。注3：对特定相关项的开发，可对现有编码指南进行修改。示例：MISRACE3I和MISRAACAGCE4I是C语言的编码指南。4
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国国家标准
GB/T34590.6—2017
道路车辆
功能安全
第6部分：产品开发：软件层面
Road vehicles-Functional safety-Part 6:Product development at the software level(ISO26262-6:2011.MOD)
2017-10-14发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
2018-05-01实施
规范性引用文件
术语、定义和缩略语
一般要求
表的诠释
基于ASIL等级的要求和建议
5启动软件层面产品开发
5.3本章的输人
要求和建议
工作成果
6软件安全要求的定义
本章的输人
要求和建议
工作成果
7软件架构设计
本章的输人
要求和建议
工作成果
8软件单元设计和实现
目的·
总则·
8.3本章的输人
要求和建议
工作成果·
软件单元测试·
............
GB/T34590.6—2017
GB/T34590.6—2017
本章的输人
要求和建议
工作成果
软件集成和测试
本章的输人
要求和建议
工作成果
软件安全要求验证
本章的输人
要求和建议
工作成果
附录A（资料性附录）
产品开发软件层面管理的概览和工作流程·附录B（资料性附录）
基于模型的开发
附录C（规范性附录）
软件配置
附录D（资料性附录）避免软件要素间的相互干扰参考文献
GB/T34590《道路车辆功能安全》分为以下部分：第1部分：术语；
第2部分：功能安全管理；
第3部分：概念阶段；
一第4部分：产品开发：系统层面；第5部分：产品开发：硬件层面；第6部分：产品开发：软件层面：一第7部分：生产和运行；
第8部分：支持过程；
第9部分：以汽车安全完整性等级为导向和以安全为导向的分析；第10部分：指南。
本部分为GB/T34590的第6部分。本部分按照GB/T1.1—2009给出的规则起草。GB/T34590.6—2017
本部分使用重新起草法修改采用1IS026262-6：2011《道路车辆功能安全第6部分：产品开发：软件层面》。
本部分与ISO26262-6：2011的技术性差异及其原因如下：修改了本部分的适用范围，由原文的“适用于安装在最大总质量不超过3.5t的量产乘用车上的包含一个或多个电子电气系统的与安全相关系统”改为“适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统”；一关于规范性引用文件，本部分做了具有技术性差异的调整，以适应我国的技术条件，调整的情况集中反映在第2章“规范性引用文件”中，具体调整如下：●用修改采用国际标准的GB/T34590.1—2017代替ISO26262-1:2011；?用修改采用国际标准的GB/T34590.2—2017代替ISO26262-2：2011：·用修改采用国际标准的GB/T34590.4—2017代替ISO26262-4：2011；?用修改采用国际标准的GB/T34590.5一2017代替ISO26262-6：2011引用的ISO262625:2011
·用修改采用国际标准的GB/T34590.8—2017代替ISO26262-8：2011；●用修改采用国际标准的GB/T34590.9—2017代替ISO26262-9：2011本部分还做了下列编辑性修改：修改了国际标准的言及其表述和图1的内容本部分由全国汽车标准化技术委员会（SAC/TC114）提出并归口。本部分负责起草单位：中国汽车技术研究中心、上海海拉电子有限公司、舍弗勒投资（中国）有限公司，泛亚汽车技术中心有限公司、博世汽车部件（苏州）有限公司、中国第一汽车股份有限公司、北京兴科迪科技有限公司、联合汽车电子有限公司、东软集团股份有限公司、北京经纬恒润科技有限公司、上汽大众汽车有限公司，上海汽车集团股份有限公司商用车技术中心本部分参加起草单位：重庆长安汽车股份有限公司，浙江尤奈特电机有限公司、上汽通用五菱汽车股份有限责任公司、本田技研工业（中国）投资有限公司，碧智三维公司、东风汽车有限公司东风日产乘用车公司、爱德克斯（常州）管理有限公司、AW（杭州）信息技术有限公司、京滨电子装置研究开发（上GB/T34590.6—2017
海）有限公司
本部分主要起草人：李波、蒋军、薛剑波、杨虎、尚世亮、童菲、曲元宁、张立君、蒋云、史晓密、刘北、常平、陈伟、明月、付越、吴含冰、张乐敏、宋锦明、周宏伟、刘姿汝、褚静娟、匡小军、盛一芝、王轶群、韩子凯、张小帆、徐寅、李钟、储小勤、徐惠忠。IV
GB/T34590.6—2017
ISO26262是以IEC61508为基础，为满足道路车辆上电子电气系统的特定需求而编写。GB/T34590修改采用ISO26262，适用于道路车辆上由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动。安全是未来汽车发展的关键问题之一，不仅在驾驶辅助和动力驱动领域，而且在车辆动态控制和主被动安全系统领域，新的功能越来越多地触及到系统安全工程领域。这些功能的开发和集成将强化对安全相关系统开发流程的需求，并且要求提供满足所有合理的系统安全目标的证明。随着技术日益复杂、软件和机电一体化应用不断增加，来自系统性失效和随机硬件失效的风险逐渐增加。GB/T34590通过提供适当的要求和流程给出了避免风险的指导。系统安全是通过一系列安全措施实现的。安全措施通过各种技术（例如，机械、液压、气压、电子、电气、可编程电子等）实现且应用于开发过程中的不同层面。尽管GB/T34590针对的是电子电气系统的功能安全，但是它也提供了一个框架，在该框架内可考虑基于其他技术的与安全相关系统。GB/T34590：
a）提供了一个汽车安全生命周期（管理、开发、生产、运行、服务、报废），并支持在这些生命周期阶段内对必要活动的剪裁；
提供了一种汽车特定的基于风险的分析方法，以确定汽车安全完整性等级（ASIL）；b）
应用汽车安全完整性等级（ASIL）定义GB/T34590中适用的要求，以避免不合理的残余c）
风险；
提供了对于确认和认可措施的要求，以确保达到一个充分、可接受的安全等级；e）提供了与供应商相关的要求。功能安全受开发过程（例如，包括需求规范、设计、实现、集成、验证、确认和配置）、生产过程、服务过程和管理过程的影响。bZxz.net
安全问题与常规的以功能为导向和以质量为导向的开发活动及工作成果相互关联。GB/T34590涉及与安全相关的开发活动和工作成果。图1为GB/T34590的整体架构。GB/T34590基于V模型为产品开发的不同阶段提供参考过程模型：
阴影“V”表示GB/T34590.3—2017、GB/T34590.4—2017、GB/T34590.5—2017、GB/T34590.6—2017、GB/T34590.7—2017之间的相互关系；以“m-n”方式表示的具体章条中，“m\代表特定部分的编号，“n\代表该部分章的编号。示例：“2-6代表GB/T34590.2—2017第6章。GB/T34590.6—2017
2-5整体安全管理
3.概念阶段
3-5相关项定义
3-6安全生命周期启动
3-7危害分析和风险评估
3-8功能安全概念
8-5分布式开发的接口
8-6安全要求的定义和管理
8-7配置管理
8-8变更管理
8-9验证
2.功能安全管理
2-6概念阶段和产品开发过程中的安全管理4.产品开发：系统层面
4-5启动系统层面产品开发
4-6技术安全要求的定义
4-7系统设计
5.产品开发：硬件层面
5-5启动硬件层面产品开发
5-6硬件安全要求的定义
5-7硬件设计
5-8硬件架构度量的评估
5-9随机硬件失效导致违背
安全目标的评估
5-10硬件集成和测试
8.支持过程
4-11生产发布
2-7相关项生产发布后的安全管理7.生产和运行
7-5生产
4-10功能安全评估
4-9安全确认
4-8相关项集成和测试
6.产品开发：软件层面
6-5启动软件层面产品开发
6-6软件安全要求的定义
6-7软件架构设计
6-8软件单元设计和实现
6-9软件单元测试
6-10软件集成和测试
6-11软件安全要求验证
8-10文档
8-11使用软件工具的置信度
8-12软件组件的鉴定
8-13硬件组件的鉴定
8-14在用证明
9.以汽车安全完整性等级为导向和以安全为导向的分析9-5关于ASIL剪裁的要求分解
9-6要素共存的准则
9-7相关失效分析
9-8安全分析
10.指南
GB/T34590—2017概览
7-6运行、服务
（维护与维修）
和报度
1范围
道路车辆功能安全
第6部分：产品开发：软件层面
GB/T34590的本部分规定了车辆在软件层面产品开发的要求，包括：启动软件层面产品开发：
软件安全要求的定义；
软件架构设计；
软件单元设计及实现；
软件单元测试；
软件集成和测试；及
软件安全要求的验证。
GB/T34590.6—2017
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。本标准不适用于特殊用途车辆上特定的电子电气系统，例如，为残疾驾驶者设计的车辆。本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时，仅修改的部分需要按照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害，包括这些系统相互作用而引起的可能的危害。本标准不针对与触电、火灾，烟雾、热，辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由电子电气安全相关系统的故障行为而引起的。本标准不针对电子电气系统的标称性能，即使这些系统（例如，主动和被动安全系统、制动系统、自适应航系统）有专用的功能性能标准。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T34590.1—2017道路车辆功能安全第1部分：术语（ISO26262-1:2011，MOD）GB/T34590.2—2017道路车辆功能安全第2部分：功能安全管理（ISO26262-2：2011，MOD）GB/T34590.4—2017道路车辆功能安全第4部分：产品开发：系统层面（ISO26262-4：2011，MOD)
GB/T34590.5—2017
道路车辆功能安全第5部分：产品开发：硬件层面（ISO26262-5：2011，MOD)
GB/T34590.8一2017道路车辆功能安全第8部分：支持过程（ISO26262-8：2011，MOD）GB/T34590.9一2017道路车辆功能安全第9部分：以汽车安全完整性等级为导向和以安全为导向的分析（ISO26262-9：2011，MOD）3术语、定义和缩略语
GB/T34590.1一2017界定的术语、定义和缩略语适用于本文件。1
GB/T34590.6—2017
4要求
4.1一般要求
如声明满足GB/T34590一2017的要求时，应满足每一个要求，除非有下列情况之一：a）按照GB/T34590.2一2017的要求，已经计划了安全活动的剪裁并表明这些要求不适用；或b）不满足要求的理由存在且是可接受的，并且按照GB/T34590.2一2017对该理由进行了评估。标有“注”或“示例”的信息仅用于辅助理解或阐明相关要求，不应作为要求本身且不具备完备性。将安全活动的结果作为工作成果。应具备上一阶段工作成果作为“前提条件”的信息。如果章条的某些要求是依照ASIL定义的或可剪裁的，某些工作成果可不作为前提条件。“支持信息”是可供参考的信息，但在某些情况下，GB/T34590一2017不要求其作为上一阶段的工作成果，并且可以是由不同于负责功能安全活动的人员或组织等外部资源提供的信息。4.2表的诠释
表属于规范性表还是资料性表取决于上下文。在实现满足相关要求时，表中列出的不同方法有助于置信度水平。表中的每个方法是：a）一个连续的条目（在最左侧列以顺序号标明，如1、2、3)；或b）一个选择的条目（在最左侧列以数字后加字母标明，如2a、2b、2c）。对于连续的条目，全部方法应按照ASIL等级推荐予以使用。除了所列出的方法外，如果应用所列出方法以外的其他方法，应给出满足相关要求的理由。对于选择性的条目，应按照指定的ASIL等级，对这些方法进行适当的组合，不依赖于这些方法是否在表中列出。如果所列出的方法对于一个ASIL等级来说具有不同的推荐等级，宜采用具有较高推荐等级的方法。应给出所选的方法组合满足相关要求的理由。注：表中所列出的方法的理由是充分的。但是，这并不意味着有倾向性或对未列到表中的方法表示反对。对于每种方法，应用相关方法的推荐等级取决于ASIL等级，分类如下：_“十十”表示对于指定的ASIL等级，高度推荐该方法；一“十”表示对于指定的ASIL.等级，推荐该方法；一“o”表示对于指定的ASIL等级，不推荐也不反对该方法4.3基于ASIL等级的要求和建议
若无其他说明，对于ASILA、B、C和D等级，应满足每一子章条的要求或建议。这些要求和建议参照安全目标的ASIL等级。如果在项目开发的早期对ASIL等级完成了分解，按照GB/T34590.9一2017第5章，应遵循分解后的ASIL等级如果GB/T34590一2017中ASIL等级在括号中给出，则对于该ASIL等级，相应的子章条应被认为是推荐而非要求。这里的括号与ASIL等级分解无关。5启动软件层面产品开发
5.1目的
本子章条的目的是计划并启动软件开发子阶段的功能安全活动2
5.2总则
GB/T34590.6—2017
软件开发的启动是一项计划活动，即按照相关项开发的范围和复杂度确定并计划软件开发中各子阶段及其支持过程（参见GB/T34590.8—2017和GB/T34590.9—2017）。通过确定适当的方法，启动软件开发各子阶段和支持过程，以满足要求及其相应的ASIL等级。这些方法得到指南和工具的支持这些指南和工具是为每个子阶段和支持过程而确定和计划的。注1：用于软件开发的工具可包括其他非软件工具。示例：用于测试阶段的工具。
软件开发计划包括协调系统层面（参见GB/T34590.4一2017）和硬件层面（参见GB/T34590.52017)的产品开发
注2：附录A中表A.1提供了对软件层面产品开发特定子阶段的目的、前提条件和工作成果的概览5.3本章的输入
5.3.1前提条件
应具备下列信息：
项目计划（细化的），按照GB/T34590.4—2017的5.5.1：安全计划（细化的），按照GB/T34590.4—2017的5.5.2；技术安全概念，按照GB/T34590.42017的7.5.1；系统设计规范，按照GB/T34590.4—2017的7.5.2；及相关项集成和测试计划（细化的），按照GB/T34590.4一2017的8.5.1。5.3.2支持信息
可考虑下列信息：
经鉴定合格的软件工具（参见GB/T34590.8一2017第11章）；—可用的经鉴定合格的软件组件（参见GB/T34590.8一2017第12章）；用于建模语言和编程语言的设计和编码指南（来自外部）；一方法应用的指南（来自外部）；及工具应用的指南（来自外部）。5.4要求和建议
应对软件层面产品开发的活动和适当方法的确定进行计划。5.4.1
5.4.2应按照GB/T34590.2一2017的6.4.5，并基于图2给出的参考阶段模型，为软件层面产品开发进行生命周期的剪裁。
5.4.3如果开发可配置软件，应按照附录C。5.4.4包括生命周期阶段、方法，语言和工具在内的相关项软件开发流程，应在软件生命周期的所有子阶段保持一致，并与系统和硬件开发阶段兼容，由此，所需的数据可被正确的转化注：相关项软件的各阶段、任务和活动（包括选代步骤）的顺序，用于确保软件相关工作成果与硬件层面产品开发（参见GB/T34590.5一2017）及系统层面产品开发（参见GB/T34590.4一2017）保持一致。3
GB/T34590.6—2017
4-7系统设计
设计阶段的
6-6软件安全要求的
设计过程
第六部乡
设计阶段的
6-7软件架构
设计阶段的
相关项测试
测试阶段的验证
软件测试
测试阶段的验证
软件测试
测试阶段的验证
6-8软件单元设计和
软件测试
测试阶段
的验证
4-8相关项集成和
6-11软件安全要求验
6-10软件集成
和测试
6-9软件单元
注：图中GB/T34590一2017每部分的特定章用以下方式标示：“m-n\，“m\代表部分号，“n\代表章号，例如\4-7\代表GB/T34590.4—2017第7章。
图2软件开发参考阶段模型
5.4.5应为软件开发的每个子阶段进行如下选择，包括其应用的指南：a）方法；及
b）相应的工具。
5.4.6当选择一种合适的建模语言或编程语言时，应考虑准则：a）无歧义的定义；
示例：语言的语法和语义
为嵌入式实时软件和运行时错误处理提供的支持；及b)
为模块化、抽象化和结构化的构建提供的支持。对于通过语言本身不能充分说明的准则应由相应的指南或开发环境来覆盖。注1：所选择的编程语言（如ADA，CC十十，Java，汇编或图形化的建模语言）支持5.4.7中给出的通则。可应用编程指南或建模指南以满足这些通则。注2：汇编语言可用于那些不适合使用高级语言的软件部分，如与硬件接口的底层软件、中断处理程序、或对时间敏感的算法。
5.4.7为了支持设计和实现的正确性，建模语言或编程语言的设计和编码指南应按照表1所列出的通则。
注1：对不同的编程语言，编码指南通常是不同的。注2：对基于模型的开发，编码指南可以是不同的。附录B描述了基于模型的开发的概念。注3：对特定相关项的开发，可对现有编码指南进行修改。示例：MISRACE3I和MISRAACAGCE4I是C语言的编码指南。4
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。