编辑推荐: |
本文主要介绍了【功能安全】硬件设计相关内容。希望对您的学习有所帮助。
本文来自于微信公众号凯文的汽车之旅,由火龙果软件Linda编辑、推荐。 |
|
01 硬件设计介绍
GBT 34590 PART5硬件设计部分内容






硬件设计需满足硬件安全要求HSR和接口规范HSI

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

输入与输出


02 硬件架构设计介绍
硬件架构设计
要求1:硬件架构应该包括硬件安全要求的内容;
要求2:硬件安全要求分配给对应的硬件安全要素的时候,应该考虑共存失效原则,举例,如果低等级的硬件安全要素失效容易引起高等级的硬件安全要素失效,则低等级的硬件安全要素的等级要求应该满足最高等级的硬件安全要素;

要求3:可追溯性:硬件安全要素与硬件安全架构之间的追溯性,应到硬件组件的最底层。(不要深入到硬件详细设计,如电容和电阻的设计)
说明:硬件组件指的是硬件设计中的各个功能单元或模块,比如处理器、内存模块、通信接口、功率管理单元等。
不需要深入到详细设计:例如,虽然电路图中每个电阻、电容等基础元器件都可能影响电路的功能,但从硬件安全要求的角度,通常不会要求对每个单独的电阻、电容等元件建立严格的可追溯性。通常会集中于更大的模块或硬件组件(如处理器、存储单元、电源管理单元等)。
要求4:硬件架构设计原则

要求5:在硬件架构设计规范编写时,除了关注硬件安全要素外,对于硬件相关的非功能要素(如振动、温度等)也需要关注;

参考AUTO世代

ASIL等级分解可参考【功能安全】ASIL等级分解
大概流程



03 硬件详细设计介绍
对硬件详细实现设计而言:
• 为了避免常见的设计缺陷, 可运用相关的经验总结。
• 在硬件详细设计时, 应考虑安全相关硬件元器件失效的非功能性原因, 可包括以下的影响因素:温度、振动、水、灰尘、电磁干扰、噪声因素、来自硬件组件的其他硬件元器件或其所在环境的串扰。
• 硬件详细设计中, 硬件元器件的运行条件应符合它们的环境和运行限制规范。
• 应考虑鲁棒性设计原则。

非功能性要求举例:
HSR :器件、PCBA、外壳具备可追溯性
04 硬件安全分析
硬件安全分析的方法论

硬件安全分析

要点1:对于每个安全相关的硬件组件或元器件,针对所考虑的安全目标,安全分析应识别以下内容图片
part10关于单点故障、残余故障、多点故障点定义描述







上述故障之间的关联汇总图

单点故障
|
| (直接导致违背安全目标)
v
残余故障
|
| (未被安全机制完全覆盖,可能导致违背安全目标)
v
可探测的双点故障
|
| (需要与另一个独立故障联合才能导致违背安全目标,且能被安全机制探测到)
v
可感知的双点故障
|
| (需要与另一个独立故障联合才能导致违背安全目标,且能被驾驶员感知到)
v
潜伏的双点故障
|
| (需要与另一个独立故障联合才能导致违背安全目标,但不被安全机制或驾驶员感知到)
v
安全故障
|
| (不会显著增加违背安全目标的概率,即使发生也不会导致违背安全目标)
|
关系说明:
单点故障:指一个硬件要素发生故障,直接导致违背安全目标,且没有任何安全机制来预防其某些故障违背安全目标。
残余故障:指单点故障中未被安全机制完全覆盖的部分,即该部分故障可能导致违背安全目标,但可以通过安全机制预防。
可探测的双点故障:指两个独立硬件故障同时发生才会违背安全目标,并且这些故障可以被安全机制探测到。
可感知的双点故障:与可探测的双点故障类似,但这种故障在发生时能够被用户感知到。
潜伏的双点故障:指两个独立硬件故障同时发生才会违背安全目标,但这些故障既不能被安全机制探测也不能被驾驶员感知。
安全故障:指不会显著增加违反安全目标概率的故障,通常是指三点及以上的多点故障,或者与安全目标违背无关的故障

要点2:应具备实施的安全机制对防止导致单点失效的故障或减少残余故障的有效性的证据;


要点3:应具备实施的安全机制对防止潜伏故障的有效性的证据。


要点4:进行相关失效分析,提供证据证明设计中的硬件要素与它们的独立性要求相符合【功能安全】相关失效分析DFA
part9 附录C示例

要点5:如果硬件设计引入了新的危害,而没有进行HARA再分析,则变更管理流程对它们进行引入和评估;(TARA分析类似在风险管理中,以年度为单位更新TARA分析报告)
05 硬件设计示例
以BMS硬件设计需求为例














06 硬件设计模板
模板示例:

软件详细设计示例
1、JTAG
1.1硬件需求输入
1.2关联的经验教训
1.3模块原理图
1.4组件详细设计描述
1.5硬件详细设计说明
1.5.1电路设计
1.5.2WCCA计算及其仿真
1.6元器件选型
1.7接口定义
|