GB∕T 34590.5-2017
基本信息
标准号： GB∕T 34590.5-2017
中文名称：道路车辆 功能安全 第5部分：产品开发：硬件层面
标准类别：国家标准(GB)
标准状态：现行
出版语种：简体中文
下载格式：.rar .pdf
下载大小：6287KB
标准分类号
关联标准
出版信息
相关单位信息
标准简介
GB∕T 34590.5-2017 道路车辆 功能安全 第5部分：产品开发：硬件层面
GB∕T34590.5-2017
标准压缩包解压密码：www.bzxz.net
标准图片预览
标准内容
ICS43.040
中华人民共和国国家标准
GB/T34590.5—2017
道路车辆
功能安全
第5部分：产品开发：硬件层面
Road vehicles-Functional safety-Part 5:Product development at the hardware leve(ISO26262-5:2011.MOD)
2017-10-14发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
2018-05-01实施
规范性引用文件
术语、定义和缩略语
一般要求
表的诠释
基于ASIL等级的要求和建议
5启动硬件层面产品开发
5.3本章的输人
要求和建议
工作成果
6硬件安全要求的定义
本章的输人
要求和建议
工作成果
硬件设计
本章的输人
要求和建议
工作成果
8硬件架构度量的评估
目的·
总则·
8.3本章的输人…
要求和建议
8.5工作成果
随机硬件失效导致违背安全目标的评估9
............
GB/T34590.5—2017
GB/T34590.5—2017
本章的输人
要求和建议
工作成果
硬件集成和测试
本章的输人
要求和建议
工作成果
附录A（资料性附录）
附录B（资料性附录）
附录C（规范性附录）
附录D（资料性附录）
附录E（资料性附录）
硬件层面产品开发的概览和工作流硬件要素的失效模式分类
硬件架构度量
诊断覆盖率的评估
硬件架构度量计算示例：“单点故障度量”和“潜伏故障度量”附录F（资料性附录）比例因子的应用参考文献
GB/T34590《道路车辆功能安全》分为以下部分：第1部分：术语；
第2部分：功能安全管理；
第3部分：概念阶段；
一第4部分：产品开发：系统层面；第5部分：产品开发：硬件层面；第6部分：产品开发：软件层面：一第7部分：生产和运行；
第8部分：支持过程；
第9部分：以汽车安全完整性等级为导向和以安全为导向的分析；第10部分：指南。
本部分为GB/T34590的第5部分
本部分按照GB/T1.1—2009给出的规则起草。GB/T34590.5—2017
本部分使用重新起草法修改采用1IS026262-5：2011《道路车辆功能安全第5部分：产品开发：硬件层面》。
本部分与ISO26262-5：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.6—2017代替ISO26262-6：2011；?用修改采用国际标准的GB/T34590.7一2017代替1SO26262-7：2011；·用修改采用国际标准的GB/T34590.8—2017代替ISO26262-8：2011；●用修改采用国际标准的GB/T34590.9—2017代替ISO26262-9：2011。本部分还做了下列编辑性修改：修改了国际标准的引言及其表述和图1的内容本部分由全国汽车标准化技术委员会（SAC/TC114)提出并归口。本部分负责起草单位：中国汽车技术研究中心、博世汽车部件（苏州）有限公司、上海海拉电子有限公司、泛亚汽车技术中心有限公司、北京兴科迪科技有限公司、舍弗勒投资（中国)有限公司、联合汽车电子有限公司，中国第一汽车股份有限公司大陆汽车投资（上海）有限公司、标致雪铁龙（中国）汽车贸易有限公司、郑州宇通客车股份有限公司、湖南中车时代电动汽车股份有限公司本部分参加起草单位：华晨汽车集团控股有限公司、东软集团股份有限公司，北京经纬恒润科技有限公司、英飞凌集成电路（北京)有限公司、爱信（南通)汽车技术中心有限公司、京滨电子装置研究开发（上海）有限公司、法雷奥汽车内部控制（深圳)有限公司、AW（杭州）信息技术有限公司。GB/T34590.5—2017
本部分主要起草人：李波、曲元宁、杨虎、蒋军、史晓密、尚世亮、薛剑波、还宏生、童菲、易威、蒋云、明月、张立君、付越、吴含冰、卢长军、易茂明、徐振环、刘北、陈伟、王龙飞、谢攀、余嘉、杨和全、廖永久、陈涛。
GB/T34590.5—2017
ISO26262是以IEC61508为基础，为满足道路车辆上电子电气系统的特定需求而编写。GB/T34590修改采用ISO26262，适用于道路车辆上由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动。安全是未来汽车发展的关键问题之一，不仅在驾驶辅助和动力驱动领域，而且在车辆动态控制和主被动安全系统领域，新的功能越来越多地触及到系统安全工程领域。这些功能的开发和集成将强化对安全相关系统开发流程的需求，并且要求提供满足所有合理的系统安全目标的证明。随着技术日益复杂、软件和机电一体化应用不断增加，来自系统性失效和随机硬件失效的风险逐渐增加。GB/T34590通过提供适当的要求和流程给出了避免风险的指导。系统安全是通过一系列安全措施实现的。安全措施通过各种技术（例如，机械、液压、气压、电子、电气、可编程电子等）实现且应用于开发过程中的不同层面。尽管GB/T34590针对的是电子电气系统的功能安全，但是它也提供了一个框架，在该框架内可考虑基于其他技术的与安全相关系统。GB/T34590：
a）提供了一个汽车安全生命周期（管理、开发、生产、运行、服务、报废），并支持在这些生命周期阶段内对必要活动的剪裁；
提供了一种汽车特定的基于风险的分析方法，以确定汽车安全完整性等级（ASIL）；b）
应用汽车安全完整性等级（ASIL）定义GB/T34590中适用的要求，以避免不合理的残余c)
风险；
d）提供了对于确认和认可措施的要求，以确保达到一个充分、可接受的安全等级；e）提供了与供应商相关的要求。功能安全受开发过程（例如，包括需求规范、设计、实现、集成、验证、确认和配置）、生产过程、服务过程和管理过程的影响。
安全问题与常规的以功能为导向和以质量为导向的开发活动及工作成果相互关联。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.5—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启动系统层面产品开发
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.指南wwW.bzxz.Net
GB/T34590—2017概览
7-6运行、服务
（维护与维修）
和报废
1范围
道路车辆功能安全
第5部分：产品开发：硬件层面
GB/T34590的本部分规定了车辆在硬件层面产品开发的要求，包括：启动硬件层面产品开发的要求：硬件安全要求的定义；
硬件设计；
一硬件架构度量；及
一因随机硬件失效导致违背安全目标的评估，硬件集成及测试。GB/T34590.5—2017
本部分对于硬件要素的要求适用于非可编程要素和可编程要素，如ASIC、FPGA和PLD。并且，GB/T34590.6—2017、GB/T34590.8—2017的第11章和12章中的要求对于可编程电子要素是适用的。本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统，本标准不适用于特殊用途车辆上特定的电子电气系统，例如，为残疾驾驶者设计的车辆。本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时，仅修改的部分需要按照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害，包括这些系统相互作用而引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由电子电气安全相关系统的故障行为而引起的。本标准不针对电子电气系统的标称性能，即使这些系统（例如，主动和被动安全系统、制动系统、自适应巡航系统)有专用的功能性能标准。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T34590.1—2017道路车辆功能安全第1部分：术语（ISO26262-1:2011.MOD）GB/T34590.2—2017道路车辆功能安全第2部分：功能安全管理（ISO26262-2:2011,MOD）GB/T34590.4—2017
GB/T34590.6—2017
GB/T34590.7—2017
道路车辆
道路车辆
道路车辆
功能安全第4部分：产品开发：系统层面（ISO26262-4：2011，功能安全第6部分：产品开发：软件层面（ISO26262-6：2011，功能安全第7部分：生产和运行（ISO26262-7：2011，MOD）GB/T34590.8—2017
功能安全第8部分：支持过程（ISO26262-8：2011MOD）道路车辆
道路车辆功能安全第9部分：以汽车安全完整性等级为导向和以安全GB/T34590.9—2017
为导向的分析（ISO26262-9：2011.MOD）3术语、定义和缩略语
GB/T34590.1一2017界定的术语、定义和缩略语适用于本文件。1
GB/T34590.5—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等级，推荐该方法；一“”表示对于指定的ASIL等级，不推荐也不反对该方法。4.3基于ASIL等级的要求和建议
若无其他说明，对于ASILA、B,C和D等级，应满足每一子章条的要求或建议。这些要求和建议参照安全目标的ASIL等级。如果在项目开发的早期对ASIL等级完成了分解，应按照GB/T34590.9-2017第5章，遵循分解后的ASIL等级如果GB/T34590中ASIL等级在括号中给出，则对于该ASIL等级，相应的子章条应被认为是推荐而非要求。这里的括号与ASIL等级分解无关。5启动硬件层面产品开发
5.1目的
启动硬件层面产品开发的目的是确定并计划硬件开发各子阶段过程中的功能安全活动，也包括在GB/T34590.8—2017中所描述的必要的支持过程。硬件特定的安全活动的计划包含在安全计划中（参见GB/T34590.2一2017的6.4.3和GB/T34590.42
2017的5.4)。
5.2总则
GB/T34590.5—2017
制定满足安全要求的硬件开发所需的活动和流程的计划。图2阐明了为满足本部分要求的硬件层面产品开发的流程步骤，以及在GB/T34590框架内这些步骤的集成。硬件层面产品开发的必要活动和流程包括：技术安全概念的硬件实现；
分析潜在硬件故障及其影响；及与软件开发的协调。
GB/T34590.5—2017产品开发：硬件层面4.7
系统设计
GB/T34590
2017范围
启动硬件层面产品开发
硬件安全要求的定义
硬件设计
运行、服务（维护与维
修)和报废
硬件架构度量的评估
随机硬件失效导致违背安
全目标的评估
硬件组件的鉴定
硬件集成与测试
」相关项的集成与测试
注：在图中，GB/T34590的各部分具体条款用以下列方式来表明：“m-n\其中“m\代表“部分\的编号和\n\表示“章”的编号，例如，\4-5”表示GB/T34590的第4部分的第5章。图2硬件层面产品开发参考阶段模型与软件开发子阶段相比，本部分包含两个章节来描述相关项整体硬件架构的定量评估。第8章描述了两个度量，以评估相关项硬件架构和实施的安全机制应对随机硬件失效的有效性。作为对第8章的补充，第9章描述了两个可选的方法以评估违背安全目标的残余风险是否足够低，或者应用一种全局概率方法，或者应用一种割集分析方法，来研究硬件要素中所识别出的每个故障对违背安全目标的影响。
注：附录A中表A.1提供了对硬件层面产品开发特定子阶段的目的、前提条件和工作成果的概览。3
GB/T34590.5—2017
5.3本章的输入
5.3.1前提条件
应具备下列信息：
项目计划（细化的），按照GB/T34590.4—2017的5.5.1；—安全计划（细化的），按照GB/T34590.4一2017的5.5.2及相关项集成和测试计划（细化的），按照GB/T34590.4一2017的5.5.3。5.3.2支持信息
可考虑下列信息：
鉴定报告（硬件组件或元器件），如果适用（见GB/T34590.8一2017的13.5.3）。5.4要求和建议
5.4.1应细化按照GB/T34590.2一2017所制定的安全计划，包括确定硬件层面产品开发活动的适当方法和措施，并与GB/T34590.6一2017中活动的计划保持一致。5.4.2相关项硬件的开发流程，包括方法和工具，应在硬件开发的所有子阶段内保持一致，并与系统和软件子阶段保持一致，以便在硬件开发过程中保持要求流的精确性和一致性。5.4.3硬件层面产品开发的安全生命周期活动的剪裁应按照GB/T34590.2一2017的6.4.5实施，并基于图2给出的参考阶段模型。
5.4.4应识别出对硬件组件的复用，或对经过鉴定的硬件组件或元器件的使用，并且应描述由此产生的对安全活动的剪裁
5.5工作成果
安全计划（细化的），由5.4.1～5.4.4的要求得出。6硬件安全要求的定义
6.1目的
本章的第一个目的是定义硬件安全要求，这些要求由技术安全概念和系统设计规范导出。第二个目的是验证硬件安全要求与技术安全概念及系统设计规范的一致性。本阶段另一目的是细化最初在GB/T34590.4一2017第7章定义的软硬件接口（HSI)规范。6.2总则
将技术安全要求分配给硬件和软件。既分配给硬件又分配给软件的要求被进一步划分出仅对硬件的安全要求。考虑设计限制和这些限制对硬件的影响，对硬件安全要求进行进一步的细化6.3本章的输入
6.3.1前提条件
应具备如下信息：
安全计划（细化的），按照5.5的要求；技术安全概念，按照GB/T34590.4—2017的7.5.1；系统设计规范，按照GB/T34590.4—2017的7.5.2；及4
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国国家标准
GB/T34590.5—2017
道路车辆
功能安全
第5部分：产品开发：硬件层面
Road vehicles-Functional safety-Part 5:Product development at the hardware leve(ISO26262-5:2011.MOD)
2017-10-14发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
2018-05-01实施
规范性引用文件
术语、定义和缩略语
一般要求
表的诠释
基于ASIL等级的要求和建议
5启动硬件层面产品开发
5.3本章的输人
要求和建议
工作成果
6硬件安全要求的定义
本章的输人
要求和建议
工作成果
硬件设计
本章的输人
要求和建议
工作成果
8硬件架构度量的评估
目的·
总则·
8.3本章的输人…
要求和建议
8.5工作成果
随机硬件失效导致违背安全目标的评估9
............
GB/T34590.5—2017
GB/T34590.5—2017
本章的输人
要求和建议
工作成果
硬件集成和测试
本章的输人
要求和建议
工作成果
附录A（资料性附录）
附录B（资料性附录）
附录C（规范性附录）
附录D（资料性附录）
附录E（资料性附录）
硬件层面产品开发的概览和工作流硬件要素的失效模式分类
硬件架构度量
诊断覆盖率的评估
硬件架构度量计算示例：“单点故障度量”和“潜伏故障度量”附录F（资料性附录）比例因子的应用参考文献
GB/T34590《道路车辆功能安全》分为以下部分：第1部分：术语；
第2部分：功能安全管理；
第3部分：概念阶段；
一第4部分：产品开发：系统层面；第5部分：产品开发：硬件层面；第6部分：产品开发：软件层面：一第7部分：生产和运行；
第8部分：支持过程；
第9部分：以汽车安全完整性等级为导向和以安全为导向的分析；第10部分：指南。
本部分为GB/T34590的第5部分
本部分按照GB/T1.1—2009给出的规则起草。GB/T34590.5—2017
本部分使用重新起草法修改采用1IS026262-5：2011《道路车辆功能安全第5部分：产品开发：硬件层面》。
本部分与ISO26262-5：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.6—2017代替ISO26262-6：2011；?用修改采用国际标准的GB/T34590.7一2017代替1SO26262-7：2011；·用修改采用国际标准的GB/T34590.8—2017代替ISO26262-8：2011；●用修改采用国际标准的GB/T34590.9—2017代替ISO26262-9：2011。本部分还做了下列编辑性修改：修改了国际标准的引言及其表述和图1的内容本部分由全国汽车标准化技术委员会（SAC/TC114)提出并归口。本部分负责起草单位：中国汽车技术研究中心、博世汽车部件（苏州）有限公司、上海海拉电子有限公司、泛亚汽车技术中心有限公司、北京兴科迪科技有限公司、舍弗勒投资（中国)有限公司、联合汽车电子有限公司，中国第一汽车股份有限公司大陆汽车投资（上海）有限公司、标致雪铁龙（中国）汽车贸易有限公司、郑州宇通客车股份有限公司、湖南中车时代电动汽车股份有限公司本部分参加起草单位：华晨汽车集团控股有限公司、东软集团股份有限公司，北京经纬恒润科技有限公司、英飞凌集成电路（北京)有限公司、爱信（南通)汽车技术中心有限公司、京滨电子装置研究开发（上海）有限公司、法雷奥汽车内部控制（深圳)有限公司、AW（杭州）信息技术有限公司。GB/T34590.5—2017
本部分主要起草人：李波、曲元宁、杨虎、蒋军、史晓密、尚世亮、薛剑波、还宏生、童菲、易威、蒋云、明月、张立君、付越、吴含冰、卢长军、易茂明、徐振环、刘北、陈伟、王龙飞、谢攀、余嘉、杨和全、廖永久、陈涛。
GB/T34590.5—2017
ISO26262是以IEC61508为基础，为满足道路车辆上电子电气系统的特定需求而编写。GB/T34590修改采用ISO26262，适用于道路车辆上由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动。安全是未来汽车发展的关键问题之一，不仅在驾驶辅助和动力驱动领域，而且在车辆动态控制和主被动安全系统领域，新的功能越来越多地触及到系统安全工程领域。这些功能的开发和集成将强化对安全相关系统开发流程的需求，并且要求提供满足所有合理的系统安全目标的证明。随着技术日益复杂、软件和机电一体化应用不断增加，来自系统性失效和随机硬件失效的风险逐渐增加。GB/T34590通过提供适当的要求和流程给出了避免风险的指导。系统安全是通过一系列安全措施实现的。安全措施通过各种技术（例如，机械、液压、气压、电子、电气、可编程电子等）实现且应用于开发过程中的不同层面。尽管GB/T34590针对的是电子电气系统的功能安全，但是它也提供了一个框架，在该框架内可考虑基于其他技术的与安全相关系统。GB/T34590：
a）提供了一个汽车安全生命周期（管理、开发、生产、运行、服务、报废），并支持在这些生命周期阶段内对必要活动的剪裁；
提供了一种汽车特定的基于风险的分析方法，以确定汽车安全完整性等级（ASIL）；b）
应用汽车安全完整性等级（ASIL）定义GB/T34590中适用的要求，以避免不合理的残余c)
风险；
d）提供了对于确认和认可措施的要求，以确保达到一个充分、可接受的安全等级；e）提供了与供应商相关的要求。功能安全受开发过程（例如，包括需求规范、设计、实现、集成、验证、确认和配置）、生产过程、服务过程和管理过程的影响。
安全问题与常规的以功能为导向和以质量为导向的开发活动及工作成果相互关联。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.5—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启动系统层面产品开发
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.指南wwW.bzxz.Net
GB/T34590—2017概览
7-6运行、服务
（维护与维修）
和报废
1范围
道路车辆功能安全
第5部分：产品开发：硬件层面
GB/T34590的本部分规定了车辆在硬件层面产品开发的要求，包括：启动硬件层面产品开发的要求：硬件安全要求的定义；
硬件设计；
一硬件架构度量；及
一因随机硬件失效导致违背安全目标的评估，硬件集成及测试。GB/T34590.5—2017
本部分对于硬件要素的要求适用于非可编程要素和可编程要素，如ASIC、FPGA和PLD。并且，GB/T34590.6—2017、GB/T34590.8—2017的第11章和12章中的要求对于可编程电子要素是适用的。本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统，本标准不适用于特殊用途车辆上特定的电子电气系统，例如，为残疾驾驶者设计的车辆。本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时，仅修改的部分需要按照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害，包括这些系统相互作用而引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害，除非危害是直接由电子电气安全相关系统的故障行为而引起的。本标准不针对电子电气系统的标称性能，即使这些系统（例如，主动和被动安全系统、制动系统、自适应巡航系统)有专用的功能性能标准。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T34590.1—2017道路车辆功能安全第1部分：术语（ISO26262-1:2011.MOD）GB/T34590.2—2017道路车辆功能安全第2部分：功能安全管理（ISO26262-2:2011,MOD）GB/T34590.4—2017
GB/T34590.6—2017
GB/T34590.7—2017
道路车辆
道路车辆
道路车辆
功能安全第4部分：产品开发：系统层面（ISO26262-4：2011，功能安全第6部分：产品开发：软件层面（ISO26262-6：2011，功能安全第7部分：生产和运行（ISO26262-7：2011，MOD）GB/T34590.8—2017
功能安全第8部分：支持过程（ISO26262-8：2011MOD）道路车辆
道路车辆功能安全第9部分：以汽车安全完整性等级为导向和以安全GB/T34590.9—2017
为导向的分析（ISO26262-9：2011.MOD）3术语、定义和缩略语
GB/T34590.1一2017界定的术语、定义和缩略语适用于本文件。1
GB/T34590.5—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等级，推荐该方法；一“”表示对于指定的ASIL等级，不推荐也不反对该方法。4.3基于ASIL等级的要求和建议
若无其他说明，对于ASILA、B,C和D等级，应满足每一子章条的要求或建议。这些要求和建议参照安全目标的ASIL等级。如果在项目开发的早期对ASIL等级完成了分解，应按照GB/T34590.9-2017第5章，遵循分解后的ASIL等级如果GB/T34590中ASIL等级在括号中给出，则对于该ASIL等级，相应的子章条应被认为是推荐而非要求。这里的括号与ASIL等级分解无关。5启动硬件层面产品开发
5.1目的
启动硬件层面产品开发的目的是确定并计划硬件开发各子阶段过程中的功能安全活动，也包括在GB/T34590.8—2017中所描述的必要的支持过程。硬件特定的安全活动的计划包含在安全计划中（参见GB/T34590.2一2017的6.4.3和GB/T34590.42
2017的5.4)。
5.2总则
GB/T34590.5—2017
制定满足安全要求的硬件开发所需的活动和流程的计划。图2阐明了为满足本部分要求的硬件层面产品开发的流程步骤，以及在GB/T34590框架内这些步骤的集成。硬件层面产品开发的必要活动和流程包括：技术安全概念的硬件实现；
分析潜在硬件故障及其影响；及与软件开发的协调。
GB/T34590.5—2017产品开发：硬件层面4.7
系统设计
GB/T34590
2017范围
启动硬件层面产品开发
硬件安全要求的定义
硬件设计
运行、服务（维护与维
修)和报废
硬件架构度量的评估
随机硬件失效导致违背安
全目标的评估
硬件组件的鉴定
硬件集成与测试
」相关项的集成与测试
注：在图中，GB/T34590的各部分具体条款用以下列方式来表明：“m-n\其中“m\代表“部分\的编号和\n\表示“章”的编号，例如，\4-5”表示GB/T34590的第4部分的第5章。图2硬件层面产品开发参考阶段模型与软件开发子阶段相比，本部分包含两个章节来描述相关项整体硬件架构的定量评估。第8章描述了两个度量，以评估相关项硬件架构和实施的安全机制应对随机硬件失效的有效性。作为对第8章的补充，第9章描述了两个可选的方法以评估违背安全目标的残余风险是否足够低，或者应用一种全局概率方法，或者应用一种割集分析方法，来研究硬件要素中所识别出的每个故障对违背安全目标的影响。
注：附录A中表A.1提供了对硬件层面产品开发特定子阶段的目的、前提条件和工作成果的概览。3
GB/T34590.5—2017
5.3本章的输入
5.3.1前提条件
应具备下列信息：
项目计划（细化的），按照GB/T34590.4—2017的5.5.1；—安全计划（细化的），按照GB/T34590.4一2017的5.5.2及相关项集成和测试计划（细化的），按照GB/T34590.4一2017的5.5.3。5.3.2支持信息
可考虑下列信息：
鉴定报告（硬件组件或元器件），如果适用（见GB/T34590.8一2017的13.5.3）。5.4要求和建议
5.4.1应细化按照GB/T34590.2一2017所制定的安全计划，包括确定硬件层面产品开发活动的适当方法和措施，并与GB/T34590.6一2017中活动的计划保持一致。5.4.2相关项硬件的开发流程，包括方法和工具，应在硬件开发的所有子阶段内保持一致，并与系统和软件子阶段保持一致，以便在硬件开发过程中保持要求流的精确性和一致性。5.4.3硬件层面产品开发的安全生命周期活动的剪裁应按照GB/T34590.2一2017的6.4.5实施，并基于图2给出的参考阶段模型。
5.4.4应识别出对硬件组件的复用，或对经过鉴定的硬件组件或元器件的使用，并且应描述由此产生的对安全活动的剪裁
5.5工作成果
安全计划（细化的），由5.4.1～5.4.4的要求得出。6硬件安全要求的定义
6.1目的
本章的第一个目的是定义硬件安全要求，这些要求由技术安全概念和系统设计规范导出。第二个目的是验证硬件安全要求与技术安全概念及系统设计规范的一致性。本阶段另一目的是细化最初在GB/T34590.4一2017第7章定义的软硬件接口（HSI)规范。6.2总则
将技术安全要求分配给硬件和软件。既分配给硬件又分配给软件的要求被进一步划分出仅对硬件的安全要求。考虑设计限制和这些限制对硬件的影响，对硬件安全要求进行进一步的细化6.3本章的输入
6.3.1前提条件
应具备如下信息：
安全计划（细化的），按照5.5的要求；技术安全概念，按照GB/T34590.4—2017的7.5.1；系统设计规范，按照GB/T34590.4—2017的7.5.2；及4
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。