对着智能汽车趋向于网联化、智能化、电动化、共享化的发展。最终的智能汽车产品趋向于行车-泊车-底盘-座舱-动力一体化的方案，而阶段性的产品是适应用户需求的快速升级，车企需要开发智能、安全、可灵活扩展、成本可控的E/E架构平台，以满足汽车不断升级的需求。

智能汽车E/E架构发展趋势如下：

1）ECU从分布式走向集中式；

即从原来的30-150个ECU，各ECU负责功能独立的系统，且复杂度高、成本高，逐步过渡到多个ECU整合成域控制器，降低成本、重量和功耗，利用硬件和软件创新实现面向服务的架构（SOA），可直接访问内存，并行计算载体提供冗余和安全性，面向OEM系统集成的可扩展开放平台的方向发展，最终实现面向服务的架构（SOA），面向网络访问，移动配置和无缝冗余。

目前，量产车型主流为分布式架构，主流OEM在研车型基本采用域控制器架构，基于中央计算平台或与融合式架构平台正处于规划阶段，对于已量产的车型从分布式演变到域控制器式，中央控制架构是下一代自动驾驶系统的趋势。

2）ECU软硬件体系结构趋向于标准化；

整个ECU软硬件体系结构从横纵向两边分别涉及软硬件组件、需求、功能，其中软硬件组件涉及底层芯片、传感器、操作系统、中间件、服务应用。需求层包含互联性、可用性、低延迟、冗余控制、集成策略。功能包含信息/娱乐、AI感知、安全、车身/舒适、动力几个方面。

3）进一步扩展中间软件层；

当前，每个ECU的中间件负责ECU的内部通讯，每个功能软件都是静态被创建在ECU中，更新一个功能需要对整个ECU软件进行重新编译和更新，没有明确地方法论去降低整个系统的复杂性。未来，中间件具备跨越域访问Domain ECU的能力。通过故障识别和故障冗余机制可实现功能安全，当车辆启动时可以通过标准化接口运行增加功能。通过资源透明化，可实现配置优化。

4）车内传感器数量将持续增加，且传感器将变得更加智能；

此外，下一代自动驾驶将设置双电源及网络冗余，加强以太网技术应用，OEM也会严控数据接口，云计算等应用也将越来越重要，OTA升级策略也将成为车辆基础技术。

从软件功能开发的角度上讲，下一代域控制器架构是实现阶段性的智能驾驶行车-泊车一体化控制策略。本文将对其进行详细的讲解和分析。

智能行车-泊车一体化全域解决方案

满足L2/L3高等级的驾驶辅助功能（智能行车-泊车）需求将集中到一个ECU对行车-泊车等基准控制功能进行有效处理。并且该集中式方案在网络安全，冗余备份等方面更具优势，在技术上也更具有挑战性。智能行车-泊车全域解决方案设计的思想主要集中在以集中式域控做为总体感知处理端口，以不同的SOC对其中的行车和泊车模块进行轨迹规划、决策，且过程中综合考虑驾驶员输入的行车/泊车控制指令，最终参照一定仲裁的策略对其行车和泊车进行执、控制。

对于智能汽车而言，下一代产品倾向于从智能行车、智慧泊车向行-泊一体化方向演进。何为行泊一体化呢？即主要面向于解决如下多个主要的开发性问题：

1）集中中央控制器

这里的中央控制单元集成行车、泊车整体控制功能，集成度更高，软件处理能力更强大，包含行车及泊车的整体感知、规划控制、决策执行的能力。且两者分布于中央控制器中的不同控制模块，可有效地降低中央控制器数量。更强大的控制器整合平台，集成行车和泊车的多个软件功能模块。

在行泊一体控制系统中，考虑到执行单元基本都是相同的控制单元，比如纵向控制均是ESP控制加减速，EPS控制转向，EMS/HCU都用于控制车辆的加速，BCM用于控制车辆的灯光、车门、车窗等控制，IP及IHU负责整个人机交互显示等。因此在特殊工况下，可能存在行车和泊车同时激活并进行执行单元控制的情况。如低速前行时可能是泊车系统控制加减速，也可能是行车系统控制的加减速，而对于控制器或执行器而言需要对这些加减速进行仲裁。假如从执行端口出发，其接收上层控制单元输出的控制指令都是一个命令输出口，那么其顶层仲裁机制就需要在行泊一体中央控制器中进行。

相应的感知控制应用处理框图如下。

2）增强型网关

由于智能行车和泊车的整个功能集中化，在传感控制等通信链路上都需要增强网关对于各个数据的转发能力，这种转发能力包括数据的数量和种类上的不同。如同时需要转发包含以太网、CANFD甚至Lin信号。这可以通过新建路由机制，可增加路由复杂度和通信吞吐量。

3）通信网络升级

行车泊车一体控制过程要求其通信带宽满足其庞大的数据量要求，这里特指通信网络能够适配更多的包含图像、激光点云、毫米波点云等原始信息。因此，需要整个智能行车-泊车需要更高带宽，更加灵活的通信机制。

4）冗余设计

从提高系统可靠性的角度出发，在整个智能化行泊一体系统设计中，不管是行车还是泊车，均需要带有一定的冗余网络结构及供电系统。以便在主控单元出现问题时，可以由冗余单元接替进行综合控制。

由于泊车处于低速控制状态，且往往在各种工况下容易处于倒挡状态，因此，冗余对于泊车而言不进行前向安全停车的需求，更多的也是包含后向紧急刹停的过程。当然如果仅仅是比较简单的控制减速停车的方法是采用固定的减速度控制刹停。如果仅仅考虑执行单元的冗余也只需要考虑如功能仲裁机制中的执行命令仲裁方式，然而这里并没有那么简单。考虑如智能行车主要考虑前向控制的传感冗余，泊车系统也需要同时考虑在其主要感知传感器失效后如何进行后向传感冗余设计，确保后向紧急刹停过程中实时调整刹车方位角与减速度。

5）功能仲裁机制

这里我们需要重点说明一下行车泊车一体化域控制器控制过程中如何进行感知输入处理及命令仲裁。对于行泊一体化域控单元，需要在内部分别进行行车感知处理与泊车感知处理。感知的结果在控制单元中首先进行感知融合，再分别生成行车规划控制轨迹及泊车规划控制轨迹，在其控制单元中的人机交互端口可以接受驾驶员的操作指令，如一键泊车指令输入后可对行车规控和泊车规控中的执行指令进行有效的仲裁。比如对于低速智能行车和泊车在规控后生成的同一个转向指令输入至转向执行端EPS中时，需要对该指令打上标签；两者指令的结合可以有效的指导执行器参照不同的响应方式进行车辆控制，而这个打标签的过程也是仲裁的一部分。

在整个控制过程中，主要涉及行车及泊车的状态机如何被仲裁后从待机向激活的整个跳转过程。

6）面向服务的软件架构

对于行车-泊车的一体化控制而言，其设计为面向服务的软件架构显得尤为必要。因为对于驾驶员来说，其并不关心其驾驶过程中如何实现，而是只是以结果为导向，关心其实现结果是否能够满足其设置的目的性要求。何为目的性要求？也就是驾驶员对整车的输入不再是我需要行车还是泊车，而是我需要到达某个地方，要求本车自动设置导航，自动驾驶到目的地，到达目的地后自动控制车辆找到车位并停车。这一过程中涉及的主要职能车辆控制技术就包括了智能驾驶和智能泊车两项。

7）基本显示单元

SOA架构的本质是将原本相互分散的行车-泊车ECU甚至后续会考虑集成智能座舱域ECU，将其对应的基础软件功能模块化、标准化，将各个应用区域相互解耦，重新部署为分层式的软件架构，汽车可在不增加或更换硬件的条件下通过不同的软件配置为驾驶员提供不同的服务，从而实现千人千面。

这里的智能行车-泊车一体化控制单元是实现了SOA的第一阶段的集中式域控设计，需要充分考虑行车与泊车显示单元所需求的一切显示与交互能力。结合智能座舱的交互机理，在人机交互层面上仍然需要仲裁行车与泊车输出的显示报警信号。同时对于座舱域输入的交互信息需要从功能的不同角度分别进行考虑行车和泊车的激活状态，比如座舱域给定的驾驶员状态监测结果显示为疲劳或分心，那么智能行车单元一般的策略是将无法持续控制车辆，发出报警显示甚至直接降级退出。又如，对于泊车控制而言，其整个泊车过程中，如果驾驶员仍然处于驾驶位上，那么肯定需要实时监控其停车的状态，随时准备微调泊车过程或直接接管。如果驾驶员在车外远程操控自动泊车，那么也仍然需要通过手机实时监控车辆的泊车的完成状态。

8）车辆互联

车辆互联实现车辆信息共享与实时信息交互。安全防护，增加威胁检测，威胁自修复等防护手段。

总结

随着汽车科技的进步，围绕“四化”的需求越来越多，智能汽车电子架构将发生变革。集中化域的电子电气架构将成为主流解决方案。未来智能汽车是基于功能域控制器的集中化架构趋势，同时诸如智能行车、泊车的区域控制器将逐渐过渡为局部中央计算单元，基于环形主干网和多域计算架构的方案都将逐渐演进到可实施的方案中。