自动驾驶硬件功能安全面临的挑战

杨莉 董昊旻 隋建鹏

（1.中国第一汽车股份有限公司 智能网联开发院，长春 130013；2.中国第一汽车股份有限公司 研发总院，长春130013）

主题词：ISO 26262 硬件功能安全 自动驾驶

缩略语

DV Design Validation

HSR Hardware Safety Requirement

DFMEA Design Failure Mode and Effects Analysis

FTA Fault Tree Analysis

ASIL Automotive Safety Integration Level

FMEDA Failure Mode Effects and Diagnostic Analysis

HARA Hazard Assessment by Risk Analysis

SG Safety Goal

LFM Latent Failure Matric

SPFM Single Point Failure Matric

PMHF Probability Metric for Random Hardware Failures

BOM Bill of Material

FIT Fault Injection Test

GPU Graphics Processing Unit

FPGA Field-Programmable Gate Array

ASIC Application Specific Integrated Circuit

1 前言

在过去的十年中，针对自动驾驶汽车的研究和应用呈现了爆发式的增长，大量的自动驾驶相关基础技术越来越成熟。目前，以戴姆勒、宝马、奥迪、福特、东风日产、沃尔沃、上汽、一汽为代表的国内外主流整车厂都在进行自动驾驶相关领域技术的研发，每年的国际消费类电子产品展览会（CES：International Consumer Electronics Show）上，可以看到越来越多的自动驾驶样车的演示[1]。有理由相信颠覆性的自动驾驶技术将带来交通和移动出行领域的又一次重大变革。

然而，随着算法复杂度的增加和自动驾驶等级的提高，安全性成为了影响自动驾驶汽车真正落地的重要阻碍。2011年，作为汽车行业专用的功能安全标准，ISO 26262应运而生。ISO 26262为汽车生产商提供了一整套系统的设计方法来识别危险源，提升汽车的安全性。

ISO 26262标准包含概念层面、系统层面、硬件层面、软件层面、管理层面等部分，本文仅重点针对硬件层面，分析硬件功能安全开发与传统汽车电子电气硬件开发的融合，并基于此，提出自动驾驶汽车计算平台硬件功能安全开发面临的风险和挑战。

2 硬件功能安全开发与传统硬件开发的融合

随着汽车电动化、智能化、网联化、共享化的程度越来越高，汽车电子模块也越来越多，为整车的性能提升和用户体验发挥着巨大的作用。汽车电子的硬件设计不同于通讯电子、工业电子和消费类电子的硬件设计，需要特殊考虑汽车电子的使用环境[2]。汽车电子的气候条件、机械条件和电气条件都要比通讯电子、工业电子和消费类电子的使用环境更恶劣。在电子产品随车使用时，汽车的使用环境条件很大程度上影响着电子产品的功能、性能和寿命。在汽车电子硬件设计开发过程中，首先要清楚这些条件和边界，其次要在设计过程中考虑这些因素，最后在模拟这些条件的实验中进行检验。

由于汽车电子特殊的使用环境，对硬件设计提出了更高的要求。为了保证汽车在使用环境下的整车性能，传统的汽车电子硬件设计流程如图1所示，硬件设计的职责从项目启动开始，到生产流程审核结束，包括计划制定、需求分析、方案设计、硬件设计及测试、设计验证（DV：Design Validation）、生产准备。

ISO 26262标准2011版本第5章[3]对硬件功能安全开发流程推荐如图2所示。硬件功能安全开发承接系统设计的输出物，并通过硬件板级测试对硬件元器件进行质量认可，提交输出物给生产、运行维护及系统集成测试。注意，标准中推荐的硬件功能安全开发流程只是概况，并不详细，与实际硬件开发中执行的开发流程有一定差距。

图1 传统汽车电子硬件设计流程

图2 ISO 26262推荐的硬件功能安全开发流程[3]

结合项目实际开发流程，将传统的汽车电子硬件开发流程与功能安全进行了融合，得到了符合功能安全的硬件开发流程，如图3所示。

由图3可见，功能安全贯穿于整个硬件开发流程中。融合后的汽车电子硬件功能安全开发流程从功能安全的角度对传统的汽车电子硬件开发流程进行了完善和补充。

完善和补充体现在以下几个方面：

（1）项目计划中，新建功能安全开发计划，统筹管理整个项目中的功能安全开发工作，包括工作内容、工作起始/结束时间、责任人、输入条件、提交物等；

（2）在进行需求分析时，除了考虑传统硬件开发的需求外，还需要考虑功能安全需求。每一条硬件需求均需要关联ASIL（Automotive Safety Integration Level）等级，非功能安全相关的需求ASIL等级为QM。形成硬件安全需求文档，并进行设计团队内部评审。

（3）在方案设计阶段，需要充分考虑为了满足功能安全需求而需要进行的复位逻辑设计、看门狗电路模块设计、电源监控设计、辅监控单片机模块设计等。

图3 功能安全硬件开发流程

（4）硬件设计阶段，需要开展设计失效模式及后果分析（DFMEA：Design Failure Mode and Effects Analysis）、故障树分析（FTA：Fault Tree Analysis）、失效模式影响及诊断分析（FMEDA：Failure Mode Effects and Diagnostic Analysis）等分析工作。其中FTA只在ASIL等级为C或D时开展，FMEDA只在ASIL等级为B或C或D时开展。同时在该阶段还需要编写软硬件接口文档和硬件设计规范文档。硬件测试阶段，针对ASIL C或D等级的系统需要开展故障注入测试。

（5）在设计验证和生产准备阶段，均需要额外考虑不同的功能安全等级对测试深度、测试方法、测试标准的不同要求。

根据不同的地质条件、潮汐风浪等环境因素，对具有相同建设条件、有代表性的灯桩进行设计（包括基础选择、选材、作用、尺寸、楼梯设计），以此为依据编制灯桩标准化设计施工图纸。

3 自动驾驶硬件功能安全开发面临的挑战

自动驾驶的初衷是保证道路参与者的生命安全，功能安全是让自动驾驶比手动驾驶更安全的基本保障之一。然而ISO 26262的最新版本[4]并不完全适用于自动驾驶相关控制器的功能安全[5]。

首先，按照SAE J3016道路车辆自动驾驶系统分类和定义[6]，将自动驾驶技术等级分为6级，分别为0级-5级。L4级及以上的自动驾驶系统中，驾驶员将不再接管对车辆的控制权。传统的功能安全中失效安全（fail-safe）的实现手段取决于驾驶员能够控制车辆，并使车辆进入安全状态。因此对于自动驾驶汽车的功能安全要求变为失效可工作（fail-operational）[7]。其次，ISO 26262是以相关项为导向，这意味着一个驾驶功能是通过一个运行于硬件系统上的软件系统来实现的。然而自动驾驶来的发展趋势是在一个域控制器上实现多个驾驶功能。这种架构使得ISO 26262中强调的“互相独立”概念很难实现。最后，自动驾驶中深度学习算法带来的不确定性和非线性使得传统的失效分析方法不再适用。

基于上述几点，本节主要分析硬件功能安全开发在自动驾驶领域面临的挑战。

3.1 输入条件不明确

硬件功能安全设计的根本依据是系统层危害分析和风险评估（Hazard Assessment by Risk Analysis，HARA）分析输出的安全目标（Safety Goal，SG）。根据ISO 26262标准，危害的定义是基于对工作情况的分析而开展的。工作情况包括运行条件和工作状态。这意味着，HARA分析通常包含很多区别很小的工作情况。将自动驾驶的驾驶参数适配到如此细化的工作状态中，工作量是很大的，有时甚至是不可能完成的。同时对如此复杂的工作情况进行管理也是存在问题的[8]。另外，不管是采用机器学习，还是深度学习，都存在一定的不确定性。这种不确定性导致不同的网络参数情况有可能具有不同的安全目标，很难得出一个确定的可以实施的安全目标[9]。这对硬件功能安全开发的影响可以说是巨大的，没有了明确的依据，硬件功能安全开发将举步维艰。

3.2 ASIL等级较高

在传统汽车开发中，人、车和路三个要素组成一个封闭的在环系统。其中，人指的就是驾驶员。对于自动驾驶等级L3以上的系统，驾驶员不再是这个系统中的要素。当驾驶员不在环的情况下，可控性面临巨大挑战。在ISO 26262标准中，可控性是直接决定ASIL等级的三要素之一[10]。驾驶员对车辆的可控性能越差，可控性参数分值（Controllability）越高。行业内正在探讨除了ASIL D之外是不是上面还应该有个更高的层次。依据ISO 26262标准，ASIL C或ASIL D意味着无论是从硬件开发流程还是硬件设计工作的复杂性来讲，都必须满足更高的要求。如果是ASIL D以上，还需要一个更高的层级，那么硬件开发工作的工作量和复杂度不可估量。

3.3 硬件架构复杂

传统的汽车电子电气架构已经很难满足自动驾驶应用中对计算性能、软件升级、关键信息高速高效处理的需求，比如摄像头、毫米波雷达、激光雷达乃至GPS（Global Positioning System）的数据都需要在一个计算中心内进行处理以保证输出结果对整车自动驾驶性能最优。新兴的整车域集中式电子电气架构如图4[11]所示。

由图4可见，根据汽车电子部件的功能将整车划分为驾驶辅助、车辆安全、车辆运动、娱乐信息、车身电子等几个域。域控制器的核心发针时芯片计算能力的提升。基于整车域集中式电子电气架构概念的提出，域控制器硬件架构更复杂。

图4 整车域集中式电子电气架构图[11]

硬件架构复杂度的提升主要体现在以下几个方面。

（1）计算能力高，功耗大，散热问题突出；

（2）数据吞吐率高，板内通信速率高，信号完整性问题显著；

（3）板内供电时序复杂。

典型的自动驾驶域控制器硬件架构如图5[12]所示。该架构中尚未充分考虑功能安全，如何设计出满足系统功能安全等级需求的完整架构还有待探索和实践。

图5 典型域控制器硬件架构[12]

3.4 上游芯片功能安全开展不成熟

由于自动驾驶高算力和低功耗的强烈需求，传统控制芯片已不能满足该领域的应用需求。目前，应用于L3以上自动驾驶领域的主控制芯片主要分为三类：GPU（Graphics Processing Unit）、FPGA（Field-Programmable Gate Array）和专用ASIC（Application Specific Integrated Circuit）。GPU以英伟达公司的PX2平台为代表，FPGA以Xilinx公司的ZYNQ系列为代表，专用ASIC以地平线公司的征程系列为代表。以上三类主控制芯片在架构上均不同于传统的控制芯片，在车载领域的应用尚不成熟，对功能安全的开展更不成熟。该三类芯片的供应商很少能够提供完善的芯片级功能安全手册及芯片级FMEDA分析结果，不利于板级硬件功能安全的开发。

3.5 硬件功能安全分析工作量巨大

对于硬件的安全分析，计算的结果作为失效随机发生的可能性考虑。这些失效可能是仅发生一次，也可能是永久发生。发生的可能性通过FIT值来表征，1FIT意味着在109小时内发生1次。硬件功能安全关注点在于限制失效的发生及/或防止危害安全目标。

硬件功能安全分析包含两部分。第一部分是硬件架构可靠性的分析，是否存在冗余机制及诊断覆盖率的数值决定潜在失效度量(LFM)或单点故障度量(SPFM)的计算结果。另一部分是对于特定安全目标产生危害的可能性，通过硬件随机失效率(PMHF)来表征。对于不同的功能安全等级，上述三个度量的可接受限值如表1所示。

表1 ISO 26262功能安全等级评估指标表

潜在失效度量和单点失效度量通过FMEDA计算得到结果，硬件随机失效率通过FMEDA或FTA计算得到结果。无论是FMEDA还是FTA，均需要针对每个安全目标分析所有BOM（Bill of Material）中元器件。因此，安全目标和BOM中元器件数量及复杂度的增加意味着工作量成倍数的增长。

3.6 硬件测试难度增加

ISO 26262中明确规定，对于ASIL C/D的电子电气系统需要进行故障注入测试（Fault Injection Test）。硬件故障注入测试的目的是验证硬件元器件发生随机故障时，软件是否可以诊断出相应的故障。该测试要求覆盖板内所有元器件的所有随机失效模式。自动驾驶电子电器系统的板内元器件众多，且主处理芯片的引脚数目动辄成百上千，每个元器件的每个引脚在均需要注入开路、短路的故障。同时，需要基础软件开发配合实现该测试，将诊断到的故障上报到测试操作界面并存储到测试日志文件（log文件）。由此带来的工作量和开发难度可想而知。

4 结论及启示

随着国内外整车厂、科技公司、新创公司自动驾驶业务如火如荼的开展，针对如何将ISO 26262标准应用到自动驾驶领域的思考和研究逐渐提上日程。然而目前尚未有明确的标准或草案出台。

作为决定整车自动驾驶性能关键一环的电子电气系统硬件设计来说，有责任和义务进一步考虑到将功能安全应用于自动驾驶电子电气硬件设计存在的问题和挑战。明晰问题和挑战对我们实际开展硬件设计工作具有指导意义。