技术博客
首页 所有文章 标签 分类 关于
技术博客

目录

2023-04-08-ISO-26262系列文章之5-硬件开发

 收录于 未分类
   约 4745 字   预计阅读 10 分钟 
https://bing.ee123.net/img/rand?artid=129947699

ISO 26262系列文章之————5 硬件开发

目录

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的交互

https://i-blog.csdnimg.cn/blog_migrate/fc18001c7c2f6daa150b09b65e90c969.png

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为 https://latex.csdn.net/eq?1*10%5E%7B-9%7D /小时，例如: 某电阻失效率λ=2 FIT，即该电阻在10^9 h内存在两次失效。

A.14 PPM

part per million，百万分之一，为 https://latex.csdn.net/eq?10%5E%7B-6%7D

A.15 ISO 26262-2018与 ISO 26262-2011在part5的文档的差异性

序号part20182011备注
15：产品开发在硬件层面“安全计划”位于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-2018ISO 26262-2011分析
part5：产品开发在硬件层面part3：产品开发在硬件层面
章节名称具体内容章节名称具体内容
///5-5启动硬件层面产品开发5.5安全计划删除旧版章节
5-10硬件集成和测试10.5.1硬件集成和验证规范5-10硬件集成和测试/新版新增1项工作成果

1 硬件开发流程

1.1 与传统硬件设计的区别点

●硬件架构度量的评估

●随机硬件失效违背安全目标的评估

1.2 ISO 26262 中硬件开发流程

https://i-blog.csdnimg.cn/blog_migrate/29b20518f51b372b70ac3317b44df3bb.png

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 验证的方法

①验证安全要求的方法

https://i-blog.csdnimg.cn/blog_migrate/29e431f22eabbb80e76c5205ffeb8663.png

②验证硬件设计与硬件安全需求的一致性和完整性方法

https://i-blog.csdnimg.cn/blog_migrate/d5840aea7605df1cddf8a1274e903485.png

2.2 硬件设计

●根据系统设计规范和硬件安全需求进行硬件设计

●硬件设计包括硬件架构设计和硬件详细设计

2.2.1 硬件架构设计

2.2.1.1 设计要点

①表示出所有硬件组件及彼此的关联

②硬件安全需求和实现之间的可追溯性

③考虑复用、考虑非功能因素，如无关功能的硬件也需考虑对于功能安全和可靠性存在潜在的影响

2.2.2 硬件详细设计

2.2.2.1 设计要点

①原理图级别、表示出构成组件的零部件的关联

②确保硬件零部件在环境和操作规范下的使用

③考虑鲁棒性设计原则

2.3 硬件架构度量的评估

2.3.1 硬件量化指标分类

https://i-blog.csdnimg.cn/blog_migrate/2a71e50c41d9318e3e7fa95f7e7c49d6.png

2.3.2 硬件架构指标的定义

2.3.2.1 架构中关于硬件要素的计算公式

①假设所有的失效都是互相独立的，且按照指数分布，计算公式如下：

https://i-blog.csdnimg.cn/blog_migrate/ff6f60869bd87d142fef7e3bf0edcab8.png

②指标定义：

指标名称计算公式
单点故障指标（SPFM）●SPFM=1 - (单点故障总和+残余故障总和) / (所有和安全相关失效率总和) 3f63e4218c5042eab5e347968816dae5.png \lambda _{RF,est}=\lambda*\left ( 1-\frac{\lambda _{DC,RF}}{100} \right ) —λSPF: 单点故障失效率 —λRF,est: 估算的残余故障的失效率 —λDC,RF: 残余故障的诊断覆盖率
潜伏故障指标（LFM）LFM=1 - (所有潜伏故障总和) / (所有和安全相关失效率总和 - 单点故障总和 - 残余故障总和) b5415db69bc64dfabb0e9efdf7e1c403.png —λMPF,L,est: 潜伏故障的估算的失效率 —λDC,MPF,L: 潜伏故障的诊断覆盖率

③架构指标

其中，可信设计：是指在批量量产后该设计已达到目标值要求的设计

https://i-blog.csdnimg.cn/blog_migrate/a4d7feaee9446f38ab7ed39514147b29.png

④SPFM及LFM对应不同ASIL的要求

20aaa264bdd84187ade47cab9d9b6587.png

⑤指标计算方法

方法一：FTA①先利用FTA进行定性分析，如下图所示，得到顶事件的失效原因 47513ed7314b44ae8d7a13ba59f2ac4e.png ②再对每个故障进行定量分析，将每个故障的失效值加进去，如下图所示，最后再一层一层推算，最后算出顶事件的失效率，可以通过软件计算该值 f285eb26860f4d47a381d10247e554d3.png
方法二：元器件计数法●源自可靠性预计方法 ●计算公式： 2fa2185e6a2e48698548692fc5313a32.png 该值计算出来肯定偏大，偏大都能满足，那么肯定满足设计要求

2.4 随机硬件失效违背安全目标的评估

2.4.1 安全相关的故障类型

故障类型说明
单点故障λSPF●该故障能直接违反安全目标，且硬件元素中没有其他安全机制，导致无功能
残余故障 λRF●安全机制无法覆盖的那部分故障(没有100%覆盖率的安全机制，如果一个安全机制覆盖率为90%，那剩余的10%则属于残余故障) ●该故障能直接违反安全目标，硬件元素中至少有一个安全机制 ●eg.硬件要素可以有“开路”，“对地短路”，“短路接高”故障，但只有“开路”，“对地短路”的故障被安全机制所覆盖，如果“短路接高”故障导致违背了特定安全目标，且没有安全机制所覆盖，那么就是一个残余故障
双点（多点）故障 λDPF●与其他独立故障可以联合导致多点失效的单个故障（单个故障不会违反安全目标，但是多个单点故障联合后导致违反安全目标的故障） ●多点故障又细分为可探测的双点故障、可感知的双点故障以及潜伏的双点故障
潜伏多点故障 λDPF_latent●在多点故障检测时间间隔不能被安全机制检测出来的也不能被驾驶员识别的多点故障
安全故障 λS●不会显著增加违反安全目标可能性的故障，例如某指示灯显示故障，但不影响其正常功能 ●三点及以上的故障通常也被认为是安全故障(一般发生概率较低且所对应的安全机制过于复杂，所以归类为安全故障
可感知故障 λLF●在规定的时间间隔内可由驾驶员推断出其存在的故障（可察觉的车辆故障，如发动机故障无动力）
多点可探测故障 λDPF_det●在规定的时间内通过安全机制检测出的故障，如仪表报警灯叫可探测故障 ●除单点故障，残余故障及双(多)点潜伏故障，剩余的则是可探测双点潜伏故障，公式为： λDPF_det=λ*失效分布比例-λSPF/RF-λDPF_latent

https://i-blog.csdnimg.cn/blog_migrate/c2d0fd54413c5cce4f48e9921a3cd091.png

2.4.2 硬件失效模式分类流程图 0e53a4f3cb904372a605418156f5b9a4.png

2.4.3 硬件失效率

2.4.3.1 失效模式分布和失效率计算（单个硬件组件）

可靠度●元件在时刻t完成功能的概率 790748a7a1554f328744c316c61c4edd.png
失效率●在时间（t， gif.latex?%5Cdelta%20t ）之间失效的元件个数和在t时刻没有失效的元件个数的比值 b6619a8161984b46ae86d2995d8867f1.png ●失效率依赖于很多因素，元件失效率计算公式如下： c8a0c3c23fee430a9a31ec7236977b44.png
R(t)与λ(t)关系48eb3e0cefdb458fae6d3ce18a2c1872.png
失效曲线●浴盆曲线： —大多数产品的失效率随时间变化的曲线形似浴盆 —分为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 随机失效指标（整个相关硬件）

https://i-blog.csdnimg.cn/blog_migrate/5b6efa816d7c659e7141b0d238ddcbf7.png

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的要求

f7c9f486c9f74c939bed178917724ad1.png

2.4.5 FMEDA

eg.MCU的FMEDA

●一般芯片厂商都会给出FMEDA表格，表里有失效率指标，失效模式分布等等

●在设计中，硬件指标要尽量远远小于ISO 26262的要求，这样对于其他器件更容易设计

https://i-blog.csdnimg.cn/blog_migrate/c56803a3d5abc31e624f857ac46d9c6e.png

2.4.6 指标计算示例

示例来源于下面这篇文章：

下图为某ECU硬件设计图，针对其安全目标: ‘‘当速度超过 10km/h 时关闭阀1的时间不得长于20 ms’’。安全目标被分配为 ASIL C 等级。安全状态为：阀1打开(I61控制阀1)。

https://i-blog.csdnimg.cn/blog_migrate/cc87dac2c0459164cfe5957ccaddf2b8.png

针对该安全目标，罗列所有硬件组件，如下表所示，根据FMEDA步骤1至4，分别查询硬件组件失效率，失效模式及分布比例，并计算相应的硬件度量指标。

https://i-blog.csdnimg.cn/blog_migrate/09def7173706f5d453c4226b96d28398.png

例如， 对于控制芯片uc而言，其失效率为100 FIT，存在两种失效模式，其分布比例各占50%，只有第一种失效模式和安全相关，第二种失效模式则无需考虑。

由于安全机制SM4的存在，对该硬件组件第一种故障的诊断覆盖率为90%，该硬件组件

单点或残余故障失效率为：

https://i-blog.csdnimg.cn/blog_migrate/0fbe13858c96baf8002f7efcc926067b.png

由于安全机制SM4还能够对该故障进行探测，防止其成为潜伏故障，其诊断覆盖率为100%，则该硬件组件的双点潜伏故障失效率为：

https://i-blog.csdnimg.cn/blog_migrate/7e4de17a969a479281df0f383e55c692.png

除单点故障，残余故障及双(多)点潜伏故障，剩余的则是可探测双点潜伏故障，则硬件组件的双(多)点故障的可探测失效率为：

https://i-blog.csdnimg.cn/blog_migrate/9a658342cc05e1bf29a690f3a0817c90.png

依此计算所有硬件组件的相关故障失效率，并进行如下统计：

https://i-blog.csdnimg.cn/blog_migrate/9ae219602778fdea59bcf114b656a699.png

则该ECU硬件整体概率化度量指标计算如下：

https://i-blog.csdnimg.cn/blog_migrate/f6ceefe371a4323b205b9d7093576109.png

根据该安全目标ASIL C，判断其可知，除SPFM没有>=97%外，其他指标均满足相应安全要求，所以该硬件设计基本满足安全目标ASIL C等级需求。当然，也可以对硬件设计进行进一步优化，提高SPFM架构度量值。

2.5 硬件集成和测试

2.5.1 原则

①通过测试确保硬件符合硬件安全需求

②集成和测试应按照相应的ASIL等级采用不同方法进行验证

③集成测试活动应参照ISO 26262-8条款9开展

④集成测试活动应参考系统阶段所指定的计划开展

2.5.2 硬件集成和测试的验证方法

①为保证安全机制实现的完整性和正确性，采用测试方法验证：

https://i-blog.csdnimg.cn/blog_migrate/2316e4592961a4dd685d9b4354b97a8d.png

②应当验证硬件抵抗外部应力的鲁棒性

https://i-blog.csdnimg.cn/blog_migrate/fadb5316f1cf558d71e6630767f45191.png

————————————————————————

参考资料：

68747470733a2f2f626c6f672e:6373646e2e6e65742f77656978696e5f34323031323134392f:61727469636c652f64657461696c732f313239393437363939

更新于 2023-04-08
 服务器, 运维
返回 | 主页