ISO26262 Functional Safety Concept(下)

Elektroauto
关注

第七章节的主要目的:

根据其安全目标明确相关项降级的功能行为;

明确适当的约束条件,及时的检测和控制相关的故障;

明确措施来实现容错,目的是减轻驾驶员或外部措施(可减轻危害的其他相关项)的影响;

将功能安全需求分配给系统架构设计或者外部措施;以及验证功能安全概念并且明确安全验证标准;

为符合安全目标,功能安全概念包含安全措施、包含对相关项要素实施的安全机制,以及功能安全需求中已明确的安全机制,见下面Figure3。

什么是安全措施?

为确保我们的架构安全所要遵循的一组活动。我们应该安全概念阶段说明这些措施,这些措施/活动包含安全机制。

什么是安全机制?

一种用达成安全合规水平的技术。有时候措施和机制互换使用。

ISO26262 Functional Safety Concept(下)

Figure3: Safety goal allocation on item's elements via allocation of FSRs

在上面的图片中,我们可以注意到,安全目标B和安全目标A具有共同的功能安全要求。
考虑到系统架构,功能安全需求应该从安全目标中导出。每个安全目标至少要导出一条功能安全需求。也就是说,不要把不必要的需求塞进FSC中,并且不要感到愧疚如果你的FSC文件中只有一个FSR来实现安全目标,这样就不会浪费时间了,我们可以继续向前进行。如果适用的话,FSR应明确下面九点策略:

fault avoidance;

faults detection;

transition to a safe state, and if applicable, from a safe state;

fault tolerance;

driver warnings to reduce risk exposure (E) time to an acceptable duration;

driver warnings to increase controllability ( go to lower C)by the driver;

the degradation of the functionality in the presence of a fault and its interaction with 5) or 7);

define fault handling time to meet Fault Tolerant Time Interval (FTTI);

avoidance/ mitigation of a hazardous event due to improper arbitration of multiple control request generated simultaneously by different functions;

战略只是整体的计划,我们还要善于将其分解成具体的战术,从而赢得战争的胜利。也就是说,我们要用FSR来实现我们的战略目的。

各功能安全需求应该考虑以下的5个限制条件来规定(如果适用的话):

1. Operation Modes;2. FTTI;3. Safe State;4. EOTI;5. Functional Redundant (e.g. Fault Tolerance);上面的陈述是说在适用的情况下,我们可以用上述的5个约束条件中的每一点来规定九点的每一个要求。最后,总结一下:我们讨论了HARA验证和功能安全概念阶段的准备,提供了:相关项定义、HARA报告和没有安全机制的系统架构。之后,我们讨论了功能安全要求的ISO 26262框架:要涵盖那些内容以及应该如何编写/约束。

本期的内容就分享到这里,我们下期再见啦!


声明: 本文由入驻OFweek维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。
侵权投诉

下载OFweek,一手掌握高科技全行业资讯

还不是OFweek会员,马上注册
打开app,查看更多精彩资讯 >
  • 长按识别二维码
  • 进入OFweek阅读全文
长按图片进行保存