[PDF] GB/T 34590.5-2017 - 自动发货. 英文版
| 标准号码 | 美元 | 购买PDF | 工期 | 标准名称(英文版) |
| GB/T 34590.5-2017 | 365 | GB/T 34590.5-2017 | 9秒内发货PDF | 道路车辆 功能安全 第5部分：产品开发：硬件层面 |
| 基本信息 | |
|---|---|
| 标准编号 | GB/T 34590.5-2017 (GB/T34590.5-2017) |
| 中文名称 | 道路车辆 功能安全 第5部分：产品开发：硬件层面 |
| 英文名称 | Road vehicles -- Functional safety -- Part 5: Product development at the hardware level |
| 行业 | 国家标准 (推荐) |
| 中标分类 | T35 |
| 国际标准分类 | 43.040 |
| 字数估计 | 70,753 |
| 发布日期 | 2017-10-14 |
| 实施日期 | 2018-05-01 |
| 发布机构 | 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会 |
GB/T 34590.5-2017
道路车辆 功能安全 第5部分：产品开发：硬件层面
Road vehicles -- Functional safety -- Part 5: Product development at the hardware level
1 范围
GB/T 34590的本部分规定了车辆在硬件层面产品开发的要求,包括:
---启动硬件层面产品开发的要求;
---硬件安全要求的定义;
---硬件设计;
---硬件架构度量;及
---因随机硬件失效导致违背安全目标的评估,硬件集成及测试。
本部分对于硬件要素的要求适用于非可编程要素和可编程要素,如ASIC、FPGA和PLD。并且,
GB/T 34590.6-2017、GB/T 34590.8-2017的第11章和12章中的要求对于可编程电子要素是适用的。
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。
本标准不适用于特殊用途车辆上特定的电子电气系统,例如,为残疾驾驶者设计的车辆。
本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。
对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时,仅修改的部分需要按
照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害,包括这些系统相互作用而
引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害,除非危害是直接由电子电气安全相关系统的故障行为而引起的。
本标准不针对电子电气系统的标称性能,即使这些系统(例如,主动和被动安全系统、制动系统、自
适应巡航系统)有专用的功能性能标准。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 34590.1-2017 道路车辆 功能安全 第1部分:术语(ISO 26262-1:2011,MOD)
GB/T 34590.2-2017 道路车辆 功能安全 第2部分:功能安全管理(ISO 26262-2:2011,MOD)
GB/T 34590.4-2017 道路车辆 功能安全 第4部分:产品开发:系统层面(ISO 26262-4:2011,
MOD)
GB/T 34590.6-2017 道路车辆 功能安全 第6部分:产品开发:软件层面(ISO 26262-6:2011,
MOD)
GB/T 34590.7-2017 道路车辆 功能安全 第7部分:生产和运行(ISO 26262-7:2011,MOD)
GB/T 34590.8-2017 道路车辆 功能安全 第8部分:支持过程(ISO 26262-8:2011,MOD)
GB/T 34590.9-2017 道路车辆 功能安全 第9部分:以汽车安全完整性等级为导向和以安全
为导向的分析(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等级的要求和建议
若无其他说明,对于ASILA、B、C和D等级,应满足每一子章条的要求或建议。这些要求和建议
参照安全目标的ASIL等级。如果在项目开发的早期对ASIL等级完成了分解,应按照GB/T 34590.9-
2017第5章,遵循分解后的ASIL等级。
如果GB/T 34590中ASIL等级在括号中给出,则对于该ASIL等级,相应的子章条应被认为是推
荐而非要求。这里的括号与ASIL等级分解无关。
5 启动硬件层面产品开发
5.1 目的
启动硬件层面产品开发的目的是确定并计划硬件开发各子阶段过程中的功能安全活动,也包括在
GB/T 34590.8-2017中所描述的必要的支持过程。
硬件特定的安全活动的计划包含在安全计划中(参见GB/T 34590.2-2017的6.4.3和GB/T 34590.4-
2017的5.4)。
5.2 总则
制定满足安全要求的硬件开发所需的活动和流程的计划。图2阐明了为满足本部分要求的硬件层
面产品开发的流程步骤,以及在GB/T 34590框架内这些步骤的集成。
硬件层面产品开发的必要活动和流程包括:
---技术安全概念的硬件实现;
---分析潜在硬件故障及其影响;及
---与软件开发的协调。
注:在图中,GB/T 34590的各部分具体条款用以下列方式来表明:“m-n”,其中“m”代表“部分”的编号和“n”表示“章”的编号,例如,“4-5”表示GB/T 34590的第4部分的第5章。
注:附录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的5.5.3。
5.3.2 支持信息
可考虑下列信息:
---鉴定报告(硬件组件或元器件),如果适用(见GB/T 34590.8-2017的13.5.3)。
5.4 要求和建议
5.4.1 应细化按照GB/T 34590.2-2017所制定的安全计划,包括确定硬件层面产品开发活动的适当
方法和措施,并与GB/T 34590.6-2017中活动的计划保持一致。
5.4.2 相关项硬件的开发流程,包括方法和工具,应在硬件开发的所有子阶段内保持一致,并与系统和
软件子阶段保持一致,以便在硬件开发过程中保持要求流的精确性和一致性。
5.4.3 硬件层面产品开发的安全生命周期活动的剪裁应按照GB/T 34590.2-2017的6.4.5实施,并基
于图2给出的参考阶段模型。
5.4.4 应识别出对硬件组件的复用,或对经过鉴定的硬件组件或元器件的使用,并且应描述由此产生
的对安全活动的剪裁。
5.5 工作成果
安全计划(细化的),由5.4.1~5.4.4的要求得出。
6 硬件安全要求的定义
6.1 目的
本章的第一个目的是定义硬件安全要求,这些要求由技术安全概念和系统设计规范导出。
第二个目的是验证硬件安全要求与技术安全概念及系统设计规范的一致性。
本阶段另一目的是细化最初在GB/T 34590.4-2017第7章定义的软硬件接口(HSI)规范。
6.2 总则
将技术安全要求分配给硬件和软件。既分配给硬件又分配给软件的要求被进一步划分出仅对硬件
的安全要求。考虑设计限制和这些限制对硬件的影响,对硬件安全要求进行进一步的细化。
6.3 本章的输入
6.3.1 前提条件
应具备如下信息:
---安全计划(细化的),按照5.5的要求;
---技术安全概念,按照GB/T 34590.4-2017的7.5.1;
---系统设计规范,按照GB/T 34590.4-2017的7.5.2;及
---软硬件接口规范,按照GB/T 34590.4-2017的7.5.3。
6.3.2 支持信息
可考虑如下信息:
---软件安全需求规范(见GB/T 34590.6-2017的6.5.1)。
6.4 要求和建议
6.4.1 相关项硬件要素的硬件安全需求规范应从分配给硬件的技术安全要求中导出。
6.4.2 硬件安全需求规范应包括与安全相关的每一条硬件要求,包括以下:
注1:a)、b)、c)或d)中描述的硬件安全要求包括确保其安全机制有效性所需的属性。
a) 为控制要素硬件内部失效的硬件安全要求和安全机制的相关属性,这包括用来覆盖相关瞬态
故障(例如,由于所使用的技术而产生的瞬态故障)的内部安全机制;
示例1:属性可包括看门狗的定时和探测能力。
b) 为确保要素对外部失效容错的硬件安全要求和安全机制的相关属性;
示例2:当外部失效发生时,如ECU的输入开路时,要求ECU应具备的功能表现。
c) 为符合其他要素的安全要求的硬件安全要求和安全机制的相关属性;
示例3:对传感器或执行器的诊断。
d) 为探测内外部失效和发送失效信息的硬件安全要求和安全机制的相关属性;及
注2:d)项中描述的硬件安全要求包括防止故障潜伏的安全机制。
示例4:安全机制中定义的硬件元器件的故障响应时间,要符合故障容错时间间隔。
e) 不定义安全机制的硬件安全要求。
示例5:举例如下:
---为满足6.4.3和6.4.4所描述的随机硬件失效目标值的硬件要素要求;
---为避免特定行为的要求(例如,“一个特定的传感器不应有一个不稳定的输出”);
---分配给执行预期功能的硬件要素的要求;
---定义线束或接插件的设计措施的要求。
6.4.3 此要求适用于等级为ASIL(B)、C和D的安全目标。当为相关项硬件要素推导目标值时,应考
虑按照GB/T 34590.4-2017第7章的要求,为本部分第8章定义的度量设定目标值。
注:在GB/T 34590.8-2017第5章定义的分布式开发情况下,此活动可包括目标值的拆分。
6.4.4 此要求适用于等级为ASIL(B)、C和D的安全目标。当为相关项硬件要素推导目标值时,应考
虑按照GB/T 34590.4-2017第7章的要求,为本部分第9章定义的过程设定目标值。
注:在GB/T 34590.8-2017第5章定义的分布式开发情况下,此活动可包括目标值的拆分。
6.4.5 硬件安全要求应按照GB/T 34590.8-2017第6章的要求进行定义。
6.4.6 应定义相关项或要素的硬件设计验证准则,包括环境条件(温度、振动、EMI等)、特定的运行环
境(供电电压、任务概述等)以及特定于组件的要求:
a) 对于中等复杂性的硬件组件或元器件的鉴定验证,其准则应满足GB/T 34590.8-2017第13
章的要求;
b) 通过测试进行的验证,其准则应满足第10章的要求。
6.4.7 硬件安全要求应符合GB/T 34590.4-2017中6.4.2.3要求制定的安全机制的故障容错时间
间隔。
6.4.8 硬件安全要求应符合GB/T 34590.4-2017中6.4.4.2要求制定的多点故障探测时间间隔。
注1:对于ASIL等级为C和D的安全目标来说,如果对应的安全概念没有描述明确的量值,多点故障探测时间间隔可以定义为等于或小于该相关项从上电到下电的周期。
注2:合适的多点故障探测时间间隔也可以通过对随机硬件失效的发生概率的定量分析来确定。
6.4.9 硬件安全要求应按照GB/T 34590.8-2017第6章和第9章的要求进行验证,以提供证据证
明其:
a) 与技术安全概念、系统设计规范以及硬件规范的一致性;
b) 关于技术安全要求分配给硬件要素的完整性;
c) 与相关软件安全要求的一致性;及
d) 正确性与精确性。
6.4.10 在GB/T 34590.4-2017第7章中最初定义的软硬件接口(HSI)应被充分细化,以允许硬件被
软件正确的控制和使用,并且应描述出硬件和软件之间的每一项安全相关的关联性。
6.4.11 软硬件开发人员应共同负责验证细化后的软硬件接口(HSI)规范的充分性。
6.5 工作成果
6.5.1 硬件安全需求规范(包括测试和认可准则),由6.4.1~6.4.8的要求得出。
6.5.2 软硬件接口规范(细化的),由6.4.10和6.4.11的要求得出。
注:此工作成果可以参考GB/T 34590.6-2017中6.5.2给出的相同的工作成果。
6.5.3 硬件安全要求验证报告,由6.4.9的要求得出。
7 硬件设计
7.1 目的
本章的第一个目的是按照系统设计规范和硬件安全要求设计硬件。
本章的第二个目的是验证硬件设计是否违背系统设计规范和硬件安全要求。
7.2 总则
硬件设计包括硬件架构设计和硬件详细设计。硬件架构设计表示所有的硬件组件以及它们彼此的
相互关系。硬件详细设计是在电气原理图级别上,表示构成硬件组件的元器件间的相互连接。
为开发同时符合硬件安全要求及所有的非安全要求的唯一的硬件设计,在此子阶段,应在同一开发
过程中处理安全和非安全性要求。
7.3 本章的输入
7.3.1 前提条件
应具备下列信息:
---硬件安全需求规范,按照6.5.1;
---软硬件接口规范(细化的),按照6.5.2;
---系统设计规范,按照GB/T 34590.4-2017的7.5.2;及
---安全计划(细化的),按照5.5。
7.3.2 支持信息
可考虑下列信息:
---软件安全需求规范(参见GB/T 34590.6-2017的6.5.1)。
7.4 要求和建议
7.4.1 硬件架构设计
7.4.1.1 硬件架构应实现第6章定义的硬件安全要求。
7.4.1.2 每个硬件组件应继承其所执行的硬件安全要求中最高的ASIL等级。
注:硬件组件的各个特征将继承该组件所执行的硬件安全要求中最高的ASIL等级。
7.4.1.3 如果在硬件架构设计中对硬件安全要求应用了ASIL分解,ASIL分解应按照GB/T 34590.9-
2017第5章的要求进行。
7.4.1.4 如果一个硬件要素由指定为不同ASIL等级的子要素组成,或由没有指定ASIL等级的子要素
与安全相关的子要素组成。除非满足按照GB/T 34590.9-2017的共存准则,否则应按照最高的ASIL
等级处理每个子要素。
7.4.1.5 对硬件安全要求和其实施之间的可追溯性,应保持到硬件组件的最底层。
注:可追溯性不要求深入到硬件详细设计,而且不需要为硬件元器件指定ASIL等级。
7.4.1.6 为避免高复杂性导致的失效,应通过使用表1中列出的原则,使硬件架构设计具有下述特性:
a) 模块化;
b) 适当的粒度水平;及
c) 简单性。
7.4.1.7 在硬件架构设计时,应考虑安全相关硬件组件失效的非功能性原因,如果适用,可包括以下的
影响因素:温度、振动、水、灰尘、电磁干扰、来自硬件架构的其他硬件组件或其所在环境的串扰。
7.4.2 硬件详细设计
7.4.2.1 为了避免常见的设计缺陷,按照 GB/T 34590.2-2017的5.4.2.7,应运用相关的经验总结。
7.4.2.2 在硬件详细设计时,应考虑安全相关硬件元器件失效的非功能性原因,如果适用,可包括以下
的影响因素:温度、振动、水、灰尘、电磁干扰、噪声因素、来自硬件组件的其他硬件元器件或其所在环境的串扰。
7.4.2.3 硬件详细设计中,硬件元器件的运行条件应符合它们的环境和运行限制规范。
7.4.2.4 应考虑鲁棒性设计原则。
注:鲁棒性设计原则可利用基于质量管理方法的核对表来展示。
示例:保守的组件规范。
7.4.3 安全分析
7.4.3.1 硬件设计的安全分析,应按照表2和GB/T 34590.9-2017第8章进行,以识别失效的原因和
故障的影响。
注1:安全分析的最初目的是支持硬件设计的定义,其后,安全分析可用于硬件设计验证(见7.4.4)。
注2:就安全分析支持硬件设计定义的目的来说,定性分析可能是适当且充分的。
7.4.3.2 此要求适用于等级为ASIL(B)、C和D的安全目标。对于每个安全相关的硬件组件或元器
件,针对所考虑的安全目标,安全分析应识别以下内容:
a) 安全故障;
b) 单点故障或残余故障;
c) 多点故障(无论是可感知的、可探测的或潜伏的)。
注1:在大多数情况下,分析可以限制到双点故障。但有时阶次高于2的多点故障可能显示与技术安全概念有关(例如,当执行冗余安全机制时)。
注2:识别双点故障的目的,并不要求对每一种可能的两个硬件故障的组合进行系统性的分析,但至少要考虑从技术安全概念得出的组合(例如两个故障的组合:一个故障影响了安全相关的要素,另一个故障影响了相应的为达到或维持安全状态所需的安全机制)。
7.4.3.3 此要求适用于等级为ASIL(B)、C和D的安全目标。应具备安全机制对避免单点故障的有效
性的证据。
为了这个目的:
a) 应具备证据以证明安全机制具有保持安全状态或安全的切换到安全状态的能力(特别是在容
错时间间隔内适当的失效减轻能力);
b) 应评估残余故障的诊断覆盖率。
注1:一个可在任何时间(例如不仅在上电时)发生的故障,如果诊断测试时间间隔加上相应安全机制的故障响应时间,大于相应的容错时间间隔,则不能认为此故障被有效覆盖。
注2:如果可以证明故障仅发生在上电时,并且在车辆行驶期间发生的概率是可以忽略的,则对这些故障仅在上电后执行启动测试是可以接受的。
注3:可用例如FMEA或FTA分析来构建理由。
注4:根据对硬件要素失效模式和它们对更高层面的影响的认知,这种评估可以是硬件要素的全局诊断覆盖率,或更详细的失效模式的覆盖率评估。
注5:附录D可作为诊断覆盖率(DC)的起始点,此起点是声明的有合适理由支持的诊断覆盖率。
7.4.3.4 此要求适用于等级为ASIL(B)、C和D的安全目标。应具备安全机制对避免潜伏故障的有效
性的证据。
为了这个目的:
a) 应具备证据以证明在可接受的多点故障探测时间间隔内完成潜伏故障的失效探测及警示驾驶
员的能力,以确定哪些故障保持潜伏,哪些故障不再保持潜伏;
b) 应评估潜伏故障的诊断覆盖率。
注1:如果一个故障的诊断测试时间间隔加上相应安全机制的故障响应时间大于相应的潜伏故障的多点故障探测时间间隔,则不能认为此故障被有效覆盖。
注2:可用例如FMEA或FTA分析来构建理由。
注3:附录D可作为诊断覆盖率(DC)的起始点,此起点是声明的有合适理由支持的诊断覆盖率。
注4:根据对硬件要素失效模式和它们对更高层面的影响的认知,这种评估可以是硬件要素的全局诊断覆盖率,或更详细的失效模式的覆盖率评估。
7.4.3.5 如果适用,应按照GB/T 34590.9-2017第7章进行相关失效分析,提供证据证明硬件设计与
它们的独立性要求相符合。
7.4.3.6 如果硬件设计引入了新危害,且这个危害没有被现有的安全目标覆盖,则应按照GB/T 34590.8-
2017中的变更管理流程对它们进行危害分析和风险评估。
注:新识别出的、没有被现有安全目标覆盖的危害,通常是非功能性的危害。非功能性的危害在GB/T 34590范围之外,但在危害分析和风险评估中可对它们添加如下注释:“由于不在GB/T 34590的范围内,所以没有对该危害指定ASIL等级”。然而,也可以指定一个ASIL等级作参考。
7.4.4 硬件设计的验证
7.4.4.1 应按照 GB/T 34590.8-2017第9章来验证硬件设计与硬件安全要求的一致性和完整性。为
达到这一目的,应考虑表3中列出的方法。
7.4.4.2 在硬件设计过程中,如果发现任何硬件安全要求的实施是不可行的,应按照GB/T 34590.8-
2017中的变更管理流程提出变更请求。
7.4.5 生产、运行、服务和报废
7.4.5.1 如果安全分析表明生产、运行、服务和报废与安全相关,则应定义其安全相关的特殊特性,这些特殊特性应包括如下属性:
a) 生产和运行的验证措施;及
b) 这些措施的接受准则。
示例:对一种依赖于新的传感器技术的硬件设计的安全分析(例如,影像或雷达传感器),可揭示出这些传感器与特殊安装流程的关系。这种情况下,在生产阶段对这些组件的额外验证措施可能是必要的。
7.4.5.2 如果对安全相关硬件要素的组装、拆卸和报废可能影响技术安全概念,则应定义这些操作的指
导说明。
7.4.5.3 应按照 GB/T 34590.7-2017的5.4.1.2确保安全相关硬件要素的可追溯性。
注:这可以包括适当的标签或其他的硬件要素识别方法,来表示它们是与安全相关的。
7.4.5.4 如果维护可能影响技术安全概念,应定义安全相关硬件要素的维护说明。
7.5 工作成果
7.5.1 硬件设计规范,由7.4.1和7.4.2的要求得出。
7.5.2 硬件安全分析报告,由7.4.3的要求得出。
7.5.3 硬件设计验证报告,由7.4.4的要求得出。
7.5.4 与生产、运行、服务和报废相关的需求规范,由7.4.5的要求得出。
8 硬件架构度量的评估
8.1 目的
本章的目的是用表征故障处理要求的硬件架构度量来评估相关项的硬件架构。
8.2 总则
本章描述了两种硬件架构的度量,用于评估相关项架构应对随机硬件失效的有效性。
这些度量和关联的目标值适用于相关项的整体硬件,并与第9章描述的对随机硬件失效导致违背
安全目标的评估互为补充。
这些度量所针对的随机硬件失效仅限于相关项中某些安全相关电子和电气硬件元器件,即那些能
对安全目标的违背或实现有显著影响的元器件,并限于这些元器件的单点故障、残余故障和潜伏故障。
对于机电硬件元器件,则仅考虑电气失效模式和失效率。
注:计算中可忽略阶次高于2的多点故障硬件要素,除非它们与技术安全概念相关。
硬件架构度量可在硬件架构设计和硬件详细设计过程中迭代使用。
硬件架构度量取决于相关项的整体硬件。对相关项涉及的每个安全目标,都应符合规定的硬件架
构度量的目标值。
定义这些硬件架构度量以实现下列目标:
---客观上可评估:度量是可核实的,并且足够精确以区分不同的架构;
---支持最终设计的评估(基于详细的硬件设计完成精确计算);
---为硬件架构提供基于ASIL等级的合格/不合格准则;
---显示用于防止硬件架构中单点或残余故障风险的安全机制的覆盖率是否足够(单点故障度量);
---显示用于防止硬件架构中潜伏故障风险的安全机制的覆盖率是否足够(潜伏故障度量);
---处理单点故障、残余故障和潜伏故障;
---考虑到硬件失效率的不确定性,确保硬件架构的鲁棒性;
---仅限于安全相关要素;
---支持不同要素层面的应用,例如,可以为供应商的硬件要素分配目标值。
示例:为方便分布式开发,可为微控制器或者ECU分配目标值。
8.3 本章的输入
8.3.1 前提条件
应具备下列信息:
---硬件安全需求规范,按照6.5.1;
---硬件设计规范,按照7.5.1;及
---硬件安全分析报告,按照7.5.2。
8.3.2 支持信息
可考虑下列信息:
---技术安全概念(参见GB/T 34590.4-2017的7.5.1);及
---系统设计规范(参见GB/T 34590.4-2017的7.5.2)。
8.4 要求和建议
8.4.1 此要求适用于等级为ASIL(B)、C和D的安全目标。应将符合附录C的诊断覆盖率、单点故障
度量和潜伏故障度量的概念用于8.4.2~8.4.9的要求。
8.4.2 此要求适用于等级为ASIL(B)、C和D的安全目标。应结合残余故障和相关的潜伏故障来预
估安全机制所实现的安全相关硬件要素的诊断覆盖率。
注1:为此目的,可使用表D.1~表D.14作为起点,此起点是声明的有合适理由支持的诊断覆盖率。
注2:根据对硬件要素失效模式和它们对更高层面影响的认知,这种评估可以是一个硬件要素的全局诊断覆盖率评估,或更详细的失效模式的覆盖率评估。
8.4.3 此要求适用于等级为ASIL(B)、C和D的安全目标。分析中用到的硬件元器件预估失效率的
确定,应使用以下方法:
a) 使用业界公认的硬件元器件失效率数据;
示例:用于确定硬件元器件失效率和失效模式分布的业界公认的来源包括IEC/T R62380、IEC 61709、MILHDBK217Fnotice2、RIACHDBK217Plus、UTEC80-811、NPRD95、EN50129:2003AnnexC、IEC 62061:2005AnnexD、RI-ACFMD97和 MILHDBK338。
注1:这些数据库给出的失效率数据一般都比较保守。
b) 使用现场反馈或测试的统计数据,这种情况下,预估的失效率宜有合适的置信度;
c) 使用工程方法形成的专家判断,该工程方法基于定量和定性的论证。应依据结构化准则进行
专家判断,这些准则是判断的基础,应在失效率预估前进行设定。
注2:专家判断准则可包括现场经验、测试、可靠性分析和设计的新颖性。
8.4.4 此要求适用于等级为ASIL(B)、C和D的安全目标。如果没有充分的证据证明计算出的单点
故障或潜伏故障的失效率的可靠性,应提出替代方案(例如,增加安全机制来探测和控制此故障)。
注:例如,充分的证据可以指失效率是通过8.4.3中列出的方法得到的。
8.4.5 此要求适用于等级为ASIL(B)、C和D的安全目标。对于每一个安全目标,由GB/T 34590.4-
2017中7.4.4.2要求的“单点故障度量”的定量目标值应基于下列参考目标值来源之一:
a) 来自应用于值得信赖的相似设计原则中,对硬件架构度量的计算;或
注1:两个相似的设计有相似的功能和分配了相同ASIL等级的相似安全目标。
b) 来自表4。
8.4.6 此要求适用于等级为ASIL(B)、C和D的安全目标。对于每一个安全目标,由GB/T 34590.4-
2017中7.4.4.2要求的“潜伏故障度量”的定量目标值应基于下列参考目标值来源之一:
a) 来自应用于值得信赖的相似设计原则中,对硬件架构度量的计算;或
注1:两个相似的设计有相似的功能和分配了相同ASIL等级的相似安全目标。
b) 来自表5。
8.4.7 此要求适用于等级为ASIL(B)、C和D的安全目标。对于每个安全目标,相关项的整体硬件应
符合下列两者之一:
a) 满足8.4.5中描述的“单点故障度量”目标值;或
b) 满足在硬件要素层规定的合适目标,这些目标足以符合分配给相关项整体硬件的单点故障度
量的目标值(在8.4.5中给出),并有理由说明在硬件要素层符合这些目标。
注1:如果相关项包含失效率等级有显著差异的不同种类的硬件要素,就会存在这样的风险,即为了满足硬件架构度量时仅关注具有最高等级失效率的那些硬件要素(一个可能发生此情况的例子是,只考虑线束/保险丝/接插件的失效率,而忽略失效率显著较低的硬件元器件的失效率,就以为实现了对单点故障度量的符合性)。为每一类硬件规定合适的度量目标值有助于规避这种不良影响。
注2:当瞬态故障与所用技术相关时,要考虑这些瞬态故障。可以通过给它们指定并确认一个特定的“单点故障度量”目标值(如注1中所解释的),或通过一个基于对内部安全机制有效性验证的定性理由来处理这类瞬态故障。
注3:如果不满足目标,将按4.1所述评估如何实现安全目标的理由。
注4:可以结合考虑多个或所有适用的安全目标来确定单点故障度量;但在这种情况下,采用最高 ASIL等级的安全目标的度量目标。
8.4.8 此要求适用于等级为ASIL(B)、C和D的安全目标。对于每个安全目标,相关项的整体硬件应
符合下列之一:
a) 满足8.4.6中描述的“潜伏故障度量”目标值;
b) 满足在硬件要素层规定的合适目标,这些目标足以符合分配给相关项整体硬件的潜伏故障度
量的目标值(在8.4.6中给出),并有理由说明在硬件要素层符合这些目标;或
c) 对于其故障可导致安全机制(防止故障违背安全目标)无效的每个硬件要素,满足相关潜伏故
障的诊断覆盖率目标值,该值与8.4.6中给出的潜伏故障度量目标值一致(被当做诊断覆盖
率),当每个安全机制都是基于故障探测且其无效可导致违背安全目标时,适用此选项。
注1:选项c)仅限于在每个相关安全机制是基于故障探测的情况。在此情况下,通过这些安全机制的探测来警示目标功能的可能潜伏故障。在其他情况下,则只有选项a)和b)适用。
注2:在选项c)情况下,不计算度量,只评估安全机制对于硬件要素的潜伏故障的覆盖率。
注3:如果相关项包含失效率等级显著差异的不同种类的硬件要素,就会存在这样的风险,即为了满足硬件架构度量时仅考虑具有最高等级失效率的那些硬件要素(一个可能发生此情况的例子是,只考虑线束/保险丝/接插件的失效率,而忽略失效率显著较低的硬件元器件的失效率,就认为实现了对单点故障度量的符合性)。为每一类硬件规定合适的度量目标值有助于规避这种不良影响。
注4:如果不满足目标,将按4.1所述评估如何实现安全目标的理由。
注5:可以结合考虑多个或所有适用的安全目标来确定潜伏故障度量;但在这种情况下,采用最高 ASIL等级的安全目标的度量目标。
8.4.9 此要求适用于等级为ASIL(B)、C和D的安全目标。应按照GB/T 34590.8-2017第9章的要
求,对应用8.4.7和8.4.8中的方法得出的结果进行验证评审,以提供其技术正确性和完整性的证据。
注:仔细验证单点故障度量,确保只考虑了安全相关硬件要素的失效率,这样度量才不会受到不具备单点故障或残余故障可能性的、不必要的安全相关硬件要素的影响(例如,向安全机制添加了不必要的硬件要素)。
8.5 工作成果
8.5.1 相关项架构应对随机硬件失效的有效性的分析,由8.4.1~8.4.8的要求得出。
8.5.2 相关项架构应对随机硬件失效的有效性评估的评审报告,由8.4.9的要求得出。
9 随机硬件失效导致违背安全目标的评估
9.1 目的
本章中要求的目的是制定可用的准则,用于表明相关项随机硬件失效导致违背安全目标的残余风
险足够低。
注:“足够低”指“与已经在使用的相关项的残余风险相当”。
9.2 总则
推荐用两个可选的方法(见9.4)以评估违背安全目标的残余风险是否足够低。
两个方法都评估由单点故障、残余故障和可能的双点故障导致的违背安全目标的残余风险。如果
显示为与安全概念相关,也可考虑多点故障。在分析中,对残余和双点故障,将考虑安全机制的覆盖率,
并且,对双点故障也将考虑暴露持续时间。
第一个方法包括使用概率的度量,即“随机硬件失效概率度量”(PMHF),通过使用例如定量故障
树分析(FTA)及将此计算结果与目标值相比较的方法,评估是否违背所考虑的安全目标。
第二个方法包括独立的评估每个残余和单点故障,及每个双点失效是否导致违背所考虑的安全目
标。此分析方法也可被考虑为割集分析。
注:在可靠性分析中,故障树中的一个割集是一组基本事件,其发生导致顶层事件的发生。
所选用的方法在硬件架构设计和硬件详细设计中可以被迭代应用。
本章的范围限于相关项的随机硬件失效。分析中所考虑的是电子电气硬件元器件。对于机电硬件
元器件,仅考虑电气失效模式和失效率。
9.3 本章的输入
9.3.1 前提条件
应具备下列信息:
---硬件安全需求规范,按照6.5.1;
---硬件设计规范,按照7.5.1;及
---硬件安全分析报告,按照7.5.2。
9.3.2 支持信息
可考虑下列信息:
---技术安全概念(参见GB/T 34590.4-2017的7.5.1);及
---系统设计规范(参见GB/T 34590.4-2017的7.5.2)。
9.4 要求和建议
9.4.1 总则
此要求适用于等级为ASIL(B)、C和D的安全目标。相关项应符合9.4.2或9.4.3中的一个。
9.4.2 随机硬件失效概率度量(PMHF)的评估
9.4.2.1 此要求适用于等级为ASIL(B)、C和D的安全目标。应按照GB/T 34590.4-2017中7.4.4.3
的要求,为随机硬件失效导致违背每个安全目标的最大可能性定义定量目标值,使用来源a)、b)或c)的
参考目标值,如下所列:
a) 来自表6;或
b) 来自值得信赖的相似设计原则的现场数据;或
c) 来自应用于值得信赖的相似设计原则中的定量分析技术(使用按照8.4.3的失效率)。
注1:这些来源于a)、b)或c)的定量目标值没有任何绝对的意义,仅有助于将一个新的设计与已有设计相比较。其目的是生成按照9.1描述的可用的设计指导,并获得设计符合安全目标的可用证据。
注2:两个相似的设计拥有相似的功能和分配了相同ASIL等级的相似安全目标。
9.4.2.2 此要求适用于等级为ASIL(B)、C和D的安全目标。9.4.2.1要求的定量目标值应表述为相关
项整个运行生命周期中每小时的平均概率。
9.4.2.3 此要求适用于等级为ASIL(B)、C和D的安全目标。针对单点、残余和双点故障的硬件架构
定量分析,应提供证据证明9.4.2.1要求的目标值已达到。此定量分析应考虑:
a) 相关项的架构;
b) 每个可导致单点故障或残余故障的硬件元器件的失效模式的估计失效率;
c) 每个可导致双点故障的硬件元器件的失效模式的估计失效率;
d) 安全机制对安全相关的硬件要素的诊断覆盖率;及
e) 双点故障情况下的暴露持续时间。
注1:在定量分析中,考虑可导致一个安全相关的硬件要素及其安全机制同时失效的硬件要素失效模式。它们可以
是单点故障、残余故障或多点故障。
注2:暴露持续时间从故障可能发生时开始,包括:
a) 与每个安全机制有关的多点故障探测时间间隔,或者当故障不对驾驶员显示(潜伏故障)时的车辆生命周期;
b) 单次行程的最长持续时间(对于驾驶员被要求以一种安全方式停车的情况);及
c) 直到车辆进入车间维修前......
英文网页: GB/T 34590.5-2017
相关标准: GB/T 34590.4|GB/T 34590.1|GB/T 34590.12|GB/T 34590.11|GB/T 34590.5-2017|GB/T 34590.5|