辅助驾驶域控架构典型功能域及SOA设计 | 盖世大学堂辅助驾驶域控系列知识讲解

随着电子电气架构从分布式向集中式演进，底盘系统的智能化转型已成为汽车技术革新的战略高地。本篇推文深度解析预控架构下底盘域控制器的功能整合路径、SOA服务化设计的工程实践陷阱，以及辅助驾驶技术对底盘实时响应能力的严苛需求。通过拆解华为VDC、特斯拉Autopilot等典型方案的核心逻辑，揭示域控架构演进中的关键技术决策矩阵。

一、域控架构设计概述

域控架构设计的核心在于对车辆功能进行域级划分与整合，主要包含多个典型功能域及 SOA（面向服务的架构）两部分。理解这两者的逻辑，即可清晰把握当前域控架构的整体框架。各功能域及 SOA 的内部设计虽较为复杂，但通过系统拆解可明确其核心逻辑。

二、典型功能域解析

（一）底盘域控制器（VMC-Vehicle Motion Controll）

底盘域控制器的核心功能是在手动驾驶、辅助驾驶及辅助驾驶三种场景下，整合空气弹簧、悬挂阻尼、前后轮转向、转向柱位置控制等底盘功能，实现车辆横纵向及垂向控制功能的有效协同。

从域融合潜力来看，ESP（电子稳定程序）、悬架、四轮驱动等系统在横摆和侧倾控制方面存在较多功能重合，但其传统交互方式难以提升性能，因此需要一个上层控制器进行统筹。采埃孚的 cubiX 软件组件便是典型案例，它通过收集整车传感器信息，为底盘、转向、制动和传动系统中主动系统的优化控制提供支持，且不依赖特定供应商，实现了底盘控制功能的集成与互联。

该控制器对认知负载的要求较高，需具备在横纵向控制中平衡车辆舒适性与稳定性的专业且全面的能力。在集中式架构下，底盘域控制器通常属于区域控制器级别，与辅助驾驶系统关联紧密，设计时需特别关注实时控制性能，因为域控架构在实时性方面往往存在一定局限。此外，为优化人机共驾体验，部分辅助驾驶控制的业务逻辑也可剥离至底盘域控制器中实现。

（二）车身域控制器

车身域控制器源于传统的 BCM（车身控制模块），主要对灯光、解锁系统、无钥匙进入 / 启动（PEPS）、后视镜、门窗、座椅等品类繁杂但复杂性较低的 I/O 设备进行集中化管理。

其资源配置丰富，输入检测涵盖高有效输入（10 + 路）、低有效输入（20 + 路）、模拟量输入（10 + 路）及预留低有效输入（数量依 MCU 资源确定），对应控制近光灯、远光灯、座椅调节、雨刮模式等多种功能；输出驱动包括高边驱动（20 + 路）、半桥驱动（8 + 路）、全桥驱动（5 + 路）及预留低边驱动；网络通讯则支持 LIN（3 + 路）、以太网（1 路，100BASE-T）及无线通讯（RF 接收）。其中，以太网用于对外提供服务，LIN/CAN 用于设备接入，核心是作为 SOA 网关存在。

车身域控制器在集中化架构下多承担区域控制职责，因其控制的设备分布较散，连接线路较长。其域融合潜力在于通过 SOA 对各类交互过程进行标准化；认知负载与原 BCM 类似，但新增了 SOA 服务化部分的内容，目前高端应用仍在探索中。将复杂 I/O 及硬件资源整合并以 SOA 形式封装，虽 SOA 在实时稳定性上不及 CAN 总线，但针对车身控制场景，其优势仍大于劣势，因此车身域控制器是发展较早且作用显著的一类控制器。

（三）中央域控制器

中央域控制器的核心功能是支持各域控制器的信息转发，同时承担 FOTA（整车在线升级）、网络安全、时间同步、远程诊断、用户自定义整车服务等功能，还可兼容其他域控制器的部分功能。

作为集中架构的 “原型”，其域融合潜力在于逐步整合当前各域控制器的功能，向集中化架构过渡，理论上各类控制器均可承担其职责。认知负载方面，开发团队需具备与原 Gateway（网关）类似的知识范围，且需覆盖和支持整个 EE 架构的开发；在中央计算架构下，中央网关会退化为多个区域网关。

不过，中央域控制器的定位存在一定模糊性，其功能多由原 CAN 网关升级而来，受组织架构影响较大，易出现功能被其他控制器承接的情况。通常，它会作为时间同步、OTA、网络安全等功能的主节点，承接不在辅助驾驶或智舱域内的用户相关动态业务软件。从长远来看，其职责可能向区域控制器转化，因为将原有职责集中在单一芯片或硬件上，对线路布置未必有利，分散化设计可能更优。

（四）动力域控制器（类似华为 VDC）

动力域控制器集成了整车控制器、电池管理系统（BMS）、热管理系统（TMS）等功能模块，部分情况下可作为智能驾驶的备用控制器。

从功能安全角度，其作为备用控制器的设计符合 “同一架构中不同控制器冗余” 的逻辑 —— 若所有功能集中于单一控制器，功能安全难以拆解，而动力域控制器可承担降级模块的角色。例如，当辅助驾驶主控制器（HPC）负责 NOA 等高阶功能时，动力域控制器可作为同质功能的备份，与主控制器形成互为备份的关系，提升安全等级。

该控制器主要涉及 “三电”（电机、电池、电控）业务，目前因线控制动、线控转向技术成熟度有限，与这些系统的集成较少，主要以三电业务为主，部分情况下会与整车其他控制器整合，具体需根据实际部门规划确定。其域融合潜力在于提升加速性能、能源利用效率及热管理效率；认知负载主要由原 “三电” 架构团队承担。

（五）辅助驾驶域控制器（类似华为 MDC）

辅助驾驶域控制器是辅助驾驶功能开发的核心，需连接相机、雷达等大部分专用传感器，并与底盘、动力相关控制器并联关键执行器（如线控制动）。其天然具备域控属性，因车辆上大部分高成本、高稳定性要求的传感器均与辅助驾驶系统相关，且辅助驾驶业务较新，历史包袱少，通常作为独立的成本中心和控制器存在（如华为 MDC）。域融合潜力体现在可集中资源支撑高阶辅助驾驶、辅助驾驶功能的开发；认知负载要求较高，一般需独立的 “辅助驾驶中心” 负责开发，团队需具备感知、决策、规划、控制等全流程技术能力。

（六）智舱域控制器（类 CDC）

智舱域控制器与辅助驾驶域控制器逻辑类似，因内部交互复杂度高，需单独作为一个控制器存在，主要负责车内交互应用及与用户体验相关的功能。

随着电子后视镜、多屏交互（前后排屏、座椅屏）、语音交互等功能的增加，智舱的 I/O 交互需求大幅提升，推动其向域控级别发展。当前智舱控制器对算力要求极高，从早期的 8155 芯片升级至 8295 芯片，部分海外车企已采用 8650 芯片，甚至多芯片组合方案。

其硬件构成与辅助驾驶域控制器类似，均需处理多类型接口（如 FM、语音、相机等），因此存在整合为 “舱驾一体” 芯片的可能。域融合潜力主要在于与辅助驾驶控制器整合，实现算力与传感器资源的综合利用；认知负载覆盖车内交互应用全领域，需聚焦用户体验优化。

（七）网联域控制器（T-BOX 升级）

网联域控制器由传统 T-BOX 升级而来，是 EE 架构的授时来源，具有较高的 EMC（电磁兼容性）设计要求，集成了 V2X、GPS 等通信芯片，核心功能是作为车辆与外部（云端、路侧、其他车辆）信息交互的中继节点。其新增的核心功能是 V2X，该功能与辅助驾驶系统关联紧密，可解决感知盲区问题（如前车遮挡导致的后车感知缺失）。同时，它作为 GPS 信号接收单元和时间同步的全局主节点，将时间信息传递给其他域控制器。因集成多种通信芯片，其对 EMC 设计要求严格，PCB 设计与其他控制器存在差异。

考虑到不同地区的通讯制式差异，网联域控制器与其他域控制器整合并非最优设计，独立设置更为合理。其域融合潜力在于对 V2X（C-V2X）、GPS、WIFI 等车联网通信机制的服务化整合；认知负载主要由原 Tbox 团队承担，业务围绕通信扩展。

三、SOA 设计解析

（一）SOA 的核心定义

SOA（面向服务的架构）并非具体技术，而是一种架构策略层面的指导思想或范式，旨在实现对不同所有权范围内信息的组织与利用，是一种软件架构设计的模型和方法论。它通过整合现有软件体系，构建可随业务变化灵活组合现有服务的新软件架构。

与基于信号的 CAN 通信不同，SOA 基于服务的通信（以太网）采用服务订阅机制：各节点既可作为服务提供方，也可作为服务消费方，通过订阅其他控制器的功能，发送请求后由服务端返回所需逻辑，本质上类似跨控制器的函数调用。

（二）SOA 的定位与价值

SOA 是分布式架构向集中式架构过渡的过渡手段。在分布式架构下，无法直接在单一控制区内调用所有函数，而 SOA 通过模拟跨控制器函数调用，实现了不同控制器间的协同。

其核心价值在于提升灵活性，尤其是支持 OTA 升级后对功能的修改。传统 CAN 总线的信号矩阵一旦确定（如在 G5、G6 阶段），难以调整，需多个部门协同讨论；而 SOA 允许在架构部门牵头下，通过点对点方式解决部分功能块间的交互问题，且支持 OTA 调整，大幅降低了后期优化的难度。

（三）CAN 与 SOA 的对比

两者均强调模块化和标准化，但维度不同：CAN 聚焦模块独立逻辑功能的实现，通过模块组合提供复杂逻辑功能，实现低成本功能重构；SOA 则聚焦模块独立业务功能的实现，通过模块组合提供不同应用，实现低成本业务重构。从技术层面看，CAN 传输的是信号，属于面向方法的过程；SOA 传输的是服务调用，属于面向对象的业务逻辑，是方法级别的调用，灵活性远高于 CAN。

（四）SOA 的业务范围与优势

SOA 的应用涵盖三个层面：EE 架构级 SOA（汽车业最熟悉）、控制器内部 SOA、云端系统 SOA。在研发阶段，SOA 可通过服务复用缩短开发周期，调整影响面小（点对点调整为主），代码编写效率高；在售出阶段，支持 OTA 实现服务动态更新，满足 “千人千面” 的用户需求（如通过订阅地图、座椅、方向盘等原子服务，组合成用户习惯服务）。

（五）SOA 的优缺点

优点：以业务为中心，能更快提供业务价值，具备快速应变能力和服务复用性；为业务应用提供灵活性，可快速创建新业务流程，降低对底层架构的依赖，缩短开发部署周期，降低模块交互复杂性和维护成本；对架构而言，服务接口与底层编程接口、通信模型无关，具有松耦合性、位置透明性和协议无关性。

缺点：对服务治理要求高，接口描述复杂；存在额外资源消耗，占用应用层 CPU，可能影响系统性能（如多控制器订阅高带宽业务时易导致负载超限）；服务粒度划分影响系统复杂度，需平衡灵活度与复杂度；对从业人员要求高，需兼顾软件层面的业务与负载等多方面考量。

（六）SOA 的技术实现与实践

工程实现中，SOA 常依托 SOME/IP、DDS 或第三方通讯库，实现灵活且技术难度可控。SOME/IP 是汽车嵌入式专用的客户端 / 服务端通信机制，位于 OSI 七层模型的 5-7 层，适用于 AUTOSAR、Linux 等系统；DDS 则更适合控制器内部的板间或核间通讯。

SOA 的实践可采用 SORS（Service-Oriented Reuse-shared Design）方法论，包括自下而上（从末端硬件向中心梳理，抽象硬件功能为服务）和自上而下（从既有功能 / 业务流程入手，拆分算法为服务）两种思路。服务接口设计建议采用粗粒度，以业务场景为单位划分，将服务接口、模型、异常等纳入 API 包管理，平衡交互效率与系统可配置性。

当前域控架构以底盘、车身、中央、动力、辅助驾驶、智舱、网联七大典型功能域为核心，通过 SOA 实现域间协同。功能域的划分基于业务属性与技术特性，SOA 则作为过渡阶段的关键架构思想，解决了分布式向集中式架构演进中的灵活性与协同性问题。尽管域控架构仍存在分布式逻辑的遗留问题，但结合 SOA 的服务化设计，为后续集中化架构的发展奠定了基础，同时也需在实践中不断优化功能域划分与 SOA 服务治理，以适应智能汽车技术的快速迭代。