您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
【功能安全】硬件架构度量
 
作者:凯文说车
  211  次浏览      8 次
2024-12-11
 
编辑推荐:
本文主要介绍了硬件架构度量相关内容。希望对您的学习有所帮助。
本文来自于微信公众号凯文的汽车之旅,由火龙果软件Linda编辑、推荐。

01 硬件架构度量介绍

GBT 34590 2022 part5

这张图很好的展示了硬件架构度量中关于硬件要素失效模式的关系,此外提到了单点故障度量(SPFM)和潜伏故障度量(LFM)

不同ASIL等级对于硬件指标的要求,可以看到ASIL A是无要求的哈;

三个硬件指标的含义

LFM (Latent-fault metric) :潜在故障度量指标。这是用来量化硬件元素中潜伏故障部分的鲁棒性,通常用于评估系统在面对潜在故障时的安全性。

SPFM (Single-point fault metric) :单点故障度量指标。这是用来衡量单个故障源对系统安全目标的影响,通常用于评估单个故障源导致系统失效的概率。

PMHF (Probabilistic Metric for Random Hardware Failures) :随机硬件失效率。这是衡量设备在其运行寿命期间因随机硬件故障而导致系统失效的概率目标值,是功能安全分析中的一个重要指标。

硬件架构度量的目的

要点1:硬件架构度量,可以作为ASIL等级是否通过的准则;

要点2:硬件架构度量,可以评估实际上的安全机制是否足以解决掉单点或残余故障风险,也就是覆盖率是否足够;

要点3:硬件架构度量,可以评估实际上的安全机制是否足以解决掉潜伏故障风险,也就是覆盖率是否足够;

硬件架构度量的目标总结的话如下:

几个关键目标:

评估硬件架构对单点故障和残余故障的防护能力:通过单点故障度量(SPFM)和潜伏故障度量(LFM),硬件架构度量可以显示用于防止硬件架构中单点或残余故障风险的安全机制的覆盖率是否足够。高SPFM和LFM值表明系统对这些故障的防护能力强,从而提高系统的可靠性和安全性。

支持最终设计评估:硬件架构度量可以在硬件设计完成后进行安全评估,以验证硬件架构对随机硬件失效的有效性,并补充对违背安全目标的评估。这些度量指标是可核实的,并且足够精确以区分不同的架构。

提供ASIL等级合格/不合格准则:硬件架构度量用于确定硬件架构是否符合特定的ASIL(Automotive Safety Integrity Level)等级要求。如果不符合,需要优化硬件设计,增加新的安全机制或采用更高诊断覆盖率的安全机制。

确保硬件架构的鲁棒性:硬件架构度量关注的是整体硬件而非单个部件,因此需要考虑所有相关硬件的失效率。通过这些度量,可以确保硬件架构在面对各种故障模式时具有足够的鲁棒性。

处理故障风险:硬件架构度量通过计算单点故障、残余故障和潜伏故障失效率,以及相应的度量指标,帮助识别和处理可能导致安全目标违背的故障风险

输入输出

 

单点故障度量SPFM

参考(AUTO世代)

单点故障度量(Single-Point Fault Metric, SPFM)是用于评估硬件架构对单点故障和残余故障的鲁棒性的重要指标。该度量反映了通过安全机制覆盖或设计手段实现的对单点故障和残余故障的防护能力。较高的单点故障度量值意味着相关硬件中单点故障和残余故障的比例较低,从而系统可靠性较高。

单点故障度量的计算公式为:

在实际应用中,单点故障度量通常用于评估硬件架构在满足特定安全目标(如ASIL B、C、D等级)时的安全性。例如,对于ASIL B等级的安全目标,单点故障度量应达到至少90%。如果计算结果低于此标准,则需要采取额外的安全措施来提升单点故障度量值。

此外,单点故障度量不仅关注硬件失效的频率,还涉及诊断覆盖率和安全机制的有效性。因此,在计算过程中,通常会考虑安全机制的覆盖率以及是否能够有效检测和隔离故障

潜伏故障度量LFM

潜伏故障度量(Latent Fault Metric, LFM)是衡量硬件系统对潜伏故障的鲁棒性的重要指标。潜伏故障指的是那些未被发现且未被诊断出的故障,这种故障可能允许另一个故障发生并导致系统违背安全目标。潜伏故障度量反映了硬件设计和安全机制在防止潜伏故障方面的有效性。

潜伏故障度量值越高,表示系统中潜伏故障的比例越低,系统的可靠性越高。对于ASIL B、C和D等级的安全目标,潜伏故障度量通常需要达到一定的标准值,例如ASIL B要求潜伏故障度量应≥60%。

潜伏故障度量不仅关注单个硬件元件的失效率,还需要考虑整个系统的安全机制覆盖率以及诊断覆盖率。例如,如果某个硬件元件的潜伏故障失效率较高,但其诊断覆盖率也较高,则可以有效降低潜伏故障的发生概率。

此外,潜伏故障度量还涉及对多点故障的处理。多点故障中的可探测双点故障和潜伏双点故障都需要特别关注,因为它们可能成为潜伏故障的重要来源。

潜伏故障度量的计算公式通常为:

参考(AUTO世代)

可以看到故障度量是从ASIL B开始有要求,对于ASIL A指标要求;

硬 件 元 器 件 失 效 率 和 失 效 模 式 分 布 的 业 界 公 认 的 来 源 包 括 SN29500、IEC61709、MILHDBK217Fnotice2、RIAC HDBK217Plus、UTEC80-811、NPRD—2016、EN50129:2003AnnexC、RIAC FMD—2016、MILHDBK338和FIDESguide2009EdA。例如,能使用由“AlessandroBirolini-可靠性工程”定义的失效模式分布。

SN29500数据库进行计算硬件架构度量

02 硬件架构度量相关说明

硬件故障可以是系统失效也可以是随机硬件失效

随机硬件故障无法消除。它们源于所有电子系统最终都会失效的事实。

硬件要素失效模式

关系说明:

单点故障:指一个硬件要素发生故障,直接导致违背安全目标,且没有任何安全机制来预防其某些故障违背安全目标。

残余故障:指单点故障中未被安全机制完全覆盖的部分,即该部分故障可能导致违背安全目标,但可以通过安全机制预防。

可探测的双点故障:指两个独立硬件故障同时发生才会违背安全目标,并且这些故障可以被安全机制探测到。

可感知的双点故障:与可探测的双点故障类似,但这种故障在发生时能够被用户感知到。

潜伏的双点故障:指两个独立硬件故障同时发生才会违背安全目标,但这些故障既不能被安全机制探测也不能被驾驶员感知。

安全故障:指不会显著增加违反安全目标概率的故障,通常是指三点及以上的多点故障,或者与安全目标违背无关的故障

既然提到了失效,也再讲一下失效、故障、错误之间的关系

失效模式

硬件要素故障分类

不同ASIL等级的硬件失效度量指标

Bathtub 曲线是随机硬件故障的经典表示

这个截图来自可靠性工程手册截图,文档可在这里获取https://t.zsxq.com/CZoC4

截取相关内容截图如下

03 硬件架构度量示例

示例,在附录E就很详细介绍了如何计算单点故障度量和潜伏故障度量,这里大家就去看原文吧;没有GBT 34590 2022原文的在这个链接下载 https://t.zsxq.com/7691w

举一些怎么用这个公式的案例大家看一下

示例1:SPFM案例

SPFM(Single-Point Fault Metric)是用于评估系统中单点故障和残余故障对系统安全目标影响的指标。它通过计算1减去单点故障和残余故障占总故障的比率来确定系统的安全性。具体来说,SPFM的计算公式如下:

SPFM=1−∑(λSPF+λRF)∑(λ)SPFM=1−∑(λ)∑(λSPF+λRF)

其中:

λSPFλSPF 是单点故障失效率。

λRFλRF 是估算的残余故障的失效率。

λλ 是所有和安全相关失效率总和。

举例来说,假设一个系统的总失效率∑(λ)∑(λ) 为1000,其中单点故障失效率∑(λSPF)∑(λSPF) 为200,残余故障失效率∑(λRF)∑(λRF) 为50。那么,SPFM的计算如下:

这意味着该系统的SPFM为75%,表示有25%的故障是单点故障或残余故障,系统在这些情况下的安全性较低。

通过这种方式,SPFM可以帮助设计者识别和优化系统中的潜在故障点,从而提高系统的整体安全性

LFM举例

假设一个系统有以下故障数据:

单点故障总和:0.05

残余故障总和:0.03

潜伏故障总和:0.02

所有安全相关失效率总和:0.10

根据上述公式,LFM的计算如下:

这意味着在这个例子中,系统的潜伏故障度量为0,即系统对潜伏故障的防护能力非常低。

示例2:参考https://nandigits.co/gof_display_doc.php?document_type=fusa

示例3:参考贫困潦倒的资本家

7.单点故障率与潜伏故障率计算

 

 

潜伏故障率计算

失效率求和=0.109+0.109+1.616+3=4.943

单点故障率求和=0.0327+1.24432+2.7+0.3=4.27702

残余故障率求和=0.0003597*2=0.0007194

则SFM=1-(4.27702+0.0007194)/4.943=13.469%

04 硬件架构度量模板

模板

 

   
211 次浏览       8
相关文章

一文了解汽车嵌入式AUTOSAR架构
嵌入式Linux系统移植的四大步骤
嵌入式中设计模式的艺术
嵌入式软件架构设计 模块化 & 分层设计
相关文档

企点嵌入式PHP的探索实践
ARM与STM简介
ARM架构详解
华为鸿蒙深度研究
相关课程

嵌入式C高质量编程
嵌入式操作系统组件及BSP裁剪与测试
基于VxWorks的嵌入式开发、调试与测试
嵌入式单元测试最佳实践

最新活动计划
C++高级编程 12-25 [线上]
白盒测试技术与工具实践 12-24[线上]
LLM大模型应用与项目构建 12-26[特惠]
需求分析最佳实践与沙盘演练 1-6[线上]
SysML建模专家 1-16[北京]
UAF架构体系与实践 1-22[北京]
 
 
最新文章
物联网安全概述
史上最详细的区块链技术架构分析
一文读懂区块链整体架构及应用案例
区块链技术架构
安全架构评审实战
最新课程
Web应用安全架构、入侵检测与防护
物联网关键技术、安全与边缘计算
区块链安全技术实践指南
云服务与安全架构
互联网安全开发方法与实践
成功案例
中国银行 信息安全技术及深度防御
北京 Web应用安全架构、入侵检测与防护
某财税领域知名IT服务商 Web安全测试
普瑞克斯 web安全设计、测试与优化
北京和利时 性能和安全性测试