汽车智能化、电子化程度的不断提高，这是大背景，这个大家肯定没异议。毕竟客户爸爸们现在很喜欢，未来会更喜欢。

这时候来了三批工程师要搞定这个事，他们首先要解决的就是怎么把车上这么多电子设备连接起来，这个设计过程就是电子电器架构

所谓「电子电气架构」，简单地说就是把汽车里的传感器、中央处理器、电子电气分配系统、软件硬件通过技术手段整合在一起。通过这种架构，可以将动力总成、驱动信息以及娱乐信息等，转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、容错、能量管理等电子电气解决方案。

通俗来说，汽车是一个软硬件结合的产物，如果把它比作是一个人，「四个轮子+一个沙发」是身体，电子电气架构就相当于神经系统，负责完成各个部位的连接，统领整个身体的运作，实现特定功能。

首先是一群抱着“机械定义汽车”思维的传统车企工程师开始动作了。增加电子控制单元(ECU)、增加传感器、增加仪表。要连接了咋么办。哪两个东西之间有需求，就加根线呗。

传统的车上电气系统，大多采用点对点的单一通信方式，相互之间很少有联系

但随着系统变复杂情况不对了，布线系统变得异常庞大, 一辆传统连接的汽车中，导线总长度可以达到2000多米，电气节点可以达到1500多个。导致线束材料成本剧增，可靠性骤减。系统不可持续了。

又来了一群抱着“硬件定义汽车”思维的车企工程师开始寻思了，计算机硬件里不是有总线嘛，能不能借鉴下，大家都先连在几根粗线上。

总线技术可以简单理解为高速公路，路上所有的车（信息）都走一段高速，降低道路（线束）成本。

为简化线路连接，提高可靠性、利于各装置之间的数据共享，以汽车分布式控制系统为基础的车载网络总线技术发展起来了。

汽车总线技术的优点是在统一应用层协议和数据定义的基础上，可以使之成为一个“开放式系统”，具有很强的灵活性。对于任何遵循上述协议的供应商所生产的控制单元都可轻易添加入该网络系统中或者从网络系统中拆除，几乎不需要做任何硬件和软件的修改，这完全符合现代汽车平台式设计的理念。因此汽车电子控制采用网络化设计可大大降低设计成本。

当然行人或者自行车（数据）移动的过程对路（线束）的需求不同，不同设备之间的通讯也有不同需求，有些要高可靠，有些要大容量，有些要抗干扰。这也催生了大量的汽车网络如LIN，CAN，CAN FD， FlexRay，MOST，汽车以太网的百家齐放。

综合考虑功能和位传输速率等因素现有的汽车通信网络大致可划分为ABCDE类网络： 
A类网络主要应用于低速场合，通信速率不超过10kb/s。目前A类网络中应用最广的是LIN总线。LIN总线标准是由LIN协会制定的专门用于低速网络的低成本网络解决方案。 
B类网络主要应用于实时性要求不高的场合，通信速率一般为过10~125kb/s。以前有低速CAN，J1850和VAN等多种，目前低速CAN总线成为B类网络中的主流。 
C类网络主要应用于实时性要求较高的场合，通信速率一般为125~1000kb/s。目前C类网络中主要有高速CAN，FlexRay其中仍属高速CAN使用较为广泛，普遍应用于动力、底盘、发动机等领域的控制。 
D类网络主要面向多媒体、导航系统等领域，网络的数据传输速率为250kb/s~400Mb/s。目前的D类网络总线有IDB-1394和MOST。两者目前在量产中是并存关系。 
E类网络主要面向成员的安全系统以及车辆被动安全领域。目前主要的E类网络主流为Byteflight，其最高传输速率10Mb/s。特点是强调高安全性。

可问题又来了，这高速公路是修了，成本也节省了，可这道路上的交规（总线协议）是几个山头（ECU供应商)定出来的，不允许你变化。最多两年变一次（整车开发周期）。还有一种情况是本来走自行车的现在要走卡车了，这路面又支持不了了，部分总线比如LIN,CAN并没有很高的容量扩展性。需求变化了，基本就只能让客户爸爸等两年换一辆车了。

 

这个时候抱着“软件定义汽车”思维的工程师跨步走来，看着他们好像要做软件了，实际他们第一件事还是尽可能的要折腾下硬件，就是在把尽可能多不同的总线合并（所有路都按照一个标准修建），另外尽可能多的合并控制器（哪有那么多山头，交通部全中国就一个），这样后面有个啥世博会，马拉松啥的，我可以根据需求统一变化，适应各种需求。

博世电子电器架构研究研究

这里还是要再专业点描述这个问题，在软件定义汽车思维下有三个重要的关注点

硬件成本进一步降低：相同功能需求下，减少 ECU（电子控制单元）数量，可以降低 ECU 物料成本，另一方面也进一步减少了整车线束使用量。Model S 线束约 3 公里长，而 Model 3 缩短了近 1 倍。

硬件抽象：此前的供应体系是供应商将「软件+零部件」打包卖给主机厂，软硬件的耦合很深，议价能力差，测试调试苦难。特斯拉的牛叉在于软件基本自己写，即便更换硬件供应商，也不会显著影响软件功能的部署。

OTA升级：在硬件抽象的基础上，特斯拉可以通过 OTA 的方式进行新功能的更新下放，以及对车辆状况进行良好监控，降低维修成本。整车软件开发变得更多样化，更简单。

一个最经典例子：特斯拉通过 OTA 解决制动距离过长的问题。彼时 Consumer Reports（消费者报告）发布的特斯拉 Model 3 测评中指出，这台车的 60mph-0 刹停距离并不理想，达到了 46.33 米，但是经过 OTA，Model 3 的刹车距离得到了显著提升。

 

刚才说了有三批工程师来解决这些问题，目前第二批工程师代表了主流的主机厂，而第三批工程师代表了Tesla等新兴的车企。主流主机厂看Tesla不眼馋嘛？家大业大干不过他？还真是。。。

阻碍帝国成长的是帝国本身，软件定义汽车本质就不是一个技术问题

表面上，车子都是整车厂造出来的，但这并不意味着车上的所有技术都是由整车厂研发的，供应商才是大部分技术的幕后功臣，而「整合」才是整车厂的重要任务。汽车工业百年发展，早已形成完备且复杂的供应商体系，比如我们常说的一级供应商、二级供应商、三级供应商。。。。

如此多供应商的加持，看起来更牛逼了。旧时代看着是一只军队，新时代里就变成了乌合之众。车企转型需要自身有足够强的研发能力，还得和供应商不断博弈，付出大量的人力物力财力，还需要经过一个比较长的磨合期，才能真正在量产车上落地。

更重要的，欲练此功，必先自宫，主机厂们担心特斯拉的这种设计趋势会淘汰掉他们数十年来培育起来的零部件供应链。谁能想到有一天，曾经让主机厂安逸发财的供应链成为阻碍其创新的绊脚石？

大众、丰田、上汽等传统整车厂，体量巨大。在电子电气架构上动刀子 ， 如果不成功，谁来为负责？轻则影响公司未来几年产品的销量，重则事关生死。而且，难免会因此而触犯别人的利益，推行阻力很大。

特斯拉体量小得多，也没什么历史包袱，因此可以直接上手去做。而马斯克个人秉承的第一性原理的思维方式以及超强控制欲，多年以来，公司坚持创新自研、垂直整合，已经是这家公司的深刻烙印。特斯拉在电子电气和软件层面的优势，并不是偶然。

传统车厂也在行动：大众开发了自己的 MEB 纯电动平台，同时斥巨资成立软件中心，提升自己的软件能力，与此同时，大众设计了全新的 E3 电子架构，计划将 70 个 ECU 减少到 3 个域控制器。去年 5 月，通用汽车发布了新一代电子电气架构，支持整车 OTA。宝马也在全新一代产品（3 系、X5、X7）都已经可以支持整车 OTA，如果不是在电子架构层面做改变，这个特性是很难实现的。中国的头部 OEM 都在积极开发下一代的电子电气架构，并且在 2022 年左右实现新一代电子电气架构的平台化。

趣闻：量产过程，不是自动驾驶工程师不努力，而是臣妾做不到哈

如果你知道整车开发流程，一定知道“冻结”这个概念，关键接口，关键零部件在每个小迭代周期都会进行冻结，以维持各个块线的合作和同步推进。

没有OTA或者域控制器之前，智能驾驶功能必须要等到底盘性能完全冻结才能开始进行标定、调教和测试，虽然多数时候会分多个迭代过程，进行多个周期的调试，但不管哪个周期，智能驾驶功能永远是拍在最后的。一旦前面的某些开发出现了延期，在量产前最着急最痛苦的就是智能驾驶工程师，因为压缩的基本都是他们性能提升和测试的时间。

自动驾驶的研发周期理论上就不可能和整车研发周期契合！

无论生物成长还是汽车制造基本都一个道理：简单构件往往会优先产生并投入工作，以支持复杂构建的产生，骨架，心肺，往往都会优先形成机能并支持大脑器官的发育，后者的成熟周期往往是最长的。不同器官需要处理的任务维度不同，因此复杂度也不同

就像小宝宝，如果它脑袋在出了娘胎后就不成长（传统电气架构），那牛津大学也要在娘胎里读了。虽然骨架，肌肉，心肺都可以在出生前健全，但10个月时间脑子的核心功能是好不了的，他需要对接外部环境。但如果可以后天学习，那ok了，差不多时候我就可以从娘胎里出来了。

OTA或者域控制器的产生，为自动驾驶等功能释放了更多空间和时间，让其开发周期和测试周期得到必要的保障。

 

---

1. 新EE架构的驱动因素

1）半自动驾驶辅助系统、定期空中升级等复杂的电子功能将很快成为许多车辆的标准功能；这些复杂的电子功能需要新的EE架构和更高性能的ECU支持；

2）车内软件的数量和复杂度持续快速增加，汽车行业正在经历重大变革以满足新的市场需求。

3）车辆新的功能和任务所需的计算能力越来越高，微处理器作为微控制器的补充，越来越多的被应用于ECU中。一个或多个微处理器与控制器相结合，形成高性能ECU，用于对高算力的需求；这些ECU的微处理器与智能手机或PC中使用的微处理器非常相似，也需要新的软件架构。为了将这些微处理器无缝地集成到现有的车辆网络中，运行在操作系统之上的中间件需基于标准的AUTOSAR Adaptive。

4）在快速数据网络和强大处理器的支持下，重点不再是高效的数据传输，而是加强单个ECU的解耦。从而使更换单个ECU对系统其余部分的影响应尽可能小。

2. E/E架构的进化路线

2.1 过去 - 分布式EE架构

一个功能是由一个ECU来实现的。并且还带有一组相关的传感器和执行器，并从车辆网络接收其他数据。车辆的通信矩阵描述了ECU之间的这些必要的通信通道。 但是，这种设计限制了可重用性。传感器和执行器直接连接到单个独立的功能性ECU上。 如果其他总线参与者需要使用这些值，则需要更改通信矩阵。

图1. 分布式EE架构

2.2 现在 – 域控制EE架构

典型的域有 “车身域”，“动力传动域”和“信息娱乐域”。 该EE架构的基本思想是每个域使用一个功能强大的控制器，绝大部分必要的传感器/执行器都与该控制器连接，这大大增加了在域中扩展功能的灵活性。

图2. 域控制EE架构

2.3 未来 – 中央服务器EE架构

域控制器进一步合并在大型高性能计算机服务器或计算机集群中，传感器/执行器现在作为所谓的“智能传感器”和“智能执行器”直接连接到网络，并执行机电一体化任务。 因此，它们变得独立于ECU和车辆，从而实现了具有高重用潜力的模块化系统设计。

但是，对于低成本传感器，此过程将不会具有良好的成本效益比。要使用这些传感器，它们还可以直接连接到图3中蓝色显示的集成节点ECU上。这些节点ECU还具有另一个重要功能：它们充当传感器和执行器的总线系统（即CAN，LIN，FlexRay和以太网）之间的网关。

在这个网络中，以太网代表了中央计算机方向的主总线系统。通过对传感器和执行器ECU接口的适当抽象来创建模块化和功能可扩展的体系架构。

图3. 中央服务器EE架构

3、基于中央服务器EE架构的复杂性

1）需要异构的高性能计算平台

中央服务器或集成节点域控制单元是结构比较复杂的ECUs单元。 它们通常由几个微控制器和微处理器组成。

优点1. 因为控制器和处理器的属性相互补充，因此这种异构结构提供了一些性能优势。

微控制器自身性能优势：

a、微控制器的启动时间更快，上电启动后，它可以快速进行操作，因此可以参与与其他ECU的通信并执行其功能。

b、微控制器甚至可以满足微秒级范围内具有低抖动的最高时序要求。

c、微控制器也更适合那些需要其频繁中断的功能；

微处理器自身性能优势：

a、使用的计算内核提供了更高的时钟速率，并带来了许多功能，例如高多标量或跳跃预测，可提高平均性能。

b、较大的高速缓存还允许连接速度较慢但较大的外部存储设备。

c、除了更多的资源容量之外，微处理器还提供了更好的硬件虚拟化支持，从而使管理程序（hypervisor）技术的使用更加容易。

优点2. 具有微控制器和微处理器的异构计算单元的另一个优点在于可以满足安全要求。 按照ISO26262标准来看，当前处理器的安全完整性等级达到ASILB。通过使用冗余，仍然可以实现高度自动驾驶所需的ASIL D等级。

在这样的系统中，冗余的微控制器执行两项任务：一方面，它执行监视功能；另一方面，它也可以用于在发生故障时提供降级的功能，以便系统能够继续以高度的可靠性执行其功能。

图4. 基于AUTOSAR Classic and Adaptive两种平台的自动驾驶系统典型安全架构分析

2）高性能异构计算平台（高性能ECU）内配备了多个可编程组件

在高性能ECU内部，许多独立的软件组件共同实现ECU的功能。这在技术层面和组织层面都具有挑战性。

从技术角度来看，组件必须能够相互通信以提供通用功能。ECU制造商的任务现在是通过使用处理器间通信（IPC）连接组件并描述交换的数据。 对于ECU制造商而言，这是一项新任务，因为在先前的工作流程中未执行此步骤。然而事实是到目前为止，只需描述ECU之间的数据交换。并且这一责任完全由车辆制造商承担。这同样适用于系统的诊断功能、软件更新和网络管理。在未来，ECU简单的单独由一方定义的方式将会变成由多方进协商后来共同完成。

从组织的角度来看，集成各种软件组件是一个日益严峻的挑战。 ECU的模块化设计和POSIX兼容的操作系统使集成来自多个独立团队的软件变得更加容易。然而，因此，ECU集成商的角色变得越来越复杂。这使得用专业的工具来支持ECU集成商完成其具有挑战性的任务变得更加重要。

4、中央ECU的软件平台 – AUTOSAR Adaptive

在软件开发中对性能和灵活性的不断增长的需求以及对成本的敏感度的不断提高要求整个供应链的广泛变化。AUTOSAR Adaptive是必不可少的软件组件平台，它将为将来高性能ECU的发展做出重大贡献。

在微处理器上执行的软件组件通常不基于AUTOSAR Classic标准。 而是使用AUTOSAR Adaptive标准以满足对模块化，动态性和更新功能的要求。

AUTOSAER Adaptive 基础介绍：

1）AUTOSAR Adaptive 中间件使用兼容POSIX的操作系统，例如Linux，PikeOS或QNX；AUTOSAR Adaptive的主要功能之一是通信层ara :: com。 这样就可以与其他AUTOSAR Adaptive应用程序以及车辆中的其他软件组件（SWC）通信。

图5. ATUOSAR Adaptive 软件结构示意图

2）AUTOSAR Adaptive允许在运行时建立动态通信路径。 这种动态性是可以在运行时安装的应用程序软件的先决条件。 经典的通信矩阵必须进行修改才能将新内容发送到ECU。但是，通过面向服务的方法，可以订阅信息；

3）硬件驱动程序和高级软件更加严格地分开。 因此，车辆中与硬件无关的应用程序具有很高的便携性。与AUTOSAR Classic ECU相比，这可以实现更大的资源优化。例如，如果超过了资源限制，开发阶段的软件可以很容易地在不同的ECU之间移动，以避免硬件设计的更改。

4）另一个优点：软件组件在几种车型上的可重用性正在提高。在AUTOSAR Adaptive项目中，软件与硬件的分离还可以使车辆制造商和供应商之间进行全新的工作分配。 以前，功能总是作为车辆中的物理设备订购的，而现在可以通过软件完全购买。