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

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

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

目录

1、什么是概念阶段开发

2、相关项定义

3、概念阶段开发——HARA

3.1 什么是HARA

3.2 HARA流程

3.3 危害分析

3.3 评价危害事件的风险，即ASIL等级

3.4 安全目标

1、什么是概念阶段开发

汽车产品开发基于需求，需求是产品开发的基础，好的需求一定程度上会决定产品的性能和质量，对汽车功能安全开发也是同理。

在不同开发的阶段，需求根据细化程度可分为：

• 功能层面的需求：逻辑功能需求，细化至技术需求
• 技术层面的需求：技术可实施的需求，可直接转化为软硬件开发

功能安全概念阶段开发本质就是，在相对抽象的逻辑功能层面，通过安全分析提出功能安全开发最初的安全需求。因此，被称为概念阶段。

具体而言，就是通过对相关相所实现的功能进行危害分析和风险评估（HARA），导出功能安全开发最初安全目标（Safety Goal）以及功能安全需求（FSR）。

2、相关项定义

定义：实现整车层面功能或部分功能的系统或系统的组合。有item等于系统的，也有综合多个系统的item。

汽车功能安全基础（二）——基于ISO26262的功能安全Part1术语部分-CSDN博客

在术语部分提过，基本的就不在阐述。

注：作为后续危害分析和风险评估（HARA）的基础。

3、概念阶段开发——HARA

3.1 什么是HARA

定义：HARA（Hazard Analysis and Risk Assessment）为了避免不合理的风险，对相关项的危害事件进行识别和归类的方法以及定义防止和减轻相关危害的安全目标和ASIL等级的方法。

解释一下，就是根据相关项定义的功能，分析其功能异常表现，识别其可能的潜在危害（Hazard）及危害事件（Hazard Event），并对其风险进行量化（即确定ASIL等级），导出功能安全目标（Safety Goal）和ASIL等级，以此作为功能安全开发最初最顶层的安全需求。

3.2 HARA流程

•     功能1                            危害事件1                 危害事件1=>(ASILX)          安全目标1(ASILX)
•     功能2                            危害事件2                 危害事件2=>(ASILX)          安全目标2(ASILX)

3.3 危害分析

目的：分析整车功能层面的故障Malfunctioning behavior（不考虑故障原因） ，基于功能定义，推荐使用HAZOP方法，使用以下规定的引导词，分析每个功能的异常表现，推导故障行为对车辆造成的危害。

步骤一：利用HAZOP分析相关项所定义的系统层面功能异常表现(非组件层面，功能安全需求分析才基于具体组件功能)：

• 功能丧失：有需求时，不提供功能；(例如：车辆非预期加速）
• 预期功能提供错误：a.过大-超过预期

                                        b.过小-低于预期 

                                        c.方向相反-错误方向

• 非预期的功能：无需求时，提供功能；（例如：无加速请求，车辆确提供加速）
• 输出卡滞在固定值：功能不能按照需求更新；（例如:需要先加速后减速，车辆却一直提供加速）
• 功能未达到预期效果：（例如：车辆加速无法达到所需的速度）

例：车辆转向系统转向功能，根据HAZOP引导词分析，其功能异常表现有: 非预期转向，转向不足，过度转向等。

步骤二：整车危害 + 车辆运行场景 = 危害事件

• 结合不同的驾驶场景，形成具体的危害事件
• 运行场景即车辆运行环境，包括道路场景（例如：道路类型，路面附着情况等）和驾驶场景（运行情况和运行模式）
• 同一危害在不同的运行场景下，形成危害事件的严重性，出现的频率及对其危险的可控性不同，即ASIL等级不同

例：在高速公路上意外刹车（车速较快），路面湿滑，后面有车速相近的车辆跟随

例：车辆非预期转向这一危害，在不同车速下和道路环境下，可能和周边基础设施或人发生碰撞，可能和迎面驶来汽车碰撞，也可能发生侧翻等等，造成的伤害是不一样的，这也是为什么需要将危害量化为危害事件的重要原因。

危害分析注意事项：

• 危害和危害事件定义必须基于整车层面，（例如：车辆非预期加速）
• 只考虑将定义的相关项功能造成的危害并假设其他的相关项是正常工作的
• 不应考虑将要实施或已经在前代相关项中实施的安全机制，（例如：功能监控，硬件冗余）
• 需考虑相关项外部措施，（例如：其他相关项内的ESP，ABS，灭火器等）
• 功能失效和相应的危害之间的关系：多对一，一对多
• 需要考虑合理的误操作造成的危害，（例如：驾驶安全距离保持不够）

3.3 评价危害事件的风险，即ASIL等级

在第二篇汽车功能安全基础（二）——基于ISO26262的功能安全Part1术语部分-CSDN博客里已经介绍过如何通过以下三个参数，对危害事件的风险进行量化评估，从而确定ASIL等级，这里不在阐述。

• 严重度（Severity）

• 暴露度（Exposure）

• 可控度（Controllability）

需要注意以下内容：

• 严重度需要关注对人造成伤害的严重程度(非对物体的伤害)。不仅需考虑车内驾驶员乘客伤害，还需考虑外部环境中的人员，包括行人，其他车辆人员伤害等。
• 暴露度可基于持续运行时间占比或发生频率确定，不应考虑装备该相关项的车辆数量或占比
• 可控度可控性受多种因素影响，需驾驶员进行合理假设(例如健康，有驾照)，相对比较难量化，对于C2及C3基于一定样本的用户测试决定。
• 三个参数一般根据ISO 26262-3:2018附录并结合经验，统计数据，仿真，测试等确定。如果存在不确定性，可以适当考虑取较大的值。
• 不同企业对同一危害事件的风险量化，即三个参数数值确定，可能不都是相同的，审核的重点在于有理有据，合理即可。

3.4 安全目标

危害事件的反面即为安全目标，其中：

• 为了避免每个危险事件的不合理风险，应将危险事件的 ASIL 分配给安全目标；
• 安全目标是相关项最高层面的安全要求；
• 安全目标不表述为技术解决方案，而表述为功能目的；
• 如果所确定的安全目标是类似的，可将其合并为一个安全目标，以此降低工作量；
• 若导出的安全目标存在相似，可对其进行合并，并继承其中最高的ASIL等级；
• 一个安全目标可能与几种危害有关，几个安全目标可能与一种单一的危害有关。

例：危害事件：汽车在弯路道路上行驶时，突然转向失灵。        

       安全目标：防止转向突然失灵。

下一篇我们介绍：概念阶段开发第三部分内容: 功能安全概念(FSC)，即，根据安全目标，导出功能安全需求FSR，系统化地形成功能安全方案FSC。