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

清轩轩

已于 2024-11-05 08:50:54 修改

阅读量1.8k

点赞数 32

分类专栏： Automotive Functional Safety 文章标签：汽车安全系统安全需求分析

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

本文链接：https://blog.csdn.net/qq_54112829/article/details/143479666

版权

Automotive Functional Safety 专栏收录该内容

6 篇文章

订阅专栏

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

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

上一篇文章汽车功能安全基础（四）——Part3概念阶段开发-CSDN博客提到了前两个部分内容，定义了功能安全研究的对象，即相关项，通过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、什么是FSC

2.1 定义

Functional Safety Concept（FSC）一般翻译为功能安全概念，FSC本质上是概念阶段所有开发工作进行系统化汇总后形成的工作输出产物。为了满足安全目标，FSC包括安全措施(含安全机制)。

那到底什么是安全措施（Safety Measure），和安全机制（Safety Mechanism）有什么区别呢？

2.2 安全措施与安全机制

安全措施：事前预防+事后补救，用来避免或控制系统性失效，随机硬件失效的技术解决方案的统称。
安全机制：其定义在第一篇汽车功能安全基础（一）——什么是功能安全？-CSDN博客
简单介绍过，大家可以简单过一下。意为事后补救部分，是安全措施的一部分，针对系统功能出现异常后，为探测，显示，控制故障所采取的措施。一般在系统阶段进行定义。

2.3 FSC的内容

只要是为保证相关项功能安全，所有在功能层面采取的解决方案都属于功能安全概念。一般来讲，一个完整的FSC应该包含以下主要内容:

1、SG，相关项及系统工作状态，模式；

2、每个SG下的FSR，定义FTTI（系统一旦违反安全目标，安全机制必须在容错时间间隔（FTTI）将系统转移到安全状态）；

3、安全状态（包括：关闭功能，功能降级，安全运行模式等），将FSR分配至架构。

3、什么是FTTI

3.1 定义

在安全机制未被激活情况下，从相关项内部故障发生到可能发生危害事件的最短时间间隔。

在故障容错时间间隔内，如果相关项保持在安全状态或过渡到安全状态或过渡到紧急运行，则表明安全机制及时对故障进行了处理。当诊断测试时间间隔比故障探测时间间隔足够短时，故障探测时间间隔可包括多个诊断测试时间间隔用于消除错误抖动。

3.2 如何确定FTTI

可以根据SG所对应的代表性危害事件（一般是ASIL等级最高的危害事件），通过对应运行场景定量或定性评估得到，包括历史数据，仿真计算，实际测试等。

在实际操作中，如果难以计算确定，可以根据经验对其进行预设，然后对代表性危害事件进行实车运行场景模拟，最后根据测试数据和安全确认指标（Validation Criteria）确定假设合理性。

对于ASIL等级较高的安全需求，理论上都应该进行车辆测试确认。

4、怎样从SG得到FSR

和上一章讲述的HARA过程相比，从安全目标到功能安全需求，也需要进行安全分析，区别在于：

安全分析的对象基于组件层级，非车辆或系统级别；
除了归纳演绎法（Inductive Analysis），还可以采取演绎（Deductive Analysis）分析方法。

4.1 FMEA与FTA

FMEA（Failure Mode and Effects Analysis, 即失效模式与影响分析）和FTA（Fault Tree Analysis, 即故障树分析）是归纳和演绎最具代表性的分析方法，也是功能安全开发最常用的安全分析方法。

简单聊聊它们的特点和区别吧：

FMEA	典型的归纳分析法：是从多个个别的事物中获取普遍的规则
	定性分析
	自下而上，从原因到结果，即从可能得故障原因，分析可能得危害结果
FTA	典型的演绎分析方法：从已知的定律经过逻辑推演得到新的定律的方法
	定性和定量分析，概念和系统阶段多样性分析
	自伤而下，从结构到原因，即从危害结果或事件，分析可能导致其产生的原因。

注意：FMEA在设计阶段一般指的是DFMEA（Design FMEA）。FMEA一般用于产品设计或工艺在真正实现之前，对其进行安全分析发现产品弱点，并优化改进，只包括事件预防。FTA自上而下，从结果到原因的分析方法和从SG到FSR的导出方向一致，操作更为便捷，更容易完整地识别故障原因和影响。

4.2 FTA操作步骤

步骤一：确定分析边界，(包括：分析对象，范围，抽象级别)。

步骤二：选择分析的故障，即顶部事件，通常将违反的安全目标（SG）作为FTA顶层事件。

步骤三：根据顶层事件，确认直接，必要和充分导致故障产生的原因，建立故障树，直至分析的最低抽象级别，即底层基本事件（对于FSR，一般为组件级别，如传感器，执行器，控制单元等）。

步骤四：根据底层基本事件，采取安全措施以消除相关故障路径，制定相应的FSR。

后续会单独出一篇关于安全分析的文章

5、FSR分配至系统架构

根据ISO 26262-3-2018要求，FSR必须分配至系统架构，作为FSC的重要组成部分。其主要目的在于：

将不同安全目标对应的安全需求及ASIL落实到架构中具体的软件或硬件组件当中去，进而确定不同组件开发对应的所有安全需求及最高ASIL等级要求，以便于后续系统，软件和硬件的进一步开发。
架构作为需求和具体软/硬件实现之间的桥梁，是基于模型的系统工程开发重要内容，能有效改善基于文本或文档开发的弊端，实现模型统一的管理，维护，及需求和测试的可追溯性，可验证性。

功能安全概念阶段开发我们介绍到这里，下期我们介绍功能安全系统阶段开发。