解析自动驾驶解决方案优劣和功能安全需求

一、目前市场上主流的ADAS解决方案大体分为两种：

1.以Mobileye为首的使用采用Smart Sensor的解决方案，即在Sensor ECU给出识别对象信息，给到ADAS ECU做决策与执行机构控制。

2.以Aptiv等Tier1为主导的域控制器方案，摄像头激光雷达直接传递Raw Data给到域控制器，域控制器进行决策并控制执行机构。

方案一：

在整车电子电器架构的设计上相比方案二较为简单，传感器供应商可以直接通过CAN通讯给出车辆执行机构所需要的信息，以传统摄像头模组搭配CAN通讯的组合可以很轻松的达到ASIL B的等级，但由于单一传感器在探测能力上面的局限性，对于Level3以上的功能如高速公路自动驾驶、城镇自动驾驶等复杂场景来讲本方案在乘用车上难以落地。

方案二：

以域控制器为自动驾驶大脑的解决方案在奥迪新款zFAS平台上大放异彩，作为全球第一款量产Level3车型，TTTech & Mobileye & Aptiv对该域控制器做出了大量贡献。同时该产品的面世也证明了域控制器将为高阶自动驾驶功能的实现提供技术支持和安全保障。在此膜拜Aptiv！

这里补充一个对于CAN通讯的解释，在Ethernet通讯如此火热的今天为什么还要在ADAS系统上继续选择CAN通讯？CAN FD是否将被使用？

答：对于ASIL B以上的安全要求，在架构上传统的Ethernet不足以符合要求，目前各大厂家采用的传感器通讯解决方案大多为Maxim的GMSL或传统CAN。CAN FD将会在下一代量产车型中被使用。根据CiA(CAN in Automation)主席Holger Zeltwanger先生的预测，CAN FD的商用将于2022年初步实现。

二、域控制器解决方案功能安全分析

ISO26262-4 5 6分别对系统、软件、硬件做出了详细的设计与验证规范，下面将以这三个维度对域控制器方案做进一步分析。

系统方面：

在系统架构上，域控制器作为整车电子电器中的一员，与其他ECU在安全等级上ASIL D的要求并无二致，在量产车的解决方案上对上承接Conti，Dephi，Bosch，Sony等大厂冗余的传感器，对下与Bosch ESP EPB EPS等全家桶紧密结合，加之Baidu，四维图新等厂的高精度地图信息加持， 基本可满足全部Level2的功能需求与部分Level3的功能需求。对于系统ASIL D的设计来说，冗余是一种途径，Safe Stop则是最终的结果。对于冗余的解释为：域控制器内部冗余和除Lidar外的传感器均采用传感器及其通讯冗余策略以达到ASIL B的标准，即多传感器多路通讯；对于Safe Stop的解释为：对于任何一种系统失效(硬件、软件)的发生，系统都可以完成对驾驶员的警示和路权交接或安全停车以保证驾驶员的安全。

软件方面：

在软件架构方面，对于标准软件：Vector的PREEvision、VectorCAST等大礼包负责Classical AUTOSAR BSW中RTE、RTOS、Mem、ECU Abstraction、Diag、Communication Protocal等下层服务，Mathwork的大礼包用于应用层服务，BSP则由芯片厂商提供。这种约定俗成的定制方案可以解决大部分MISRA需求，但对于神经网络的存在目前并无低成本的、可靠的、复用性强的方案出现。这部分黑盒的存在引入了SOTIF的概念并导致了Validation策略和框架对比传统ECU的变化。

这里马克一下RTE和SOTIF，目前绝大多数厂商的Demo都是基于ROS的框架搭配Unix系统实现，个人的理解为缺点是不能量产、安全等级低，优点是低硬件依赖度、更适应快速迭代开发的过程。SOTIF目前还未推出正式版本，在当前版本的SOTIF中，系统需求，场景分析和测试都被重点提及，测试方面会后续说明。

硬件方面：

对于域控制器的硬件方案来说，ASIL D是必备的，目前各家半导体厂商均给出了自家的拳头产品，其中较为出色的就是Nvidia的Drive PX、Pegasus系列，Renesas的R-Car系列，NXP的Blue Box系列。对于硬件来说“概念林志玲，量产罗玉凤”的情况不大可能出现，而且域控制器中并不一定所有的SoC都需要ASIL D，在SoC的选择上ASIL D的SoC通常用于执行机构的控制和诊断，其他QM、ASIL A、ASIL B的SoC则负责感知和计算，SoC间互相监控冗余，也可以做到ASIL D的效果。在实际项目中往往其最大的风险来自于量产的时间。

在这种高冗余的设计模式下，自动驾驶系统可以完成理论上ASIL D的实现。但ASIL D并不代表绝对的安全，功能安全是一种艺术。在自动驾驶系统开发的过程中，被所有人质疑的神经网络模型将使用新的Validation策略和框架予以验证。

个人认为Validation是在自动驾驶量产过程中非常大的难题，对于如此特殊的系统来说，好的软件开发决定了基础，而好的验证则决定了客户及市场的满意度。

Validation方面:

自动驾驶的验证在内容上不再局限于单元测试，集成测试，软件测试，系统测试，系统集成测试，整车测试等几块V Cycle的定义。由于在SOTIF中Simulation Scenario的提出，Validation被赋予了更重要的意义，对于黑盒系统，新形式系统测试和整车测试不但可以增加产品置信度，更可以加速产品迭代效率，增加黑盒可靠性。一般来说系统测试及之后的测试内容会分为三块，功能测试，系统测试，和整车测试，对于三块不同的测试内容，ASPICE中对于测试覆盖度和测试深度对于同的安全目标有着详细的定义，ISO26262中也针对不同的安全等级做出了不同的推荐。最后，各大欧洲主机厂的量产方案大多以“脱离比例”为Software Release指标，这点在各大Safety Report上也可见一斑。

三、个人感想

自动驾驶的系统设计最终很可能偏离传统的汽车电子路线，Adaptive AUTOSAR和SOTIF等新标准的出现证明了这一点，但无论如何，ISO26262的意义不仅针对最终的产品，更存在于每个汽车电子工程师点滴的产品开发生涯中，产品手中过，安全心中留。