拆解特斯拉AP2.0/2.5运算单元看未来无人驾驶域控制器的设计趋势2

结合对DriveWorks的实际应用和性能评测，Autopilot2.0这样的硬件架构，到底能完成几级的自动驾驶呢？在此，做一些分析和分解。

图1 系统安装位置

图：AP2.0接口分析

先说CPU部分，4xA57+2xDenver+Aurix，其运算能力足以处理自动驾驶相关的HMI、总线通讯、结果输出型传感器融合、GNSS数据处理以及车辆运动控制，大概还有一半的冗余。

而GPU则是256+1280个CUDA单元，以6个摄像头的配置，4个作为环视和SFM，两个前视作为车道线、行人/目标检测、交通标示检测以及前向空间(Free Space)的检测，按DriveWorks提供的代码和资源占用情况，其能力是不太足够满足同时运算的要求，SFM先放到一边，车道线、目标和交通标示的检出大概要占用90%左右的GPU，而对这些目标做标记、编号以及识别则需要40%左右的CPU，可能的做法是对场景进行进一步的分解，不追踪和识别全部的目标，

这里就是特斯拉和量产Autopilot和nVidia的Drive开发平台的重要差异化，但无论如何1536个CUDA即使是为运算优化的GP106-505，我们判断单纯依靠Autopilot的运算能力达到完整的L3还是有些困难的。实际上如果按照特斯拉和Mobileye分手之前来说，ME处理了大部分前向视觉相关的部分，AP2.0应该足够完成L3。

板载的NEO-M8L GNSS接收芯片，则是一个单频多模2.5米CEP自动驾驶精度的模块，即使配合IMU，也还达不到高精度定位和导航的需要。

补充：

【Autopilot 2.5】

新悦内部一直称之为AP3或者AP NextGen，拿到这个单元时，我们并不知道其具体的车型，但是按照架构和形态猜测，应该是用在Model 3上面，国外包括特斯拉官方论坛内称之为Autopilot2.5的单元。

图：Autopilot2.5外形，水冷

图：Autopilot 2.5外壳分解

之所以我们分析认为AP2.5是给Model 3使用的，因为这个单元正反面一共有两块板，一块是和AP2.0类似，但是多了一个Parker的自动驾驶控制板，另外一个是基于Intel一颗保密型号的芯片加上SPC5748G MCU，并且带有Telit Modem和LG的BT/WLAN模块及8声道Class SB-I的数字功放。从Model 3来看，其取消了仪表，将信息娱乐系统和仪表做到了一起，那么SPC5748G则是处理功能安全的MCU，也就是仪表系统可靠性的保证。而Intel的SoC则是做信息娱乐导航或者一些数据处理。这两块电路板之间并没有物理连接在单元内部，只是共用了水冷散热部分，以及整合到同一个金属外壳之中，不计散热部分你，其主体部分体积并没有比AP2.0大太多。

图：AP2.5多角度视图

以下逐一分析自动驾驶部分的主板和信息娱乐部分的主板：

图：AP2.5自动驾驶主板正面

图：AP2.5自动驾驶主板背面

接口部分，因为AP2.5（或许是因为我们拿到的并非Release版本）标注了所有接口的功能，所以不用想AP2.0去推测。按照接口标注，该主板支持如下接口：

1、 GPS天线

2、 REAR CAM后摄像头

3、 SELFIE内置驾驶员摄像头

4、 MAIN CAM前置主摄像头

5、 REPEATER两路转发

6、 B-PILLAR B柱两路摄像头

7、 FISHEYE NARROW两路窄幅鱼眼摄像头

8、 一系列IO，CAN和电源

9、 单路以太网

10、 USB

11、 MCU外接口

主要芯片如下：

1、 两颗NVIDIA “PARKER” PC5S58H.S8P TA795SA-A2，Parker SoC主控，内置了256 CUDA单元，4核A57 64位ARM和2核丹佛64位ARM

2、 六颗Samsung DRAM K4F8E3S4HBMHCJ，其中四颗给A，两颗给B

3、 NVIDIA GP106-510-KC的板载芯片，4GB GDDR显存，应该是AP2.0的改进型号

4、 INFINEON TriCore AUTRIX TC297TX-128 ASIL-D MCU

5、 UBlox NEO-M8L GNSS接收模块

6、 一颗Toshiba eMMC给A和Spansion NOR Flash两颗，AB各一颗

7、 Marvell 88AE1512 AVB/以太网收发器

8、 Marvell 88EA6321 7口AVB交换芯片

9、 三颗TI DS90UB964 LVDS摄像头输入

10、 一颗TI DS90UB954 LVDS摄像头输入

11、 和AP2.0一样的TAS5421单声道数字功放和TLV320AIC3104立体声Codec

12、 FTDI 1647-C串口转USB调试芯片

13、 CAN收发器若干

取消了明显的显示输出部分，是否交给信息娱乐主板来处理呢？

图：AP2.5信息娱乐主板正面

图：AP2.5信息娱乐主板背面

接口部分：

1、 FTDI USB调试

2、 WLAN天线

3、 BT天线

4、 LTE USB调试

5、 CAM IN摄像头入

6、 CAM OUT摄像头出

7、 BMP调试口

8、 BMP LPC调试口，谈到LPC(Low Pin Count)，基本可以认为那个INTEL的芯片是x86系列。

9、 PMIC调试接口

10、 GSM开关

11、 BROADREACH网口

12、 CAN/POWER接口

13、 ETHERNET网口

14、 AUDIO接口

15、 USB接口

而主要芯片如下：

1、 一个带有4G内存的INTEL CONFIDENTIAL的模块

2、 模块附近有一个NOR Flash和一片eMMC，可以理解为BIOS/EFI和硬盘

3、 NXP SPC5748GSMMJ6一颗

4、 LG Innotek B216C BT/WLAN模块

5、 Marvell 88EA6321 7口AVB交换芯片

6、 TI DS90UB949串行化和TI DS90UB940解串芯片各一颗

7、 还有一颗未知厂牌的WQ1214CS芯片

8、 两颗ST TDA7802 Class-SB-I数字功放，每颗包含四路28瓦标称72瓦峰值。一共8路

9、 一颗TJA1059，一颗TJA1043

10、 以及一个类似MiniPCIE的4G模块插槽

从音频配置和SPC5748G以及接口配置来看，这基本就是信息娱乐系统单元没跑了，但是为何上面没有明显的显示接口？难道Model 3的液晶屏当中，还像之前的Model S和Model X用一套Tegra 3来做显示？

前面提到，AP2.0是Parker+Pascal，而AP2.5在自动驾驶部分则是双Parker+Pascal，实际上按我们的理解Parker本身的CPU处理能力之前就有剩余，而256个CUDA的增加又能带来什么样的改变呢？我们分析，实际上这个能带来非常多的好处，用一颗独立的Parker，处理一些关联度不高的任务，避免和主要的运算任务做竞争，减少了切换和资源调度的开销。这应该是Tesla从实际应用角度出发做的一个改进。

图：Model S的显示单元，T301应是Tegra 3的车规版本

回到AP2.5，刚才提到，信息系统主板上有一个Modem插槽，这个Modem长啥样呢？

图：AP2.5的Modem模块

此模块采用了Telit的LE940B6-NA车规通信模组块，并有一颗88EA1512网络芯片，从外壳结构来看，这个模块可以支持热插拔。在这里应该说Tesla的工程师应该是经过考虑的。首先USB虽然可以热插拔，但是整体来说不如以太网可靠。而且采用AVB的以太网，可以灵活配置网关和其他车内模块的可访问性。

上一代信息娱乐系统中，采用的则应该是USB链接。

图：上一代信息娱乐系统的通信模块，整合LEA-6R GPS和一颗非常特别的Gyro

继续回到AP2.5信息娱乐主板，该主板上有SIM卡和TF卡插槽，SIM卡从ICCID来看应该是美国某运营上的卡，而TF卡中只有一个分区，里面存储了一些Log，并没有地图和其他数据。

当然，分析还在继续，我们有一些有意思的“跨界工具”，例如……

写到这里，我想说，无论对PX2还是AP2.0或者2.5进行分析，都肯定会有一些偏颇，毕竟不是原始设计，但是这样的对标分析，结合芯片行业的从业经历，多少能得到不少有用的信息。

特斯拉的几代产品从PCB工艺角度来说，都相当不错，全部都是12层盲埋孔，很多连接器和芯片都是定制型号，例如MXM，特斯拉设计的是带锁扣和托架的，连接相当稳固，这样的连接器在zFAS一代Prototype上也能看到。

而从接口的角度来看，特斯拉大量采用了AVB和LVDS（包括FPDLink3和GMSL等），但是也依然保留了CAN、LIN等，作为市面上为数不多大规模量产的自动驾驶控制单元，不管其无人驾驶实际执行效果如何，这一系列控制单元无论从设计还是制造工艺，都堪称是完美的艺术品。

【从WiseADCU谈无人驾驶域控的设计】

未来无人驾驶的域控制器，其设计理念应该是前述的“高可靠、高性能、低成本、低功耗、小体积”的高度整合软硬件平台，而芯片企业、算法团队、零部件企业和主机厂之间所存在的鸿沟需要进一步的填补。

从目前公开的各种自动驾驶和无人驾驶系统架构来看，环境感知和融合发展非常迅速，但是大家都忽视了车辆本身的运动控制和线控之间的差别。不止一次在非常专业的会议和组织，听到了“车辆动力学模型和仿真是不必要的”，“环境感知融合后给出引导曲线，线控按此执行即可”这样的论断，实际上这还只是实验室阶段的无人驾驶。

新悦智行深刻认知到，简单的把车辆作为一个质心固定的刚体，是非常浅薄的理解。车身姿态和运动状况是一个层面，环境传感器是一个层面，车辆本身的能力也是一个非常重要的层面，如果不把执行器的“能力”和车辆的状态考虑在决策条件之中，是无法完成精准可靠的自动驾驶系统的。更无法满足“安全和舒适”这两个自动驾驶和无人驾驶的基本需求。

图：新悦智行的WiseADCU-L4v1

未来无人驾驶域控的软硬件架构应该充分而科学的整体规划，从系统架构上应可分为两个主要的派系，也就是域控强算法和域控弱算法。其区别非常类似分布式运算和虚拟化集中运算的差异。

设计思路方面的感想

结合新悦智行自己设计WiseADCU的历程和理解，做一些设计方面的分享。

强算法的域控从成本角度来说，能够降低前端传感器的复杂度和成本，更加高效的利用域控的运算资源和能力，对各种原始数据的融合更加合理。还能让物理架构更加清晰。

其缺点或者说挑战也非常明显：

1、 多种算法的理解、整合、优化和资源的合理调分配及调度，非常考验系统架构师的设计能力以及工程师团队的实现能力；

2、 比起ASIC处理特定的运算和数据，用CPU和GPGPU做运算，未必是最优的情况；

3、 原始数据（RAW Data）对带宽和实时性的要求都更加严苛；

4、 系统复杂度的增加，提高了出错的几率和影响程度，原本单一传感器的故障，可能会在此放大成整体系统的故障。

图：板载Mobileye EyeQ3芯片的Audi zFAS（非第一代）

弱算法的域控，简而言之就是大家做好各自的事情，按照统一的约定和协议，提供目标检测的结果，其缺点在于原始数据融合度极低，相互之间没有前后文关联，依赖统一的时间戳做即时运算形成决策结果，有些传感器本身依赖车身姿态和相关状态，需要多套系统冗余。

考虑到这样的问题，可以考虑设计可扩展架构，例如新悦的WiseADCU加入了FPGA单元，对传感器的前端数据处理和数据通路可以进行灵活配置，对于车辆状态和姿态等数据做了统一的协议和数据接口。同时兼容原始数据和结果数据的处理，前端传感器除了提供检测结果数据，同时提供一份原始数据，而WiseADCU根据原始数据取出一些特定信息进行融合及权重的分配，而不需要涉及非常专业的算法，结合所处的“域控”的地位所能采集的几乎全部数据，形成合理的“环感-车辆-权重-融合-决策-执行”的大闭环。

图：新悦智行WiseADCU硬件框图

图：基于新悦智行WiseADCU域控所做的网络架构

图：新悦智行WiseADOF系统架构

优化，相信Tesla做了并且一直在做这一点。首先，不能完全否定Linux的可用性，很多人一谈到Linux就认为其不如某些商用实时系统可靠，从宏观的层面来说，Linux系统内核发展到4.x版本，其代码的庞大程度确实超过某些特定的商用实时系统，但是从微观角度来看，单纯的内核，如果不考虑驱动、文件系统和协议栈这些的话，其实大家都差不太多。

作为一个1997年开始涉足网络安全和嵌入系统的老司机，听过一句话非常经典“堡垒往往是从内部被攻破的”。这是一个系统工程，后面可以单独弄一系列长篇大论。WiseADCU采用了ASIL-D级的MCU硬件配合AutoSAR规范的系统架构，并实现多种仿真软件的接口，其主要目的是在规模化应用阶段开始取代MicroAutobox等接口层硬件。

满怀敬畏，开放心态，跨界交流和实力团队的务实工作才能设计和落地一个深度跨界的产品并保持其不断的延续和演进。