引言

汽车功能安全ISO-26262

随着新能源汽车市场的不断发展，自动驾驶技术日新月异的迭代，汽车上用到的芯片越来越多。未来，电子系统，或者说自动驾驶系统在汽车中的重要性会越来越高。ISO-26262是电气和电子（E/E）系统的通用功能安全标准。本文将结合ISO-26262，从什么是功能安全、什么是功能安全工程师以及功能安全工程师主要做什么，三个方面展开对功能安全的介绍。

什么是功能安全

1 背景简介

根据汽车电子行业功能安全标准ISO26262的定义，功能安全是为了避免因电气/电子系统故障而导致的不合理风险。根据故障的严重程度不同，功能安全可划分为不同的等级。ISO26262标准针对汽车功能的ASIL（汽车安全完整性）等级从低到高划分为：QM、A、B、C、D五个等级。其中，ASIL D为安全等级最高。比如，线控油门系统，当驾驶员踩下油门踏板，踏板上的传感器向控制器发送信号时，控制器会综合分析如发动机转速、车辆速度、踏板位置等信号，然后将控制指令发送给油门本体。测试和验证线控油门系统等是汽车行业面临的一个挑战。ISO 26262的目标就是为所有汽车E/E系统提供一个统一的安全标准。

图1: IEC 61508

脱胎于IEC-61508的功能安全ISO-26262的国际标准草案于2009年6月发布。从草案发布开始，ISO-26262已经在汽车行业获得了广泛的关注。工程师将ISO-26262视为最先进的技术状态。该技术的技术状态在特定时间是开发设备或流程的最高水准。汽车制造商一般要对因产品故障而造成的损害负责。ISO-26262在汽车行业是一个通用标准，它提供了一种衡量系统安全性的方法。

图2: 安全相关系统

ISO-26262使用V-Model来管理功能安全，并在系统、软件和硬件级别上规范产品的开发。ISO-26262标准提供了整个产品开发过程中的法规和建议——从概念阶段到产品报废阶段。它详细说明了如何为系统和组件分配一个可接受的风险级别，并对整个测试过程进行记录。一般来说，ISO 26262：

① 提供了汽车整个安全生命周期 ，并支持在这些生命周期阶段中定制必要的活动；

② 提供了一种基于汽车特定风险的方法来确定风险类别（ASIL）;

③ 使用ASIL来指定项目的必要安全要求，以实现可接受的残余风险；

④ 提供了验证和确认措施的要求，以确保达到足够和可接受的安全水平；

2 评估风险——危害分析和风险评估（HARA）

当我们对新开发的车型有了清晰的定义后，也就打响了汽车功能安全的第一枪。我们需要用HARA来识别和评估潜在的危险。一般来讲， OEM的功能安全工程师会对车辆级的功能进行HARA分析，以识别潜在的危险场景，并确定每个潜在危险所需的风险降低水平。HARA考虑了在特定驾驶场景中暴露于潜在危险情况的频率和持续时间，纠正故障行为以减轻潜在危险所需的控制量，以及在故障行为发生时潜在后果的严重程度。

3 分配安全等级——功能安全完整性等级（ASIL）

在HARA过程中，OEM为每个已识别的潜在风险分配了一个ASIL 等级。ASIL在开发过程中就已经确定了。根据可能存在的风险。

图3：功能安全等级评定

为了适当地解决这些情况，ISO 26262使用ASIL评级来确定供应商必须采取的开发步骤的严格性，并定义了安全目标（safety goal）的要求：

1. FIT率（Failure In Time）: FIT率是车辆在给定时间段内可接受的故障率。车辆必须满足ASIL评级所规定的FIT率，但OEM也可以灵活地为系统内的基础组件选择FIT率。

2. 安全概念（Safety Concept）：安全概念决定如何检测故障及如何控制故障，具有更高ASIL评级的系统需要更严格的故障检测和响应能力。

3. 安全要求（Safety Requirements）：安全要求规定了对任何给定故障的适当响应。比如，传感器检测到与内部安全相关的问题，如内存损坏，故障响应系统可能会在规定的时间内终止通过控制器的通信，以便向其他系统指示其故障状态。这是安全要求所描述的典型的安全机制——故障响应系统并不总是恰当合适的。如：对于智驾功能，车辆可能采用故障操作系统，这要求冗余系统接管需要必要的时间，以使车辆处于最小的风险状态（比如，安全停车在路边）。对于系统故障，遵循严格的开发过程有助于增加该功能将以一种安全的方式运行的信心。

4 持续的测试和集成

汽车功能安全在整个开发过程中都采用了V模型。V模型要求，对于开发的每一步骤，在测试中都必须对应有一个相应的步骤。供应商定期评估其开发过程，以确保硬件和软件开发都遵循了所需要的步骤。

图4：V模型

OEM，供应商或者独立的第三方公司对所有相关的工作产出物进行功能安全审核和评估，以确保功能安全的实现。功能安全需求一个全面的管理过程，以确保适当的监督和完整的系统集成。

危害分析和风险评估

依据ISO 26262标准进行功能安全设计时，首先识别系统的功能，并分析其所有可能的功能故障（Malfunction），可采用的分析方法有HAZOP，FMEA、头脑风暴等。如果在系统开发的各个阶段发现在本阶段没有识别出来的故障，都要回到这个阶段，进行更新。功能故障在特定的驾驶场景下，才会造成伤亡事件，比如近光灯系统，其中一个功能故障就是灯非预期熄灭，如果在漆黑的夜晚行驶在山路上，驾驶员看不清道路状况，可能会掉入悬崖，造成车毁人亡；如果此功能故障发生在白天就不会产生任何的影响。所以进行功能故障分析后，要进行情景分析，识别与此故障相关的驾驶情景，比如：高速公路超车、车库停车等。

分析驾驶情景建议从公路类型：比如国道、城市道路、乡村道路等；路面情况：比如湿滑路面、冰雪路面、干燥路面；车辆状态：比如转向、 超车、制动、加速等；环境条件：比如：风雪交加、夜晚、隧道灯；交通状况：拥堵、顺畅、红绿灯等；人员情况：如乘客、路人等几个方面去考虑。功能故障和驾驶场景的组合叫做危害事件（hazard event）， 危害事件确定后，根据三个因子——严重度（Severity）、暴露率（Exposure）和可控性（Controllability）评估危害事件的风险级别——ASIL等级。其中严重度是指对驾驶员、乘员、或者行人等涉险人员的伤害程度；暴露率是指人员暴露在系统的失效能够造成危害的场景中的概率；可控性是指驾驶员或其他涉险人员能够避免事故或伤害的可能性。这三个因子的分类在表1中给出。

什么是功能安全工程师

关于什么是功能安全工程师？这个问题乍一看很好回答，但如果仔细思考下就会发现，想找到真实统一的答案却并不容易。一般来说供应商端功能安全工程师的工作职责一般包括但不限于：

计划和协调系统安全开发活动

1）基于HARA分析，根据安全需求和系统架构定义功能安全概念和技术安全概念，对系统架构设计提出要求或建议

2）将安全需求分配给对应的软件工程师和硬件工程师

3）完成系统功能安全设计的定量分析和定性分析，通常分别使用FTA和FMEA

4）协助功能安全验证，如创建整车test case和测试结果评估

5）作为客户功能安全团队和功能安全审核团队的接口

6）对软/硬件工程师提供功能安全开发建议和指导

以一个新项目为例，来说明下什么是功能安全工程师以及在产品开发过程中功能安全工程师做什么。

1 报价阶段

A. 安全要求的分析与澄清：

功能安全工程师要对客户的安全输入进行分析，以确认公司内部产品的安全要求是否与客户匹配。通常会以会议的形式跟客户讨论和澄清相关安全要求。

B. 执行影响分析：

分析完客户的安全要求之后，一般功能安全工程师还会做影响分析，以确定公司内部的平台项目或者已经量产的其他客户项目是否有可以直接复用的功能，或者修改之后可以复用的功能。如果是全新的产品开发，则客户忽略影响分析。

C. 开发接口协议（DIA）责任划分：

弄清楚产品的开发边界之后，功能安全工程师要跟客户去确定每一方的开发责任范围，并明确开发过程中的产出物的责任方以及双方如何进行产出物的交互，双方对以上内容都达成一致后，DIA也就完成了。

D. 准备项目功能安全计划和安全档案：

在报价阶段，功能安全工程师要根据项目的时间计划以及客户的安全输入来准备初版的项目功能安全计划。

E. 相关项定义以及危害分析：

如果站在主机厂和Tier 1角度，功能安全工程师要完成所开发产品的相关定义、并对其进行危害分析和风险评估，以便得出产品的顶层功能安全目标，以及功能安全概念，并打包发给供应商。

F. 准备评审会议：

以上内容都完成之后，功能安全工程师就可以跟审核员约评审会议了。审核员会根据功能安全工程师准备的证据对该项目的产品开发成熟度进行评估以确认是否满足当前的开发需要，以及是否有安全相关的风险，并输出当前阶段的评估报告。

2 概念设计阶段

功能安全概念/要求开发：功能安全工程师要完成功能安全概念/要求（FSC/FSRs）的开发。功能安全概念的主要目的如下：

1) 要根据功能安全目标定义产品的功能性或者降级的功能性行为；

2) 要根据功能安全目标定义关于合理地、及时地检测和控制相关故障的约束条件；

3) 要定义产品层面的策略或者是措施，以通过产品本身、司机或者外部的措施来实现故障容错或者减小对相关故障的影响；

4) 把功能安全要求分配给系统架构设计；

5) 确认功能安全概念并且定义好安全确认的准则；

图5：功能安全目标和安全要求层级

3 开发设计阶段

系统开发设计

1. 技术安全概念/开发要求：

功能安全工程师要完成TSC/TSRs的开发。技术安全概念的主要目的如下：

1. 制定系统要素和接口关于功能、相关性、约束和属性方面实施中所需的技术安全要求；

2. 制定系统要素和接口实施安全机制的技术安全要求；

3. 制定在生产、运行、服务和报废中系统及其要素功能安全的相关要求；

4. 验证技术安全要求在系统层级是否符合功能安全要求并与功能安全要求一致；

5. 制定满足安全要求且不与非安全相关要求冲突的系统架构设计和技术安全概念；

6. 分析系统架构设计，防止故障并为生产和服务得出必要的安全相关特殊特性；

7. 按照各自的ASIL等级，验证系统架构设计和技术安全概念是否适用于满足安全要求；

图6：系统层面的产品开发

2. 安全机制的裁剪：

一般在产品设计初期，开发人员已经完成了关键芯片的选型。功能安全工程师在此阶段还要主导完成对芯片手册安全机制的裁剪活动，哪些是产品所必须用到的，哪些是可以裁剪的，并给出充分的理由。

3. 系统安全架构开发：

有了系统需求，系统架构，功能安全要求和技术安全要求后，功能安全工程师就可以开始设计系统安全架构了。设计系统安全架构要注意以下几点：

a. 确保系统安全架构和前面阶段的系统架构设计的一致性；

b. 系统安全架构要能实现技术安全要求；（相应的安全要求和安全机制最好能体现在系统安全架构中）

c. 设计的系统安全架构能否被充分验证，预期的软硬件设计是否能满足此系统安全架构，是否方便于系统集成时测试的执行；

d. 设计时要充分考虑安全相关的内部和外部接口；

e. 如果此阶段需要进行ASIL等级的降级分解，要按照ASIL的要求进行分解；

4. 启动系统层面的安全分析：

有了完整的安全要求和系统安全架构之后，功能安全工程师就可以启动系统层面的安全分析FMEA分析，FTA分析，DFA分析了。

a. FMEA分析：FMEA是一种定性的、归纳式的单点故障分析方法，主要是在早期检测和消除产品设计和制造过程中的薄弱点。

b. FTA分析：FTA是一种演绎式故障分析，它使用布尔逻辑来分析系统不期望的状态，以结合一系列较低级的事件。FTA的目标是分析在系统中发生的实际故障的路径，以定位系统故障的原因。

c. DFA分析：DFA的主要目的是通过分析潜在原因或者诱发因素，来确认设计中已经充分实现了要求的独立性或相互之间免于干扰。如果有必要的话，也可以制定相应安全措施，来减轻可能的相关失效。

图7：不同类型的相关性与失效之间的关系

硬件开发设计

1. 硬件安全的开发要求：

有了系统层面的安全要求、安全架构和安全分析的输入后，功能安全工程师就可以开始开发（或者协助硬件工程师开发）硬件安全要求。

图8：硬件层面的产品开发

硬件开发的基于硬件安全需求，其来源于TSR、HSI和系统架构。硬件设计主要分为硬件架构设计和硬件详细设计。硬件架构设计需要以模型或者框图的方式进行，定义清楚硬件内部各元素及其功能，同时内部之间各接口需要详细定义。在硬件架构定义好后，进行硬件详细设计，设计硬件原理图和layout。对于硬件设计，为了避免系统性失效，需要进行对应的安全分析。对于ASIL C等级的产品，硬件设计的安全分析需要同时进FMEA和FTA分析。硬件安全设计主要包括两个方面:硬件安全架构设计

硬件安全详细设计

硬件安全架构和详细设计均基于HWSR，硬件安全架构的设计旨在描述硬件组件以及其彼此的相互关系，更重要的是将硬件架构相关的HWSR，尤其是安全机制应用于硬件架构，为后续硬件详细设计提供基础。硬件安全机制是硬件安全设计中最核心的内容，我们会在第三部分单独阐述。除此之外，ISO 26262-5:2018第7部分还对硬件安全架构和详细实现设计提出了相关约束，主要包括:

对硬件安全架构设计而言:

硬件架构应能够承载HWSR。

HWSR应该被分配至硬件架构中的组件。

不同或非ASIL等级硬件组件开发需满足以下原则之一:

按最高ASIL等级

要素共存FFI

对硬件安全要求和实施之间的可追溯性。

为避免系统失效, 硬件架构应具有下述特性:

模块化;

适当的粒度水平;及简单性。

在硬件架构设计时，应考虑安全相关硬件组件失效的非功能性原因，例如: 温度、振动、水、灰尘、电磁干扰、来自硬件架构的其他硬件组件或其所在环境的串扰。

对硬件详细实现设计而言:

为了避免常见的设计缺陷, 可运用相关的经验总结。

在硬件详细设计时, 应考虑安全相关硬件元器件失效的非功能性原因, 可包括以下的影响因素:温度、振动、水、灰尘、电磁干扰、噪声因素、来自硬件组件的其他硬件元器件或其所在环境的串扰。

硬件详细设计中, 硬件元器件的运行条件应符合它们的环境和运行限制规范。

硬件安全分析：

功能安全工程师要协助硬件工程师进行硬件层面的安全分析，包括FMEA和FMEDA分析。

a. FMEA分析：硬件FMEA分析直接在系统FMEA分析的基础上继续对硬件组件进行分析就可以了。

b. FMEDA分析：FMEDA的计算，需要的输入安全目标，硬件失效率目标值，安全要求，安全架构，BOM表，Mission Profile，安全机制列表，SN29500的基础失效率等，有了这些输入就可以开始FMEDA的计算了，以检查所设计的硬件产品的SPFM，LFM，PMHF是否满足相应ASIL等级的要求。

图10：硬件失效率度量指标值

4. 软件安全的开发要求：

与硬件开发类似，有了技术安全要求、系统需求和系统架构、硬件设计规范、软硬件接口列表和软件开发环境的输入后，功能安全工程师就可以协助软件需求工程师来开发软件安全要求了。软件安全要求一般来源于分配给软件的技术安全要求或者软件功能和特性的要求。

图11：软件层面的产品开发

5. 软件安全架构：

软件安全架构设计主要是软件架构师来负责，功能安全工程师协助支持，并支持做软件架构的评审活动。软件架构的设计要尽量满足一致性、简单性、可验证性、模块化、可维护性等特征。在软件架构设计中也可以参考ISO 26262第６部分中软件架构设计的方法。

图12：软件架构设计原则

4 测试验证阶段

对于各个阶段的测试话题，由于很少有公司要求功能安全工程师去执行测试活动。

系统测试验证

系统阶段的测试一般包含以下几种：

a) 系统功能测试：验证系统功能是否满足系统要求

b) 系统集成测试：验证组件之间的接口是否满足设计要求

c) DV测试：DV是设计验证，验证产品设计是否满足要求，其中DV测试又包含环境耐久测试、电磁兼容测试、电气特性测试

d) PV测试：PV是产品验证，主要验证产线上生产出来的产品是否符合要求。一般PV之后的产品，就具备了批量生产的资格了。

硬件测试验证

硬件阶段的测试一般比较关注硬件功能测试，也就是基于相关硬件需求的测试，以确认硬件电路设计与硬件需求是一致的。

软件测试验证

硬件阶段的测试一般包含以下几种：

1) 软件功能测试：验证软件功能是否与软件需求一致。

2) 软件单元测试：验证单元设计是否与单元设计需求规范一致。

3) 软件集成测试：验证集成的软件是否满足软件需求，以及软件组件之间的接口是否一致。

失效分类与硬件随机失效诊断

依据ISO 26262，电气/电子(E/E)组件功能异常可分为系统性失效和随机失效两种类型。

a.系统性失效

指在开发、制造或维护(制程问题)过程中以决定性方式产生的项目/功能失效。这些通常是出于工艺原因的故障，可通过改变设计或制造流程、操作流程、使用说明或其他相关因素来解决。一般要求是追踪和追溯性。ISO 26262-2：2011所述的功能安全管理活动对于这些方法和期望皆有所说明。

b.随机失效

硬件元件在使用寿命期间发生，源自制程固有随机缺陷或使用条件的随机失效。硬件随机失效又可区分为永久失效(例如固定型故障)与暂时失效(例如单一事件扰乱或软件错误)。随机失效的处理方式是在硬件/软件系统的设计与验证过程中导入安全机制，让架构具备诊断并修正功能异常的能力。

依据ISO 26262：1-2011的定义，安全机制是指由E/E功能或元件，或由其他技术所实施，而能用以诊断失效或控制失效，从而达成或维持安全状态的技术解决方案。举例而言，安全机制可包括错误修正代码(ECC)、循环冗余校验(CRC)、硬件冗余、内建自我测试(BIST)。

解决方案能否有效诊断上述随机失效，可参考其诊断失效和失效率(FIT)的三种诊断以及风险整体可能性，包括单点失效指标(SPFM)、潜在失效指标(LFM)以及硬件失效概率指标(PMHF)。这三种诊断是ISO 26262中用来判定硬件组件功能安全的测量方式，本文其余部分主要聚焦于如何进行分析以达成这些诊断的目标值。定义硬件架构诊断的架构和公式，可参阅ISO 26262-5：2011，附录D、C.2和C.3以及9.2：

a.单点失效诊断

反映项目/功能对于单点失效的鲁棒性，由设计或以安全程序覆盖均包含在内。

b.潜在失效诊断

反映项目/功能对于失效的鲁棒性，由设计(本质安全失效)、通过安全程序的失效覆盖，或驾驶人在违反安全目标前即认知失效存在等情形均包含在内。

c.硬件失效概率诊断

说明因随机硬件失效引起的违反安全目标残余风险够低。

简单来区分，单点故障可能直接导致违反安全目标，而潜在故障则是指可能容许另一失效造成危险的未测得失效。

车辆安全完整性等级(ASIL)

若已知某项功能的异常属于车辆层级(例如防抱死刹车系统)，应继而进行危险与风险分析以判定其伤及人员并造成财物损失的风险。此项分析是根据危险的接触情况、严重性及可控制性和因而产生的风险，来判定车辆安全完整性等级(Automotive Safety Integrity Level, ASIL)，也就是想要达成的可容忍风险所需降低的风险程度。图2说明ASIL基于功能异常及其可能影响而做出判定的范例步骤。ASIL A是最不严格的安全降低程度，而ASIL D最为严格。

图2 在ABS范例中，概念阶段基于危害分析与风险评估的车辆安全完整性等级

对于硬件组件，ASIL要求决定达成表1中失效诊断所需的数值。在解决系统性故障时，ASIL也将设定工艺合规的严格程度，例如追溯性、制程品质、使用说明

表1 每个ASIL级别的失败诊断标准

前景展望

就目前的现状来看，随着ADAS功能的普及和自动驾驶研究的热门，功能安全越来越被重视，市场需求量很大。猎头在挖人时开出的价码往往非常诱人。与此同时，目前国内功能安全做的成熟的企业不多，尚处于边做边摸索的阶段，所以目前挖人时并不很挑剔，对系统/软/硬件开发经验的要求有放宽。

相对于本土OEM，外企或者合资Tier1的know-how更高，比如博世，大陆，联电等等。合资OEM中泛亚的功能安全团队已经很成熟，因此在和这些供应商合作时很强势也有底气；而本土OEM在和这些供应商合作的同时也抱着花钱学习怎么做功能安全的目的。换句话说，OEM的态度从“你觉得怎么做？”到“我要你这么做！”还有些距离。但是，这种状况在将来一定会得到改变，因为本土主流的几家OEM的功能安全团队在以肉眼可见的速度壮大，大家越来越舍得在功能安全开发上投入成本（好多外国专家也因此体会到了社会主义高薪的诱惑力）。可以预见的是，自动驾驶的驱动会加速功能安全的落地，这会大大加速行业整体水平的提高。届时，国内市场对功能安全工程师的专业素养的要求也会越来越高；另一方面，ISO 26262在自动驾驶开发中的局限性也日益凸显，由此也催生了新的标准SOTIF的诞生，功能安全工程师需要掌握的知识越来越多。

【注】：本文以EPB为例介绍了ISO 26262标准中安全目标及其ASIL等级确定的方法，安全目标的ASIL等级被开发阶段安全需求继承，如果安全需求的ASIL等级高，那么需要进行ASIL分解以降低ASIL等级，本文以实例介绍了ASIL分解的原则和步骤。ASIL分解并没有在ISO 26262中被强制要求执行，但是我们可以通过对系统进行分析、进而对系统架构进行调整，实现ASIL分解，可以解决因ASIL等级高而带来的开发成本、开发周期和技术要求等方面的问题。