下一代自动驾驶域控制器系统架构设计

Posted 2021-07-31 焉知智能汽车

作者 |  Aimee

出品 |  焉知

知圈 |  进“域控制器群”请加微13636581676,备注 域

近年来，随着计算机和通信等技术的发展，汽车产业的发展逐渐呈现出以下几个主要特点：智能网联化、电动化、轻量化和国际化。智能网联汽车的出现不仅为汽车交通事故、交通拥堵等问题提供了良好的解决方案，也为我国汽车产业的发展提供了新的机遇。根据国际自动驾驶工程师协会SAE所提出的标准[1]，自动驾驶一共可以分为六个级别：L0，L1，L2，L3，L4 和 L5。其中，L0 -L2 属于驾驶辅助阶段，L3、L4 和 L5 属于高级自动驾驶。就目前的技术储备和产业基础而言，L1 级和 L2 级具有较多的应用场景和市场，部分主机厂已宣布量产L3级或准L3，而针对L3 级及以上（这里我们称之为L3+）仍然存在诸多技术难题。

L3+级自动驾驶相对于初级版L3主要呈现的问题如下：

1）当前L3级自动驾驶系统中仍然存在较大的传感探测盲区，比如当前架构下前视摄像头对前方目标的距离深度及广度探测存在局限性；侧向雷达无法完成侧方目标（包含距离、类型、方位）的精准探测；后向通过侧向雷达存在较大的三角探测盲区等问题都会在一定程度上影响对于目标的输出，而这种探测局限性又很可能导致自动驾驶存在一定的危险性；

2）此外，中央域控制器算力、带宽不足以满足传感器输入的指数级数据量，从而导致无论对于传感信息亦或者逻辑信息的处理实时性、有效性均无法满足性能要求；

3）系统架构设计无法满足驾驶功能安全及性能设计要求。这里我们指的系统架构包含但不限于网络架构、冗余设计架构、关联系统接口以及诊断设计架构；

4）功能安全设计是下一代自动驾驶需要解决的老大难问题，所有的系统开发工作均围绕着功能安全展开。其中的设计过程包含了系统级、零部件级等等，从整体系统级别出发的功能安全等级分析往往需要牵一发而动全身，其智能驾驶系统自身内部设计的方方面面均需要考虑全面，同时参照其控制器、执行器搭载架构而言还需要更多的关注零部件级硬件+软件功能安全分析。

5）系统功能测试局限问题明显。对于真正的自动驾驶而言，系统开发往往围绕正向开发过程进行，正向开发意味着很多边缘化的场景并未在开发过程中进行响应，我们知道通过APICE流程开发模型中，其中涉及的单元测试和过程测试正是针对开发原始软件的漏洞和缺陷进行实时补充和更新的方式，这就要求测试过程具备极为丰富的场景库以及测试平台搭建能力。场景库不难理解，就是我们常常称之为的UseCase，而平台搭建能力则是对下一代自动驾驶系统测试的巨大挑战。因为其中包含了仿真测试与实车测试两种方式。难点在于在很多真实场景下无法进行测量（可能测量时存在较大危险性）的边缘化场景只能通过仿真平台搭建，而仿真搭建的模型却又很难真实的再现出实际的功能场景。

本文针对下一代自动驾驶系统的功能设计架构进行详细分析，从不同的角度说明自动驾驶系统在设计上的详细需求，从而确保为开发下一代自动驾驶系统提供支撑。

整车架构与功能列表

下一代自动驾驶从整车架构上讲主要增加了不同的几类硬件配置，典型的方案是采用集中式控制方案进行数据处理与逻辑控制。顾名思义集中式即是域控制器直接处理激光雷达、前视摄像头、后视摄像头、侧视摄像头、环视摄像头、超声波雷达等传感器原始信号，同时集成高精地图与定位数据至Soc中（此时可以摒弃掉告警地图盒子），包含创建SLAM定位建图策略，外挂独立IMU进行车辆位姿数据优化等过程。如下表示了下一代自动驾驶的整车架构典型示意图：

下一代自动驾驶系统涉及的整车网络系统由若干路 CAN 子网、LIN 子网、车载以太网Ethernet组成。其中CAN 子网分别为：动力 CAN、底盘 CAN、舒适 CAN、信息 CAN、ADAS CAN、T-Box CAN与诊断 CAN等这几种主要类型。而主体的LIN 子网分别为：VCU/EMS- LIN、BCM-LIN、GW-LIN以及IHU-LIN等。

针对顶层自动驾驶控制系统而言，需要充分考虑的部分包括传感器与控制器部分的搭载更新，如下图表示了一种典型的下一代自动驾驶传感器升级配置图以及相关控制器主导网络架构：

从下一代自动驾驶功能架构上看，主要是实现当前阶段自动驾驶无法实现的新功能以及提升当前已实现的自动驾驶功能的相关性能指标项。主要的新增功能项有一定环境下的全脱眼自动驾驶Eyesoff，高速路下的点对点自动驾驶NoP，紧急转向支撑ESS以及自动寻位的全自动泊车系统AVP等等。

整体来讲下一代自动驾驶系统的功能架构总体包含的系统功能列表如下：

平台化系统架构

下一代自动驾驶平台化系统架构设计的要点在于做到下几个典型的控制处理方向。为了满足功能安全设计要求必须实现控制器、传感器、通信网络、执行单元等全部双冗余。从控制器层面讲，实现双冗余可以通过两方面来实现，各自具备相应的优缺点。

下一代域控制器架构主要分为如下两种： 一种是双域控制器双芯片，另一种是单域控制器单芯片。两种设计方式各有优劣，且相应的设计原理主要考虑如下因素：

1）传感器数据对于各个芯片的连接有何条件？

当两片Soc的算力足够时，设计所有传感器进行双链接，可以完全实现感知数据无遗漏传输处理。如果将所有传感器均连接至双芯片时，也可能由于两个Soc的数据源均来自相同的传感器，可能引发数据同源的风险。

2）是否可以做到真正的数据冗余处理及过程控制，并且可以从硬件安全等级上做到完全的防水、防尘、热保护、高压、过电保护等内容？

对于设计单控制器双芯片来说，在一定程度上，特别是软件上几乎可以完全做到冗余保护作用，但是对于由于某些外部环境导致的机械性故障，确是无能为力的。特别是当防水、防尘过程中无法满足需求时，两片控制器军可能失效。这是单控制器双芯片设计的一大弊端。因此，为了更好的向高等级自动驾驶系统需求兼容，一般会选择设计双域控制器双芯片单独控制方案。

3）是否可以在数据处理结果中做到相互校验，安全监测等？

在 MCU 设计中对于数据的处理除了包含通常情况的逻辑控制外，还包括对于处理结果的逻辑校验，其过程包含了数据完整性校验，数据有效性校验、功能安全相关校验等过程。

4）Soc本身是否设计安全岛提升功能安全等级？

可靠性高的处理器，监控外围电路，独立的电源和电压域，不能和其他混在一起，相关逻辑在必要时候有冗余设计。两份芯片来比较，看每份输出是否一致，有限状态。设计IP时候需要注意内部子模块在接口上是否看到。功能安全岛的作用主要是利用锁步的方式实现更高级别的安全等级（一般可达到ASIL-D），Soc芯片本身需要设计安全岛用以提升自身功能安全等级。其中锁步类型包含控制、数据仲裁、系统监控、系统生命周期、时间管理等。

5）芯片之间的连接如何考虑数据带宽、时钟同步等因素？

芯片之间的数据连接及通信过程主要包含如下几个类别：CAN、GPIO、PCIe、SPI、Ethernet、UART、SerDes。各种连接所具备的特征如下：

GPIO是一种通用的数据接口，一般适用于大多数芯片之间的数据传输。如果是单控制器双芯片设计过程中，两个芯片之间主要通过ehtenet、SPI、PCIe、UART进行通信，如果通信需求实现的高速率、大数据量、高效率，则系统主要选择PCIe进行，比如两个芯片之间需要传输表格或像素级点云数据，但要注意这种传输类型对于数据链路的带宽占有量比较大。如果通信需求对于传输数据没有特别高的稳定性要求，可以采用UART进行传输，这样可以弥补PCIe需求大带宽的特点。此外，一般情况下，Soc与MCU的连接一般是通过ehtenet、PCIe进行传输，可以实现将Soc的数据高效传输至MCU，这里需要注意的是在连接设计上两者的区别，如果是需要对传感器信号进行时标同步至控制器，则一版采用Ethernet效果更优。而SPI设计来说相对简单、高效。

以上涉及的内容会完全影响到对于域控制器的硬件设计结果。

平台化软硬件架构

系统功能架构上主要包含设计实现功能的应用软件层及底层驱动处理层。分别由中央域控制器的MCU芯片及SOC芯片进行控制处理，当然其中也有功能交叉。

其中，底层驱动处理层一般是由Tier2供应商进行设计开发的Soc芯片，处理任务主要包含如下：

1）传感器原始数据处理：

参照下一代自动驾驶传感器架构而言，其原始数据的处理包括了激光雷达原始点云数据处理，摄像头原始RGB图像数据处理（包含一定程度的深度学习模型训练），毫米波雷达原始微波处理。下图表示了一种典型的传感器数据处理架构：

 

2）基础驱动处理：

主要包含文件系统读写、线程控制，同时集成高速、大数据吞吐量、灵活和智能的网络子系统；集成硬件加速器提高数据包和网络安全处理，以降低延迟性和软件复杂度；集成以太网交换机降低系统成本，缩小系统体积。

另一方面，应用软件位于平台的最顶层，通常由主机厂负责定义和开发，一般是实现四方面的功能子项。

1）用户可感知的应用软件功能，如HWP、TJP、NoP等。如上这些自动驾驶子功能拆解开来的功能模块主要包括激光雷达感知软件、侧向摄像头感知软件开发、激光雷达/侧向摄像头/V2X融合软件开发、源融合定位软件开发、规划决策-控制软件开发等方面。

2）是数据记录Log。一般指对自动驾驶过程中异常情况的有效记录，服务内容包括意外事件记录EDR和行车记录DVR。

3）包含数据运行过程中的实时监控（如芯片状态监控、执行监控、传感器状态监控、安全监控），并将监控结果反馈给后台进行总体管理。

4）四是软件自动升级，包含手动升级与自动升级。这一方面包含设置云端接口、OTA服务，动态交通信息、传感数据上传、驾驶员状态数据上传等。

5）是故障诊断功能。诊断功能包含对于传感器、控制器以及关联对手件的整体诊断，其中还有对于整个实现功能的诊断监控。

如下图表示了一种典型的自动驾驶应用平台软件开发模块架构。

 

如上这些部分的功能项一部分是由Soc进行处理，如感知前/后融合，源定位软件开发，因为这些都需要具备较高的算力与数据带宽。另一部分逻辑算力如决策规划及控制执行方面是由MCU进行处理，这些数据处理对算力要求并不是很高，但是对于数据处理的实时性要求较高。

总结

随着下一代自动驾驶程度的提高，汽车自身所产生的数据将越来越庞大。据估算，假设 一辆自动驾驶汽车配置了GPS、声纳、 相机、雷达和激光雷达等传感器，则上述传感器每秒钟产生的数据将是：50kB（GPS）+10-100kB（声呐）+20-40MB（相机）+10-100kB（雷达）。将上述数字相加后可知，一辆自动驾驶汽车每天将产生约4000GB待处理的传感器数据。由此，有志于投入自动驾驶系统研制的汽车制造商、IT公司以及初创科技公司们不得不面对一个复杂的难题：如何使自动驾驶汽车能够实时处理如此海量的数据，并在提炼出的信息的基础上，得出合乎逻辑且形成安全驾驶行为的决策？

解决上述难题的两个关键环节在于提出合理的自动驾驶系统架构，本文正是基于如上现有问题进行阐述和分析，用于重点区分数据处理在终端传感器处还是在中央处理器完成，这一过程需要对中央控制器的实际算力进行重新评估。同时如何将数据从终端传感器传输到中央处理器，且当对并非位于一处而是遍布自动驾驶汽车车身的多个传感器进行数据融合时，需要专门考虑传感器和中央处理器之间的连接设计和线路布置需求。