汽车功能安全基础（五）——Part3概念开发阶段

原创

已于 2024-11-05 08:50:54 修改 · 2.3k 阅读

24 ·

CC 4.0 BY-SA版权

文章标签：

#汽车 #安全 #系统安全 #需求分析

于 2024-11-04 16:52:55 首次发布

ISO 26262基于V模型，汽车功能安全开发活动始于概念阶段，该阶段主要包括以下内容：

相关项定义（Item Definition），即定义研究的对象
危害分析和风险评估（HARA），即导出安全目标及ASIL等级
概念阶段开发内容（FSC），即形成系统化概念阶段工作方案输出

上一篇文章汽车功能安全基础（四）——Part3概念阶段开发-优快云博客提到了前两个部分内容，定义了功能安全研究的对象，即相关项，通过HARA过程，对相关项的功能进行系统级别的安全分析，导出危害事件并量化其风险（ASIL），最终得到功能安全目标（SG）及其ASIL等级，作为整个功能安全研究最初的安全需求。

本篇文章主要介绍功能安全概念第三部分概念阶段的第三个部分的内容：概念阶段开发内容（FSC）

1、什么是FSR

定义：功能安全目标(SG)属于基于车辆或系统级别的安全需求，过于抽象，我们需要将其进行细化，得到为满足安全目标，基于组件级别的相对比较具体的，但依旧还是基于功能层面的逻辑功能需求，这个就是FSR。

根据ISO 26262，功能安全需求应遵从以下几点，作为FSR：

故障避免，是指减少故障发生的措施；
故障探测，是指对故障或其导致的功能异常表现的控制；
故障容错，是指是指在属于特定故障集的故障发生后，至少在有限时间内提供特定功能的能力；
故障情况下的功能降级（例如，跛行回家）；
如果适用，从一个安全状态过渡到另一个安全状态；
为将风险暴露时间缩短至可接受的持续时间，并提高驾驶员的可控性所需要的驾驶员警告。（例如发动机功能异常指示灯，ABS故障报警灯）；
如何满足车辆层面的时间要求，即如何定义故障处理时间间隔来满足故障容错时间间隔；
避免或减轻因不当仲裁了不同功能同时产生的多个控制请求而导致的危害事件。

总结来说，可以从以下两个角度来理解FSR：

一：从设计出发，为尽可能避免系统中软件和硬件相关失效，系统组件应实现或具备哪些功能。

二：如果系统发生失效，应及时探测，显示并控制故障，尽早给驾驶员警示故障，使驾驶员有所干预，控制车辆系统进入一个安全状态，防止或减轻伤害产生。

注意：

针对每个SG，应该至少导出一个FSR。
FSR本质是需求，一般是甲方（主机厂）对供应商提出的安全要求，只考虑为满足安全目标及ASIL等级，系统应该怎么正常工作，不涉及具体的技术实现方式。
FSR应该继承对应安全目标的ASIL等级。如果存在ASIL等级分解，则需要遵循ISO 26262-9:2018中独立性（Independence）要求。(注意独立性和免于干扰(FFI)的区别）
FSR本质是需求，一般是甲方(主机厂)对供应商提出的安全要求，只考虑为满足安全目标及ASIL等级，系统应该怎么正常工作，不涉及具体的技术实现方式。
如果FSR涉及事后补救措施，则该FSR需要定义相应的安全状态，故障容错时间间隔（如果安全状态需要过渡，还需定义紧急运行时间间隔）。很多朋友搞不清楚到底这些东西属不属于安全需求。
FSR需要分配至系统架构，并作为FSC的组成部分。

2、什么

最低0.47元/天解锁文章