前言

为什么？

为什么同样实现NOA功能，特斯拉只用摄像头方案，而大部分OEM还会增加毫米波雷达，甚至激光雷达？

为什么5R1V架构这么受欢迎？到底有什么经典之处，这种架构会长期存在吗？

为什么L3级以上自动驾驶功能一定要用冗余技术？是否可以不用？

L4架构相比L3做了哪些升级？

域控制器为什么通常采用SOC+MCU架构方案？

行泊一体域控制器是是过渡，还是终极形态？

中央计算平台会是ADS乃至整车的终极架构形态吗？

自动驾驶的安全如何设计，如果规避SOC陷阱？

国内的自动驾驶能力真实现状到底啥样？

造车新势力们“短平快”开发策略会不会有后遗症？

以上问题都会在本文中找到答案，相信通过本文的阅读，大家会对自动驾驶有更深层次的认知。

所有的技术方案、架构形态只是实现需求的一种技术路线！

想必大家都曾思索过以上问题，笔者以第一性原理，谈一谈智能驾驶到自动驾驶的技术发展路线，同时剖析国内几家OEM、造车新势力的自动驾驶现状。

先有需求、后有设计是正向开发的第一理念，这个理念放在智能驾驶上一样适用，无论用了多少传感器，什么芯片，多少算力，几大冗余技术等等，这些夺人眼球的配置都只是表象——并不是因为车上的硬件配置多牛逼、软件迭代多快速才能实现自动驾驶，而是为了实现自动驾驶XX功能才选择了这种方案。

本文以电子电气架构的理念和视角分析并预测行业主流ADAS架构到ADS架构的演变，不同架构的技术实现方案及优缺点，同时结合国内主流OEM、新势力的自动驾驶现状并分析其自动驾驶路线及产品竞争力。

一、架构的艺术

（一）关于架构的基本概念

本文贯穿了自动驾驶功能架构、系统架构，网络架构，那么有必要先和大家统一架构的概念和认知。

你也说架构、我也说架构，仿佛不谈几句架构就跟不上时代了，近两年新老OEM在新车发布会、智能驾驶产品发布会，不谈几句架构，那都彰显不出产品高端，体现不出我们技术底蕴，写PPT的也是受累了，笔者希望从一个正确的、完整的视角阐述架构的来源和意义，看它在OEM和Tier1的产品开发中到底起到什么作用！

“架构”这个概念最早是德尔福提出的，由博世把它的迭代路线可视化了，近两年“软件定义汽车”的概念把EEA这个概念再次炒火，同时特斯拉先进的EEA工程落地，属实让底蕴深厚的OEM羡慕嫉妒，但是仅看博世的架构路线路图和特斯拉的高内聚架构，反而把架构说小了，把架构核心作用和意义忽视了，下面我们自顶向下看看架构的范围：

物理（电气）架构：

上图是整车电器件布置和线束二维布置，看起来线束和电器件密密麻麻布置在二维图上，通常在OEM叫物理架构，有的公司也叫电气架构或者整车电气拓扑。核心是体现整车电子电气的布置关系和连接关系，主要工作是电气原理图设计、电源分配设计、搭铁分配设计、二维线束走向与三维布置设计。

在分布式开发的时代，ECU特别多，大概2018年之前，各家OEM为了达到电器件布置和线束走向优，通常购买同行畅销车型，拆解对标。物理架构设计对整车NVH表现、线束成本、车间安装，售后维修有很大的影响 ，限于篇幅不再继续解析。

功能架构：

本文的“分布式架构”、“域控式架构”等都是整车功能层级的架构，体现了功能实现所需要的完整的电器要素和逻辑关系（传感器-控制器-执行器），主要工作输出物是功能定义规范以及故障后处理策略，这里的架构虽然是一个个硬件实体，但不能体现出物理布置关系，也有公司把它称为逻辑架构。

系统架构：

系统架构和功能架构的区别在于架构的层级不一样，系统架构是ECU层级的，体现了ECU内部的元器件逻辑关系，系统架构是最具争议的一个词，在不同场合、不同语境代表的含义也不同，比如本文的各个ADAS功能架构图，也可能被称为系统架构，由于“系统”二字范围可大可小，结合语境，双方能会意即可。

网络架构（网络拓扑）：

上图大家应该不陌生，是特斯拉M3的网络拓扑，好多人误认为它就是特斯拉的电子电气架构，实际上网络拓扑主要体现各个ECU在哪个网段、在总线上连接关系，比如常规的动力PT-CAN、车身BD-CAN、驾驶辅助AD-CAN，不同网段的总线类型可能不同（LIN/CAN/CAN-FD/以太网），带宽和速率也不同，个别ECU之间如果仅仅是私有信息，还会有私有CAN（只是两个ECU之间信息交互）。

不论是物理架构、功能架构、系统架构还是网络架构都是EEA的一部分，它们分别体现了EEA不同维度的信息，所以一个先进的EEA必须要综合考虑架构的各个维度；架构是虚虚实实的存在，它从高维度上抽象地定义了各电子器件之间的逻辑关系，定义上层规则，从低纬度上又依赖于各个器件做工程实现和维护各电子器件规则，从这个层面讲架构设计就是设计架构！

全文从分布式架构→域控式→跨域式→跨域冗余式→中央式，讲解每一代架构的内在关联，让大家切身体会架构的艺术！

（二）基于场景服务的“功能驱动”

自动驾驶的技术路线和架构形态都是结果，而不是原因。

谈到这里，我联想到去年年底，我的一位大学同学找我帮忙，内推一台我司车辆，当我问到要哪款车、以及什么配置的时候，显然我同学是个地地道道的外行，他说“高速上能自动跟车，能自动拐弯，变道的时候有危险能报警那个”，然后，我以工程师的角度得出结论，他想要的功能是自适应巡航ACC+车道保持LCK+变道辅助LCA，最终我给他选择了对应配置的车辆。

言归正传，归根结底终端消费者关注的是在什么场景下，车辆具备什么服务，能辅助、代替驾驶员更舒适、更安全地操控车辆，企业将消费者对场景的需求抽象为服务（service）、具化成功能（function）、转化成特征（feature）、细化成工程架构设计(design)，评估传感器性能，用几个、控制器的内存和带宽得多大、用什么总线通讯，用什么软件架构方案，细化为功能需求（requirement），然后选择供应商进行需求（requirement）实现。

谈到这里，想必大家脑海里已经出现了共鸣，这就是所谓的基于“功能驱动”，是EEA的第一理念，没错！而行业内对于不同场景的ADAS需求已经成为共识，形成了ADAS功能库，功能有了，下一步就是如何规划ADAS架构来实现功能。

行业内自动驾驶功能库：

值得注意的一点，紧急介入的ADAS功能根据SAE J3016的规定被定义为L0，国标也是如此，如：AEB、FCTB、RCTB都属于L0，笔者只是单纯地还原正确的概念，本质上，某个ADAS功能属于L几意义并不大，只要说清功能在什么场景下会有什么服务，是否需要驾驶员介入就足够了。

二、ADAS功能架构的演进

基于功能的升级，需求的增加，自动驾驶架构也不断进化，笔者结合博世EEA发展路线图并结合工程实践绘制了ADAS的架构演进路线：

全文以自动驾驶架构为主线，穿插每一代架构的意义和难点，做最全面的解析！请各位看客老爷耐心阅读并加以思考，尤其思考每一代架构图的变化点和背后的含义。

（一）分布式ADAS架构

功能架构简介：

该架构最高支持到L2级ADAS功能，这里解释一下，所谓实现的L2需要同时开启ACC和LCK的开关，这种分布式架构还不能实现一键激活L2，行车域无域控制器，泊车域设置控制器。

在该架构下，横向ADAS功能由集成了EQ4芯片的camera实现，纵向ADAS功能由前毫米波雷达实现，角雷达实现FCTA/B、RCTA/B及DOW/BSD等报警功能，环视摄像头和超声波雷达服务于泊车功能，此架构各个传感器耦合度极低，各司其职，是典型的分布式开发，因此对于行车功能也叫1R1V架构，在此基础上可以演变出4R1V架构（取消前毫米波雷达），此种架构十分依赖供应商，OEM在掌控力方面基本没有话语权。

泊车采用的，其实也算不上域控制器，而是单独的一个ECU盒子。因为泊车用的传感器，超声波雷达和广角摄像头，就是纯传感器里面没有集成控制器。

简而言之，在分布式阶段，规控也是由传感器中的控制模块负责，而泊车功能的规控算法则在控制器里。

功能和传感器的映射关系如下：

架构特点：ECU分散，软件分散

传感器配置：行车—5R1V，EQ4集成在camera中；泊车—4环视+12超声波雷达

应用车企：吉利、长城、比亚迪、长安、广汽、北汽、蔚来、理想

评价一个EEA通常考虑10个维度（评价方法常使用蜘蛛网、普氏分析法，由于不是本文重点，就不再赘述）

下面，从上述评估EEA的几个维度评价分布式ADAS架构：

复杂度：集成难度低，开发周期短，可移植性强，对于OEM而言，主要工作在于集成和标定，大部分ADAS的集成和标定都相对容易，复杂度主要在于AEB标定。

多解释一下，AEB看似是L0级功能，但是其开发难度不低于NOA脱手功能，主要挑战在于如何权衡误制动和漏制动。这既是功能话题，又是安全话题，业界做的最好的Mobileye，AEB的成绩是10万公里误制动一次，俗称AEB false positive，而这个成绩对于预期功能安全的AEB接受准则（某公司要求30万公里误制动一次），还远远不够，当前乘用车+商用车的AEB前装量接近100%，市场配置AEB车辆的数量巨大，意味着每天都会发生由于AEB导致的急刹车，进而可能导致追尾事故。

复用性：此架构虽然无域控制器，但得益于SOC的发展，前摄像头可集成EQ4/5，作为“域控制器”使用，并统一输出接口；且纵向L1功能和横向L1功能接口由camera统一输出对整车的控制接口，整体功能上实现L2的效果，对于转向、制动、动力的接口无影响，利于OEM平台化设计。因此，这种操作深得OEM的喜爱。

灵活性：可剪裁掉前毫米波雷达，形成4R1V架构，集成EQ4/5的前摄像头实现横纵向ADAS行车功能，但需要EQ4/5开放更多的服务，要加钱！一般单摄像头价格涨幅＜前毫米波雷达单价。

与此同时，架构做减法，可能导致某些ADAS功能鲁棒性降低，如AEB改为摄像头实现，会由于摄像头的性能局限导致频繁误制动和漏制动，因此对于摄像头标定和AEB计算车距、目标识别算法有很高的要求。算法做得不好，造成的后果有2个，要么频繁误制动（如某著名车企，单摄像头方案的AEB），要么会漏制动。这种无域控制器的架构形态，必然会牺牲一部分功能可用性。

兼容性：分布式ADAS架构，OEM很容易被巨头Tier1绑架——Tier 1们捆绑销售执行器（EPS、ESP），然后找一堆所谓客观的理由，如果OEM选择其他公司的执行器，那么我们的产品需要同步更改哪里哪里，开发周期多久多久，开发费用多少万…

安全性：

功能安全：该架构支持的功能清单中，如AEB存在ASL D的安全目标，但是通过执行器的性能限制/安全阀值约束，降低整车风险至ASIL B，分配给传感器整体满足ASIL B即可，camera和前毫米波雷达满足ASIL B。

小结：传统OEM将同一车型分为3~4个配置，如：低配、中配、高配，顶配，其中低配是为了拉低车型起步价，实际上并不生产；主销配置是中、高配，随着ADAS渗透率的提升，以前只有顶配才有的L2级功能，现在中、高配就会配备，同时受限于域控制器价格原因，分布式ADAS架构将持续存在。

（二）域控式ADAS架构

介绍域控式ADAS架构前，有必要先科普一下多传感器融合算法，因为域控式ADAS架构是OEM和Tier1对于感知算法的第一次博弈，OEM逐渐蚕食Tier1的“算法专利” ，各位看客老爷请细看OEM如何逐渐摘掉“组装厂”的帽子。

为啥要多传感器融合？

多传感器融合的核心目的是提高系统决策、规划的正确性，为了实现这个目标，传感器必须从基础的感知能力进化到深层次的认知能力，通俗地解释一下，类比人类，我们认识世界是通过视觉、触觉、嗅觉获得外界的多维度信息由大脑统一加工处理，从而来认识世界，多传感器融合的底层理念就源于这里。

多传感器融合算法有哪几种？

多传感器根据信息不同层级的融合从宏观上分为数据级融合和特征级融合，这里不长篇大论理论层面的东西，着重说一下融合算法。

各传感器输出的信息都存在不确定性，针对不确定信息进行融合实际上是一个不确定性推理的过程，融合算法基于大量传感器的输出信息通过不断训练，更新各个传感器权值，得到黑盒推理机制，利用神经网络的信号处理能力和自动推理功能，不断优化、迭代算法，行业内把感知融合算法分为后融合和前融合算法。

① 后融合算法，见下图：

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

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

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

② 前融合算法，见下图：

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

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

目前具备前融合算法能力的OEM不存在，好一点的科技公司能做到把毫米波雷达+摄像头信息做融合，但是对激光雷达的点云处理能力目前还是捉襟见肘，本人认为未来能把前融合算法做好的前提是强大的AI团队+对各种传感器性能有深入了解，缺一不可。

回到本章节正文：

功能架构简介：

域控式架构最高支持到ADAS功能清单内L2级别功能。

硬件上，相比于分布式ADAS架构，域控式架构仅仅增加了域控制器，那么域控制器会带来什么收益呢？笔者基于开发经验总结以下三点：

优势1：域控式ADAS架构将sensor控制算法上移，从传感器端上移到域控制器端，域控制器做简单的后融合算法，提高了功能可用性；

优势2：域控式ADAS架构引起HMI设计变化，开关可以“一键多用”，如拨一次激活ACC功能，拨二次激活TJA功能，不必用户从HUT软开关上再次开启LCK功能；

优势3：此架构最大的意义在于OEM逐渐打破了Tier1的封锁，应用层算法被OEM掌握在手里了，把对Tier1传感器的依赖转移到对域控制器芯片的依赖，OEM的自由度会高一些，毕竟芯片的可选择性会多一些。

架构的核心之一在于功能分配、资源合理利用，域控式ADAS架构功能分配如下：

红色√是相比于分布式ADAS架构下，传感器功能的拓展。比如AEB、FCW功能调用了前角雷达信息，前角雷达和前毫米波雷达/摄像头的FOV覆盖区域重叠设计，形成异构冗余，那么对于一个功能而言，更多的传感器覆盖，通常漏检率会降低。

但并非绝对如此，感知融合算法的误检率和漏检率跟每个传感器的权重也有关，下面插播一段，剖析特斯拉AEB漏制动的感知融合算法。

特斯拉为啥删掉毫米波雷达？

网络上有很多对特斯拉事故的分析，笔者不进行解析，本文从算法角度阐述，用数据清晰地展示给读者，相信读完后大家会得到答案。

已知AEB为毫米波雷达+摄像头融合方案，算法方案为后融合，笔者做了一个简易的AEB事件仿真，融合算法模型：当毫米波*A+摄像头*B≥80%，则激活AEB。结果如下——

选取几个典型事件进行分析：

AEB事件1：这个案例告诉我们，如果权值比较低的毫米波在某紧急场景下探测率低（50%），将会导致1+1＜1的后果，还不如删除毫米波雷达，一句话：臭鱼搅得满锅腥！

AEB事件3：权值高的传感器如果达不到及格线（80%，因为感知融合算法模型是超过80%才激活，那么，如果只有一类传感器，其检测正确率也不能低于80%，否则就会出现短板效应），那么AEB也无法激活，好比一个在其位不谋其职的领导，权力很大，能力很差，那么结局可想而知！

AEB事件5&7：这个案例告诉我们，虽然毫米波雷达探测力很强（85%），奈何队友不给力，导致整体1+1＜1的结果，也无法激活AEB。

AEB事件6：这个案例告诉我们即使两个话语权一样的人，但是如果一方达不到及格线，那这个队友就很难带了。

综上所述，数据显示没有毫米波雷达，9次AEB事件中会发生3次漏制动（表格第5列，小于80%的数据个数），而增加毫米波雷达，发生了7次漏制动（表格第6列，小于80%的数据个数），尽管此表格仅为部分数据，但是我想大部分读者已经理解为什么特斯拉不再用毫米波雷达了吧？

多传感器异构融合方案，如果采用后融合算法，对权值的设定非常考验算法的设计，需要大量的仿真及实车标定数据支撑，否则容易引起1+1＜1的情况。另一方面，多传感器后融合一定是强强联合，每个传感器的能力不能太差；可能有的朋友会说多传感器融合，未必是强强联合，也可以是取长补短，没错！下文会提到前融合算法。

另外，现阶段3D毫米波雷达虽然是号称全天候传感器，但是由于其分辨率低，通常漏检率会高一些，但是又因为其对金属物体敏感，遇到金属会频繁误报，在开发中实在有一种“食之无味，弃之可惜”的尴尬。

那么是否毫米波雷达就真的很鸡肋呢？答案肯定不是，在AEB这个案例中，用到毫末波雷达的目标探测属性，这不是它的强项，但如果用毫米波雷达的目标速度/距离信息作为前融合算法的输入，那效果还是要优于摄像头，一句话：取其长，避其短！

域控式ADAS架构存在的意义是什么？

上文已经提到，本质上域控式ADAS架构是算法的上移，关键点在于后融合算法的设计和芯片选型，芯片的选型相对自由一些，大部分OEM采用Mobileye EQ4+英飞凌TC39x系列的组合，由于短期内大部分OEM对视觉算法处理还无法赶上Mobileye，考虑Mobileye对算法的封闭，一些OEM已经和开放度更高的地平线合作，参与视觉算法的研发，这个阶段的OEM已经不是简单的组装厂了！

主流域控制器设计方案：

域控式ADAS架构评价：

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

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

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

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

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

这种架构形态对于OEM而言是一种技术过渡的中间态，然而这个阶段却是OEM技术沉淀的一个缓冲期， OEM同步搭建感知融合团队、域控制器团队、规控团队、基础软件团队、标定团队、定位团队、软硬件集成团队，大大提高了资源整合能力（控制器布置、线束布置、总线通讯设计、接口定义平台化设计、工具链的打通、仿真测试能力建立）， 时机成熟后OEM会迅速切入跨域式融合架构，把域控式架构中的控制器从架构中剥离出来，作为后续跨域冗余架构的fallback控制器（别急，下文跨域冗余式架构章节会详细解析），这就体现了架构的艺术，架构的价值！

（三）跨域式ADAS架构（行泊一体）

低配版行泊一体功能架构图

功能架构介绍：

这代架构相比上一代架构从硬件形态上增加了GNSS+IMU组合定位，从软件包上加入ADAS地图，行车域+泊车域控制器融合成行泊一体域控制器。

支持功能：功能清单中L2及以下所有ADAS功能

局限性：ADAS地图无法支持车道级定位，无法安全通过匝道，无法实现点到点的行车

安全性：侧后方无视觉传感器，侧后方只有角雷达，主动变道有风险

高配版行泊一体功能架构图

变化点：相比低配版，高配版所使用的地图由ADAS地图升级为高精地图，高精地图硬件盒子一般集成到域控制器内，车身两侧分别增加2个侧视摄像头，和对应侧的角雷达形成异构冗余

优势：

1. 支持高速公路自动上下匝道场景，实现点到点的NOA功能；

2. 冗余侧视摄像头的数据引入降低了目标漏检率，降低主动变道的风险；

开发难点：侧视摄像头算法开发，侧视和角雷达后融合算法的设计和测试

系统架构如何设计？

上文提到电子电气架构开发是自顶向下的开发，系统架构的设计道理也一样，。

正向开发的思路：系统功能清单→功能分配到抽象的逻辑模块→硬件架构设计→功能分配到硬件→应用层软件开发，目前能力靠前的OEM不断扩大软件的投入，一方面招兵买马挖墙脚，一方面提高校招的门槛，已初步具备应用层软件开发能力。

为啥域控制器通常采用SOC+MCU架构方案？

首先，域控制器不一定是SOC+MCU方案，单SOC也可以，比如使用单TDAV4芯片，只要SOC的能力可以覆盖MCU的一些特性，从实现功能角度单SOC也没问题。

主流方案是域控制器使用SOC+MCU方案，因为SOC往往是基于GPU/TPU架构，比如华为自研的达芬奇架构，这类芯片擅长做大规模低精度的浮点型运行，作为感知主处理芯片（处理前视、侧视、环视摄像头、高精地图信息），而MCU处理毫米波信息、超声波雷达信息，同时MCU作为和整车底盘CAN通讯接口；此外，紧急工况下，MCU可以靠毫米波雷达实现AEB功能。

另一方面，MCU可以作为安全岛来实现最低风险策略，如SOC出现故障，持续输出过大的转向指令，MCU设计固定的安全阈值，比如当转向扭矩大于3牛米时，MCU不响应请求，来降低整车风险，从而实现功能安全，由于MCU相比SOC逻辑简单，内置的自检（BIST）检测本身的故障，错误检查和校正（ECC）机制可检测并校正影响内存（如闪存）和内部总线的数据误差，以及使用多核锁步很容易实现功能安全ASIL D的要求，如OEM最常用的TC397芯片，这里纠正一个容易混淆的概念，MCU虽然可以作为安全岛来诊断SOC的故障，但是并不意味着SOC所有的失效都能被MCU探测到。

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

未来单SOC的价格会比SOC+MCU便宜，即使单SOC也能符合功能安全ASIL D的要求（目前行业内的大算力SOC只能做到ASIL B），也可以满足网络安全要求，但是对于完全自动驾驶安全而言做到“相对安全”还远远不够，需要做到“本质安全”，因此笔者认为外挂MCU还是非常有必要，笔者是独立MCU的拥护者。

跨域式系统架构设计

行业存在4种系统设计方案

① 单SOC+MCU，如华为MDC610控制器；

② 双SOC+MCU，如华为MDC810控制器；

③ 三SOC+MCU，如地平线行泊一体方案；

④ 单SOC，如知行科技IDC3.0方案、寒武纪SD5223行泊一体方案；

上文提到，不论采用哪种方案，万变不离其宗，不变的是上层功能和系统feature，变化的是系统内部的硬件架构，当意识到这点，系统设计就容易理解了。

系统设计流程：三个关键词：分解、转化、分配。

系统架构师分解上层功能，转化成系统feature（大部分公司叫逻辑模块，属于软件模块的抽象），分配到架构要素（电源模块、处理芯片等），然后相关工程师设计内部通讯、评估是基于AP还是CP进行软件算法设计。

行泊一体系统feature导出和资源分配：

系统设计过程中如何分解功能，如何转化成系统feature很好理解，如何分配资源是开发难点，笔者总结如下两点经验：

分区设计：正向开发先定义架构，评估所有feature所需要的硬件资源总和，后进行芯片选型，不同feature分配到不同芯片（如果是单SOC则分配到不同核）；同时由于不同feature的安全等级不一样，需要进行分区设计，如：低ASIL的feature不可以访问(写) 高ASIL的内存分区，避免产生串扰。

分时设计：行车、泊车功能不同时起作用，那么为了节省资源，可以共享硬件资源，做分时管理，通常由MCU做状态机管理，单SOC方案则由SOC实现。

设计难点

在设计行车和泊车独立域控制器的时候，行车功能很难调用环视摄像头的信息和超声波雷达信息，而行泊一体控制器使用前融合算法则可以规避此问题，比如NOA功能调用鱼眼摄像头的数据来检测一些场景来从而避免碰撞，据悉知行科技和毫末智行都使用该方案，如下图：

前融合算法的优势是毋庸置疑的，但是能把前融合算法做好，而且能SOP的企业目前还没有，行业内看似百花齐放，实则99%企业都处于demo车阶段，大部分OEM/科技公司都是采用后融合，某个功能的特定场景采用前融合策略。这并不是真正意义的前融合算法，在行泊一体的上半场硬件比拼中，大家不分高下，下半场就要拼软件算法了，尤其是对环视摄像头和侧视摄像头数据的融合算法和目标轨迹预测算法。

OEM的“外患、内忧”有望解除

在分布式架构和域控式架构时代，Mobileye无疑是最大的赢家，一个EQ4+封闭算法就把OEM拿捏得死死的，集成EQ4的摄像头也分割了前毫米波雷达的市场份额，行业恨Mobileye久矣，对于OEM而言这种局面毫无安全感，此乃外患。

上文提到分布式ADAS架构会长期存在，这意味着，在低端ADAS市场上，Mobileye 还会继续收割红利，这种局面OEM一直想打破，随着地平线等企业的发展，Mobileye在低端ADAS市场份额也会收窄，而行泊一体高配置ADAS市场，OEM去“Mobileye化”才刚刚开始。

另外，OEM内部的行车、泊车分布式开发的局面，形成臃肿的开发团队，部门内领导的权力之争，也日益彰显。不同车型、不同平台、不同供应商产品、不同接口定义致使各个组织割据分割，往小了说拉帮结派，影响公司级ADAS平台化设计，往大了说影响整车EEA的进步和公司的未来，此乃内忧，而大公司的组织架构小变革是换汤不换药，大变革通常是大象转身。

笔者认为行泊一体域控时代的到来对于OEM是自我革新的契机，从组织架构上优化团队，从公司EE架构路线上进行平台化设计。

（四）跨域冗余式ADS架构（L3和L4的标配？）

L3需要什么形态的架构？

回归架构设计流程，场景的需求抽象为服务（service）、具化成功能（function）、转化成特征（feature）、细化成工程架构设计（design），生成工程需求（requirement），然后我们再回顾一下SAE J3016对L3的定义描述：L3系统执行ODD内全部的动态驾驶任务（DDT），且目标和事件的探测和响应（OEDR）是系统，说直白些就是驾驶员可以脱脚、脱手、脱眼，映射到文章开头的ADAS功能清单也就是HWP、UNP，以上是service和function，那么它的特征（feature）如何分析？

先抛一个结论：L3特征分析是设计的难点，产品的性能局限是落地的难点。

在设计L3系统时，大部分OEM/科技公司都宣传，用冗余架构啊，传感器冗余、控制器冗余、执行器冗余、通讯冗余、电源冗余，说的像没说一样，这种回答毫无工程落地指导意义，工程实现就不用考虑成本吗？不用考虑三维布置吗？当问到冗余的必要性，什么场景，什么情况才需要冗余，多数原因又是“对标”，本文反反复复地说需求是正向地、系统性地导出的，这样才能保证设计需求的正确性、完整性、追溯性。

笔者从功能的可用性、安全性两个维度进行特征导出（仅供参考）：

表格起到抛砖引玉的作用，对于L3而言，大部分OEM/科技公司的架构设计几乎都是源于“对标”，导致L3的硬件架构虽然雷同，但是整车策略、鲁棒性、安全性却天差地别，由于没有基于正向导出特征（feature），漏掉了一些特征，导致整个功能需求的合理性、正确性、完整性压根无法保证，这就是为什么说L3特征分析是设计的难点。

那么产品的性能局限是L3落地的难点如何理解？请耐心往下阅读。

L3功能架构设计

架构解析：

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

主控制器：

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

作用1：处理激光雷达+前视+侧视摄像头+角雷达+高精地图数据，3种硬件传感器FOV重叠，做前融合设计，高精地图作为辅助传感器，提供车道线+车道级定位信息以及道路分流、合流、限速路段等道路静态信息；

作用2：主控制器输出的控制请求一路通过网关转发给到执行系统，一路通过冗余私有CAN直接发给执行系统，可能读者会问“直接跳过网关做两路通讯不就可以吗”？解释一下，信息发到网关公共CAN上，相关零部件都可以收主域控制器的信号做策略判断；

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

副控制器：

通过上面功能架构图，你会惊奇地发现，L3架构的副控制器其实跟行泊一体是一样的，处理的传感器也是一样的。此处的副控制器可以使用上一代行泊一体控制器，这不是巧合，这就是跨域冗余域控制器的使命，也是架构的艺术！每一块积木都有它的用途，每一代架构都有它存在的意义！

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

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

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

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

需要特别解释一下，副控制器跟“冗余控制器”并不是同一个概念。

冗余，意味着互相独立，在主控故障后，冗余控制器接管车辆。因此，冗余控制器需要跟主控制器完全解耦，只有L4才会采用这种设计理念（L4的副控制器跟冗余控制器是同一个概念）。

但在L3中，副控制器通常承担算力分担功能——通俗地说就是，它也参与计算，但只是把计算结果发给主控，节省主控算力。在主控挂掉后，副控制器接管整车，实现L2功能，仍可以保留安全行车的能力；或者，能执行MRM就可以。

有些芯片商或者OEM宣传单芯片、单域控制器能实现L3这类“大言不惭”的话，笔者是嗤之以鼻的，在整车无故障下单芯片、单域控制器完全可以实现L3，那故障后呢？

L3架构的安全考量

“安全”是自动驾驶绕不开的话题，未来国家层面一定会出台监管政策，而且不是简单地提交一份类似美国“自愿性安全评估报告”就可以，如下图：

这些报告对于安全的总结几乎都是一带而过，碎片化的信息并不能说明企业在安全上到底做了什么，大部分企业都在谈遵循ISO 26262&21448&21434流程体系，那么是否真正按流程开发了？即使按照流程开发了，产品是否符合了26262并没有标明啊，不得不说，各家企业对措辞拿捏得非常到位！

笔者先后从事EE架构、EE安全、自动驾驶功能开发，坦白地讲，仅仅拿最成熟的ISO 26262标准来说，也没有任何一家OEM敢宣称其ADS功能涉及的产品完全符合26262要求！

理论物理近百年没有重大突破，科技达到了技术瓶颈，电子电气实现“本质安全”可能没希望了，只能做到“相对安全”，ISO 26262&21448&21434本质上都是“相对安全”。解释一下，所谓本质安全就是不可能发生任何危害事件，相对安全是允许发生危害事件，只要风险足够低，低到可以被大众接受就可以。

设计“相对安全”有时要牺牲功能可用性，二者之间如何做权衡？那么安全做到什么程度就可以了呢？如何从策略和系统设计角度来合理规避风险呢？

安全策略（示例）：

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

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

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

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

5.主控接入的传感器和副控接入的传感器从预期功能安全角度形成互补，对于L3主功能而言是逻辑“或”的关系，这种设计能大幅度规避corner case，但也不能完全消除corner case。

宝马汽车安全策略解析：

相比于笔者提到的安全策略，宝马使用了一种低成本传感器方案实现MRC（最低风险状态）:

图片最左侧是传感器输入，上侧是副控制器，下侧是主控，宝马的主控接入全集传感器，副控接入5R1V+DMS。这样的话，一旦主控失效，副控可以通过5R1V实现fallback，但是靠边停车存在风险（尤其在车道线模糊的情况下），所以笔者推测宝马的L3的MRC是本车道停车，对于L3来说没有问题，对于L4还不够，具体请继续阅读下文。

行业SOC大部分只能做到ASIL B，咋办？如何解决行业难题？

L3的主控制器毋庸置疑是需要达到ASIL D的（非预期类安全目标），主控制器应该按照ASIL D能力开发，SOC和MCU是串联的关系，那么都要符合ASIL D，ASIL D的MCU常见，但是符合ASIL D标准的SOC还没有，行业内SOC几乎都是ASIL B（最新消息：安霸CV2FS/CV22FS芯片已做到ASIL C，获得Exida认证，为全球首例），那这个差异会造成什么后果呢？

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

安全方案（独家观点，仅供参考）：

符合功能安全、预期功能安全的安全架构

预期功能安全考虑：

传感器分组接入，上文中L3的feature2，考虑到不同传感器都有性能局限，主控和副控的传感器从SOTIF角度属于场景互补关系。

我们都知道，如果主控和副控分别发出不同的指令，在主控无EE故障的情况下，执行器是优先信任主控，如果主控没有EE故障，但主控的输出结果却是错误的，这个时候执行器就执行了一个错误的、不安全的指令，产生事故的概率会增大，而上图这种设计理念恰巧能规避主路SOTIF问题。

功能安全考虑：

使用副控的毫米波+主控感知融合输出目标距离做安全距离参考，每路传感器故障诊断能力要求符合ASIL B，引用Mobileye的责任敏感模型理念（缩写RSS），来规避最终的输出异常。

那么读者会问，为什么不直接使用激光雷达的目标距离信息呢？

因为激光雷达的数据也是靠主控制器SOC处理，如果SOC异常，输出的距离也是错误的。这种架构设计既规避了SOC的共因失效(硬件失效，ASIL B的硬件度量未覆盖的那部分失效)，又规避了主控SOC的AI感知融合算法的错误。

对于L3功能架构两个域控制器必须是冗余关系吗？

从功能架构图可以看出，主控制器和副控制器接入的传感器并不是全集传感器，而且副控制器接入的传感器反而更少，意味着两个控制器不是冗余的关系。L3架构只要能实现最小风险策略，能避免单点失效即可，控制器并不一定需要冗余设计，主控和副控互补设计更利于成本的管控，和硬件资源利用最大化。

电源冗余是必要的吗？

这个话题行业内争论较多，90%的工程师都认为冗余电源是有必要的，大部分企业的L3 demo车辆也试装了冗余电源，通常采用博世BEG方案，但是冗余电源起作用的概率到底有多大呢？冗余电源起作用的真正原因经过分析了吗？你们的测试数据是否显示冗余电源带来价值了呢？是由于方案的骑虎难下，还是真有效益？

带着问题我们先了解所谓的冗余电源是什么，冗余电源包括：供电源头冗余，供电链路冗余。

供电源头分析：

供电源头一般是发电机/DC-DC(电动车)和蓄电池并联，从提供电能角度已经实现了互补，而且蓄电池容量通常是60-70AH，在发电机故障下能支持至少15分钟的运行。这里读者可能会说EPS的功率通常800多瓦，非常耗电，怎么办？

实际L3系统执行MRM过程中，并不会长时间请求EPS，而且L3并没有要求必须靠边停车！到了L4，要么提高蓄电池容量，要么设计备份电池，那就另当别论了，此处我们仅讨论L3冗余电源的必要性。

笔者和电源设计工程师沟通得知，如果能消除发电机/DC-DC和蓄电池的共因失效，那么供电源头确实可以不需要额外再加一块小电池。那么，什么条件下，发电机/DC-D和蓄电池能同时失效呢？

经过系统分析，当大于60A的负载发生短路，导致整车电压拉低至10V以下，这个电压无法满足ADS系统工作时，理论上确实有“共因失效”的可能。那么，实践中是否可以通过工程的设计来规避这个共因失效呢？我认为是可以的。

供电链路分析：

传统的供电链路的组成是汇流排、继电器、保险、线束、插件、端子，这里面任何一个环节失效都会造成供电异常，那么是否一定要冗余供电链路呢？一路链路真的无法避免单点失效吗？或者说，什么情况下才会导致失效，是否可以case by case的解决呢？毕竟线束的成本很高，线束捆变粗，造成布置难度很大。

笔者的看法是从两方面入手，第一，从整车策略上域控制器接常电（KL30），那么链路上就没有继电器了，从而可以规避继电器的失效；第二，保险丝采用可恢复保险并联或者取消保险丝在控制器里做过流监控，目前域控制器的电源芯片可以做到，从而规避保险丝的失效，而汇流排、线束、端子要做好物理防护从而无限接近“本质安全”。

以上仅为个人思路，欢迎专家提意见。

OEM当家作主

L3的设计是正向设计的开端，没有任何一级Tier1或者科技公司比优秀的OEM更懂整车，上文提到“L3特征分析是设计的难点，产品的性能局限是落地的难点”，只有OEM从顶层正向的设计才能保证L3特征的正确性、完整性。OEM不断摸索不同产品性能的边界，制定合理的、安全的ODD边界，这是OEM先天优势，在行泊一体架构时，OEM已经投入很多资源，提高了自研能力，相信在下一个制高点L3的开发，基于正向设计的方案才会靠谱！笔者认为L3是OEM当家做主的时代。

L4架构相比L3需要做哪些升级？

L3和L4功能都支持点到点运行能力，L3和L4从功能的正常表现行为实际上无差异，差异点在于功能的异常后的行为，L3要求驾驶员作为fallback用户，而L4的fallback用户依旧是系统，意味着L4要具备更强大的fallback能力，相比于L3架构的副控制器就无法满足fallback要求了，这时我们就要重新根据L4的功能（function），推导L4的特征（feature），再转化成架构设计(design)。

L4架构方案预测

承接本文L3架构，L4架构相比L3架构最大的变化是副控制器要做真正意义上的冗余，而且两路必须无共因失效，由于L3架构的副域控制器起到了算力分担和执行MRM的作用，那么：

主控制器设计构想：

L4的主控制器要具备完整的L3能力，也就是L4主控=本文的L3主控+L3副控，基于此构想，L4架构需要开发L4专属高性能域控制器，L4主域控制器设计3颗SOC，主域控预留V2X接口，为L4车路协同预埋硬件。

注：两颗也可以，比如使用地表最强英伟达orin，性能涵盖上文SOC#1和SOC#2 feature即可，笔者从可靠性、可用性角度更倾向3*SOC+MCU方案。

冗余控制器设计构想：

从L4的fallback定义出发，fallback由系统执行，在整个驾驶的ODD内，不需要驾驶员参与，那么要求即使主控故障，副控制器依旧可以完成ODD内全部的动态驾驶任务，那么思考一下，L3的主控制器是否可以支持呢？是的！这同样不是巧合，从本文的架构路线进化演进，这体现的是架构的艺术！

L4设计和落地的难点

L3特征分析是设计的难点，产品的性能局限是落地的难点，那么L4呢？

控制器的设计简单粗暴地说可以增加传感器接口数量、提高通讯带宽、降低时延、堆AI芯片来实现，而L4实现点到点自动驾驶，ODD场景复杂度骤增，传感器采用怎样的组合方案？现有的成熟的传感器技术是否能应对更严苛的ODD？是否要使用4D毫米波雷达？是否使用远红外相机？

以上感知问题是设计最大的瓶颈，没有之一，即使是非常牛叉的前融合算法在遇到奇奇怪怪的场景时，对目标的处理能力也捉襟见肘，尤其针对城市车辆和二轮骑行人员的轨迹预测算法，挑战非常大，出于安全考虑，系统必然会“小心驾驶”。

此时此刻车路协同派可能要举手发声，仿佛车路协同这个上帝视角传感器可以为L4救命稻草，且不说路侧单元（RSU）普及要到何年何月，笔者认同车路协同对于通勤效率的提升有很大帮助，但是作为传感器给自动驾驶系统作为决策算法的输入，这个风险可能比纯粹的单车智能风险还要大。

一方面V2X存在网络安全风险，另一方面RSU也存在性能局限（SOTIF问题），基于二者的考虑，RSU作为传感器，域控设定RSU权重不会高，笔者认为V2X发展可能要经过3个阶段才会参与整车动态控制，V2X 1.0时代仅是报警功能；2.0时代RSU和高精地图数据耦合，作为全局路径规划算法的输入参考，提高通勤效率；3.0时代才会作为决策算法的参考。

言归正传，L4在demo车上拿掉司机、拿掉安全员都没问题，真正量产做到无人化，L4难度比登月都大，毕竟人类 50多年前就已成功登月。

笔者相继和小马智行、滴滴、文远的同仁了解当前Robotaxi现状，就目前市场来看，限制场景的L4，如点到点无人巴士、园区车、港口车、物流车都相继小规模落地，但是对乘用车的L4落地大家仍是抱着保守的态度，原因如下：

其一、人民对乘用车L4的需求也没有那么强烈—市场需求小

其二、产品的可靠性、安全性并没有企业宣讲的那么靠谱—技术不成熟

其三、L4乘用车的保险模式也未成熟—相关配套体系不健全

其四、国家监管政策也不明朗—国家政策还未跟上步伐

基于上述多方面原因，L4级乘用车的大规模落地可想而知，短期来看L4的结局大概率会是限制ODD的高性能L3! 然后美其名曰简单场景的点到点L4功能，长期来看行业不会停止对L4的研发，尤其是主打Robotaxi的企业还会继续“胡说八道地吹”与“脚踏实地地做”。二者缺一不可，不会讲故事忽悠（商业模式）、没有硬核技术的企业注定走不远。

（五）中央计算平台（行泊舱一体）

什么是中央计算平台，请参考九章智驾往期文章《EE架构|国内主流OEM的中央计算+区域控制架构信息梳理》

不论是沃尔沃、宝马还是国内的长城、长安、吉利、理想、华为都在规划中央计算平台，大部分中央计算平台的功能涵盖了座舱、动力、部分底盘功能，从工程设计角度把行泊舱放一个控制器完全没问题，从工程实现角度也能实现，本文仅讨论中央计算平台和自动驾驶的关系。

中央计算平台能支持ADAS吗？

据悉长城GEEP4.0架构：中央计算平台 + 智能驾驶域控 + 智能座舱域控 + 区域控制吧有望在2022年Q4量产。该中央计算平台是行业内第一个集成ADAS功能的产品。

其行车最高支持HWA，泊车最高支持APA，其采用的策略是L2配置搭载CCU，L3配置CCU作为小魔盒3.0的fallback控制器，这时CCU的作用和上文笔者所说跨域冗余式架构的副控作用就呼应上了，看来长城在自动驾驶架构迭代和中央计算平台的发展路线做出，很好的权衡。

中央计算平台能支持L3吗？

目前，在主流的L3架构中，自动驾驶域控制器是主控制器，而看起来更高大上的中央计算平台则仅扮演冗余的角色——对整车的EE架构来说，中央计算平台是主角，但对自动驾驶来说，中央计算平台则是配角。

那么，中央件计算平台有可能成为L3自动驾驶系统中的主角吗？

之所以提出这个问题，是因为笔者不看好中央计算平台（目前，主流厂商所谓规划的中央计算平台，都是单一盒子）在自动驾驶上的前景——对于L3以上ADS，中央计算平台是配角，不可能是主角，原因有四：

其一、在上文的“L3需要什么形态的架构”章节，笔者提出L3不一定需要冗余域控制器，但是要做到主控制器失效，整车能实现MRC，而单中央计算平台却存在单点失效。

不是说100%不能做到无单点失效，从工程设计上单域控制器也能实现无单点失效，即域控制器做到失效可运行，也就是常说的fail-operational，只是从系统架构上避免单点失效，工程代价巨大，还不如直接设计副控制器来实现特定条件的MRC。如果是为了集成而集成，不考虑成本、不考虑收益、不考虑架构的艺术，那当我没说，但凡有个明白的总师都干不出来这事。

其二、笔者和几个OEM的同仁聊起来中央计算平台这个话题，吐槽最多的也是不同部门的权益之争，中央计算平台明显是“非我族类”的存在——它不仅吃掉了座舱的大部分功能，还要吃掉底盘的部分功能，最可恨的是它还对ADAS虎视眈眈等等，“我自己能做L3控制器，为啥要集成到你的中央计算平台里？也不要和我提软件定义汽车，我们单独的L3控制器和fallback控制器一样能快速迭代。

在传统OEM的组织架构中，整车的EEA团队和自动驾驶设计并不是一个部门，这种“部门墙”很坚固，很难打破；对于一些新势力OEM/科技公司而言，组织架构偏平，即没有所谓的“部门墙”，但是出了问题谁担责呢？整个中央计算平台的主责部门又如何判定呢？

其三、就实际产品而言，目前中央计算平台还仅仅支持行泊一体+座舱+动力+部分底盘功能（比如最简单的EPB），走的路线基本是“单板多SOC”或者“叠板设计”，从外观上看是一个集成的控制器，实际上ECU内部硬件相对独立，软件互相独立，本质上还是一个多ECU封装到一个ECU内的套路，确实是“软硬分离”！确实是“高内聚”“低耦合”！

另外，中央计算平台目前还是策略上移，原来的控制器的控制策略放在中央计算平台里，I/O驱动放在区域控制器内，对于实时性要求不高的舒适性功能还好，对实时性要求高的功能是不可接受的。

其四：可靠性，中央计算平台的耐久性、老化试验未经验证，短期内集成高阶ADS功能存在风险。

基于以上问题，笔者推测，对于L3以上ADS，中央计算平台是配角，不可能是主角。

三、架构演进的总结

笔者感触最深的是架构的正向开发理念，从工作到生活，貌似这种理念都潜移默化地影响了我的好多思考和决策，笔者认为架构的灵魂在于规划，在于布局。一个优秀的架构师必须是具备“上可九天揽月”的夸夸其谈，“下可五洋抓鳖”的工程落地能力，需要对架构的演进有清晰的认识和判断，定义好每一代架构的使命，清晰地规划上一代如何协助下一代架构进化，下一代架构又如何利用上一代架构资源，这个资源包括工具链、供应链、组织架构、ECU硬件、软件包等等，这是关键！

根据本文节奏，分布式ADAS架构→域控式ADAS架构→跨域式ADAS架构→跨域冗余式ADS架构→中央式架构，我们总结一下自动驾驶架构演进路线、每一代架构间的内在关联和OEM在每个阶段的能力布局，国内大部分车企都遵循这个路线发展：

传统的OEM，基本上都是采用稳扎稳打的路线，从结果上看传统OEM出成绩会慢一下，但是每一代架构的升级，传统OEM都会积累相关领域的经验，甚至转化为企业标准、设计指导书，作为经验固化下去，不会由于人员的离职导致业务停滞。

没有历史包袱的新势力则直接跳跃式发展，短平快地出业绩。对于只有一两款车的新势力OEM，这无可厚非，对于想发展多平台、多领域车型的新势力，EEA无疑是他们最大的短板。笔者了解到，一些新势力对内部平台化设计考虑很少，只看眼前，不考虑长期平台化，在这个角度看“短平快”策略的后遗症就暴漏出来了。

架构引发的产业链重塑

需求的升级导致功能的升级、功能的升级引起顶层架构的进化、最终拉动上下游产业链相互渗透、合作，车载域控制器将打破原有的垂直封闭产业链条，横向打通融合交叉领域，OEM逐渐从组装厂演变成Tier1、Tier2、ICT之间的纽带，协同Tier1、Tier2、ICT企业、整合跨界资源，地图商等企业，最终搭建集成化的基础平台，支撑市场化的服务需求。

顶层架构的进化致使OEM架构的电子电气要素升级，引发域控制器以及外围传感器的升级，如毫米波雷达向高分辨率发展，出现4D毫米波雷达，摄像头从200万像素发展到今天的800万像素，激光雷达从笨拙的旋转式到小巧的固态高性能发展，整个电子电气架构也将出现新型传感器形态，随着“智能化”时代到来，OEM的话语权势必越来越大。

批判与尊重

国内的新老OEM最常用的战略路线就是“抄”，特斯拉从Mobileye→英伟达+自研算法→自研FSD芯片+重写算法的三步战略仿佛给国内OEM指明了路线，蔚小理、智己、路特斯等纷纷站队英伟达，自研域控制器及算法，毕竟人家英伟达芯片是地表最强，开放度高，而且支持全链路的工具链，这也无可厚非，但是你们陆陆续续地高调宣布开始“全栈自研”、实现了“全栈自研”，笔者确实看不过去了，只想说：走别人走过的路确实永远不会迷路，但永远无法超车！

目前大部分OEM，不论是老牌OEM还是新势力，热衷于对标和超越特斯拉，大多并没有基于“本质”思考，毫无平台规划可言，更多是“为了对标而对标”，为了集成而集成，每一个战略决策大部分不是基于”国情“，而是基于理想主义，反正我先立一个课题，组一个团队，任命一群领导，概念范XX，量产罗玉凤，最终给罗玉凤画个妆，也就交作业了。

记得日经BP社的报道，特斯拉M3的EEA领先对手6年，特斯拉无疑是行业的开拓者，不拘泥常规套路，也无所谓什么“车规级”，毕竟车规级标准要求都是行业大哥（BBA）定的，人家也不屑于在大哥们制定的条条框框里玩耍，笔者认为认知的差距是我们和特斯拉最大的差距，我们拥有顶级的餐厅，顶级的食材，顶级的炊具，但是厨子手艺不行！而特斯拉呢，拥有顶级的厨子和餐厅，然后厨子去寻找合适的食材，设计趁手的炊具，这点我们望尘莫及，也无法复制！

廉颇老矣、尚能饭否？

相比于企图“乱拳打死老师傅”的造车新势力，笔者更尊重具有文化底蕴和技术底蕴的传统OEM，在智能驾驶赛道不断涌入新玩家，让整个赛道变得异常浮躁，相比于一些公司的短平快出demo车，秀PPT，传统OEM具备强大的资源整合能力和雄厚的技术储备优势，短期看，大OEM的组织变革如大象转身，但长期看，最后的胜利大概率会是老牌OEM。

国外的奔驰宝马就不多说了，国内南有比亚迪北有长城汽车，在汽车“新四化”的较量中，比亚迪的“电动化”已经是妥妥行业一哥，在“智能化”上比亚迪已经布局芯片，近期有消息比亚迪和华为在自动驾驶和智能座舱领域展开深度合作，比亚迪必定雄起！

北方的长城汽车也是一匹低调的黑马，其自动驾驶路线可以用“双轮驱动”来形容，一方面采用全栈自研的内部供应商毫末智行提供的系统方案，另一方面使用华为MDC+Momenta算法的软硬解耦方案，两种方案同时兼容了L0-L3级别自动驾驶功能，同时具备拓展到L4的能力，得益于长城汽车电子电气架构平台化的优势，预计两种方案对相关系统（转向、制动、HMI）的接口要求做到平台化设计，域控制器的可移植性、替代性较强。

目前，长城汽车的供应链：转向、制动、座舱、智能驾驶基本实现全面自主化，具备自主产权，供货成本和风险较低、核心控制器采用多家供货原则，断货/延货风险较小。

由于全球疫情原因，以及芯片危机，同行都争先恐后站队英伟达，据不完全统计，目前选择英伟达orin的客户已经超过了25家，然而长城汽车选择了自动驾驶芯片的后起之秀-高通，成为全球首个基于高通芯片平台的自动驾驶的客户，如毫末智行的小魔盒3.0，采用了高通9000+高通8540+TC399方案，预计2022Q3量产，据内部人员透漏毫末智行的小魔盒3.0还有B计划，目的是防止芯片卡脖子，笔者猜测B计划会采用国产地平线征程5芯片方案。

汽车智能化竞争越来越激烈，最终花落几家，让我们拭目以待。