电动汽车EEA架构

0 序言

在之前的文章里，有以运动相机为例，简单的讲了一下其系统设计。其他像手机、电脑、无人机等电子消费品，其整体的系统设计，无非是功能模块略微差异。以一个处理器为核心，在其周围加各种外设。经过很多年的发展，这些电子消费品的系统架构基本固定，逐年可能会有些细微变化。虽然我说的比较轻巧，但并不意味着，从设计到量产这些电子消费品是件容易的事，系统设计只是工程的很小一部分，众多工程师们在解决一个个细节问题中付出了诸多努力。

如果说目前还有什么电子消费品的系统架构在快速迭代的，可能只有电动汽车了。特斯拉于2012年交付了第一辆Model S，并于2013年才在欧洲和亚洲上市。

国内的电动汽车发展，可能得从2016年左右，蔚小理三家的创立开始算起。那个时候，可能很多人没有想到，一个电车时代将要来临。2016年，我刚刚本科毕业，从江苏跑到北京读研。彼时，对于新能源车和我来说，都是一个新起点。在目前新能源车大混战的背景下，不管蔚小理三家创立之初是出于什么目的，圈钱也好，情怀也罢。于我个人而言，都希望这三家最初的新势力能活下去。当新能源车市场像如今手机一样成熟稳定之后，大家回顾新能源的发展，这三家能够成为行业的记忆坐标出现。

汽车是现代工业的集大成者，因此其系统架构不会很简单。本文就试着来学习一下新能源汽车的EEA，即电子电气架构设计。本文的主体内容来自于九章智驾的文章《2万字长文说清自动驾驶功能架构的演进》，并结合其他的资料、与朋友的交流，按照我自己的思维路径进行整理。

1 什么是架构

对于一个功能模块，其要做的工作无非是外界输入、内部处理、给出驱动信号，即一个输入--控制处理--输出的过程。

那输入输出的是什么呢？以我个人的理解，电子世界里，只存在两个本质活动，能量和信息的传递和转换。自然界的三要素，其实也是物质、能量和信息。功能模块可以看作是能量和信息的载体，可以对应于自然界的物质概念。

车是一个复杂系统，会有非常多的功能。在电车时代，出于一些原因（原因在后文展开），工程师们好像并不希望每个执行器各自为政，对于若干功能，我们希望有个控制中心。

每个控制中心，相当于一个“诸侯”，管理一方天地，在工程术语里，将这一方天地称为“域”。

那这个控制中心，就称为域控制器。执行器各自为政的分布式布局带来了若干问题。

（1）算力分散，无法高效利用：分布式架构下汽车搭载数十个控制器，且为保证性能稳定性及安全性，每个控制器芯片硬件算力相对其上运行的程序都有所冗余。这就导致从整车维度，各个控制器的能力“各自为政”，无法高效协同。

（2）线束成本及重量劣势：庞大的ECU数量同样意味着复杂、冗长的总线线束。一辆高级汽车的线束使用量约2km，重量在20~30kg。在线束中，线缆材料本身重量占到线束总重量的75%左右。

（3）无法支持高带宽车内通信：在分布式ECU时代，计算和控制的核心是MCU芯片，传输的基础核心是基于传统的CAN、LIN和FlexRay等低速总线。随着ECU的不断增多，导致总线负载增加，基本上达到允许的上限了，这样容易导致信号丢帧、总线堵塞等技术难题，从而导致安全隐患。

（4）系统集成及OTA维护困难：各个ECU开发主要由各Tier1提供主机厂，主机厂由内部团队进行集成整合。对主机厂集成开发能力，供应商管理能力提出了很高的挑战。此外，分布式架构中零散的ECU布局也难以支持车载软件在线升级（OTA），从而加大了软件后期维护迭代的难度。目前OTA已经成为了新能源车提高用户体验的一个工具，使得用户常用常新。2021年部分车企的OTA情况如下所示。

那需要分成多少个域控制器呢？每个域控制器需要管理哪些功能呢？这就可以称为功能架构的设计。

每个域控制器自己也是一个小系统，这个系统内的功能该如何设计呢？这就可以称为系统架构的设计。“系统”的概念可大可小，但这里，我们将之框束在域控制器这个范围内。

多个域控制器之间需要进行“能量”和“信息”的传递和转换，这就会形成复杂的配电网络和通信网络。这就是电气架构设计和网络架构设计。

电气架构、功能架构、系统架构、网络架构是EEA不同维度的信息，下面来分别看看。

2 整车功能架构的演进

为了解决以上分布式架构的问题，不同的汽车制造商和零部件供应商针对电子电气架构的演进提出了各自的理念。2017年，博世提出了一个三段六步的演进构想。

尽管不同厂商和机构在具体方案上存在差异，但在整体方向上达成了共识——分布式架构、域集中式架构和中央计算式架构。

2.1 模块化阶段

在这种架构下，每个电控单元（ECU）与实现的功能一一对应。

在模块化阶段，ECU的数量众多，并且每个ECU负责一个特定的功能。 

2.2 集成化阶段

在集成化阶段，ECU开始集成多个功能。比如一个ECU可以同时控制雨刮和车窗。

2.3 集中化阶段

在这种架构中，进一步实现了ECU的集成，并引入了域控制器（DCU）。

在集中化阶段，整车被划分为5至7个域，每个域配置一个DCU，每个DCU管理多个ECU。

在博世经典的五域架构中，整车被划分为动力域、底盘域、座舱域、自动驾驶域和车身域，完全集成了所有控制功能。

2.4 跨域融合阶段

在跨域融合阶段，整车功能在域的层面进一步集成。在跨域融合阶段，不同厂家有不同的思路，主要分为两个方向。

具有相似性的多个域实现功能融合。

由于动力域、底盘域和车身域涉及的计算和通信具有相似性，这三个域合并成整车控制域。

整车于是形成三个域控制器，即智能驾驶域、智能座舱域和整车控制域。其中，

整车域控制器负责整车控制，对实时性和安全性要求较高；

智能驾驶域控制器负责实现与自动驾驶相关的感知、规划和决策功能；

智能座舱域控制器负责人机交互和智能座舱相关功能的实现。

下图是华为的CC架构。华为的CC（Computing/Communication）架构分为智能驾驶、智能座舱和智能车控三个域控制器，该架构专注于计算和通信两个主要领域，通过分布式网关形成环形网络，实现高速的网络数据传输，并在三个计算中心进行实时数据分析和处理，以实现整车的感知、计算能力和电源共享。 

为了构建以功能为导向的电子电气架构，汽车制造商不得不拉长后刹车灯、后位置灯、尾门锁甚至双撑杆的连接线束，跨越车身80%的距离，连接到位于车身前方的区域控制器中。

在ADAS的前后雷达、空调系统的前后制冷以及底盘系统的前后轮转向控制等方面也存在类似的问题，给线束系统带来了巨大的挑战。于是，在一些厂家的整车架构中，传统的车身域、动力域等被基于物理空间划分的区集中式架构（Zonal EEA）所取代。

在区集中式架构（Zonal EEA）中

关键组成部分包括车载中央计算机、区域控制器、基于环形连接的以太网TSN构成的主干网，以及CAN、LIN、10Base-T1s等区域内网络，双电源冗余供电和区域内智能分级供电。

车载中央计算机的核心定位是实现与智能驾驶和智能座舱相关的业务逻辑，并具备车联网功能，连接车辆和云端。

区域控制器主要充当网关、交换机和智能接线盒的角色，提供和分配数据和电力，并实现车辆特定区域的功能。区集中式架构实际上是一种"供电的分布式，计算的集中式"架构。它不仅能够集中计算资源，便于软硬件分离，也为整车各个控制器的电源管理带来了许多创新空间。

该架构的典型代表是特斯拉的Model3。Model3分为一个中央计算模块，负责自动驾驶和智能座舱的功能，另外三个区域控制器，即前、后、右车身控制器，按照物理位置，控制各执行器，为其配电和进行数据转发。

沃尔沃的EEA架构和特斯拉有点像。中央计算模块VCU+区域控制器VIU。事实上，特斯拉的Model 3早在2016年就发布了，这两年其他家OEM才慢慢跟进到这种架构。

2.5 中央域控制器

以物理位置划分的区域控制器+中央计算平台在某种意义上来说，就已经跨越到了车载电脑，即中央域控制器阶段。

理论上在中央域控阶段，整车由中央计算机进行统一管理，但由于动力、车身、底盘等领域的执行功能复杂，对实时性和安全性的要求较高，仍然会保留基础控制器进行边缘计算。这些边缘计算就可以存在于区域控制器上。所以，很难实现整车只有一个中央域控制器。

个人理解，中央域控阶段可以这么定义，将一切不需要边缘计算控制的任务都向上集中到中央域控制器。在Model3的架构中，中央计算平台只涉及了座舱和智驾，很多OEM的架构也是这么定义中央计算平台的。在真正的中央域控阶段，中央域控还会涉及一些车身控制的计算。

2.6 车云协同

随着智能网联汽车的推广与普及，尤其是车联网、5G通信、云/边缘计算等技术的快速发展，行业对于多车系统、车路系统、车路云融合系统的协同决策与控制技术越来越关注。

"车-路-云-网"系统的协同控制不仅为单车决策提供了有效的信息，还可以通过全域控制在现有车路协同基础上实现对所有交通参与者的全路段、全天候、全场景的自主控制。

这将为未来不同等级智能汽车混行的交通环境提供重要的解决方案。

车云协同需要将车辆、道路、网络和云端的信息进行融合处理。EEI具备高带宽、低时延、高可靠性的特点，并且需要合理分配车辆终端、边缘节点和云平台的算力资源。

3 智驾域相关传感器

在ECU集中化阶段，按照每个ECU（电子控制器）的功能，工程师们通常将新能源车分成5个域，即底盘域、动力域、座舱域、智驾域、车身域。

每个域包括若干ECU，一起完成这个域的整体功能。OEM目前最在意哪个域的用户体验呢？

应该是智驾域和座舱域，因为这两部分的功能对于用户来说，体验最直接，最能引发用户给钱的冲动。

每个域控制器的系统架构会随着整车功能架构也会不停的变化。

下面以智驾域为例，来看智驾域在不同功能架构下的变化。但在这之前，先简单介绍下智驾域涉及的传感器。

3.1超声波雷达

3.1.1超声波雷达工作原理

超声波雷达是一款极其常见的传感器，其还有个更通俗的名字，倒车雷达。它是汽车驻车或者倒车时的安全辅助装置，能以声音或者更为直观的显示器告知驾驶员周围障碍物的情况，解除了驾驶员驻车、倒车和起动车辆时前后左右探视所引起的困扰，并帮助驾驶员扫除了视野死角和视线模糊的缺陷。

超声波雷达USS 模块的工作原理是：

通过超声波发送探头向外发送超声波，超声波在向外扩散过程中遇到障碍物就会产生反射波，然后通过接收探头对反射波进行接收，通过发送和接收到超声波的时间差来计算障碍物的距离。

如下图所示。常用的探头工作频率有 40KHz，48KHz以及58KHz，一般来说频率越高，灵敏度越高，但是水平以及垂直方向的探测角度FOV就越小，所以一般就采用 40KHz的探头。

按照在车上的布置位置以及性能差异，超声波雷达还可以分为UPA和APA。

UPA（Ultrasonic Parking Assistant,超声波驻车辅助）超声波雷达的探测距离一般在15~250cm之间，主要用于测量汽车前后方的障碍物。

APA（Automatic Parking Assistant,自动泊车辅助）超声波雷达的探测距离一般在30~500cm之间。APA的探测范围更远，因此相比于UPA成本更高，功率也更大。APA的探测距离优势让它不仅能够检测左右侧的障碍物，而且还能根据超声波雷达返回的数据判断停车库位是否存在。

一套倒车雷达系统需要在汽车后保险杠内配备4个UPA超声波传感器

自动泊车系统需要在倒车雷达系统基础上，增加4个UPA、4个APA超声波传感器

构成前4（UPA）、侧4（APA）、后4（UPA）的布置格局。

超声波雷达不受烟雾影响，精度可达毫米级别。超声波的速度会受到温度的略微影响，其计算公式如下。

V0为温度0℃时超声波传输速度，一般取332 米/秒，T为温度，单位℃。

如果能够记录到发送探头发送超声波时间为ts，接收探头接收到反射波时间为 tr，两者时间差为Δt，则可以得到障碍物与USS 模块之间的距离L如下。

根据上述分析可以得知，其中发送超声波时间ts以及捕获到反射波时间 tr的精确度将直接影响到超声波雷达对障碍物距离的计算。

3.1.2 超声波雷达主要性能参数

超声波的性能参数主要有以下几个。

1.工作频率：工作频率直接影响超声波的扩散和吸收损失、障碍物反射损失、背景噪声，并直接决定传感器的尺寸。

一般选择40kHz左右，这样传感器方向性尖锐，且避开了噪声，提高了信噪比；虽然传播损失相对低频有所增加，但不会给发射和接收带来困难。

2.测量范围：超声波传感器的测量范围取决于其使用的波长和频率；波长越长，频率越小，检测距离越大。

3.波束角：传感器产生的声波以一定角度向外发出，声波沿传感器中轴线方向上的超声射线能量最大，能量向其他方向逐渐减弱。以传感器中轴线的延长线为轴线，到一侧能量强度减小一半处的角度称为波束角。波束角越小，指向性越好。

一些传感器具有较窄的6°波束角，更适合精确测量相对较小的物体。一些波束角为12°～15°的传感器能够检测具有较大倾角的物体。

4.测量精度：测量精度是指传感器测量值与真实值的偏差。超声波传感器测量精度主要受被测物体体积、表面形状、表面材料等影响。

被测物体体积过小、表面形状凹凸不平、物体材料吸收声波等情况都会降低超声传感器测量精度。测量精度越高，感知信息越可靠。超声波雷达的定位精度一般在1cm-3cm。

5.抗干扰性能：超声波为机械波，使用环境中的噪声会干扰超声波传感器接收物体反射回来的超声波，因此要求超声波传感器具有一定的抗干扰能力。

3.1.3 超声波雷达系统

超声波雷达的系统级框图如下,这里不展开其内部的原理设计。

一般的，超声波雷达需要外部输入脉冲宽度调制波PWM到模块中，作为激励脉冲驱动内部电路，从而使得超声波发送探头发送超声波信号。

接收方面，处理器通过GPIO或硬件捕获等方式捕获超声波雷达的回波，通过定时器中的时间差来计算超声波发送接收时间差。

下图是TI 相关技术文档中，超声波接入的框图，可以看到，超声波雷达对于处理器的资源占用并不高。也有的超声波雷达以DSI3总线接入域控制器。

3.1.4 超声波雷达供应链

超声波雷达传感器领域主要公司有国际供应商博世、法雷奥、村田制作、尼赛拉，国内供应商奥迪威、上富股份等。

这些供应商可以分为三个梯队

第一梯队为国际知名供应商博世、法雷奥等

第二梯队为国内知名供应商辉创电子、航盛电子、同致电子等

第三梯队为行业 初创企业晟泰克、辅易航等

3.2 毫米波雷达

3.2.1 毫米波雷达原理

毫米波雷达是工作在毫米波波段探测的雷达，频段一般为30 GHz ~ 300 GHz， 波长 1~10mm，介于微波和厘米波之间，兼具有微波雷达和光电雷达的一些优点。

目前各个国家对车载毫米波雷达分配的频段各有不同，但主要集中在24GHz和 77GHz，少数国家（如日本）采用60GHz频段。

在电磁频谱中，这种波长被视为短波长，也是该技术的优势之一。

毫米波雷达相比厘米波雷达具有体积小、易集成和空间分辨率高的特点。所以处理毫米波信号所需的系统组件（如天线）的尺寸也确实很小。短波长的另一项优势是高准确度，77GHz左右（对应波长约为 4mm）的毫米波系统将能够检测小至零点几毫米的移动。

根据电磁波发射的方式不同，毫米波雷达主要有脉冲和连续波两种工作原理，车载毫米波雷达用的基本上都是线性调频连续波，即LFMCW。

FMCW毫米波雷达系统简图如下。

FMCW雷达系统主要包括收发天线、射频 前端、调制信号源和信号处理模块等。

（1）FMCW调制信号发生器经过压控振荡器（VCO） 产生高频信号（GHz级别），一部分能量耦合输入混频器作为本振信号，另一部分能量经功率放大器（PA）由发射天线以电磁波的方式向空中辐射。

（2）电磁波在空气中向前方传播过程中如遇到目标则会小部分反射，反射回来的回波信号被接收天线截获形成电信号。

（3）回波信号经低噪声放大器（LNA）放大，与本振信号在混频器进行混频，输出一个较低的差拍频率（一般为MHz级别），差频信号含有目标和雷达之间的距离和相对速度等信息。

（4）然后通过带通滤波器（BPF）放大滤波，A/D转 换，对所得到的数字信号作FFT（快速傅里叶变换），进行频谱分析，便可以获得目标和雷达之间的距离、相对速度及方位角等信息。TI的技术文档《毫米波雷达传感器基础知识》里，详细讲了如何计算结果。

毫米波雷达的优势在于不受天气影响，即使是恶劣天气和光照情况下也能正常工作，穿透烟雾、雨雪、灰尘能力强，具有全天候、全天时的工作特性，且探测距离远、精度较高、被广泛用于车载距离探测，具体应用包括自适应巡航、碰撞预警、自动紧急制动、盲区探测等。

但劣势同样明显，包括无法识别物体颜色，视场角较小，需要多个雷达组合使用，同时对行人的反射波较弱，难以识别，并且对金属表面非常敏感，一个弯曲的金属表面会被误认为是一个很大面积的表面，在隧道里效果不佳。未来随着搭载毫米波雷达车辆增加，相近频率的毫米波会相互干扰、降低了信噪比、严重时甚至会使雷达“致盲”。

3.2.2 毫米波雷达性能参数

毫米波雷达的性能参数主要包括三个维度。

（1）距离：距离精度、距离分辨率、最大探测距离。

（2）速度：速度精度、速度分辨率、最大不模糊速度。

（3）角度：角度精度、角度分辨率、最大角度范围。

3.2.3 毫米波雷达系统

很多供应商对于毫米波雷达有成熟的芯片解决方案。

毫米波雷达内部的处理器通过主机控制接口给IC发送指令，IC通过CSI2接口反馈雷达数据，处理器进行处理分析。毫米波雷达整机可以通过例如车载以太网/CAN这样的总线接入到域控制器。

毫米波雷达在ADAS上应用大致分为前向雷达和后向雷达，前向包含自适应巡航ACC、自动紧急制动AEB、前方碰撞预警FCW、主动车道控制ALC、行人检测系统PDS，后向包含盲点监测 BSD、变道辅助 LCA、后方碰撞预警 RCW、开门报警DOW、倒车碰撞预警RCW等等。

3.2.4 毫米波雷达供应链

毫米波雷达关键技术被外商垄断，集中度较高。在全球毫米波雷达市场上，占主导地位的是德国、美国、日本等国家。

目前毫米波雷达技术主要被博世、大陆集团等厂商垄断；其中，77GHz毫米波雷达技术被垄断于博世、大陆、德尔福、电装、TRW、富士通天、Hitachi等公司手中。

3.2.5 拓展-4D毫米波雷达

传统毫米波雷达仅可探测距离、方位以及速度三个维度，而最新的4D 毫米波雷达在传统功能基础上，多出了高度这一维信息，即具备测高能力，因此可以有效地解析空中的天桥、 路牌，地面的减速带、金属井盖等目标的轮廓和类别，进而感知传统毫米波雷达无法识别的细小物体、静止物体或者横向移动的障碍物等。目前来看，各家OEM对4D毫米波雷达都有浓厚兴趣，毕竟特斯拉带了个头，想要加装4D毫米波雷达。

3.3 摄像头

3.3.1 车载摄像头介绍

相比于毫米波雷达和激光雷达，车载摄像头成本低、硬件技术相对成熟，核心优势在于能够识别物体内容（如辨别指示牌与道路标识），因此成为率先装车的核心传感器。关于摄像头的工作原理，可以查看之前的文章。

相比于雷达等其他传感器，摄像头的优点是采集的数据量更多，也最接近人眼获取的周围环境信息，当前车载摄像头分辨率主要以720P、1080P为主，与人眼接近，并且技术成熟、成本低。

但缺点同样明显：

首先是基于视觉的感知技术受光线、天气影响较大，在恶劣天气和昏暗环境下性能难以得到保证；

其次对物体的识别基于机器学习数据库，需要的训练样本大、训练周期长，也难以识别非标准物体；

最后，广角摄像头存在边缘畸变，得到的距离准确度较低。

摄像头按安装位置不同可分为前视、环视、侧视、后视和内置五大类。

1. 前视摄像头包括单目、双目和多目类型，能够实现 FCW、LDW、TSR 等功能；
2. 侧视摄像头又分为前置和后置两种，其中前置侧视摄像头能够参与识别交通标识（TSR）；
3. 环视摄像头一般为4个，装配于车辆四周，能够实现道路感知和全景泊车辅助（SVC）；
4. 后视摄像头主要用于泊车辅助（PA）；
5. 内置摄像头安装于车内驾驶座位前方，实现DMS、OMS等功能。

单车平均搭载摄像头数量也将随着自动驾驶级别升级同步提升，L1/L2 级别为 3-5 颗，L3 级别大约为 8 颗，到了 L4/L5 级别将增加至10-20 颗。

3.3.2 车载摄像头接入

在车载摄像头里，一幅图像数据经过ISP 处理完成后，接下来就是考虑以怎样的方式传输出去。像环视、倒车后视摄像头等，其在车上安装的位置往往与中央处理器相隔少则数十厘米，长则数米的距离，考虑到信号稳定性和线束成本等因素，决定了摄像头必须采用串行传输的方式。

在车上，常用的有GMSL和FPDlink。其中GMSL是美信开发的总线，FPDlink是TI开发的总线技术。下图是FPDLINK的典型应用示意图，GMSL和FPDlink的底层技术都是Serdes。车上的摄像头很多，所以对于智驾控制器部分，需要提供足够多的MIPI接口才行。

3.3.3 车载摄像头供应链

车载摄像头包括镜头、模组、芯片、软件算法等。

• 镜头厂商中，舜宇光学全球第1，国内厂商联创电子和欧菲光亦有所布局；
• CMOS 芯片中，安森美全球第 1，此外还有索尼、三星、韦尔股份（豪威科技）、思特威等；
• 软件算法主要厂商有 Mobileye、地平线、极目等。

OEM通常直接买模组，很少会自研摄像头。

模组厂商中，国外厂商包括大陆、麦格纳、法雷奥，中国厂商有比亚迪、德赛西威、欧菲光等。

3.4 激光雷达

3.4.1 激光雷达工作原理

激光雷达通过发射激光，然后根据反射激光的时间差来探测物体的距离，探测距离可达300m ，工作频率为100000GHz，波长集中在600-1000nm之间，由于其波长短精度高，可以探测物体距离和表面形状，测量精度可达厘米级。

此外，还可用于车辆定位，自动驾驶汽车定位 除了依赖 GNSS 系统，还依赖激光雷达生成的点云与数据库中的高精地图做对比，从而得出汽车所在精确位置，精度可达厘米级。

激光雷达整个系统可以分为激光发射、激光接收、扫描系统、信息处理四个大块。

个人觉得，相对于其他传感器，激光雷达的技术难度要高几个level。

激光雷达的优势在于能够很好的探测障碍物的距离、大小、表面形状，提高了障碍物检测的准确性，算法比摄像头更为简单，抗有源干扰能力强，定向性好，测量距离远，时间短，大多数整车厂、Tier1认为激光雷达是 L3 及以上级别自动驾驶必备的传感器。

当然也存在一定劣势，包括在雨雪云雾天气下衰减严重，后期处理需要大量的坐标系转换，对硬件（CPU、 GPU、FPGA）要求高，技术门槛和成本较高。

3.4.2 激光雷达的主要参数

激光雷达的主要参数如下。

3.4.3 激光雷达系统接入

激光雷达通常以千兆以太网接入域控制器，但将来随着线束等性能提升，有可能需要用到10G的以太网。

3.4.4 激光雷达供应链

外国厂商如法雷奥、Velodyne、Luminar、 Innoviz起步较早，在技术和产品具备一定的先发优势。

禾赛科技、速腾聚创、图达通、华为、大疆等企业的产品在行业内具备较强的竞争力，各方势力百花齐放。2021-2022年激光雷达上车的信息如下。

3.5 传感器对比

对比摄像头、超声波雷达、毫米波雷达、激光雷达几类常用自动驾驶传感器，在性能及使用上各有优劣。

• 摄像头技术成熟、造价低，也是唯一能识别颜色和标识的传感器，但是受光照、天气影响大，机器学习数据库训练样本大、周期长。
• 超声波雷达受天气干扰小，但是测量精度差，距离短；
• 毫米波雷达不受天气影响，穿透烟雾、雨雪、灰尘能力强，探测距离远，但无法识别物体颜色，视场角较小，对金属表面非常敏感，在隧道里效果不佳。
• 激光雷达能够很好的探测障碍物的距离、大小、表面形状，算法简单，但是在雨雪云雾天气下衰减严重，技术门槛和成本较高。

各传感器的具体对比如下图所示。

4 智驾系统架构演进

介绍完了智驾相关的传感器，来看下智驾的系统架构演变。

智驾分为多个等级，每个等级的说明如下。

行业内认为智驾应该支持以下功能。每个等级下需要支持的功能不同，目前各家OEM做的比较好的，能够实现多数L2的功能，正朝着L3努力。

关于智驾的各个功能，九章智驾也有一篇文章进行了说明，《详解智能驾驶的功能与场景体系》。

4.1 分布式架构

智驾系统在分布式架构下的框图如下所示。根据速度场景的不同，智驾分为行车和泊车两个场景。

在分布式架构下，横向ADAS功能（车道居中保持、车道居住辅助）由集成了SOC（如EQ4）的camera实现，纵向ADAS功能由前毫米波雷达实现，角雷达实现FCTA/B、RCTA/B及DOW/BSD等报警功能。横向和纵向ADAS属于行车场景，依赖Camera和前毫米波雷达实现，因此行车功能可以叫做5R1V架构，在此基础上可以演变出4R1V架构，即仅依靠camera实现横纵向的移动,4个角雷达依然起到报警的功能。

环视摄像头和超声波雷达服务于泊车功能，环视摄像头和超声波雷达里面没有集成控制器，因此有一个泊车控制器，收集传感器的数据，并做出判断处理。

功能与传感器的映射关系如下。

这种分布式架构下，功能实现非常依赖供应商，OEM在掌控力方面基本没有话语权，OEM干的就是个组装的活。该架构下，最高能支持L2级别的ADAS功能。

4.2 域控式架构

域控式的架构如下。

看起来只是比分布式架构多了个行车控制器，但实际上远远不止。下面主要讲行车控制器。

域控式架构，本质上是把传感器的数据处理和控制算法转移到了控制器里，该控制器可以由OEM自行开发，这样OEM对整车功能实现的掌控力大大提升。除了OEM可以提高话语权，这种架构还可以充分利用传感器资源，实现更灵活的传感器融合算法。

分布式架构中，行车功能例如AEB，只用了前毫米波雷达，而没有用到摄像头或雷达。人们的生活经验是“偏听则暗，兼听则明”，如果某个功能用到多个传感器的数据，把这些数据进行融合，则将会达到更好的控制效果。域控式架构中，各项功能调用的传感器资源如下。

多传感器融合的核心目的是提高系统决策、规划的正确性，传感器融合算法分为两种，即前融合与后融合，下面来简单介绍下。

后融合算法如下图所示。

每个传感器独立输出原始数据然后对每个传感器的数据进行处理，输出识别结果，最后在域控制器内设计合适的传感器权重做最终的仲裁。可以简单的理解为这种感知融合方式类似投票机制，每个传感器有不同的话语权。

举个例子，员工相当于传感器，领导是感知融合算法，每个员工都有发言权，但是每个人的权重不一样，领导最终会把两个人说的话进行加权，输出决策结果。

后融合算法的优势在于逻辑简单，计算速度快，通讯带宽小，劣势在于信息损失大，信息精度低。虽然说后融合算法简单，但是目前大部分OEM仅仅能处理毫米波雷达的融合，视觉算法的融合还是依赖芯片+算法系统供应商（Mobileye和地平线这种）。

前融合算法如下图所示。

前融合算法指的是：

在传感器原始数据层面进行融合，原始数据保留了最全的目标信息，融合算法根据各个传感器输出目标的纹理特征、三维信息、RGB信息综合判断，然后输出一个准确率更高的结果。在一些场景下，如果使用后融合算法，由于每个传感器只能探测到目标的一部分，而这一部分由于信息不全，很容易被作为噪点过滤掉，但是前融合算法就可以规避这个问题，前融合虽好，但是对处理器要求很高，需要高算力、高带宽的通讯，同时非常依赖大量数据的驱动以及数据闭环来优化算法。

举个例子，领导（前融合算法）不会轻易相信某一个员工或者某几个员工的话，领导要求每个员工都把他们看到的、听到的原始信息提交上来，领导会根据每个人的特点，综合评估，输出最终结果，对于领导而言很费脑力。

关于“兼听则明”这个生活经验，是需要有些前提的。即多传感器融合并不一定是好的，文章中讲了一个特斯拉去掉毫米波雷达的例子，可以自行去看下，为了不脱离本文的主线，这里不展开。

主流的行车域控制器设计方案如下所示，基本都是SOC+MCU的组合，SOC用于传感器数据融合，MCU主要用于规划控制、安全岛、与整车底盘的接口，同时承担部分传感器的数据融合，如毫米波雷达的数据融合（如果SOC失效，可以依靠前毫米波雷达的数据进行紧急制动）。

思考一下，SOC强大一点，涵盖MCU的功能是不是可行？这个后面再说。

域控式架构有如下特点：

成本：域控式ADAS架构形态从成本上要高于分布式ADAS架构，虽然支持的功能可靠性、鲁棒性有所提高，但是收益和代价仍不成正比；

可拓展性、灵活性：此架构类型是算法上移，域控制器单MCU，视觉依赖单SOC（这颗soc只是位置从摄像头中转移到了域控制器中，但处理的数据仍然只限于摄像头数据，可以理解为“工位调整了，但工作内容没变”），功能上可拓展性差、拓展难度大；

兼容性：域控制器和底盘控制器接口进行平台化设计，当自动驾驶架构演进为跨域冗余式架构，此域控制器可以作为冗余控制器存在，从L3功能降级为L2功能运行，或者执行最小风险策略，如在本车道停车。

安全性：L2功能虽然有ASIL D的安全目标，但是可以在执行器（转向系统、制动系统）做安全约束，降低域控制器的功能安全等级。

单从成本和可拓展性两个维度就注定域控式ADAS架构的生命周期不会太长，但考虑长远战略，OEM又不得不研发这类架构，毕竟这是域控制器自研的第一步，是OEM掌握话语权的开始。

 

4.3 跨域式融合

在设计行车和泊车独立域控制器的时候，行车功能很难调用环视摄像头的信息和超声波雷达信息，而行泊一体控制器使用前融合算法则可以规避此问题，比如NOA（领航辅助，需要控制车速和变道）功能调用鱼眼摄像头的数据来检测一些场景来从而避免碰撞。为了更灵活得利用传感器的资源，可以将行车控制器和域控制器也整合到一起，如下图所示。该架构能够实现功能清单中所有L2等级及以下的所有ADAS功能。

市面上主流的行泊一体控制器方案如下。

（1）单SOC+MCU，如华为的MD610控制器。

（2）双SOC+MCU，如华为的MDC810控制器

（3）三SOC+MCU，如地平线行泊一体方案

（4）单SOC，如知行科技的IDC3.0方案

行泊一体各项Feature的资源分配如下图所示。 

现在来说下，为什么主流的控制器方案用的是SOC+MCU的方案。

SOC往往是基于GPU/TPU架构，比如华为自研的达芬奇架构，这类芯片擅长做大规模低精度的浮点型运行，作为感知主处理芯片（处理前视、侧视、环视摄像头、高精地图信息）

而MCU处理毫米波信息、超声波雷达信息，同时MCU作为和整车底盘CAN通讯接口；

此外，紧急工况下，MCU可以靠毫米波雷达实现AEB功能。

另一方面，MCU可以作为安全岛来实现最低风险策略。由于MCU相比SOC逻辑简单，内置的自检（BIST）检测本身的故障，错误检查和校正（ECC）机制可检测并校正影响内存（如闪存）和内部总线的数据误差，以及使用多核锁步很容易实现功能安全ASIL D的要求。

SOC和MCU串联，MCU可以用来监测和校验SOC的输出结果。如SOC出现故障，持续输出过大的转向指令，MCU设计固定的安全阈值，比如当转向扭矩大于3牛米时，MCU不响应请求，来降低整车风险，从而实现功能安全。

得益于SOC的发展，类似德州仪器TDAV4H，单SOC都可以实现MCU的属性，比如SOC内“MCU区域”，采用多8个R核，4组双核锁步设计，同样可以可以实现处理USS算法和安全岛的作用。

未来单SOC的价格会比SOC+MCU便宜，即使单SOC也能符合功能安全ASIL D的要求（目前行业内的大算力SOC只能做到ASIL B），也可以满足网络安全要求，但是对于完全自动驾驶安全而言做到“相对安全”还远远不够，需要做到“本质安全”，因此单MCU可能还是很多公司的选择。 

行泊一体域控制器看起来将所有的传感器数据都集中到了一套处理器系统里，可以充分进行融合了。前融合算法相对后融合算法有很多优势，但能够把前融合算法做好，非常难。所以，行泊一体只是把硬件框架搭好了，要充分发挥其性能，还需要OEM的软件能力提高。

4.4 跨域式冗余融合

跨域式架构可以实现L2及以下等级的智驾功能，但OEM是肯定不会满足于此的，纷纷向着L3高地进发。对于L2级智驾，在行驶过程中，驾驶员的手必须在方向盘上，脚必须在刹车上，出现问题可以随时接管。而对于L3级智驾来说，允许用户手脚离开方向盘和刹车，当故障出现时，系统需要提醒用户进行接管。L3级别可以认为是解放人的手脚，但没有解放大脑。看了一篇关于L3落地的文章《“L3级”自动驾驶落地知道思想：高速辅助人，低速替代人》，其中提到了一些法规相关的问题。OEM厂商担心L3级别下的定责问题，因此不想也不敢承诺自身的智驾系统是L3级别。

L3级别的智驾，其需要满足的部分特征如下。

L3的系统架构设计如下，传感器采用异构冗余，控制器采用主控+副控设计，副控作为fallback和算力分担，执行器进行全冗余设计，通讯进行冗余设计，预留V2X接口（路侧单元RSU接口）作为路径规划的参考。

4.4.1 主控制器

L3主控制器通常采用双SOC+MCU设计，SOC跑感知融合算法+规控算法，MCU作为安全岛并且做整车接口。可以理解为soc是“干活的”，MCU是项目接口人，它把信息转化成整车认识的格式，通过CAN总线发给整车。主控制器的作用如下。

作用1：处理激光雷达+前视+侧视摄像头+角雷达+高精地图数据，3种硬件传感器FOV重叠，做前融合设计，高精地图作为辅助传感器，提供车道线+车道级定位信息以及道路分流、合流、限速路段等道路静态信息。这里注意，用激光雷达替代了毫米波雷达。L2本质上只能算辅助驾驶，驾驶员手脚都在方向盘和油门刹车上。但L3一定程度上已经可以算是自动驾驶了。摄像头无法直接获得距离和速度信息，当然通过毫米波雷达可以。但毫米波雷达只能获得物体的XY左边和相对雷达方向的速度，其无法探测物体的高度信息以及侧向移动速度。假如前方有一台底盘很高的大车横穿马路，则毫米波雷达可能无法提供全面的信息和预警。L3给机器的权限提高了，那给机器的信息就应当更全面，激光雷达的特点，就可以补充摄像头和毫米波雷达的补足，这也是为什么大家普遍认为，L3及以上的智驾需要激光雷达。当然，上面说到了4D毫米波雷达，不知道日后能否取代激光雷达，这个问题，拭目以待。

作用2：主控制器输出的控制请求一路通过网关转发给到执行系统，信息发到网关公共CAN上，相关零部件都可以收主域控制器的信号做策略判断；一路通过冗余私有CAN直接发给执行系统。

作用3：轻微故障障管理+故障处理策略的切换，执行预设的MRM（最小功能策略）。如冗余传感器遮挡/故障，冗余执行器故障，主控制器做降级处理策略。

4.4.2 副控制器

通过上面功能架构图，你会惊奇地发现，L3架构的副控制器其实跟行泊一体是一样的，处理的传感器也是一样的。此处的副控制器可以使用上一代行泊一体控制器，其作用如下。

作用1：处理环视摄像头+前视摄像头+前毫米波+超声波雷达数据， 当主控制器无故障时，则将上述目标融合后的信息转发给主控制器，起到算力分担的作用。

作用2：实现独立AEB功能。

作用:3：另外副控制器自身接入这些传感器也可以实现本车道停车。

当然，只有实力比较强的OEM才能规划好这些，没有架构底蕴的“新势力”，很难规划好每一代架构的递进关系。

副控制器和冗余控制器并不是一个概念。冗余，意味着互相独立，在主控故障后，冗余控制器接管车辆。因此，冗余控制器需要跟主控制器完全解耦，只有L4才会采用这种设计理念。但在L3中，副控制器通常承担算力分担功能——通俗地说就是，它也参与计算，但只是把计算结果发给主控，节省主控算力。在主控挂掉后，副控制器接管整车，实现L2功能，仍可以保留安全行车的能力；或者，能执行MRM就可以，比如本车道停车。

4.4.3 L3级别下的安全策略

L2级别下，如果智驾功能出现问题，直接让驾驶员接管就好了，因为其手脚就在方向盘和刹车上。但既然发展到了L3阶段，其实可以提高功能的可用性。故障情况下，虽然L3等级的功能无法实现，但可以在保证相对安全的情况下，让功能降级，继续维持一些智驾功能。这需要一些安全策略。

1.当失效发生在冗余传感器，功能并不受影响，但是为了避免发生主链路传感器再次失效的问题，功能上做报警，降级运行，常规做法是报警降速，驾驶员接管后功能降级到L2。

2.当失效发生在主控制器，主控自己发出MRM请求，或者主控和副控的心跳信号丢失（注：周期性握手，表明是否有故障），副控开始依靠前摄像头+毫米波雷达+环视摄像头的前融合策略继续运行L2级功能，同时报警，降速。

3.当失效发生在副控制器，在L3运行过程中，副控上报故障，由主控制器主动报警，告知驾驶员，做降级策略。

4.执行器要冗余这个毋庸质疑了，因为一旦终端执行器故障，功能直接失效。执行器做仲裁策略，优先执行主控制器请求，当主控故障时，才执行副控制器请求。

5.主控接入的传感器和副控接入的传感器从预期功能安全角度形成互补，对于L3主功能而言是逻辑“或”的关系，这种设计能大幅度规避corner case，但也不能完全消除corner case。上面这句话从九章智驾的文章中直接COPY的，没咋看懂，个人理解是主副控制器要尽可能的独立，互补影响，以最大限度的降低主副控制器的关联性，保证两个控制器系统不会同时失效。

4.4.4 SOC性能限制下的L3架构设计

L3的主控制器毋庸置疑是需要达到ASIL D的（非预期类安全目标），主控制器应该按照ASIL D能力开发，SOC和MCU是串联的关系，那么都要符合ASIL D，ASIL D的MCU常见，但是符合ASIL D标准的SOC还没有，行业内SOC几乎都是ASIL B。

ASIL B和D在软件的单元设计和架构设计上差异不大，但硬件方面差异较大——ASIL B的单点、潜伏、随机硬件失效率的要求均低于ASIL D，意味着只达到ASIL B标准的SOC的某些故障无法被探测到，这导致主域控制器无法设计对应的安全机制。

鉴于目前SOC达不到ASIL D，《2万字说清自动驾驶功能架构的演进》文章中给出了一种参考架构设计。

传感器分组接入，考虑到不同传感器都有性能局限，主控和副控的传感器从SOTIF角度属于场景互补关系。使用副控的毫米波感知融合输出目标距离做安全距离参考，每路传感器故障诊断能力要求符合ASIL B，引用Mobileye的责任敏感模型理念（缩写RSS），来规避最终的输出异常。

4.4.5 L4下的冗余架构设计

L3是支持点到点运行的，L4也是。L3和L4从功能的正常表现行为实际上无差异，差异点在于功能的异常后的行为，L3要求驾驶员作为fallback用户，而L4的fallback用户依旧是系统，意味着L4要具备更强大的fallback能力，相比于L3架构的副控制器就无法满足fallback要求了，这时我们就要重新根据L4的功能。

L4架构相比L3架构最大的变化是副控制器要做真正意义上的冗余，而且两路必须无共因失效。即L4的主控制器需要有L3主控制器+L3副控制器的完整功能，L4的冗余控制器有L3主控制器的功能。

思考一个问题，直接用两套完全冗余的L3架构中的主控制器组成L4的架构可以吗？个人觉得不行，下面来分析。

当主系统失效后，切换到冗余系统。注意，L4是不会轻易要求用户接管的（SAE定义了L4不要求用户接管，个人觉得总不至于任何场景下都不要求用户接管，毕竟这世界上没有万无一失的系统），因此即使切换到冗余系统后，也不会要求用户接管的。如果冗余系统再失效呢？整个系统就不安全了。因此，当两套全冗余的L3系统都失效后，还需要有降级运行的能力，提醒驾驶员接管，保证用户安全。那就需要再加一个L2级别的功能系统。于是L3+L2的功能系统形成了L4的主控制器，另一个L3功能系统成为L4的冗余控制器。

4.5 中央计算架构

在未来，电子电气架构会进一步发展，向中央-区域架构演进。在这种架构下，算力全部向中央计算机集中，中央计算机完成车控，娱乐，驾驶辅助等所有能力的提供，承担类似“中央大脑”的角色；在区域端，由区域控制器（Zonal Control Unit）充当网关、交换机角色，并完成供电。保证来自中央计算机的指令上下通达。来看下目前几家的架构。

4.5.1 Tesla Model 3架构

以特斯拉为代表的以ECU模块在车辆物理空间内所在位置进行的整合，即跨域集中式。特斯拉Model 3及Model Y的车电子电气架构分为四大部分：CCM(中央计算模块)、BCM FH（前车身控制模块）、BCM LH(左车身控制模块)、BCM RH(右车身控制模块)。

其中CCM(中央计算模块)由三个模块组合而成：智能座舱系统(IVI)，智能驾驶系统(ADAS)和车内外通信系统，其共用一套液冷系统。

前车身控制模块：负责整车电源分配，车辆前舱用电器的逻辑控制和驱动；

左车身控制模块：负责左侧用电器的配电，左侧用电器的逻辑控制和驱动，包括左车身便利性控制以及转向、制动等底盘控制等；

右车身控制模块：负责右侧用电器的配电，右侧和背部用电器的逻辑控制和驱动，包括右车身便利性控制、动力系统、空调等。

Model 3基本上实现了中央集中式架构的雏形，但并不是严格意义上的中央集中式架构，业内把这种类型称之为“准中央-区域集中式架构”。通讯架构以CAN 总线为主，中央计算模块只是形式上将影音娱乐MCU、自动驾驶 FSD以及车内外联网模块集成在一块板子上，且各模块独立运行各自的操作系统。真正的中央域控制器，应该算力集中在一个芯片上（个人这么认为的，不一定准确）。

4.5.2 小鹏G9架构

小鹏的X-EEA 3.0硬件架构方面，采用中央超算（C-DCU）+区域控制（Z-DCU）的硬件架构，中央超算包含车控、智驾、座舱3个域控制器，区域控制器为左右域控制器，将更多控制件分区，根据就近配置的原则，分区接管相应功能，大幅缩减线束。

通信架构方面，X-EEA3.0 在国内首次实现了以千兆以太网为主干的通信架构，同时支持多通讯协议，让车辆在数据传输方面更快速。从G9搭载的新一代电子电气架构可以看出，小鹏在骨干网络的建设和面向SOA的方向起步较早。

电力架构方面，可实现场景式精准配电，可根据驾驶、第三空间等不同用车场景按需配电，比如在路边等人时，可以只对空调、座椅调节、音乐等功能供电，其他部分断电，这样就能实现节能耗节省，提高续航里程。车辆定期自诊断， 主动发现问题，引导维修，以科技手段赋能售后。

另外，在数据架构方面，域控制器设置内存分区，升级运行互不干涉，便用车边升级，30分钟可升级完成。但说实话，在前期，我是不敢边用车边升级的，总觉得有点危险。

X-EEA3.0应该也算是准中央-区域集中式架构，在这种架构里，集成的最多的是智驾和智能座舱域的功能，而市面上，还没有一个SOC的性能能够同时支持这两个域的需求。

4.5.3 长城GEEP4.O架构

长城的GEEP4.0架构拥有中央计算、智能座舱及高阶自动驾驶3个计算平台，外加3个区域控制器（左、右、前）。

中央计算单元跨域整合了车身、网关、空调、动力/底盘控制及 ADAS 功能，它的主控芯片算力高达 30KDMIPS，能够高效保障系统的控制和响应。3个区域控制器为标准化的控制单元，负责整合周边MCU，目前三个区域控制器的大部分软件算法已经上移到中央计算单元中，由长城软件团队开发。

该架构引入SOA设计方式及理念，打造软件分层的基础架构平台，提供模块化标准服务接口，优势是可以提供积木式拆装 组合、解耦软硬件平台，提高软件复用性，让汽车实现全生命周期的功能迭代升级，用户可以根据需求喜好，动态订阅升级车辆服务功能，无需等待软件升级批次。同时 SOA 化还能灵活部署智能化场景，标准化接口可实现开放服务，构建长城汽 车众创生态，联合开发者为用户提供全场景智慧出行服务。

该架构也是准中央-区域集中式架构。回看下L3的架构设计，需要主副两个控制器。在GEEP4.0架构中，其智能驾驶模块可以作为L3主控制器，中央计算平台则可以作为副控制器，二者结合，在架构层面上有实现L3级别智驾的可能。至于小鹏的中央超算里，对于智驾是否有做主副控制器设计，就不得而知了。

4.5.4英伟达方案

前面讲的几个厂家的架构，虽然有中央计算平台，但座舱和智驾是各顾各的，只是把负责不同功能的芯片放在一个PCB上而已。这种架构叫做准中央-区域集中式架构。真正的中央-区域集中式架构至少要一个SOC能够完美融合舱驾的功能，最终再吸收车身控制的功能。英伟达于2022年发布的下一代车载SOC Thor将有望在一个芯片上高效整合数字仪表盘、信息娱乐、泊车、辅助驾驶等多种功能，从而极大地提高开发效率和软件更新迭代的速度。

Thor能够进行多域计算，这意味着它可以将自动驾驶、车载信息娱乐等功能划分为不同的任务区间，同时运行，互不干扰。多计算域隔离能力，可支持时间关键型的进程不间断同时运行，也就是说，车辆在一台计算机上可以同时运行 Linux、QNX 和 Android。

高通也在开发类似的SOC。对于用这种高集成度的SOC实现中央计算平台的方案，有一个有趣的观点。中央计算平台从舱驾融合开始，在将来甚至会把车身控制、底盘、动力多域的功能都吸纳进来，但是中央计算平台无法支持L3以上的智驾，这里指的中央计算平台狭义是指以单SOC为核心构造出的计算平台（或为了提高算力，多SOC执行同样的功能）。因为L3级及以上的智驾需要主副控制器或完全冗余的控制器。

从工程设计上单域控制器也能实现无单点失效，即域控制器做到失效可运行，也就是常说的fail-operational，只是从系统架构上避免单点失效，工程代价巨大。但如果是为了集成而集成，不考虑成本、不考虑收益，不值得。

5 设计一个简单的中央域控架构

在看完整车的功能架构演变，以及智驾域系统架构演变之后，应当再讲讲电气架构和网络架构的变化。于是干脆试着设计一个中央域控架构，在这个过程中，会涉及到电气架构和网络架构。NXP的官网也给出了一个示意图，看得比较清晰。可以看到这样一个架构，我们需要关注的其实就是中央控制器和区域控制器。

电动汽车EEA架构