文章来源：新智驾 作者：徐超 李林峰
先看一组图片，这是目前几乎所有主机厂和无人驾驶新兴团队的标准配置：
杂乱不堪的后备箱
那么通常情况下，这里面会有哪些东西呢？业内通常的标配就是工控电脑（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 等接口层硬件。
总的来说，未来无人驾驶域控，要有好的整体架构设计、完整细致的框图以及有实战经验的团队，满怀敬畏，开放心态，跨界交流和实力团队的务实工作才能设计和落地深度跨界的产品并保持其不断的延续和演进。【完】
欢迎关注 GeekCar 微信公众号： GeekCar 极客汽车 （微信号：GeekCar）& 极市 （微信号：geeket）。
