汽车功能安全概述及产品设计过程详解

2年前浏览1302

随着电动化、智能化的发展，越来越多的汽车配备了电子电气系统，如电传动系统、助力转向系统、自动驾驶系统等，原有的机械部件被电子器件取代。而引入如此复杂的电子电气系统对整车安全带来了极大的风险，简单的一个元器件老化、失效，都有可能引发系统故障，进而导致事故发生。因此，对汽车及其相关零部件安全的要求也是越来越高。

为了达到更高程度的安全要求，在针对其他行业安全的通用IEC 61508标准的基础上，衍生出针对汽车行业特定的ISO 26262功能安全标准。ISO 26262要求车载电子电气系统在检测到潜在的危险情况，启动保护或纠正装置，以防止发生危险事件或提供缓解措施以减少危险事件的后果。简而言之，功能安全的最终目的是确保产品安全运行，即便出现问题也能够最大程度减少伤害。所以，在电动化及智能化程度最高的新能源汽车行业，引入和深入实施ISO 26262功能安全标准，指导相关的产品开发，是十分必要的。

ISO 26262对关键的安全级别进行了四层划分，通过汽车安全完整性等级（ASIL）来衡量。ASIL A是最低等级，要求数目约100个左右，而ASIL D是最高等级，要求数目近200个（如图1所示）。等级越高，安全系统就需要提供越多的安全和验证措施，需要增加更多的测试和集成工作，也就意味着供应商需要承担更多的开发成本和时间。

为了实现新能源汽车的整车功能安全，需要OEM和各级供应商有着明确的职责划分和合作模式，国外主机厂在与供应商合作中，如博世、电装等，都有着明确的功能安全标准和验证要求。当然不同的汽车部件对功能安全的要求是不同的，越核心的部件需要越高等级的功能安全。就新能源汽车车辆自身安全而言，电机控制器不得不算是最核心的部件之一，电机控制器作为新能源汽车的动力控制系统，掌握着整车的加速、刹车等关键性能，电控失效带来的安全风险不容忽视，所以，符合功能安全的电控设计正逐渐成为业内的普遍需求，当前对电控的功能安全需求多为ASIL C等级，但在未来，电控的功能安全需求或将提升为ASIL D级，这需要供应商具备复杂度更高、冗余性更强、可靠性指标更高的电控产品设计能力和水平。

下面对功能安全在整个产品设计过程中的应用进行详细介绍：

1 概念阶段

概念阶段主要任务是从整车层面确定功能，针对功能失效的危害事件进行风险评估并制定安全目标（主要属性：ASIL等级、FTTI和安全状态）导出功能安全需求。本部分主要有4个活动（如图2），接下来咱们就来讲讲这些活动主要实现什么。

注：FTTI: 从故障发生到故障处理完成的时间,FTTI时间是从整车层面定义，零部件的FTTI时间为其中一部分。

图2：概念阶段主要活动

1.1 相关项定义

在汽车功能安全领域，很多人都有听说过HARA分析。但在进行HARA分析之前，需要先定义项目要实现的功能，以及实现该功能产品的使用环境、与其它产品相关的依赖性和相互影响、法规要求、系统和组件之间的接口和边界条件，这就是相关项定义的主要目的。在此活动中需要画一个与相关项相关的物理架构图，即为项目边界图，定义系统的边界和与它相关联的系统。值得注意的是，针对零部件厂家此处的功能是零部件在整车层面体现的功能。如：电机控制器的提供扭矩功能，简称“扭矩功能”，在HARA分析后的功能就会这样描述“请求正向动力实际输出反向动力”，属于比较细化的描述。

1.2 HARA分析

危害分析和风险评估针对相关项所定义的每一个功能分别进行HAZOP分析（功能无、功能多、功能少、功能相反、非预期、卡滞）。在定义危害事件（整车故障、路面状况、天气状况、驾驶情景和用户），最后进行风险评估确定每一条危害事件的ASIL等级，从S（严重度）、E（暴露概率）、C（可控性）三个角度进行分析。

注：巧记S E C=7对应ASILA；S E C=8对应ASIL B；S E C=9对应ASILC；S E C=10对应ASIL D。

1.3 安全目标

完成HARA分析后，应为每一条危害事件确定安全目标。安全目标是最高层面的安全需求，其重要属性包括ID、描述、ASIL等级、FTTI、安全状态。ASIL等级为所覆盖的危害事件的最高等级。产品的最后验证活动也就是从整车层面确定ASIL等级和安全目标，是大“V”验证活动中最后一个活动“安全确认”。

1.4 功能安全需求

功能安全需求是由安全目标和安全状态导出，可能有人会问如何导出？把它简单理解成一个分解的过程就行。例如：确保把大象放进冰箱里这个“安全目标”，第一步打开冰箱门；第二步把大象装进冰箱；第三步关上冰箱门，这三步就是根据“安全目标”导出的“功能安全需求”。

注意：在分解过程中，需要继承安全目标最高ASIL等级。功能安全需求是大“V”验证活动中，对应整车集成和测试。

为了使导出的功能安全需求更具完整性，可以通过整车层面的安全分析导出，如：FMEA、FTA、HAZOP。目前行业内常用FTA方法。其方法将每个安全目标的故障作为FTA的顶事件，然后将每个安全目标相关设备的物理框图画出来，用FTA分析相关设备失效，将FTA分析的每一个可能的底事件和未开展事件都需要定义相应的安全需求来降低危害事件发生的可能性。例如：整车控制器与电机控制器之间通信的CAN总线错误可能导致安全目标违背，于是就提出“要求整车控制器输出的信号需要进行时序保护和CRC校验，以保证传输给电机控制器的信号正确”这样一条功能安全需求。

2 系统阶段

系统阶段主要根据功能安全需求和其它非安全需求一起整合并细化成技术（安全）需求，然后进行系统设计，形成技术（安全）概念，并将技术（安全）需求分配给软硬件。此阶段主要有6个活动，见图3，接下来详细讲一下各过程。

图3：系统阶段主要活动

2.1 技术（安全）需求

大家看到标题中的“安全”用括号是否会感到好奇呢。咱们就先从这讲起，工程师们想想就知道，作为一个产品不可能只有安全相关的需求，肯定需要一些非安全相关的需求才能做出一个完整的产品。在系统阶段的第一个任务，就是将功能安全需求和非安全需求整合并细化成技术（安全）需求。

非安全相关的需求包括：装配工艺（如：特殊点胶位）、振动需求、性能需求等。在细化安全需求时，需要将安全机制及具体实施方案考虑进去。确定产品开发设计的相关方案，如上面例子第二步“把大象装进冰箱”，在这里就要细化成是买冰箱还是自己做冰箱，以及把活的大象赶进去还是杀了后整头或切块装进去。在此活动中需要注意ASIL等级的分解。此活动对应大“V”的系统集成和测试。

2.2 系统架构设计

大家看到这部分标准可能很容易犯迷糊，不清楚系统架构是啥意思，也不知道如何下手。其实系统架构设计就是将技术（安全）需求描述的功能模块用框图的形式表示出来，即为每一条需求的技术解决方案以框图形式表达。框图的输入、输出接口就是功能模块的输入、输出接口，然后把所有的框图组合在一起就成了系统架构图。注意这里面包含两个内容，第一、技术（安全）需求的ID要与系统架构的ID对应，确保需求与架构一致；第二、要将模块接口描述的参数信息写到架构的接口参数描述当中去。

另外系统架构应该从概念阶段的初步架构中展开设计系统架构，等把整个产品的架构设计好后，打开概念阶段的架构点击深入就是系统阶段的架构，再点击深入就是软硬件层面的架构。就像咱们看地图一样，先是从地球放大展开找到中国再放大找到省再放大找到市。作为一个工程师想想自己设计出这样的架构是不是很漂亮。

2.3 安全分析和相关性失效分析

安全分析是分析系统性失效的工具，目的是帮助与支持设计。在系统阶段的安全分析需要用到两种，分别为FMEA、FTA。FMEA和FTA都是以识别系统性失效的原因和系统性故障影响的工具，FTA是演绎分析法，FMEA是归纳分析法。演绎分析，从上往下分析导出安全目标违背的根本原因；归纳分析，从下往上采用故障模型（可采用HAZOP关键字）对可能导致安全目标违背的所有失效模式进行分析。两者可以相互验证且都是通过分析验证架构来满足技术（安全）需求，一般分析安全机制的需求是否满足功能安全需求的要求。

相关性失效分析又称为独立性分析简称DFA。DFA主要识别在不同ASIL等级的模块间不能相互干扰，以达到不违背安全需求或安全目标。

技术（安全）需求、系统架构设计、安全分析和DFA是一个迭代过程，如果安全分析的结果，发现技术（安全）需求细化的安全机制不够全面，就需要去更新需求同时也要更新架构，以达到四者一致。

2.4 软硬件接口设计

软硬件接口设计就是将软件与硬件交互的内容定义清楚，先将接口定义清楚，方便软件工程师和硬件工程师分别设计。在后续产品硬件和软件分别验证完成后，可以进行软硬件集成和测试。站在实际开发角度来讲，也可以减少软硬件工程师之间扯皮的事情。

3 硬件层面

硬件层面就是根据技术（安全）需求导出硬件(安全)需求并通过硬件设计来实现。在详细设计后，分析随机硬件故障失效和影响。在硬件层面有6个活动（见图4）。硬件（安全）需求、硬件架构设计、安全分析这三个活动与系统阶段同理，这里就不再赘述。在这里主要讲下硬件详细设计和FMEDA。硬件（安全）需求对应小“V”的硬件集成和测试。

图4：硬件层面的主要活动

3.1 硬件详细设计

硬件详细设计是原理图级别的设计，根据硬件（安全）需求和硬件架构来设计原理图。特别需要注意原理图模块电路需要跟硬件架构的模块对应，模块之间的接口也要一样。

3.2 FMEDA

FMEDA（随机硬件失效导致违背安全目标的评估）是评估硬件随机失效的方法。针对每一个ASIL等级的开发，根据ISO 26262标准要求具有相应的量化指标需要满足，如ASIL B PMHF＜100FIT，SPFM≥90%，LFM≥60%。FMEDA分析就是确定是否满足安全目标所定义的ASIL等级目标值。

输入原理图和BOM结合安全目标，对原理图上的元器件逐个进行FMEDA分析，通过查找行业认可的失效率手册（SN 29500、IEC 62380等）获取元器件的基础失效率，然后针对每一个元器件分析单点故障和残余故障，多点故障和潜伏故障，考虑对应安全机制的诊断覆盖率确定安全失效总和、单点故障失效和残余故障失效总和，计算单点故障失效率和潜伏故障失效率以及随机硬件故障失效率衡量是否满足量化指标。

4 软件层面

软件层面的软件（安全）需求跟硬件层面一样，都是从技术（安全）需求那里导出，但在细化软件（安全）需求时应考虑硬件约束及其对软件的影响。软件层面共有7个活动（见图5）。软件（安全）需求、软件架构设计、安全分析跟前面讲的一样是迭代过程，软件（安全）需求和安全分析与系统阶段工作内容同理，这里就不再赘述。

图5：软件层面的主要活动

4.1 软件架构设计

软件架构跟硬件架构一样，先要实现软件（安全）需求，还需要描述各软件模块及其在层次结构中的交互。交互包括两方面，静态和动态。静态：需要把每个模块与模块之间的接口和数据路径描述清楚；动态：需要将模块与模块之间的时序和定时描述清楚。此活动对应小“V”的软件集成和测试。

4.2 软件单元设计与实现

软件单元设计与实现主要是根据软件架构和软件（安全）需求详细定义软件单元并按照定义实现软件单元代码，并且在单元测试之前需要先进行静态测试。特别需要注意软件代码模块与软件架构的模块对应，模块之间的接口、静态接口描述的一样。此活动对应小“V”的软件单元测试。

5 3“V”

ISO 26262基于“V”模型开发产品验证，可能很多工程师不清楚活动对应关系。现在我把3个“V”对应的活动用图示方式画出来，图6是大“V”对应的活动，图7是硬件“V”对应的活动，图8是软件“V”对应的活动。

图6：大“V”对应的活动

图7：硬件“V”对应的活动

注：硬件阶段的验证也可以参考软件V模型，将测试分成三个部分。针对硬件详细设计验证的硬件模块测试；针对硬件架构设计验证的硬件集成和测试；以及针对硬件需求验证的硬件测试，分别定义测试用例进行测试，使验证和设计的追溯更清晰，只是因为硬件需要将所有电路模块整合在一片板上才方便工作，所以看起来只有一个测试活动。