目录
A 名词解释
A.1 HSR
A.2 DFA
A.3 FMEA
A.4 FMEDA
A.5 FTA
A.6 FTA与FMEDA的交互
A.7 TSC
A.8 SPF
A.9 SPFM
A.10 LF
A.11 LFM
A.12 PMHF
A.13 1 FIT
A.14 PPM
A.15 ISO 26262-2018与 ISO 26262-2011在part5的文档的差异性
A.16 ISO 26262-2018与 ISO 26262-2011在part5的工作成果差异性
1 硬件开发流程
1.1 与传统硬件设计的区别点
1.2 ISO 26262 中硬件开发流程
2 开发过程中各环节说明
2.1 硬件安全需求规范
2.1.1 原则
2.1.2 验证
2.2 硬件设计
2.2.1 硬件架构设计
2.2.2 硬件详细设计
2.3 硬件架构度量的评估
2.3.1 硬件量化指标分类
2.3.2 硬件架构指标的定义
2.4 随机硬件失效违背安全目标的评估
2.4.1 安全相关的故障类型
2.4.2 硬件失效模式分类流程图编辑
2.4.3 硬件失效率
2.4.4 随机失效率指标
2.4.5 FMEDA
2.4.6 指标计算示例
2.5 硬件集成和测试
2.5.1 原则
2.5.2 硬件集成和测试的验证方法
A 名词解释
A.1 HSR
Hardware Safety Requirement，硬件安全需求，由TSR得到HSR
A.2 DFA
dependent failure analysis，相关失效分析
A.3 FMEA
failure mode and effects analysis，失效模式及后果分析，一种自下而上的归纳分析方法，通过识别部件的失效模式来追溯失效影响，包含DFMEA（设计FMEA）和PFMEA（过程FMEA），FMEA适用于系统、软件、硬件层次
A.4 FMEDA
failure mode，effect and diagnostic analysis，失效模式影响及诊断分析，一种自下而上的归纳分析方法，在FMEA上对随机硬件失效率的计算，FMEDA适用于硬件层次，考虑独立的故障，工具相对简单
A.5 FTA
fault tree analysis，故障树分析，一种自上而下的演绎分析方法，通过危害事件来追溯失效原因，同时可反向计算顶部事件的失效率，FTA适用于系统、软件、硬件层次，考虑多个故障，需要专业的工具
A.6 FTA与FMEDA的交互
A.7 TSC
Technical safety concept，制定技术安全需求，满足功能安全要求的系统架构
A.8 SPF
single point failures，单点故障
A.9 SPFM
single-point fault metric，单点故障度量，用于硬件架构度量的评估
A.10 LF
latent failures，潜在故障
A.11 LFM
latent fault metric，潜在故障度量，用于硬件架构度量的评估
A.12 PMHF
Probabilistic Metric of for random Hardware Failures，硬件随机失效概率度量，PMHF是用于评估硬件随机故障导致违背安全目标的残余风险足够低的方法之一，描述为相关项整个运行生命周期内每小时的平均概率，因此PMHF的单位与故障率单位一致，均为FIT
A.13 1 FIT
failure in time，失效率的单位，每小时失效的次数，1 FIT为/小时，例如: 某电阻失效率λ=2 FIT，即该电阻在10^9 h内存在两次失效。
A.14 PPM
part per million，百万分之一，为
A.15 ISO 26262-2018与 ISO 26262-2011在part5的文档的差异性
| 序号 | part | 2018 | 2011 | 备注 |
| 1 | 5：产品开发在硬件层面 | “安全计划”位于2018：2-6“依赖于项目的安全管理” | “安全计划”位于2011：5-5“启动硬件层面产品开发” | 移动 |
| 2 | 无 | 删除2011：5-附录F“比例因子的应用” | 删除 | |
| 3 | 增加： 2018：5-附录F“满足9.4.2目标的示例”、 2018：5-附录G“由两个系统组成的项目的PMHF预算分配示例”、 2018：5-附录H“潜在故障处理示例” |
无 | 增加 |
A.16 ISO 26262-2018与 ISO 26262-2011在part5的工作成果差异性
| ISO 26262-2018 | ISO 26262-2011 | 分析 | ||||
| part5：产品开发在硬件层面 | part3：产品开发在硬件层面 | |||||
| 章节 | 名称 | 具体内容 | 章节 | 名称 | 具体内容 | |
| / | / | / | 5-5 | 启动硬件层面产品开发 | 5.5安全计划 | 删除旧版章节 |
| 5-10 | 硬件集成和测试 | 10.5.1硬件集成和验证规范 | 5-10 | 硬件集成和测试 | / | 新版新增1项工作成果 |
1 硬件开发流程
1.1 与传统硬件设计的区别点
●硬件架构度量的评估
●随机硬件失效违背安全目标的评估
1.2 ISO 26262 中硬件开发流程
2 开发过程中各环节说明
2.1 硬件安全需求规范
2.1.1 原则
①硬件需求规范应从分配给硬件的技术安全要求中导出，即由TSR导出HSR
②硬件需求规范应包括与安全相关的每一条硬件要求，包括：
| 要求 | 具体说明 |
| 为控制要素硬件内部失效的安全机制的硬件安全要求和相关属性 | ●这包括用来覆盖相关瞬态故障（如由于所使用的技术而产生的瞬态故障）的内部安全机制 eg.属性可包括看门狗的定时和探测能力 |
| 为确保要素对外部失效容错的硬件安全要求和安全机制的相关属性 | eg.当外部发生失效时，如ECU输入开路，要求ECU应具备的功能表现 |
| 为符合其他要素的安全要求的硬件安全要求和安全机制的相关属性 | eg.对传感器或执行器的诊断 |
| 为探测内外部失效和发送失效信息的硬件安全要求及安全机制的相关属性 | ●该项中的硬件安全要求包括防止故障潜伏的安全机制 eg.安全机制中定义的硬件元器件的故障响应时间，要符合故障容错时间间隔 |
| 没有定义安全机制的硬件安全要求 | eg. —满足随机硬件失效目标值的硬件要素要求 —为避免特定行为的要求（如“一个特定传感器不应该有一个不稳定的输出”） —分配给执行预期功能的硬件要素的要求 —定义线束或插接件的设计措施的要求 |
2.1.2 验证
2.1.2.1 验证内容：
●与TSC、系统设计规范和硬件规范的一致性
●与软件安全需求的一致性
●完备性
●正确性和精确性
2.1.2.2 验证的方法
①验证安全要求的方法
②验证硬件设计与硬件安全需求的一致性和完整性方法
2.2 硬件设计
●根据系统设计规范和硬件安全需求进行硬件设计
●硬件设计包括硬件架构设计和硬件详细设计
2.2.1 硬件架构设计
2.2.1.1 设计要点
①表示出所有硬件组件及彼此的关联
②硬件安全需求和实现之间的可追溯性
③考虑复用、考虑非功能因素，如无关功能的硬件也需考虑对于功能安全和可靠性存在潜在的影响
2.2.2 硬件详细设计
2.2.2.1 设计要点
①原理图级别、表示出构成组件的零部件的关联
②确保硬件零部件在环境和操作规范下的使用
③考虑鲁棒性设计原则
2.3 硬件架构度量的评估
2.3.1 硬件量化指标分类
2.3.2 硬件架构指标的定义
2.3.2.1 架构中关于硬件要素的计算公式
①假设所有的失效都是互相独立的，且按照指数分布，计算公式如下：
②指标定义：
| 指标名称 | 计算公式 |
| 单点故障指标（SPFM） | ●SPFM=1 - (单点故障总和+残余故障总和) / (所有和安全相关失效率总和)
—λSPF: 单点故障失效率 —λRF,est: 估算的残余故障的失效率 —λDC,RF: 残余故障的诊断覆盖率 |
| 潜伏故障指标（LFM） | LFM=1 - (所有潜伏故障总和) / (所有和安全相关失效率总和 - 单点故障总和 - 残余故障总和)
—λMPF,L,est: 潜伏故障的估算的失效率 —λDC,MPF,L: 潜伏故障的诊断覆盖率 |
③架构指标
其中，可信设计：是指在批量量产后该设计已达到目标值要求的设计
④SPFM及LFM对应不同ASIL的要求
⑤指标计算方法
| 方法一：FTA | ①先利用FTA进行定性分析，如下图所示，得到顶事件的失效原因
②再对每个故障进行定量分析，将每个故障的失效值加进去，如下图所示，最后再一层一层推算，最后算出顶事件的失效率，可以通过软件计算该值
|
| 方法二：元器件计数法 | ●源自可靠性预计方法 ●计算公式：
该值计算出来肯定偏大，偏大都能满足，那么肯定满足设计要求 |
2.4 随机硬件失效违背安全目标的评估
2.4.1 安全相关的故障类型
| 故障类型 | 说明 |
| 单点故障λSPF | ●该故障能直接违反安全目标，且硬件元素中没有其他安全机制，导致无功能 |
| 残余故障 λRF |
●安全机制无法覆盖的那部分故障(没有100%覆盖率的安全机制，如果一个安全机制覆盖率为90%，那剩余的10%则属于残余故障) ●该故障能直接违反安全目标，硬件元素中至少有一个安全机制 ●eg.硬件要素可以有“开路”，“对地短路”，“短路接高”故障，但只有“开路”，“对地短路”的故障被安全机制所覆盖，如果“短路接高”故障导致违背了特定安全目标，且没有安全机制所覆盖，那么就是一个残余故障 |
| 双点（多点）故障 λDPF |
●与其他独立故障可以联合导致多点失效的单个故障（单个故障不会违反安全目标，但是多个单点故障联合后导致违反安全目标的故障） ●多点故障又细分为可探测的双点故障、可感知的双点故障以及潜伏的双点故障 |
| 潜伏多点故障 λDPF_latent |
●在多点故障检测时间间隔不能被安全机制检测出来的也不能被驾驶员识别的多点故障 |
| 安全故障 λS |
●不会显著增加违反安全目标可能性的故障，例如某指示灯显示故障，但不影响其正常功能 ●三点及以上的故障通常也被认为是安全故障(一般发生概率较低且所对应的安全机制过于复杂，所以归类为安全故障 |
| 可感知故障 λLF |
●在规定的时间间隔内可由驾驶员推断出其存在的故障（可察觉的车辆故障，如发动机故障无动力） |
| 多点可探测故障 λDPF_det |
●在规定的时间内通过安全机制检测出的故障，如仪表报警灯叫可探测故障 ●除单点故障，残余故障及双(多)点潜伏故障，剩余的则是可探测双点潜伏故障，公式为： λDPF_det=λ*失效分布比例-λSPF/RF-λDPF_latent |
2.4.2 硬件失效模式分类流程图
2.4.3 硬件失效率
2.4.3.1 失效模式分布和失效率计算（单个硬件组件）
| 可靠度 | ●元件在时刻t完成功能的概率
|
| 失效率 | ●在时间（t，）之间失效的元件个数和在t时刻没有失效的元件个数的比值
●失效率依赖于很多因素，元件失效率计算公式如下：
|
| R(t)与λ(t)关系 |  |
| 失效曲线 | ●浴盆曲线： —大多数产品的失效率随时间变化的曲线形似浴盆 —分为3个阶段，第一阶段磨合期，故障多，属于系统性故障；第二阶段偶发期，即正常使用阶段，设计中无法消除，属于随机硬件故障，26262中硬件量化指标就是针对该阶段；第三阶段老年期，寿命到期后，故障率上升
|
| 失效率数据的来源 | ①硬件的失效率和失效分布可参考相关的行业标准： ●IEC62380、SN29500、IEC61709、MIL HDBK 217F注2、RACHDBK 217加强版、NPRD95、EN50129附录C、EN62061附录D、RAC FMD97、MIL HDBK 338 ②利用现场返回或测试所得的统计数据 ●这种情况下得到的失效率估计值需要有较高的置信水平 ③利用工程上定量和定性讨论建立的专家建议 |
| 失效模式分布 | 失效率可以根据失效模式进行分配 eg.电阻的失效模式为开路和短路 —总失效率假设为2FIT —开路模式占90%，失效率为1.8FIT —短路占10%，失效率为0.2FIT |
2.4.4 随机失效率指标
2.4.4.1 随机失效指标（整个相关硬件）
2.4.4.2 随机失效指标计算公式
PMHF=∑λSPF + ∑λRF + ∑λDPF_det × λDPF_latent × TLifetime
●λSPF: 单点故障的失效率
●λRF: 残余故障的失效率
●λDPF_det: 双点故障的可探测失效率
●λDPF_latent: 双点故障的潜伏失效率
●TLifetime: 车辆生命周期
2.4.4.3 PMHF对应不同ASIL的要求
2.4.5 FMEDA
eg.MCU的FMEDA
●一般芯片厂商都会给出FMEDA表格，表里有失效率指标，失效模式分布等等
●在设计中，硬件指标要尽量远远小于ISO 26262的要求，这样对于其他器件更容易设计
2.4.6 指标计算示例
示例来源于下面这篇文章：
09 - 汽车功能安全(ISO 26262)系列: 硬件开发 - 随机硬件失效量化FMEDA - 知乎文章来源地址https://www.toymoban.com/news/detail-674105.html
下图为某ECU硬件设计图，针对其安全目标: ''当速度超过 10km/h 时关闭阀1的时间不得长于20 ms''。安全目标被分配为 ASIL C 等级。安全状态为：阀1打开(I61控制阀1)。
针对该安全目标，罗列所有硬件组件，如下表所示，根据FMEDA步骤1至4，分别查询硬件组件失效率，失效模式及分布比例，并计算相应的硬件度量指标。
例如， 对于控制芯片uc而言，其失效率为100 FIT，存在两种失效模式，其分布比例各占50%，只有第一种失效模式和安全相关，第二种失效模式则无需考虑。
由于安全机制SM4的存在，对该硬件组件第一种故障的诊断覆盖率为90%，该硬件组件
单点或残余故障失效率为：
由于安全机制SM4还能够对该故障进行探测，防止其成为潜伏故障，其诊断覆盖率为100%，则该硬件组件的双点潜伏故障失效率为：
除单点故障，残余故障及双(多)点潜伏故障，剩余的则是可探测双点潜伏故障，则硬件组件的双(多)点故障的可探测失效率为：
依此计算所有硬件组件的相关故障失效率，并进行如下统计：
则该ECU硬件整体概率化度量指标计算如下：
根据该安全目标ASIL C，判断其可知，除SPFM没有>=97%外，其他指标均满足相应安全要求，所以该硬件设计基本满足安全目标ASIL C等级需求。当然，也可以对硬件设计进行进一步优化，提高SPFM架构度量值。
2.5 硬件集成和测试
2.5.1 原则
①通过测试确保硬件符合硬件安全需求
②集成和测试应按照相应的ASIL等级采用不同方法进行验证
③集成测试活动应参照ISO 26262-8条款9开展
④集成测试活动应参考系统阶段所指定的计划开展
2.5.2 硬件集成和测试的验证方法
①为保证安全机制实现的完整性和正确性，采用测试方法验证：
②应当验证硬件抵抗外部应力的鲁棒性
————————————————————————
参考资料：
iso26262之2018版与2011版主要内容对比与分析…_汽车功能安全-商业新知
车规级 | ISO26262中对硬件安全性的定性和定量评估 - 知乎
EPB功能安全笔记(14)：FTA定量分析之ISO26262对随机硬件失效的要求 - 知乎文章来源：https://www.toymoban.com/news/detail-674105.html
09 - 汽车功能安全(ISO 26262)系列: 硬件开发 - 随机硬件失效量化FMEDA - 知乎
到了这里，关于ISO 26262系列文章之————5 硬件开发的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
