一文快速理解汽车功能安全Functional safety

现在很多汽车和零部件企业在控制器开发过程中都要求采用ISO 26262的功能安全标准。由于功能安全标准制定了汽车整个生命周期中与安全相关的所有活动，内容繁杂、细化规则多、专业术语多，很容易让人陷入某个细节而无法理解整体目标。

今天我们针对重点内容做个简化的介绍，便于快速理解！

1.功能安全的概念

汽车功能安全的定义是“不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险”，就是说汽车上各种E/E模块在功能失效时不能给人员带来伤害。

简单的说，功能安全就是“功能”失效时要保证人的“安全”！

2.功能安全的目的

功能安全的目的是为了降低来自系统性失效和随机硬件失效的风险。

简单地说，功能安全的目的就是降低风险，避免伤人！

3.功能安全的内容

功能安全的内容不仅仅是产品功能本身，还包括需求、研发、验证、生产、运行、维保等产品生命周期内的所有活动及管理过程，功能安全需要第三方认证时也是分为体系和产品两种认证。

4．功能安全的分级

功能安全根据严重度S、暴露概率E和可控性C三个因素分为A、B、C、D四个等级。

ASIL A-D为安全等级，QM质量管控为非安全等级

其中的严重度S分为4级，从无伤害到致命伤害；暴露频率分5级，从不可能到高概率；可控制性C分4级，从可控到难以控制或不可控。

S、E、C分级说明

ASIL四个等级中A最低，D最高，等级越高，意味着该产品失效后可能引起的安全风险越大，这时产品的研发严格程度越高、研发成本越多、研发验证周期也越长。

这里要注意的是ASIL的分级要从三个因素综合考虑，单一因素等级很高，不一定是属于安全等级。比如有些风险严重度很高，但频率很低，就不一定是安全等级，可能属于质量管控QM。

5.产品相关的功能安全

功能安全标准提供了产品整个生命周期的方法论，涉及内容广泛，但是工程师们最关注的还是产品设计开发相关的标准。

功能安全中的产品适合应用于车辆中的电子、电气、软件组件安全相关的产品，可以是整个系统，也可以是硬件模块、嵌入式软件、半导体IC等产品，比如某款MCU芯片通过功能安全ASIL-B产品认证。

产品相关的部分主要包括概念阶段、产品开发中的系统层面、硬件层面和软件层面。

产品设计开发相关部分

5.1概念阶段

概念阶段要做的工作是相关项定义、危害分析和风险评估、功能安全概念。

相关项的定义就是确定功能安全的研究对象，包括产品功能、接口、环境条件和法规要求等，这一步实际上就是要先把产品的主要功能梳理清楚。

危害分析和风险评估HARA是基于相关项展开，进行功能失效分析和整车危害分析，对危害事件根据S、E、C三个维度进行ASIL等级评定，这一步的主要目的是确定安全目标。

危害分析和风险评估HARA

安全目标中应包括FTTI ，即“故障容忍时间间隔(Fault Tolerant TimeInterval)”，这是保障生命安全的重要性能指标。

功能安全概念就是要根据安全目标和初始的系统架构，确定功能安全概念层面的安全需求FSR。

5.2产品开发

产品开发涉及到了ECU的具体设计部分，包括系统层面、硬件层面和软件层面。这三个层面的开发流程是个V模型，先进行系统分析设计、然后是硬件、软件设计及其测试，最后是系统测试和确认。

产品开发V模型

5.2.1系统层面

系统层面

系统层面中的技术安全实际上就是针对概念阶段中提出的功能安全的拆解，它是根据系统的设计方案来分析。

比如一个ECU可以分为很多个模块，电源、通信、AD采样、IO输出等，可以分别分析每个模块可能的失效模式，分析其对功能安全要求的影响程度。

如果某个模块的失效违背了功能安全要求，那么就要对这个模块分配相应的设计要求，这个设计要求就是技术安全要求。

集成和测试是常规开发流程，安全确认是为了确认安全需求是否正确，按照预期的实现后，能否能达到安全目标。

这里要说明的是，系统的技术安全概念完成后并不能直接进入系统集成和测试，而是要先进入硬件层面和软件层面。

5.2.2 硬件层面

硬件层面就要对系统层面提出的模块进行硬件的拆解分析，确定硬件安全要求，硬件层面的内部开发过程也是个V模型。

硬件层面

硬件安全的拆解要进一步细化，比如电源模块失效时的欠压或者过压值是多少？当欠压或过压时，要执行的安全机制是什么？重启还是强制断电还是发出报警信息？MCU是否需要两路完全独立的电源供电等等。

硬件架构设计也要遵循一定的功能安全原则：

硬件架构设计原则

对于硬件架构设计原则表格里的技术或方法，一个+号表示建议实施，两个+号表示强烈建议实施。

硬件层面中还有个概念叫硬件随机失效，我们在做功能安全时，主要关注两种失效，系统性失效和随机硬件失效。

随机硬件失效是指在硬件要素的生命周期中，非预期发生并服从概率分布的失效。因此只有硬件会发生随机失效，软件不会。

随机失效与硬件的设计无关，即使硬件的设计是正确的，元器件也符合质量标准，但随机失效仍然会发生，而且无法预知。

随机失效虽然无法预知，但是失效率可以在合理的精度范围内进行预测，也就是可以进行定量评估的。

另外一个系统性失效是指以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。

不同于随机硬件失效的不可预知性，系统性失效的形式是确定的，只要满足相应条件就一定会发生。从另一个角度来说，系统性失效是可以复现的。硬件和软件都会产生系统性失效。

当找到造成失效的确定方式后，可以采取对应的措施，如修复软件bug、更改电路设计等就可以有效避免系统性失效。

6 软件开发层面

软件自身的开发也是一个V模型，从产品开发概述、安全定义到最后的软件测试。

软件层面

软件层面也是从系统层面提出的模块分解为软件安全要求，软件安全分析可以采用归纳的方法，也可以采用演绎的方法。

归纳就是自下而上分析，先分析底层单元有什么失效模式，再找出其对顶层安全要求的影响。比如底层采样值的计算错误会导致顶层的ECU无法输出正确的控制信号。

演绎就是自上而下，比如ECU的安全目标是能够输出正确的控制信号。

这时就需要根据软件架构从一层层排查，最后排查出哪些底层原因会导致输出错误的控制信号。比如逻辑运算错误、数据存储失效会影响顶层的安全目标，那么这两部分就要被分配相应的安全要求。

与硬件不同，软件只有系统性失效，而没有随机硬件失效，其中比较重要的是软件架构设计，软件架构也要遵循一定的原则。

软件架构原则

软件开发完成后，再重新回到系统层面，进入系统及相关项集成和测试、安全确认，完成一个大的V模型流程。

产品开发V模型

7.功能安全示例

下面我们以BCM的灯光控制为例，做一个简单的流程说明，便于大家更直观的理解。

产品设计开发相关流程

7.1概念阶段

相关项定义：BCM的主要功能是灯光控制、门锁控制、车窗控制、雨刮控制、发动机防盗、胎压监测等。其中灯光控制中的刹车灯如果失效，会导致后方车辆看不到前车刹车提醒，有一定风险，属于相关项。

危害分析和风险评估：行车过程中，如果刹车灯不能点亮则无法及时提醒后方车辆刹车或减速，有被追尾的风险。

根据三个维度初步判断安全等级为ASIL B级，安全目标为刹车灯应按预期点亮。

7.2产品开发-系统层面

BCM的灯光控制中的刹车灯相关的系统架构如下图所示：

刹车灯系统架构图

相关软硬件的接口描述如下：

1.MCU通过硬线信号和CAN收发器接收刹车相关信息；

2.MCU根据相关输入信息控制刹车灯点亮逻辑；

3.MCU控制高边芯片驱动刹车灯输出；

4.MCU和HSD通过SBC提供电源。

根据系统架构，初步安全分析可知，要满足安全目标，刹车灯功能需满足如下几点：

1.安全的信息接收；

2.安全的处理逻辑；

3.安全的驱动输出；

4.安全的电源供电。

7.3产品开发-硬件层面

硬件层面需先定义硬件安全需求 HSR，细化软硬件接口（HSI）规范；再做硬件安全分析 FMEA/FTA/DFA、计算硬件架构度量指标 SPFM、LFM并评估由于随机硬件失效导致的安全目标违背的概率 PMHF；最后是硬件集成和测试，验证 HSR。

具体设计内容可以从电路设计异构、自检、驱动芯片诊断、独立供电、看门狗等方面考虑。

7.4产品开发-软件层面

软件层面也需要先定义软件安全需求 SSR；再设计软件架构 AD，并进行软件层面的安全分析FMEA 和相关失效分析DFA；完成软件单元设计UD 和实现，然后进行软件单元测试验证，最后是嵌入式软件测试，验证 SSR。

具体设计内容可从软件功能单元解耦、错误探测和错误处理的安全机制，如软件自检、CAN通信超时处理、驱动诊断逻辑和诊断故障处理机制方面考虑。

此外，在实际应用中，某些安全目标如果难以直接达到，还可以进行ASIL分解。ASIL分解是可以将一条功能安全需求分解成两条相互独立的需求并分配到两个及两个以上相互独立的元素（如软件模块、硬件模块、输入信号等）上。

这样一个ASIL D可以分解为一个ASIL C和一个ASIL A或分解为两个ASIL B。对每个元素来说降低了对功能安全需求的ASIL等级。

8 小结

功能安全是覆盖产品整个生命周期的方法论，最终目的是保证产品不因E/E系统的故障而产生对人的不合理危害。

产品开发相关的内容主要是概念阶段、系统阶段和软硬件开发阶段。

功能安全失效主要分两种，软硬件的系统性失效和硬件的随机失效。系统性失效是可复现的，可以通过设计方法、流程控制改善。硬件随机失效是电子器件本身的特性，不可复现，也无法通过设计或流程控制等改善。

功能安全的过程，就是自上而下，从系统到软硬件逐层分析、拆解，细化安全需求，制定应对策略，通过精确的设计，尽可能减少故障发生时对人员的伤害！