首页 > 国家标准(GB) > GB∕T 34590.10-2017 道路车辆 功能安全 第10部分:指南
GB∕T 34590.10-2017

基本信息

标准号: GB∕T 34590.10-2017

中文名称:道路车辆 功能安全 第10部分:指南

标准类别:国家标准(GB)

标准状态:现行

出版语种:简体中文

下载格式:.rar .pdf

下载大小:8427KB

相关标签: 道路 车辆 功能 安全 指南

标准分类号

关联标准

出版信息

相关单位信息

标准简介

GB∕T 34590.10-2017 道路车辆 功能安全 第10部分:指南 GB∕T34590.10-2017 标准压缩包解压密码:www.bzxz.net

标准图片预览






标准内容

ICS_43.040
中华人民共和国国家标准
GB/T34590.10—2017
道路车辆
功能安全
第10部分:指南
Road vehicles-Functional safety-Part10:Guideline
(ISO 26262-10:2012,Road vehicles—Functional safety-Part10:GuidelineonISO26262,MOD)2017-10-14发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
2018-05-01实施
2规范性引用文件
3术语、定义和缩略语
4GB/T34590中的关键概念
针对汽车系统的功能安全(与GB/T20438的关系)4.1
4.2相关项、系统、要素、组件、硬件元器件和软件单元4.3故障、错误和失效之间的关系5关于安全管理的精选话题
工作成果
5.2认可措施
5.3安全档案的理解
概念阶段和系统开发
危害分析和风险评估示例
6.3关于可控性分级
6.4外部措施
6.5合并安全目标的示例:
7安全过程的要求结构-安全要求的运行和顺序关于硬件开发
8.1随机硬件故障的分类·
82残余失效率和局部单点故障度量评估的示例·8.3关于硬件的进一步解释
9独立于环境的安全要素
独立于环境的安全要素的开发…9.1
使用案例
在用证明的示例
相关项定义和在用证明候选项的定义变更分析
在用证明的目标价值
关于ASIL的分解
ASIL分解的目的
ASIL分解的描述
GB/T34590.10—2017
GB/T34590.10—2017
ASIL分解的示例
附录A(资料性附录)GB/T34590和微控制器附录B(资料性附录)故障树的架构和应用参考文献
+*.++.++++++*+*.+.++.*+*++*.+.......
F....+........a.....S..S..........
++++++++++++++++++++++++++.
GB/T34590《道路车辆功能安全》分为以下部分:第1部分:术语;
第2部分:功能安全管理;
第3部分:概念阶段;
第4部分:产品开发:系统层面;第5部分:产品开发:硬件层面;一第6部分:产品开发:软件层面;一第7部分:生产和运行;
第8部分:支持过程;
一第9部分:以汽车安全完整性等级为导向和以安全为导向的分析;第10部分:指南。
本部分为GB/T34590的第10部分。本部分按照GB/T1.1一2009给出的规则起草。GB/T34590.10—2017
本部分使用重新起草法修改采用ISO26262-10:2012《道路车辆功能安全第10部分:指南》。本部分与ISO26262-10:2012的技术性差异及其原因如下:修改了本部分的适用范围,由原文的“适用于安装在最大总质量不超过3.51的量产乘用车上的包含一个或多个电子电气系统的与安全相关系统”改为“适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统”;关于规范性引用文件,本部分做了具有技术性差异的调整,以适应我国的技术条件,调整的情况集中反映在第2章“规范性引用文件”中,具体调整如下:·用修改采用国际标准的GB/T34590.1—2017代替ISO26262-1:2011;·用修改采用国际标准的GB/T34590.2—2017代替ISO26262-22011;●用修改采用国际标准的GB/T34590.3—2017代替ISO26262-3:2011;·用修改采用国际标准的GB/T34590.4—2017代替ISO26262-4:2011;●用修改采用国际标准的GB/T34590.5—2017代替ISO26262-5:2011;·用修改采用国际标准的GB/T34590.6—2017代替ISO26262-6:2011;·用修改采用国际标准的GB/T34590.8—2017代替ISO26262-8:2011;,用修改采用国际标准的GB/T34590.9—2017代替ISO26262-9:2011。本部分还做了下列编辑性修改:修改了国际标准的引言及其表述和图1的内容本部分由全国汽车标准化技术委员会(SAC/TC114)提出并归口。本部分负责起草单位:中国汽车技术研究中心、中国第一汽车股份有限公司、上海海拉电子有限公司、博世汽车部件(苏州)有限公司、北京兴科迪科技有限公司、泛亚汽车技术中心有限公司、舍弗勒投资(中国)有限公司、联合汽车电子有限公司、大陆汽车投资(上海)有限公司、浙江尤奈特电机有限公司、北京新能源汽车股份有限公司。
本部分参加起草单位:上汽通用五菱汽车股份有限责任公司、湖南中车时代电动汽车股份有限公GB/T34590.10—2017
司、标致雪铁龙(中国)汽车贸易有限公司、奥托立夫(中国)电子有限公司、爱德克斯(常州)管理有限公司、爱信(南通)汽车技术中心有限公司、宝马(中国)服务有限公司、法雷奥汽车内部控制(深圳)有限公司。
本部分主要起草人:李波、张立君、蒋军、曲元宁、付越、尚世亮、杨虎、史晓密、蒋云、薛剑波、童菲、明月、还宏生、吴庆森、戴军、丑丽丽、匡小军、谢勇波、王俏力、易威、张蕾、靳琼、李钟、谢攀、郭厚锐,杨和全。
GB/T34590.10—2017
ISO26262是以IEC61508为基础,为满足道路车辆上电子电气系统的特定需求而编写。GB/T34590修改采用ISO26262,适用于道路车辆上由电子、电气和软件组件组成的安全相关系统在安全生命周期内的所有活动。安全是未来汽车发展的关键问题之一,不仅在驾驶辅助和动力驱动领域,而且在车辆动态控制和主被动安全系统领域,新的功能越来越多地触及到系统安全工程领域。这些功能的开发和集成将强化对安全相关系统开发流程的需求,并且要求提供满足所有合理的系统安全目标的证明。随着技术日益复杂、软件和机电一体化应用不断增加,来自系统性失效和随机硬件失效的风险逐渐增加。GB/T34590通过提供适当的要求和流程给出了避免风险的指导。系统安全是通过一系列安全措施实现的。安全措施通过各种技术(例如,机械、液压、气压、电子、电气、可编程电子等)实现且应用于开发过程中的不同层面。尽管GB/T34590针对的是电子电气系统的功能安全,但是它也提供了一个框架,在该框架内可考虑基于其他技术的与安全相关系统。GB/T34590:
a)提供了一个汽车安全生命周期(管理、开发、生产、运行、服务、报废),并支持在这些生命周期阶段内对必要活动的剪裁;
提供了一种汽车特定的基于风险的分析方法以确定汽车安全完整性等级(ASIL);b)
应用汽车安全完整性等级(ASIL)定义GB/T34590中适用的要求,以避免不合理的残余c)
风险;
提供了对于确认和认可措施的要求,以确保达到一个充分、可接受的安全等级;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.10—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硬件架构度量的评估免费标准下载网bzxz
5-9随机硬件失效导致违背
安全月标的评估
5-10硬件集成和测试
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.支持过程
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范围
道路车辆功能安全
第10部分:指南
GB/T34590.10—2017
GB/T34590的本部分提供了GB/T34590的概览,也给出了额外的解释,目的是增强对本标准其他部分的理解。本部分只具有资料性特性,描述了GB/T34590的一般概念以便于理解。该解释将般概念扩展到特定的内容。
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。本标准不适用于特殊用途车辆上特定的电子电气系统,例如,为残疾驾驶者设计的车辆。本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时,仅修改的部分需要按照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害,包括这些系统相互作用而引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害,除非危害是直接由电子电气安全相关系统的故障行为而引起的。本标准不针对电子电气系统的标称性能,即使这些系统(例如主动和被动安全系统、制动系统、自适应巡航系统)有专用的功能性能标准。如果本部分与本标准的其他部分存在不一致时,以本标准的其他部分中定义的要求、建议和信息为准。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。GB/T34590.1—2017道路车辆功能安全第1部分:术语(ISO26262-1:2011.MOD)功能安全第2部分:功能安全管理(1SO26262-2:2011,GB/T34590.22017
道路车辆
GB/T34590.3—2017
功能安全第3部分:概念阶段(ISO26262-3:2011,MOD)道路车辆:
GB/T34590.4—2017
GB/T34590.5—2017
GB/T34590.6—2017
GB/T34590.8—2017
功能安全第4部分:产品开发:系统层面(IS026262-4:2011,道路车辆
道路车辆
道路车辆
第5部分:产品开发:硬件层面(ISO26262-5:2011,功能安全
功能安全第6部分:产品开发:软件层面(ISO26262-6:2011,第8部分:支持过程(ISO26262-8:2011,MOD)道路车辆
功能安全
GB/T34590.9一2017道路车辆功能安全第9部分:以汽车安全完整性等级为导向和以安全为导向的分析(ISO26262-9:2011,MOD)1
GB/T34590.10—2017
3术语、定义和缩略语
GB/T34590.1一2017界定的术语、定义和缩略语适用于本文件。4GB/T34590中的关键概念
4.1针对汽车系统的功能安全(与GB/T20438的关系)GB/T20438是关于电气、电子、可编程电子安全相关系统的功能安全通用标准和基础安全标准。这意味着,各工业领域将基于GB/T20438的要求建立自身的功能安全标准在汽车行业,如果直接应用GB/T20438会存在许多问题。其中的一些问题和GB/T34590中相应的差异描述如下。
GB/T20438基于“受控设备”模型,例如具有如下关联控制系统的工业嵌人装置:a)危害分析识别出与受控设备(包括设备控制系统)关联的危害,并对此应用风险降低措施。这可通过电子/电气/可编程电子系统、其他技术的安全相关系统(例如:安全阀)或外部措施(例如:嵌人装置的物理围堵)来实现。GB/T34590基于严重度、暴露概率和可控性,为危害分级提供了规范化的汽车领域的方案。分配给电子/电气/可编程电子系统的风险降低,是通过指定的安全功能实现的。这些安全功b)
能要么是独立的保护系统的一部分、要么嵌人装置控制中。但在汽车系统中,未必能做出这种区分。车辆的安全依赖于控制系统自身的表现GB/T34590使用了安全目标和安全概念的如下思想:通过危害分析和风险评估识别出需要防止,减轻或控制的危害和危害事件;一为每个危害事件制定安全目标;一将汽车安全完整性等级(ASIL)与每个安全目标关联;一功能安全概念是实现安全目标的功能性的表述一技术安全概念是功能如何通过硬件和软件在系统层面实现的表述,及一软件安全要求和硬件安全要求表述了特定的安全要求,这些要求将作为软硬件设计的一部分而被实施。
示例:
安全气囊系统:其中一个危害是气囊非预期的起爆:相关的安全目标是气囊不能起爆,除非发生需要气囊起爆的碰撞;一功能安全概念可定义完余的功能来探测车辆是否发生碰撞;一技术安全概念可定义两个具有不同轴向的独立加速度传感器和两个独立点火回路的实施方案,如果两路均闭合则起爆点火管。
GB/T20438针对的是单一的或小批量的系统。系统经过制造和测试后安装到嵌人装置,然后执行安全确认。对于大批量销售的系统,如道路车辆,安全确认在量产之前执行。因此GB/T34590中生命周期活动的次序有所不同。对此,GB/T34590.7一2017第5章提出了对生产的要求。而在GB/T20438中并未覆盖此部分内容。GB/T20438未对管理跨多个组织和供应链的开发提出特定要求,而GB/T34590明确地提出了这个问题,包括开发接口协议(DIA)[参见GB/T34590.8一2017第5章(分布式开发的接口),这是因为汽车系统是由客户(如整车厂、客户的供应商或客户自已)的一个或多个供应商生产的。GB/T20438不包含危害分级的规范化要求。GB/T34590则包含了汽车领域危害分级的方案。此方案认为不是汽车系统的每个危害都会导致事故。其结果取决于涉险人员是否实际暴露在危害发生2
GB/T34590.10—2017
的场景下,且它们能否采取措施以控制危害的结果。图2给出了应用了此概念的失效示例,即:影响运动中车辆可控性的失效。
注:此概念仅为了阐述失效的发生和事故之间没有必然的直接关联。尽管此过程中评估的参数与图中状态过渡的可能性相关,但它不是危害分析和风险评估过程的展示。功能正常的相关项
(含安全状态)
失效被控制、
减轻或变成瞬态
尝试控制成功
功能异常的相关项
(危害出现)
尝试控制动作
失效发生
驾驶场景出现
尝试控制失败
图2汽车风险的状态机模型
为符合汽车工业的当前技术水平,对硬件开发(GB/T34590.5一2017)和软件开发(GB/T34590.62017)要求进行了调整。特别地,GB/T34590.62017包含涉及基于模型开发的要求;GB/T20438规定了特定方法的应用,对于使用任何替代方法,必需提供详细的理由。而对于GB/T34590中列出方法,给出了特定的目标。为实现这些目标,可应用给出的方法,或应用替代方法,但需提供理由证明替代方法也能实现目标。
为GB/T34590中的安全要求分配汽车安全完整性等级(ASIL)而不是安全完整性等级(SIL),其主要原因是GB/T20438中的SIL表述为概率术语(参见GB/T20438.1一2006表3)。GB/T20438闸述:“在评估目标的失效措施是否达成时,可以接受仅考虑硬件安全完整性的量化技术及应用可靠性预测技术。为满足(有关系统性安全完整性的)目标失效措施的必要预防措施,需使用定性技术和判断。”ASIL不是基于这类有关危害发生的概率的要求,但也存在关于符合ASIL要求的概率目标。4.2相关项、系统、要素、组件、硬件元器件和软件单元GB/T34590.1一2017中定义了相关项、系统、要素、组件、硬件元器件和软件单元。图3展示了系统,要素,组件,硬件元器件和软件单元的关系。图4举例展示了相关项的分解(构成关系)。可分解的要素可被标注为系统、子系统或组件。满足系统标准的可分解要素可被标注为系统或子系统。当着重强调要素是一个更大系统的一部分时,使用术语“子系统”。组件是非系统层面的,逻辑上和技术上独立的要素。通常,术语“组件”用于仅由元器件和单元组成的要素,但也能用于由更低层面的特定技术领域厂例如:电子电气技术(参见图4)要素组成的要素示例:对于微控制器或特定用途集成电路(ASIC),可使用如下分割:整个微控制器是一个组件,处理单元[例如:中央处理单元(CPU)]是一个元器件,处理单元中的寄存器(例如:中央处理单元寄存器组)是一个子元器件。在进行微控制器分析时,需要进行更细节层面的分割,为帮助达到此目的,可能要将元器件分割成子元器件,再将子元器件进一步分割成基础子元器件3
GB/T34590.10—2017
相关项
硬件元器件、
软件单元
(子》系统:
例如:传感器、
控制器、执行器
(子)组件:
例如,微控制器、
应用软件
例如:中央处理单元,
RAM的软件测试模块
个实例由一个或多个其他实例组成(例如,一个系统可由一个或多个子系统组成)一个实例是由另一实例实现(例如,一个功能是由一个或多个系统来实现》
集合:一个实例由其他实例组成(例如,系统由一组组件组成)
注1:根据上下文,要素可用于此图表中的系统,组件,硬件元器件和软件单元,按照GB/T34590.1一2017的2.3.2。注2:GB/T34590.1中定义的系统至少包含传感器、控制器和执行器,例如:至少3个相关的要素。注3:*表示可能有N个要素。
图3相关项、系统、组件、硬件元器件和软件单元间的关系系统
相关项
电子/电气
传感器
控制器
执行器
硬件软件
软件硬件
硬件软件硬件软件硬件软件
其他技术
图4相关项分解示例
4.3故障、错误和失效之间的关系在GB/T34590.1一2017中定义了术语:故障、错误和失效。图5从三个不同类型的原因(系统性软件问题、随机硬件问题和系统性硬件问题)描述了故障到错误并从错误到失效的发展过程。系统故障(参见GB/T34590.1一2017)起因于设计和规范的问题:软件故障和部分硬件故障是系统性的。随机硬件故障(参见GB/T34590.1一2017)起因于物理过程,比如疲劳,物理退化或环境应力。在组件层面,每个不同类型的故障会导致不同的失效。然而,组件层面的失效是相关项层面的故障。注意,在此示例中,整车层面不同原因导致的故障可引起相同的失效。如果额外的环境因素使失效叠加了事故场景,相关项层面的部分失效将会是危害(参见GB/T34590.1—2017)。示例:当车辆开始穿越十字交叉路口时发生非期望的行为,可能发生碰撞,例如:对危害事件“当车辆开始穿越十字4
小提示:此标准内容仅展示完整标准里的部分截取内容,若需要完整标准请到上方自行免费下载完整标准文档。