从TeslaAP2.0/2.5运算单元看未来无人驾驶域控制器的设计趋势
雷锋网·新智驾按：本文来自未来出行服务商新悦智行联合创始人&CEO徐超、联合创始人&CTO李林峰的技术详解。新悦智行目前业务线包括新能源整车和L3级无人驾驶整合方案。今年4月，新悦智行发布了自主研发的WiseADCU无人驾驶运算控制单元。在本文中，作者对TeslaAP2.0/2.5运算单元进行了拆解，并结合之前国际先进的无人驾驶运算控制单元的平台分析报告进行了资料分享。雷锋网(公众号：雷锋网)·新智驾获作者授权转载此文。
先看一组图片，这是目前几乎所有主机厂和无人驾驶新兴团队的标准配置：
杂乱不堪的后备箱
那么通常情况下，这里面会有哪些东西呢？业内通常的标配就是工控电脑（GPU运算卡、CAN卡）、UPS电源/稳压电源、交换机、低压电源分配器、GNSS/IMU模块、车辆控制单元（通常是dSPACE MicroAutobox）、散热及冷却机构等。如果采用了一些特定的传感器，则还会有独立的工控机、融合器、接口和电源模块等。再加上互联的线缆、高低压电缆以及HMI和调试用的接口，其规模不亚于一个小型企业的机房。
正是因为如此，新悦智行才会设计自己的WiseADCU，正如Tesla的Autopilot运算控制单元、Audi的zFAS等等。自动驾驶从实验室走向量产，必然需要在提升可靠性的同时降低体积、成本和功耗。当然，NVIDIA提供了Drive系列，NXP也有BlueBox，但这些都只是“开发工具”，而主流零部件供应商则宣布了他们的运算控制单元或者域控制器，对于主机厂来说，也只是黑盒子的存在，而且很有可能会捆绑其底盘电子相关产品。新悦智行的WiseADCU则是用开放的软硬件合作模式，为主机厂和无人驾驶团队“赋能”，使其完全掌握无人驾驶运算控制系统的软硬件规划和定义能力。
一、NVIDIA Drive PX2
首先分析的是Drive PX2 AutoChauffeur开发板，这是NVIDIA Drive系列目前公开的最新的一代产品：
NVIDIA的Drive系列
虽然基于Xavier的下一代SoC已经公开，但是依据N家的产品节奏，保守估计明年Q2才有机会看到车载级的产品和开发板公开发售。
NVIDIA的Drive PX2版本
而在Drive PX2中，AutoChauffeur是一个定义面向L3的版本，其运算部分的配置是双Parker SoC外加双MXM3.1接口的Pascal架构独立运算单元，而更低一些的AutoCruiser是单颗Parker SoC，更高一级的Full Autonomy是由两个AutoChauffeur组成。AutoChauffeur和AutoCruiser都采用了Infineon的TriCore AURIX TC297作为ASIL-D的功能安全控制单元。
Drive PX2 AutoChauffeur区别
实际上，AutoChauffeur也有至少两个不同的版本，其区别在于Parker之间的互联模式，其中一个采用Altera的Cyclone V FPGA + ARM SoC和以太网互联，而另一个则是采用了PLX的PEX8724非透明PCIe交换芯片和以太网互联。
Drive PX2 AutoChauffeur框图
因为手头没有FPGA的版本，也没有FPGA的实现逻辑，只能分享一下PEX版本的情况，简单来说，采用PEX的版本，可以将独立的Pascal GPU挂在任何一颗Parker SoC上，采用PCIe 4x互联。
正面
背面
12路FHD摄像头，在PX2上采用了Maixm定制的GMSL-CSI2转换芯片，这是一颗非公开物料。
标准的Drive PX2相对比较公开，虽然我们手头有Drive PX2的硬件，但因为保密协议和相关法律条款，以上的分析虽然都是实物分析，但均可以找到互联网公开的资料来源。
前段时间疯传Tesla（Tesla）正在和AMD合作打造自己的无人驾驶芯片，这种可能性当然存在，打造自己的芯片也理应是Tesla的必然选择。但是作为一个曾经在农企（AMD）工作过的人，结合对Drive系列平台尤其是DriveWorks相关框架的实际应用和理解，农企在自动驾驶领域的积累比起兵工厂（NVIDIA）可能差了不止3、5年。在成型的DriveWorks框架和海量的基于CUDA的算法面前，OpenCL还是非常苍白。实际上，农企在工控机领域是有长期积累的，以前脱胎于Cyrix后来被NatSemi收购的Geode系列，还有农企自己的AM186~AM486系列直到今天还在供货。只是在生存的窘境面前，面对牙膏厂和兵工厂的双重挤压，一个连笔记本处理器都不太敢碰的企业，又有多少精力和勇气去进入无人驾驶领域？
话说回来，在目前传感器大都具备一定的算法处理能力，能做到结果输出。如果不是极端的成本优化和控制需求，是否需要重度依赖CUDA、OpenCL和各种CV加速呢？
二、Tesla Autopilot 2.0
做了一些背景铺垫，大家最关心的莫过于Tesla的Autopilot运算单元分析，之所以会有前面对Drive PX2的描述，是因为此前看了很多国内外的文章和分析，大家都将Tesla Autopilot硬件直接说成“采用NVIDIA Drive PX2”，这一点是不准确的。至少Autopilot2.0和2.5都不是Drive PX2任何一个版本的简单复制。
简而言之，AutoPilot2.0基本等同于AutoChauffeur的一半，或者AutoCruiser加上一块Pascal独立运算单元，同时增加了GNSS接收芯片。而AutoPilot2.5则是AutoChauffeur去掉一块Pascal独立运算单元，另一个则从MXM插卡变成板载，增加了一套基于Intel芯片和NXP MCU的仪表/导航板的整合系统，同时将TBOX和GNSS接收整合在板。
Autopilot2.0外观，双风扇
风扇下面的散热片
Autopilot2.0主板正面
Autopilot2.0主板背面
和Drive PX2 AutoChauffeur对比，Autopilot2.0去掉了PEX PCIe交换芯片，增加了Ublox NEO-M8L GNSS接收芯片，将Maxim的GMSL摄像头接口换成了TI的FlatLink III芯片，从12路GMSL变成6路LVDS，保留两路GMSL视频输出和一路HUD输出。增加了一路22W单声道Class D功放和一颗立体声Codec，9路CAN总线，其中有4路没有焊接收发器。保留了三路以太网，其中一路没有焊接，另外两路也没有采用BroadR Reach，而是标准AVB，采用散热片加双风扇风冷散热。
简单列举一下主要芯片的型号：
1、 NVIDIA “PARKER” P94W97.01P TA795SA-A2，Parker SoC主控，内置了256 CUDA单元，4核A57 64位ARM和2核丹佛64位ARM
2、 四颗Samsung DRAM K4F8E3S4HBMHCJ
3、 NVIDIA GP106-505-KC的MXM插卡，4GB GDDR显存，预留4个焊盘，最大可以到8GB，属于GP106系列去掉显示部分的运算卡，有1280个CUDA运算单元
4、 INFINEON TriCore AUTRIX TC297TX-128 ASIL-D MCU
5、 UBlox NEO-M8L GNSS接收模块
6、 Toshiba eMMC和Spansion NOR Flash
7、 Marvell 88EA1512 AVB/以太网收发器
8、 Marvell 88EA6321 7口AVB交换芯片
9、 Maxim MAX9260 GMSL显示输出
10、 TI DS90UB964 LVDS摄像头输入
结合对DriveWorks的实际应用和性能评测，Autopilot2.0这样的硬件架构，到底能完成几级的自动驾驶呢？在此，做一些分析和分解。
AP2.0接口分析
先说CPU部分，4xA57+2xDenver+Aurix，其运算能力足以处理自动驾驶相关的HMI、总线通讯、结果输出型传感器融合、GNSS数据处理以及车辆运动控制，大概还有一半的冗余。
而GPU则是256+1280个CUDA单元，以6个摄像头的配置，4个作为环视和SFM，两个前视用于车道线、行人/目标检测、交通标识检测以及前向空间(Free Space)的检测，按DriveWorks提供的代码和资源占用情况，其能力是不太够满足同时运算的要求。
SFM先放到一边，车道线、目标和交通标识检测大概要占用90%左右的GPU，而对这些目标做标记、编号以及识别则需要40%左右的GPU，可能的做法是对场景进行进一步分解，不追踪和识别全部的目标，这里就是Tesla量产Autopilot和NVIDIA Drive开发平台的重要差别，但无论如何，1536个CUDA即使是为运算优化的GP106-505，我们判断单纯依靠Autopilot的运算能力是否能达到完整的L3还是有些困难的。
实际上，如果按照Tesla和Mobileye分手之前来说，后者处理了大部分前向视觉相关的部分，AP2.0应该足够完成L3。
板载的NEO-M8L GNSS接收芯片，则是一个单频多模2.5米CEP自动驾驶精度的模块，即使配合IMU，单独来说应该也还达不到高精度定位导航要求的精度和可靠性。
三、Tesla Autopilot 2.5
对于Tesla Autopilot 2.5，新悦内部一直称之为AP3或者AP NextGen，拿到这个单元时，我们并不知道其具体的车型，但是按照架构和形态猜测，应该是用在Model 3上。国外包括Tesla官方论坛内称之为Autopilot 2.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进行分析，都肯定会有一些偏颇，毕竟不是原始设计，但是这样的对标分析，结合芯片行业的从业经历，多少能得到不少有用的信息。
Tesla的几代产品从PCB工艺角度来说，都相当不错，全部都是12层盲埋孔，很多连接器和芯片都是定制型号，例如MXM，Tesla设计的是带锁扣和托架的，连接相当稳固，这样的连接器在zFAS一代Prototype上也能看到。
而从接口的角度来看，Tesla大量采用了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硬件架构基于以上理念设计，新悦智行CTO李林峰则调用了其武汉海微科技核心汽车电子团队平均十年以上的硬件和驱动工程师共同参与，和新悦的工程师一起完成了理念到实际产品的转化。从第一版的情况来看，只有30多个Minor Bugs，对于一个600多元器件、9000多焊盘的复杂系统来说，非常不易。
基于新悦智行WiseADCU域控所做的网络架构
从一些细分领域来看：
网络架构，基于AVB演进的TSN将会是重要的架构，但是不能因为有了TSN就放弃CAN/LIN，对于一些成熟和简单的场景，CAN/LIN无论成本还是可靠性，都是有保障的。
新悦智行WiseADOF系统架构
操作系统，Drive系列开发工具的Ubuntu Linux及其内核都需要做深入的改造和优化，相信Tesla做了并且一直在做这个工作。首先，不能完全否定Linux的可靠性，很多人一谈到Linux就认为其不如某些商用实时系统可靠，从宏观的层面来说，Linux系统内核发展到4.x版本，其代码的庞大程度确实超过某些特定的商用实时系统，但是从微观角度来看，单纯的内核，如果不考虑驱动、文件系统和协议栈这些的话，其实大家都差不太多。
信息安全、传感器本身的安全、传输层的安全以及系统的安全等都需要综合考虑，作为一个1997年开始涉足网络安全和嵌入系统的老司机，听过一句话非常经典“堡垒往往是从内部被攻破的”。这是一个系统工程，后面可以单独弄一系列长篇大论。
车辆控制，需要ASIL-D的功能安全，丹诺西城的李丹曾经作为Fujitsu/Spansion的老员工，对ASIL-D和LockStep相关的知识做了非常详细的讲解，这位老司机同样也是WiseADCU的核心专家和智囊。加上吉大底盘和运动控制国家重点实验室多年的积累和积淀，以及对车辆运动控制的实践，WiseADCU后续和Matlab/Simulink以及各种主流车辆仿真软件的的深度融合也符合未来主流自动驾驶域控趋势。WiseADCU采用了ASIL-D级的MCU硬件配合AutoSAR规范的系统架构，并实现多种仿真软件的接口，其主要目的是在规模化应用阶段开始取代MicroAutobox等接口层硬件。
总的来说，未来无人驾驶域控，要有好的整体架构设计、完整细致的框图以及有实战经验的团队，满怀敬畏，开放心态，跨界交流和实力团队的务实工作才能设计和落地深度跨界的产品并保持其不断的延续和演进。
关注新智驾（公众号：AI-Drive），回复“拆解特斯拉”获取TeslaAP2.0/2.5运算单元拆解过程的高清细节图。
本文作者：新智驾
本文转自雷锋网禁止二次转载，原文链接