聊聊功能安全概念开发阶段基本问题及内容的学习心得

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

相关项定义(Item Definition)，即定义研究对象

危害分析和风险评估(HARA)，即导出安全目标及ASIL等级

功能安全方案开发(FSC)，即形成系统化概念阶段工作方案输出

该阶段内容将会分两篇文章进行阐述，后续会考虑出专门实例阐述。

本篇着重聊以下内容:

什么是概念阶段开发

概念阶段开发内容 - 相关项定义

概念阶段开发内容 - HARA

01

什么是概念阶段开发？

很多朋友可能疑惑，为啥它叫概念阶段，听着好像很不专业，接下来我们来看它的本质。

汽车产品开发基于需求，需求是产品开发的基础。好的需求一定程度直接决定产品性能和质量，对汽车功能安全开发也不例外。

我们所熟知的功能实现的需求多源于用户需求，而功能安全开发的需求源于功能实现部分。

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

功能层面的需求: 相对抽象的逻辑功能需求(就是大爷大妈们也能看得懂)，需细化至技术需求

技术层面的需求: 技术可实施的需求，可直接转化为软硬件开发

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

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

02

概念阶段开发 - 相关项定义

相关项定义的本质为确定功能安全研究的对象，内容比较简单，方便理解直接上个人理解公式:

相关项 = 结构 + 功能描述 + 对象属性特征

结构: 研究对象是什么，由哪些系统及组件构成，一般采用UML或SysML结构视图表达(实在不行就上PPT)。

功能描述: 研究对象实现了哪些系统级别的功能，是后续危害分析和风险评估(HARA)基础。

对象属性特征: 对象预期的功能危险，内部以及对外依赖关系(以接口体现)，相关法律法规。

注: 可对相关项进行裁剪，复用类似相关项工作输出产物，以此降低产品开发周期和成本。

03

概念阶段开发 - HARA

3.1 什么是HARA

简单来说，HARA(Hazard Analysis and Risk Assessment)是在概念阶段为导出功能安全目标及其ASIL等级的系统安全分析方法。

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

3.2 HARA流程

话不多说，直接上图:

接下来，分别看看各流程中关键内容及心得:

3.2.1 危害分析

目的: 利用安全分析方法(例如FMEA，HAZOP)，对相关项定义的功能进行分析识别危害和危害事件。

方法:

FMEA故障识别部分和HAZOP(Hazard and operability analysis)无本质区别，流程基本类似。   一般来说，HAZOP操作更为简单，多用于功能安全概念阶段识别相关项功能存在的潜在危害及危害事件。  

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

HAZOP基于定义的功能，使用以下规定的引导词，分析每个功能的异常表现：

功能丧失: 在有需求时，不提供功能；

   (如车辆非预期加速)

在有需求时，提供错误的功能：

      ‒ 错误的功能: 多于预期；        (如车辆加速大于驾驶员需求)       ‒ 错误的功能: 少于预期；        (如车辆加速小于驾驶员需求)       ‒ 错误的功能: 方向相反；        (如驾驶员要求加速，车辆出现减速)

非预期的功能: 无需求时，提供功能；

(如驾驶员无加速需求，车辆提供加速度)

输出卡滞在固定值上: 功能不能按照需求更新。

(如驾驶员需先加速后减速，车辆一直提供加速)

注: 对每个功能分析不一定会用到所有引导词，可对其进行裁剪。

功能异常分析举例: 

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

步骤二: 将危害和运行场景结合，形成危害事件

危害 + 运行场景 = 危害事件

危害是抽象的可能性，不可量化，需结合不同运行场，形成具体的危害事件

运行场景即车辆运行环境，包括道路场景(例如道路类型，路面附着情况等)和驾驶场景(运行状态，车速等)。J2980提供了场景分类参考，分析中需确保危害最大化化的运行场景。

同一危害在不同的运行场景下，形成危害事件的严重性，出现的频率及对其危险的可控性不同，即ASIL等级不同

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

危害分析注意事项及约束:

1

危害和危害事件定义必须基于整车层面，例如危害:非预期的车辆加速

2

只考虑将定义的相关项功能造成的危害并假设其他相关项正常工作

3

不应考虑将要实施或已经在前代相关项中实施的安全机制，例如功能监控，硬件冗余等

4

需考虑相关项外部措施，例如其他相关项内的ESP，ASB或安全气囊，灭火器等

5

功能失效和相应的危害之间的关系: 多对一，一对多

6

需要考虑合理的误操作造成的危害，例如驾驶安全距离保持不够

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

首先，通过以下三个参数，对其进行赋值，对危害事件的风险进行量化评估：

严重度（Severity）

暴露度（Exposure）

可控度（Controllability）

具体定义和取值见ISO 26262-3:2018，其中：

1

严重度主要根据AIS分级，关注对人造成伤害的严重程度(非对物体的伤害)。不仅需考虑车内驾驶员乘客伤害，还需考虑外部环境中的人员，包括行人，其他车辆人员伤害等

2

暴露度可基于持续运行时间占比或发生频率确定，不应考虑装备该相关项的车辆数量或占比

3‍‍

可控度可控性受多种因素影响，需驾驶员进行合理假设(例如健康，有驾照)，相对比较难量化，对于C2及C3基于一定样本的用户测试决定‍‍

4

三个参数一般根据ISO 26262-3:2018附录并结合经验，统计数据，仿真，测试等确定。如果存在不确定性，可以适当考虑取较大的值

5

不同企业对同一危害事件的风险量化，即三个参数数值确定，可能不尽相同，审核的重点在于有理有据，合理即可

然后，根据ISO 26262-3:2018，Table 4 ‒ ASIL determination得到每个危害事件的安全等级ASIL。ASIL等级定义了对相关项功能安全开发必要的要求和安全措施，其中，D代表最高严格等级，A代表最低严格等级。QM属于一般质量管理。

为了免去查表的麻烦，这里分享个简单的ASIL等级计算公式：

               S + E + C =10 => ASIL D

               S + E + C = 9 => ASIL C

               S + E + C = 8 => ASIL B

               S + E + C = 7 => ASIL A

               S + E + C < 7 => QM

3.2.3 安全目标

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

可以对相似的危害事件进行组合和分类，再导出安全目标，以此降低分析工作量

针对分类后的每一个危害事件导出对应的安全目标

若导出的安全目标存在相似，可对其进行合并，并继承其中最高的ASIL等级

为了方便朋友们进行安全分析，特意制作HARA分析模板如下:

审核编辑：刘清