2.5 系统阶段技术安全需求(TSR)和方案(TSC)开发... 13
随着软件定义汽车，汽车功能安全显得尤为重要，本文主要简述在功能安全不同开发阶段(包括概念，系统，软件，硬件开发等)重要内容。
1 功能安全概述
1.1 功能安全的意义
通俗的讲明白，就是：人和物都不是完美的。
1 人不是完美的 => 系统性失效
汽车开发工程师在汽车E/E系统开发中，包括软件和控制器硬件，不可避免地存在人为疏忽或错误，引起系统功能功能失效，进而导致故障并产生危害。这部分人为疏忽导致的失效为系统性失效。(注: 硬件也有系统失效)
2 物不是完美的 => 随机硬件失效
控制器硬件，由于自身老化，外部环境因素等引发功能失效，导致相应故障并产生危害。硬件失效带有随机性，符合一定概率分布，因此称为硬件随机失效。
为了避免上述两种失效，功能安全由此诞生。
1.2 功能安全的作用
1 除通常质量管理(QM)外，对汽车E/E系统软硬件全生命周期安全开发流程，方法等进行约束和规范(主要是通过ASIL)，尽可能降低人为结构性的系统失效
2 对控制器硬件部分进行概率化度量，尽可能降低随机硬件失效
3 除过程约束外，设定安全状态，一旦系统发生故障，在故障容错时间内将系统导入安全状态，避免对人身、财产造成伤害
1.3 汽车功能安全法规
1 ISO 26262: 2018版，属于第二版
2中文国标: GB/T 34590，于2017年发布，属于ISO 26262第一版的中文版，英文不是太好的朋友可以先看中文版，但和 ISO 26262: 2018最新版存在一定差异
ISO 26262属于方法论模型，抽象又具体:
抽象在于: 除了个别开发流程方法外，其他过程并没明确如何具体操作，这导致功能安全开发相对难以落地，不同开发商对功能安全理解也不近相同，不同企业产品功能安全无法直接横向对比。
具体在于: 开发大的流程及工作输出产物明确，和ASPICE过程参考模型相比还是具体很多。
可能是其魅力吧！通过抽象又具体的方法论，一方面对功能安全开发大的流程和方法提供了指南，另一方面，考虑了不同企业技术及理解差异，为技术施行多样性提供了可能。
1.4 汽车功能安全特点
汽车功能安全特点包括:
1 旨在尽可能避免由系统功能异常导致的危害，不是为了提高系统原有功能或非安全性能(如动力性)或避免系统本身功能不足导致的危害(属预期功能安全)
2 不关注本质安全(即通过消除危险的原因确保安全的方式)
3既基于系统功能实现(基于现有功能进行危害分析和风险评估，定义目标及安全需求并采取安全措施)，又有所区别(一般独立开发，ASIL要求贯穿全过程，直接决定功能安全开发工作量和内容)
4系统，软件，硬件开发遵寻各自V模型，都是从需求，到架构，再到设计实现，最后验证及系统确认(确认只有在系统层面)。为了加速迭代过程，可以和敏捷过程相结合(后续细聊)
1.5 功能安全真的必要性
虽然目前大部分开发商对功能安全越来越重视，但对很多企业而言，功能安全难以落地，投入产出比不高，项目进度受阻等等。因此，也有一些质疑的声音，如：
- 为了覆盖极少数可能发生的安全问题，功能安全是否在浪费项目开发时间和资源？
- 标准化的安全规范ISO 26262是否必须执行？
针对以上质疑，有大拿给出这样的解释：
1安全问题重视程度取决于企业价值排序。个人觉得，安全第一，须竭尽全力保障汽车产品安全，先发布再以牺牲用户利益为代价的市场测试，至少有违道德
2条条道路通罗马，ISO 26262只是其中一条，非强制执行。只要企业安全文化到位，产品开发流程有效覆盖功能安全问题，也能走出自己的一条功能安全之路
3规范的存在既是门槛，也是为了让普通工程师在规范的约束下，有可能开发出一流的符合功能安全的产品(我这么说不要打我，我也是普通工程师)
4功能安全不是形式主义，不为死抠标准，不为通过评审而做，不会短期见效，却能避免企业陷入重大安全召回
5系统优化企业组织架构和交流接口，优化开发流程，将功能安全融入企业各自开发流程中，实现不同平台，项目间的最大化复用，是功能安全实施的关键之一
2 功能安全开发
2.1 概念阶段开发定义
汽车产品开发基于需求，需求是产品开发的基础。好的需求一定程度直接决定产品性能和质量，对汽车功能安全开发也不例外。
我们所熟知的功能实现的需求多源于用户需求，而功能安全开发的需求源于功能实现部分。
在不同开发阶段，需求根据其细化程度可分为:
- 功能层面的需求: 相对抽象的逻辑功能需求(就是大爷大妈们也能看得懂)，需细化至技术需求
- 技术层面的需求: 技术可实施的需求，可直接转化为软硬件开发
功能安全概念阶段开发本质就是，在相对抽象的逻辑功能层面，通过安全分析提出功能安全开发最初的安全需求。因此，被称为概念阶段。
具体而言，就是通过对相关相所实现的功能进行危害分析和风险评估(HARA)，导出功能安全开发最初安全目标(Safety Goal)以及功能安全需求(FSR)。
2.2 概念阶段开发 - 相关项定义
相关项定义的本质为确定功能安全研究的对象，内容比较简单，方便理解直接上大拿理解公式:
相关项 = 结构 + 功能描述 + 对象属性特征
结构: 研究对象是什么，由哪些系统及组件构成，一般采用UML或SysML结构视图表达(实在不行就上PPT)。
功能描述: 研究对象实现了哪些系统级别的功能，是后续危害分析和风险评估(HARA)基础。
对象属性特征: 对象预期的功能危险，内部以及对外依赖关系(以接口体现)，相关法律法规。
注: 可对相关项进行裁剪，复用类似相关项工作输出产物，以此降低产品开发周期和成本。
2.3 概念阶段开发 - HARA
2.3.1 HARA定义
简单来说，HARA(Hazard Analysis and Risk Assessment)是在概念阶段为导出功能安全目标及其ASIL等级的系统安全分析方法。
具体而言，根据相关项定义的功能，分析其功能异常表现，识别其可能的潜在危害(Hazard)及危害事件(Hazard Event)，并对其风险进行量化(即确定ASIL等级)，导出功能安全目标(Safety Goal)和ASIL等级，以此作为功能安全开发最初最顶层的安全需求。
2.3.2 HARA流程
流程图如下：
2.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.需要考虑合理的误操作造成的危害，例如驾驶安全距离保持不够
2.3.3.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
2.3.3.3 安全目标
危害事件的反面即为安全目标，其中:
- 可以对相似的危害事件进行组合和分类，再导出安全目标，以此降低分析工作量
- 针对分类后的每一个危害事件导出对应的安全目标
- 若导出的安全目标存在相似，可对其进行合并，并继承其中最高的ASIL等级
为了方便进行安全分析，大拿特意制作HARA分析模板如下:
全文资源链接如下：
ISO26262汽车功能安全标准的详细解析及实践指南资源-CSDN文库
https://download.csdn.net/download/ChrisKKC/90149159
或点击下方公众号二维码，发送“功能安全”，会自动回复网盘下载链接，免费
扫一扫
1563
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
