一、什么是自动驾驶中的功能安全？

对于自动驾驶或驾驶辅助车辆来说，车辆大部分或几乎全部交由系统控制，控制效果的优劣是必须要考虑的因素。在传统汽车领域中，失效表现往往源于系统的失效。在自动驾驶系统中则不然，及时系统不发生故障，也可能因为神经网络黑盒输出等因素的不确定性导致功能的偏离，造成交通伤害。尽管可能在感知决策执行层面没有任何错误和失效发生，其他复杂的交通状态和车辆意外行为依然可能成为自动驾驶系统的不稳定因素。自动驾驶行业中的人工智能AI可以加强感知和决策能力，理想状态下对其输入的确定数值，我们期望得到相同的结果，但AI问题本质上是一种概率问题。考虑到车辆的运行场景往往是多变的，静态和动态因素同时存在与驾驶场景中，这种连续或离散变化的状态对于感知来说的输入变量是不可量化和计算的，这是实际的项目开发过程中就很难保证系统输出的稳定性和鲁棒性，直接导致流向市场的自动驾驶车辆无法准确保证实际需求。

针对自动驾驶的功能安全分为两个方面内容解决：

1、 道路车辆功能安全解决“电子电器失效”对人造成的危害；

2、 预期功能安全解决“非系统故障原因”对人造成的伤害；

这类非故障情况下因系统功能不满足预期而导致的安全风险就是预期“功能安全”要解决的问题。自动驾驶系统的复杂化，软件算法的多样化，导致设计预期功能安全的部分越来越多。

二、功能安全需求分析详解

由国际标准化组织于2011年制定的ISO 26262标准适用于道路车辆上特定的由电子、电气和软件组成的安全相关系统在生命周期内的所有活动。针对自动驾驶板块，提供了安全系统安全硬件和安全软件基础。其目的是确保在发生故障时能够独立、安全的的运行整车。其核心内容如下：

1. 功能安全管理 Functional Safety Management建立每个过程的安全开发架构（Part 2）2.安全相关产品开发 Safety Product Development① 概念开发阶段 Concept development phase (Part 3)② 系统开发阶段 System development phase (Part 4)③ 实际开发阶段（硬件和软件）Actual product development（H/W & S/W） (Part5,6)3. 生产和运维Production and Operation (Part 7)

对于自动驾驶系统开发人员而言，详细阐述了到所有开发阶段的要求。

1、功能安全管理

功能安全管理（FSM）是质量管理（QM）的延伸，主要包含如下功能：

Ø 定义安全生命周期模型

Ø 建立和促进公司安全文化

Ø 定义所有相关部门、人员的安全责任

Ø 保证必要的人员能力、资质

Ø 保证足够的质量管理活动

针对产品开发而言，功能安全管理的目标是：

形成公司级功能安全规范和流程

制定出功能安全培训指南

功能安全机制集成到公司已在执行的质量管理体系当中

2、 概念阶段

功能安全概念阶段是整个自动驾驶系统开发功能安全分析最重要的节点，包括了四个阶段进行相应的工作：

2.1 概念阶段

2.1.1、对象相关项

功能安全分析是基于对系统对象定义的，对象定义是对自动驾驶系统工作必要的相关项定义和描述，以确保安全生命周期中定义的每项活动都能得到准确实施，在相关项的定义过程中需要考虑行业专家意见（如设计中的建议与边界划分），同时必须考虑如下相关需求：

整车级功能性的需求

环境要求（EMC，温度，水，尘…)

法规、标准、规范

已知的安全要求（基于行业要求、经验等）

要素定义

与其他对象关联的要求

2.1.2、对象回路

功能安全分析是针对一个安全回路而言，并不是针对一个设备或部件。比如，我们只能针对自适应巡航系统ACC执行正常减速跟车的功能安全分析，因为这个减速过程涉及了前雷达radar目标探测，中央控制单元ECU进行数据处理，制动系统ESC进行减速响应执行减速的整个过程回路。此案例中，不能只针对前雷达探测目标是否准确进行功能安全分析，因为这个并未形成安全回路。

针对目前针对自动驾驶安全回路分析发现，系统局限可分为如下几个部分：

感知-目标场景考虑不周到，系统无法对环境做出正确的响应；

决策-功能逻辑仲裁机制、算法不合理，导致决策出问题；

执行-执行机构的输出与理想输出发生偏差，难以完美控制；

2.2 安全生命周期初始化

针对自动驾驶车型开发项目而言，如果为全新开发车型，则需要进行完整的安全生命周期分析。若是改款车型，则只需要识别变更部分进行影响分析后，裁剪部分安全生命周期活动。

2.3 危险分析和风险评估（H&R，Hazard and Risk Analysis）

危险分析和风险评估是整个概念阶段的核心，其目的是对对象相关危害识别并分类，制定安全目标预防或减轻危害，避免不合理的风险。主要分为如下步骤实现：

其中ASIL（Automotive Safety Integrity Level）表示汽车安全完整性等级，是对危害程度需要降低到何种地步的一种衡量。等级越高，说明安全等级越高，需要花费更高额的代价去实现该等级的功能安全。

2.3.1 危害识别

危害分析与风险评估（H&R）是对功能故障进行识别并对其产生的危害进行分类，从而决定相应的功能安全目标并以此制定相应的措施来避免不合理的危险。其中，危害的识别方法主要有：FTA、 FEMA、HAZOP等等，其中HAZOP分析方法是目前评估最有效的分析方案。

对于危害的识别与描述必须从整车级。

ADAS系统举例：危害为“ACC系统可能存在前方有目标时进行猛加速”，而不是“ACC控制器安装误差错误导致识别错误”，因为危害为猛加速后的碰撞风险，该危害可能是由不同的原因造成的（比如EMS错误响应，ACC识别错误，ACC识别正确信号发送错误等等）。注意：功能安全只与由于项目故障导致的危害相关，由于驾驶员或者乘员错误使用正常功能造成危害不再其范围内。

2.3.2 危害分类

1）暴露度分析-E

暴露度的分类可以从两个方面描述：对于经常发生的驾驶或操作情况的典型特征用其总占运行时间比例表达；而偶尔发生最好按其频率来表达。评估等级E可对不同暴露时长或频率分类。共有五种分类（E0，E1，E2，E3和E4）应用来表示评估等级E。

ADAS应用举例：比如驾驶员在使用ACC过程中，误碰加速设置按钮。此工况可统计为有时发生，则暴露等级为E2；

2） 严重程度（伤害）分析-S

危害程度是指某个功能在特定的条件下，由潜在危险造成人员伤害的严重程度，包括对驾驶员、乘员以及行人的伤害（物理伤害）。事故的伤害程度能够被分为四类：S0, S1, S2 和 S3。这样的分类代表不同的潜在伤害的程度。

ADAS应用举例：S0是指没有人身伤害，比如ACC制动过程中产生噪声，都只能定义为S0。伤害程度等级为S0，则不需要定义ASIL；如果在定义的过程中，对于严重度的等级在两个等级之间难以确定，则取高等级。S1指的轻度伤害，比如ACC在低速下为触发制动时间晚，导致两车有轻微碰撞。

3） 可控度分析-C

可控性评价是评估驾驶者或其它道路使用者获得对危险情况的控制并能避免伤害的概率。如果对于特定市场，则要基于特定市场的典型驾驶员的特点（比如文化背景、年龄、性别、手眼协调能力等）来分析其行为的可能性。为此，评价等级C分为四类（C0，C1，C2和C3）可区分避免伤害的概率。

ADAS应用举例：如ACC在定速巡航发生误加速时，驾驶员可通过踩制动即可保证整车减速。故应该描述为C2。又如若LKA纠偏过度导致方向偏离过大，则此时驾驶员将难以控制，可控度分析为C3。

2.3.3 功能安全等级明确

对每个潜在的危害从危害的严重度、暴露度和可控度3个维度来确定功能的安全等级，即ASIL（Automotive Safety Integrity Level）等级，ASIL分为A、B、C、D，以及QM，其中A安全等级最低，D安全等级最高，QM是属于质量管理范畴不属于功能安全的内容。下表即是安全等级确定表。

ASIL等级综合评估方式为：ASIL_X=Sx+Cy+Ez，一般的ASIL_X<7，功能安全等级为QM；ASIL_X=7，功能安全等级为A，ASIL_X=8功能安全等为B，ASIL_X=9功能安全等为C，，ASIL_X=10功能安全等为D。

2.3.4 功能安全目标

安全目标是针对驾驶员能感知到的危害故障（驾驶员级/整车级）从管理人员角度为避免危害的描述，而不是技术角度，其针对的用户也是项目管理人员。安全目标的应该包含以下内容：

1) ASIL等级（与对应的危害分析与风险评估等级相同）；

2) 如何避免对应的危害事故（通常为危害的对立面）；

3) 故障容错/监测时间（故障发生后多长时间系统自我修复解决这个问题或报警，该内容可在安全要求提出）；

安全目标举例：

一个项目可能有多个安全目标，一个安全目标关联多个危险事件。

2.3.5 功能安全审查

通过分析好的功能安全等级需要进行功能安全复审，验证分类的一致性和正确性。对于自动驾驶车型项目开发而言，就是将功能安全确定并通知其相应的传感器控制器供应商进行实现。

I0: 可以进行认可，如果实施认可的话，应由不同的人进行

I1: 应进行认可，由不同的人进行

I2: 应进行认可，有来自不同团队的人进行，即不同的直属领导

I3: 应进行认可，有来自不同部门或组织的人进行

2.4 功能安全概念

2.4.1明确功能安全状态

安全状态是指功能的运行没有不合理的风险存在。主要根据危害情况从三个角度提出1、功能正常的运行、执行、操作状态2、功能故障后的降级反应（如跛行回家）3、功能故障后关闭并报警

注：在进行提出安全状态时并不是说每一个危害都要按照这三条来提出，要根据具体的功能，比如EMS可能涉及到的安全状态包含了以上三个内容，但是对于车道偏离，故障后就直接关闭该系统，不存在降级的概念。

ADAS安全状态举例：在摄像头与雷达融合进行弯道限速时，首选摄像头进行弯道曲率检测并做提前控制，如果摄像头故障无法检测弯道曲率时，该系统降级为由雷达控制器可采集整车横摆角信息做弯道限速控制。

2.4.2 明确功能安全需求

功能安全需求仍然是从管理人员的角度来看待问题，故不涉及具体的实现技术，在提出功能安全需求时应该考虑：a) 功能正常运行、操作模式;b) 故障发生时容错的时间间隔（该要求具体情况可在技术安全需求中具体提出）；

c) 如何转换到安全状态；d) 应急操作时需要在多长时间内完成的时间间隔（该要求具体情况可在技术安全需求中具体提出）；e) 功能冗余（例如故障冗余，该要求可在技术安全需求中具体提出）；

2.4.3 完成ASIL等级与需求的分解

明确功能安全ASIL等级后需要将功能安全需求分配到定义对象的初步架构模块或外部措施。

比如，明确了不同的ASIL等级可采用如下分解叠加的形式最终实现满足终极目标。

ASIL D → ASIL C(D) ＋ ASIL A(D)

ASIL D → ASIL B(D) ＋ ASIL B(D)

ASIL D → ASIL D ＋QM(D)

ASIL C → ASIL B(C) ＋ ASIL A(C)

ASIL C → ASIL C(C) ＋ QM(C)

ASIL B → ASIL A(B) ＋ ASIL A(B)

ASIL B → ASIL B(B) ＋ QM(B)

ASIL A → ASIL A ＋ QM (A)

以上ASIL分解过程中要求：* 各安全需求要求相互独立，降低部分模块的ASIL等级要求

* 冗余系统可以对子系统采用较低的ASIL等级来达到较高系统ASIL等级

* 相关的安全目标的失效只有在两个元素同时故障的情况下才会发生

ADAS系统ASIL分解举例：比如LKA需要实现功能目标为避免系统发出错误的转向角与扭矩，该功能安全等级为ASIL D，可分解为ADAS端执行QM，EPS端执行ASIL D。

注意以上功能安全分解如果分解后的目标两者都是QM，则对功能安全无贡献，该分解方式是无效的。

3、 产品开发

功能安全分析最终是要应用到主机厂产品开发中，相应的开发阶段包括了三方面:

系同级别：主要工作时进行系统设计、对象集成测试、功能安全评估、发布生产等，其中最重要的是根据功能安全分解的需求制定相应的硬件设计方案和软件设计方案。

3.1、硬件安全需求制定

硬件安全需求来自软件技术安全需求及技术安全需求，同时硬件安全需求描述了产品开发过程中的测试指标、认证指标、以及架构指标需求。

架构指标需求包括了最常用的评价标准:单点故障指标（Signal-point fault metric）、潜在故障（Latent fault metric）、随机硬件故障（Random hardware failure rate）。我们设计硬件架构时，应该重点考虑故障指标。

ADAS应用举例：LKA系统的功能安全需求为QM，EPS功能安全目标为ASIL D，则其硬件目标响应被分配为单点硬件故障>99%,潜在失效故障>90%,随机硬件故障率<10-8/h.

以上硬件指标应该包含进入对供应商前期招标定点的技术要求里。

3.2、软件安全需求制定

软件安全需求制定应充分考虑在系统失效即将违反功能安全目标时，通过相应的算法是系统进入或维持在一个安全状态，并检测、指出和处理安全相关的硬件和软件故障。相应的软件开发如下图：

ADAS应用举例：如L3级自动驾驶TJP在主中央控制器处于故障或降级状态时，考虑到功能安全问题，应该充分利用冗余控制算法将本车减速刹停以避免风险。