在读到一篇关于底盘集成控制的综述时，对其底盘架构的发展历史梳理与分类感到一些困惑。之前接触过一些描述汽车电子电器架构的报告、白皮书、论文，感觉它们之间也有一些混乱，各有各的说法。

  各种架构方法、名称的出发点是什么呢？目前主流的架构到底是怎样的？未来的升级趋势又是什么呢？各个控制域是如何划分的？是执行器集成控制ECU的形式，还是域控制器集成控制算法，执行器仅作为机械标准件更容易实现模块化-硬件解耦呢？

  对于刚入门的人来说，对这些概念是感到困惑，尤其是不同的文档中出现冲突时。因此尝试结合国内外一些较权威机构发布的关于新能源、电子电器架构的文档，目的是理清复杂、纷乱的定义，明确汽车电子架构的趋势，给出一个能让自己信服的说法。

  //由于研究方向与底盘控制相关，本文将偏向于车辆动力学控制的角度进行考虑。

  促使汽车电子电器架构升级的出发点，我个人觉得主要有三个：减少相关成本，提供长期的软件收入以及智能化体验。

  降低成本，这点比较容易理解：之前的分布式架构每个执行器都配备一个ECU，整车的硬件模块增多，走线也更长。现在，随着算力降价，可以将一定区域内的执行器交由一个ECU进行管控，自然能够更好的降低硬件和线缆成本。此外，升级域控制器有利于软硬件解耦，缩短开发周期，减小供应商依赖。

  长期的软件收入：可以借鉴Xbox亏本卖主机但通过游戏赚钱的模式。汽车行业认为OTA（空中升级）会成为一个长期的收入来源，但要让用户为持续的升级和软件服务付费，就必须要提供优质的软件。

  智能化体验：将电车作为“带轮子的超级终端”，融入用户的数字、私人和职业生活中，而不单单是交通工具。

  关于汽车智能化的体验，我个人还没到买车的年龄，不过之前问界的城市内自驾适配问界M5 智驾版上海城市NCA 全程无接管完整版_哔哩哔哩_bilibili以及智能车机【汽车茶谈】购买新能源汽车一年后，我想谈谈对汽车智能化的看法_哔哩哔哩_bilibili让我印象非常深刻，之后如果购车智能体验也会是一个参考项。

  在当今市场上，引擎性能、外观和安全性已不再是消费的人选择汽车时唯一考虑的标准。特别是年轻人购买汽车是因为它能为他们提供娱乐、便利和融入在线世界(Online World)的机会。他们寻求能够无缝连接交通、家庭和工作的产品。当前，汽车正在演变为一个技术阶段，

  个性化使用者真实的体验(User eXperience)和可持续演进迭代是重要的条件

  汽车行业对这些挑战的应对方案是软件定义汽车(SDV Software Defined Vehicle)，它代表了技术解决方案空间从硬件到软件的转变。这种新的关注点带来了所期望的灵活性，但也需要改变整体汽车架构。过去的分布式电子电气架构在可更新性、可定制性和互联性方面存在扩展性不足。随着速度成为关键因素，这些架构的设计、基础开发方法和工具都受到显著限制，阻碍了引入以软件为中心的技术平台与软件定义汽车的转型。

  博世给出的电子电气架构路线图分为三个大阶段：分布式阶段、域集中式、车辆中央集中式[2]。

  1）在此阶段，每个电子控制单元（ECU）负责特定的功能，例如车灯对应一个控制器，车门对应一个控制器，无钥匙系统对应一个控制器。随着汽车功能的增加，这种架构慢慢的变复杂，无法继续使用。

  2）集成化阶段，一个ECU开始负责多个功能，因此ECU的数量比上一个阶段减少。在这两个阶段中，汽车的电子电气架构仍然是分布式的，ECU的功能集成度低。

  在传统的汽车E/E架构中，各个ECU相互独立，通过总线进行通信。每个控制单元负责特定的功能，例如发动机控制、制动系统控制等。尽管这些控制单元之间通过总线进行通信，但它们的通信较为独立，缺乏整体协调。这种架构存在硬件成本高、开发周期长、扩展性差等问题。

  为了解决传统架构的问题，汽车电子电器架构逐渐向集中化发展。最常见的是如博世划分的五个功能域，包括动力域、底盘域、车身域、座舱域和无人驾驶域。这种域集中式架构是在传统分布式架构的基础上进行改进的。它将电子电气系统区别划分为多个功能域，每个域由一个主控制单元负责管理，并通过域总线进行通信，实现了域内的集中管理和域间的协调。在这样的架构中，多个ECU被集成到一个中央控制单元中，域控制器之间通过以太网和CANFD（CAN with Flexible Data Rate）相连。其中，座舱域和无人驾驶域由于要处理大量数据，算力需求逐步增长，而动力总成域、底盘域和车身域主要涉及控制指令计算及通讯资源，算力要求较低。

  中央集中式架构是汽车电子电气架构的当前趋势。它试图将所有电子电气功能集中到一个中央控制单元，并通过高速总线与各子系统通信。其核心理念是将多个领域整合在一起，由一个跨领域控制单元控制。例如，将动力、底盘和车身领域合并为整车控制领域，从而将五个功能领域（无人驾驶、动力、底盘、座舱、车身）过渡到三个（无人驾驶、智能座舱、车控）。中央控制单元具有更强的解决能力和更高的集成度，可实现更复杂的功能和更高效的系统管理。

  在域集中式架构中，相关功能的控制单元被组织成不同的域，如动力、底盘、车身等。每个域都有一个主控制单元，负责管理该域的所有功能。各域通过高速总线通信，实现域内和域间的集成。

  目前前沿车企慢慢的开始转向集中式(Centralized)和区域式(Zonal)架构[2]。在分布式 E/E 体系中，功能在具有高度软硬件集成的 ECU 上。在域集中体系中，出现了核心域控制器，通过整合多个功能来实现成本优化和增加更多的功能。

  博世为咱们提供了一个参考的领域划分方式。从功能领域（Domain）的角度来看无人驾驶车辆（SDV）的架构，如前所述，明显地看出集中化的发展的新趋势。高级驾驶辅助系统（ADAS）、休息娱乐系统和驾驶和车身功能都将集成到一个统一的电子控制单元（ECU）上。

  具体的领域划分方法和后续的整合形式，各个汽车制造商都有自己的解决方案，但总体思路是一块电路板（PCB）管理一定区域内的执行器和传感器。这可以是根据功能进行划分，例如底盘安全和动力总成，从而方便在不同的领域控制器中部署相应的软件算法、进行OTA等操作。也可根据车身区域进行划分，例如特斯拉按照左、右、前区域进行划分的领域控制器，这样做才能够更有效地减少总线长度。

  通讯作者：Aldo Sorniotti，UK萨里大学现代汽车工程领域教授。

  随着有人无人汽车的底盘执行器数量的增加，集成底盘控制（Integrated Chassis Control, ICC）愈发重要。ICC通过克服单个执行器的局限性，解决冲突和冗余问题，确保系统地开发现有执行器的潜力，来提升车辆性能、驾驶舒适性和安全性。

  在车辆底盘控制的情境下，执行器可能包括转向系统、刹车系统、悬挂系统等。这些执行器的控制器可能会产生的输出在没有适当协调的情况下可能相互冲突，导致车辆性能直线下降或不稳定。对于控制算法，能够在同一台计算机中读取各项传感器数据，进行状态估计，然后下发控制指令，肯定优于将各种控制算法写在专用ECU中的分布式架构。底盘集成域控制融合了更多的信息，能够给大家提供更好的控制精度和灵活度，但控制算法也变得更复杂。

  底层设计：自上而下的。分布式；分散结构；子系统模块化；出故障单独运行，减少互相干扰。

  这种架构的优点是引入一个新的底盘驱动系统并不一定有必要进行重大的重新设计，也不一定需要额外的高级控制器。单个系统的算法可以从传统供应商处批量购买，汽车制造商主要要确定哪些底盘促动器适合特定车辆，并事先验证其兼容性。

  all chassis actuation systems are developed independently, and each of them includes both software (control layer) and hardware (physical layer)。 每个单元的性能都会进行独立测试，这样的设计被称为分散控制或异构架构。每个底盘系统都可以独立传输控制输入，并有自己的电子控制单元(ECU)，这很适合汽车制造商的传统组织架构。系统间唯一的互动方式是信息共享，例如，系统能通过网络进行通信，但前提是相关供应商必须提供适当的接口。这种设置允许对控制行动进行轻度协调，而每个控制器设定的参考车辆响应之间的冲突能够最终靠校准单个算法解决。

  由于减少了开发时间，PeC 在实施单目标 ICC 时通常具有成本效益，但在实施多目标 ICC 时，与集中式解决方案相比，PeC 可能意味着更高的成本和更不利集成。单目标集成底盘控制可能专注于实现一个主要目标，例如提高车辆性能或燃油效率。相比之下，多目标集成底盘控制可能需要平衡多个目标，例如同时优化性能、燃油效率、舒适性等多个方面。

  因此，single-objective ICC和 multi-objective ICC是在比较 PeC 架构在这两种不同应用情境下的性能和成本。在单一目标的情况下，PeC 通常是成本效益的，而在多目标情况下，可能涉及到更高的成本和不太理想的包装（系统组织方式）。

  PeC 是最不适合主动安全控制的架构，因为它不存在任何实际监督或协调。虽然这个架构有一些过时、但确实是第一代实现了“底盘集成控制ICC”的架构。即使各执行单元各干各的，也能够最终靠总线进行一定程度上的协调联控。

  与 PeC 相比，CoC 增加了一个协调层，负责接收各个控制器的输出，并将相同变量（偏航率？）的修正值反馈。

  对协调层的要求是在20世纪90年代中期引入车辆稳定性控制系统（VSC，其他几个缩写意思是一样的，如ESC、ESP和VDC）和全地形控制系统，以及设计新的执行器之后提出的。

  CoC架构比起PeC只是多了一层协调策略层，用以收集、处理、下发各执行器的控制命令，进而让各个执行器达到一定的“协调合作”。需要注意的是，此时执行器仍然是包含了控制器slave controllers，就电子元件数而言不会比PeC少，大概。

  在这个上下文中，冲突 指的是各执行器之间的冲突，即它们在执行各自的任务时可能发生的相互干扰或不协调。具体来说，在车辆底盘控制的情境下，执行器可能包括转向系统、刹车系统、悬挂系统等。这些执行器的控制器可能产生的输出在没有适当协调的情况下可能相互冲突，导致车辆性能下降或不稳定。

  举例来说，考虑一个情景，其中车辆的横向加速度需要通过转向系统和刹车系统来协同控制。如果转向系统和刹车系统的控制策略没有协调，它们可能会产生相互矛盾的指令，例如一个系统试图增加横向加速度，而另一个系统试图减小。这样的冲突可能导致车辆在操控性能或稳定性方面出现问题。

  根据论文的说法，CoC内的计算单元实际上比较少，没有高级的计算单元和复杂的控制算法。由于相对于PeC而言，它的变化非常有限，因此在对变化持保守态度的汽车产业界得到了应用。算法也相对简单，基于驾驶条件的基于规则的控制算法，简单理解为一系列的if-else语句。因此，CoC更适用于单目标ICC，并且与PeC类似，不推荐用于复杂的自动驾驶应用。这是在工业上有一定应用的阶段性产物。

  Cooperative Coexistence (CoC) 架构在这方面提供了一个协调层，用于处理各个执行器间的输出。但这只能是事后的修正，也就是说，只有在冲突发生后才进行调整。这是因为，只有在接收到各执行器的输出后，协调层才能识别出潜在的冲突并试图进行调解。由于没有预先设定的协调规则，CoC 无法防止执行器输出前的冲突。

  相对而言，一些更先进的底盘控制架构采用了预先设定协调规则的方法，这样在执行器输出前就能避免潜在的冲突。这使得这些系统能够更有效地防止冲突，而不仅仅是事后修正。但是，这些更先进的方法可能需要更复杂的系统设计和更高级的协调控制，这增加了实施的复杂性。

  自上而下，高级多变量控制器位于传感器/状态估计层和底盘执行系统之间。高级控制器通过通常基于优化的控制分配（CA）算法协调各子系统并防止冲突。在架构图中，将传感器和估计的状态变量信息集中考虑在高级控制器中，实现集成控制。

  由于所有相关参数都存储在多变量控制器中，因此上游架构可以轻松考虑到许多方面，例如驾驶条件、驾驶员意图、执行器响应时间和功耗。管理多目标 ICC 的能力-上游协调架构。

  文章中架构变化按照时间叙事的方式呈现，这种架构是基于CoC架构改进的，将控制层和协调层集中在一个算力较大的控制器中。

  CeC架构的顶层收集估计的状态信息，并将其传送到第二层，包括多变量主控制器。该控制器向底层的执行器提供控制命令，并向从控制器提供参考。这些从控制器负责完成集成中未涉及的特定任务，例如反馈车轮滑移控制。集成控制器拥有对所有子系的完全控制权，因此CeC能够最终靠同时操纵所有模块来提高性能。此外，这种解决方案允许从初始设计阶段就对系统稳定性进行系统和正式的考虑。

  缺乏模块化，要求汽车制造商与供应商共同开发主控制器，以便能够适当修改子系统的执行算法。

  与单一多变量控制器相关的复杂性巨大。一般而言，通过将系统划分为主控制环和伺服控制环，可以降低这种复杂性。虽然任务被适当解耦，但系统仍然保持了多变量控制结构。这种结构被称为主/伺服环路分区，是之后监督和多层架构结构的重要环节。

  难以应对中央单元故障。与下游架构不同，CeC本身不提供容错功能；但可以识别故障并设计额外的控制逻辑，帮助系统从故障中恢复。

  也是一个过渡架构，或者说这种架构能实现的能力有限。用一个高级计算机控制所有执行器，这显然是上面提到的车辆集中域控或底盘域控架构的终极形态，但这篇文章说的和之前EE架构说的可能不是一个事情。

  以主控制环和伺服控制环为例，EE架构中的域集中指的是域计算机控制执行器的主控制环，而伺服系统还是在执行器上的，切换到这篇文章的视角，就是说会有一层control layer。目前产家提供的执行器可以做到私服控制电路集成到机械元件内部，某种机电一体化设计，也相当于减少了ECU。而文章提到的CoC架构，非常极端，连更底层的伺服控制系统也要囊括，这显然是太过分了。

  架构的三个主要层是监督层、控制层和物理层。监督策略从车辆信号和人类或自动驾驶的指令出发，对当前驾驶情况进行分类，检测特定的不稳定性或系统故障，并通过以下方式确定每个底盘执行系统的工作区域：

  监测控制行动，并允许根据预先定义的优先级对执行器进行干预。例如，当转向控制无法提供进一步的偏航力矩时，直接激活偏航力矩控制。

  监测参考状态，系统根据指标检测驾驶条件。例如，使用 split-μ 识别算法，然后修改参考模型，生成不同的目标偏航率。

  结合前两种策略。控制层可以进一步分为高级控制器（主控制器）和低级控制器。

  高层控制器将监控层生成的参考值转换为每个本地控制器的控制参数，即主控环。底层控制器是底盘执行系统的本地控制器，可以由各个供应商单独设计和验证。相较于CoC，架构的分层意味着具有某些特定的程度的容错性。特别是，如果控制层不完全依赖于监控层，即基本的车辆传感器和状态估计输出也传送到控制层，该结构可以确保最低限度的功能来保证车辆安全。否则，如果车辆状态信息仅由顶层使用，则该结构仍然是集中式的，通信中断将导致整体系统功能障碍。

  SuC的一个特点是其模块化性质，允许汽车整车厂及其供应商独立开发补充控制器，当然前提是要有一致的接口。

  与 SuC 类似，MuC 通过分离功能需求，同时协调和监控每个模块，实现了系统模块化和设计灵活性的基本特征。

  在这种架构中，汽车制造商通常负责车辆动态监控，直至 CA 层，而相关供应商则独立设计各个执行系统。和SuC不同的是，从整车动力学分析、目标指令到各个执行器的控制输入，这种架构多了很多层：监督、中控、协调、下发。从某种程度上可以看作是SuC的改进，这么多层可以都是软件层，部署在一个中控机内。

  这篇综述文章的作者认为，actuator集成controller是有利于模块化的。作为一个技术人员很容易理解：中央计算机中发的指令层级越高，底层模块就越方便替换。例如，对于转向模块，我下发的是一个转角，还是转向执行器的具体电压值（甚至带闭环控制），这两者的复杂度是不一样的。从整车厂的工程师或底盘集成研究人员的视角，自然是你执行器带的控制器能力越强，模块越容易替换：如果下发的是转角命令，更换一个供应商控制算法几乎是不变的。如果在底盘域计算机或主板MCU中部署了steering相关的闭环控制代码，则每换一个供应商都得根据机械、硬件重新调参，硬件可替换性自然会下降。

  那么，为什么电子电器架构或软件定义汽车类的文档，认为域控制器集成控制算法，执行器作为机械标准件的形式，更有利于实现模块化、硬件解耦呢？在文献[6]中有关于软件定义汽车缩短开发周期、整车厂规范接口等方面的论述。

  开发迭代的朴素理解是，在软件定义汽车的框架下，通过数字化建模来定义汽车系统，其目的是推动汽车研发的软硬件分离。

  相较于之前技术人员的视角，架构升级从行业、周期的宏观视角，认为整车厂在域控内做更底层的控制是有利于加速开发周期、软硬件解耦的。

  分布式计算导致了车内信息孤岛、算力浪费、软硬件耦合深，主机厂严重依赖供应商。

  传统汽车供应链中，不同的ECU来自不同供应商，不同的硬件有不同的嵌入式软件和底层代码，整车软件实际上是很多独立的、不兼容的软件混合体，导致整个系统缺乏兼容性和扩展性。车厂要进行任何功能变更都需要和许多不同的供应商去协商软硬件协调开发问题，每新增一个新功能都需要增加一套 ECU 和通信系统，耗时长，流程繁琐。且由于每个 ECU 绑定一个具体功能无法实现横跨多个 ECU 传感器的复杂功能，亦无法通过 OTA（Over the Air ）来保持汽车软件的持续更新。

  就是说，业内认为整车厂后续的设计趋势，Control Layer内的控制功能应该交给整车厂来做，而不是供应商做。这样方便修改、替换。硬件标准化-供应商提供机械硬件，如何控制由整车决定。

  至此出现了一个很有意思的现象，同一个问题，从技术人员和管理人员两种不同的视角，得出了两种相反的结论，并且两个都挺有道理。不过就行业整体趋势而言，域控制器集成更多执行器控制的路线是更具优势的，技术人员也应该在这个背景下去思考整车的控制。

  总结一下上面的讨论，架构大体是升级思路是：硬件上集成、精简；软件上分层、解耦。

  做域控制器-架构升级，一个重要的目的是实现解耦。理论上来说分布式ECU+actuator更容易实现组件替换，但是这种架构电路板+执行器会非常多，每一个执行器配一个ECU，走线、电子结构非常复杂。做域控制升级，主要意义是用一个更高级的控制器来控制多个actuator，那么对于模块的可更换性，要求是能够接收更底层的控制命令。但实际集成情况是一个缓慢的，ECU逐渐减少的过程，例如[2]的主界面展示这种架构升级的优势： Up to 20% fewer embedded control units. 注意这是Up to，而这种架构升级是博世2016年开始提的（能查到的最早的资料），并且有些控制单元是不好集成的。

  以电机举例，一般的ECU+actuator的模块，控制命令下发速度指令或者转矩指令就够了，之后由电机驱动板+控制算法（FOC）+PWM调制来实现。而且电机控制板一般都是由电机厂家来做。硬件方面主要PWM调制-电驱驱动模组，这一部分需要额外供电，三相or多相驱动对走线要求高，一般也是做到电机里面的；既然都有额外电路板了，直接把FOC等控制算法的MCU也做到电机里面就好了。所以我认为电机模块的方向一定是ECU+actuator的，即电子架构上电驱控制一定部署在域控计算机之外的控制单元芯片上。

  查阅一些新闻稿后，发现整车厂自研自产电机电控是一个行业内的趋势，但三方供应商仍然不可或缺。从我们技术人员的角度来看，在本文考虑的框架内，一个问题是：在底盘底盘集成域控制中，对于电机的控制到哪个层级？就我目前接触到的情况来看，最高级别是扭矩环，仅涉及到牵引动力学与横向动力学，扭矩指令就足够了。更底层的电机电流策略和PWM合成方法在动力学系统中并没有体现出来。

  那么其他模块呢？例如大灯、液压转向、刹车。这些组件有一个特点是，控制算法比较简单，很多时候就是一个电压指令，但是产生的效果会影响整车动力学。所以更合理的做法是这部分的ECU就不要了，集成到域控制器里面进行控制。

  [1]讨论的问题其实和EE架构不太相同。其主要关注的点是如何将底盘各actuator集成、联合起来进行控制，而不是电子元件的精简。各个模块更像是软件算法模块，而不是hardware -结合域控制器升级。相较于论文和其他报告中的说法，我倾向于集成域控更有利于组件模块化。因为换个组件不仅仅是接口合适，接上去能用的问题，还得性能调试、测试。

  综上所述，电动汽车的对象应该从底盘集成和综合控制的角度来考虑，从分布式到域集中再到中央集成式。

  ii）操控性能和横向稳定性，即车辆横向动力学，这是大多数现有ICC 论文的核心内容；

  iii）姿态控制，即对由纵向和横向加速度以及道路不规则性引起的车身运动的控制。

  在每个领域内，控制器跟踪相应的状态变量，这些变量可以间接影响其他领域的动态变量。而这一节标题“整车动力学控制”，想要强调的是整车动力学模型对于底盘集成控制的重要性。在横向动力学的研究中，车辆建模和控制器设计已经非常复杂，而关于整车建模的具体构建方法以及通过底盘集成控制来优化整车性能的问题，将成为底盘集成控制的一个重点内容。

  因此，底盘集成控制目前面临的另一个重要问题是，每个子系统的控制法则可能基于不同的模型，这些模型可能是整车模型的一部分。每种算法都在内部计算不同的参考车辆行为，当参考计算的参数和模型不同时，以及各子系统在系统集成中的位置不同时，都会影响协调策略的可靠性。如何整合一些常见的底盘集成控制策略，例如电子稳定控制管理系统和主动悬挂系统，并分析它们对整车动力学的影响？

  将各个子系统控制所需的模型结合起来是底盘集成控制的一个重要方法。例如，转向角根据转向模型和下发轨迹进行控制，车辆横摆力矩控制又需要横向动力学模型。如何综合考虑这些因素，并确保在一定时间内得到控制量的解决方案？在需要时，是否可以使用ANN代替数学模型？

  [3] 国泰君安：从特斯拉看汽车电子电气架构变革2020-7-13，吴晓飞、徐伟东、陈麟瓒

  [4] 国泰君安：从特斯拉看汽车智能化趋势，2022-7，李沐华、齐佳宏

  [5]中国智能网联汽车产业创新联盟：车载智能计算基础平台 SOA 软件架构白皮书，2022年8月

  [6]中国汽车工业协会软件分会：汽车产业-生态创新白皮书，2022年11月 [7]深度解析汽车电子电气架构（上） - 知乎 (zhihu.com)