3. 域控制器架构
在ADAS功能融合与域控制器集成工程中，域控制器是承上启下的核心计算单元。它把原本分散在多个ECU上的感知、融合、规划、控制等功能收敛到一个高性能计算平台上，通过统一的软件框架调度算力、传感器与外设，从而支撑L2+及以上辅助驾驶功能的持续演进。理解域控制器的概念、架构差异以及软硬件组成，是后续功能融合与集成落地的基础。
一、域控制器的核心概念
域控制器（Domain Controller，DC）是指按照功能域划分、集中承担某一类或跨类计算任务的电子控制单元。在ADAS领域，它通常负责多传感器数据接入、时间同步、感知融合、路径规划、车辆控制指令输出以及诊断与安全监控。与传统的分布式ECU相比，域控制器强调集中算力、统一软件平台、标准化接口，其本质是把“多个小脑”整合为“一个大脑+若干执行末端”。
域控制器一般具备以下特征：
- 多核异构算力：CPU、GPU、NPU、DSP、MCU协同，分别承担逻辑控制、图像处理、神经网络推理和实时安全任务。
- 丰富的高速接口：车载以太网、CAN/CAN FD、LIN、LVDS/GMSL、PCIe等，用于连接摄像头、雷达、激光雷达和底盘执行器。
- 功能安全与信息安全：支持ASIL-D等级的安全机制、安全启动、加密通信和OTA升级。
- 软件可迭代：通过中间件、SOA服务和OTA实现功能持续更新，而不必更换硬件。
二、集中式与分布式架构对比
分布式架构是传统汽车电子的主流形态：每个功能由独立ECU实现，ECU之间通过CAN/LIN总线交互。其优点是开发解耦、单点故障影响小、供应商成熟；缺点是算力分散、线束复杂、跨功能融合困难、OTA升级成本高。集中式架构则将多个功能域的计算任务集中到域控制器，甚至进一步演进为中央计算平台，优势是算力利用率高、数据共享方便、软件迭代快，但对安全冗余、散热、功耗和软件复杂度提出更高要求。
| 对比维度 | 分布式架构 | 集中式域控制器架构 |
|---|---|---|
| 计算资源 | 分散在多个ECU，单点算力低 | 集中高性能SoC，算力可动态分配 |
| 数据共享 | 总线传输，带宽受限，时延大 | 共享内存/高速以太网，低时延 |
| 线束与重量 | 线束长、连接器多、重量大 | 线束简化，区域化布线更轻 |
| 功能融合 | 跨ECU融合困难，接口定制多 | 同一平台内融合，接口标准化 |
| OTA升级 | 多ECU分别升级，协调复杂 | 统一升级，版本一致性好 |
| 安全冗余 | 单点故障影响范围小 | 需设计冗余与降级策略 |
| 典型应用 | 传统L1/L2、独立泊车/行车ECU | L2+/L3行泊一体、中央计算 |
从工程实践看，集中式并非完全取代分布式，而是形成“中央域控+区域控制器+执行末端”的分层结构。域控制器负责高算力融合决策，区域控制器负责就近供电、通信和I/O，末端执行器仍保留独立控制能力，从而兼顾性能与安全。
三、典型域控制器硬件平台
当前主流ADAS域控制器硬件平台通常围绕高性能SoC构建，典型方案包括NVIDIA Orin、TI TDA4、地平线征程、Mobileye EyeQ、高通Snapdragon Ride等。硬件平台一般由以下模块组成：
- 主控SoC：提供CPU/GPU/NPU算力，运行感知、融合、规划等算法。
- 安全MCU：负责电源管理、安全监控、车辆控制输出和故障降级，满足ASIL-D。
- 传感器接口：多路GMSL/LVDS摄像头输入、CAN FD、车载以太网、PCIe扩展。
- 存储与内存：LPDDR5、UFS/eMMC，用于模型加载、日志记录和OTA缓存。
- 电源与散热：多路PMIC、液冷或风冷散热，保证高负载下的稳定性。
- 调试与诊断：JTAG、DoIP、UDS、以太网抓包接口，便于开发和售后诊断。
硬件选型时需要重点评估算力（TOPS）、接口数量、功能安全等级、功耗、散热方案和量产成本。例如，行泊一体域控制器通常需要100～250 TOPS算力，支持8～12路摄像头和5～8路雷达，并预留激光雷达接入能力。
四、软件架构与运行流程
域控制器软件架构通常采用分层设计：硬件抽象层、操作系统与中间件层、功能软件层、应用算法层。操作系统可能是QNX、Linux、AUTOSAR Adaptive或实时RTOS组合，通过Hypervisor实现多系统隔离。中间件负责通信、时间同步、服务发现和资源管理，常见方案包括SOME/IP、DDS、ROS 2和自研框架。
应用层：感知融合 / 预测规划 / 控制决策 / 诊断监控
-----------------------------------------------
功能层：AUTOSAR Adaptive / ROS 2 / 自研服务框架
-----------------------------------------------
中间件：SOME/IP、DDS、时间同步、日志、OTA
-----------------------------------------------
OS层：QNX + Linux + RTOS（Hypervisor隔离）
-----------------------------------------------
硬件层：SoC、MCU、传感器接口、电源、散热
典型数据流为：摄像头/雷达/激光雷达原始数据经接口层进入SoC，完成时间同步和预处理；感知模块输出目标列表和占用栅格；融合模块生成统一环境模型；规划控制模块计算轨迹和加减速/转向指令；安全MCU校验后通过CAN FD或以太网发送到底盘执行器。整个过程需要在数十毫秒内闭环，并满足功能安全与信息安全要求。
五、案例与常见误区
以某L2+行泊一体域控制器为例：硬件采用单Orin+安全MCU，接入6路摄像头、5路毫米波雷达和12路超声波；软件采用QNX+Linux双系统，QNX负责安全控制和诊断，Linux负责感知融合与泊车算法；中间件使用SOME/IP和DDS混合通信。项目初期曾出现“算力足够但时延超标”的问题，复盘发现是摄像头数据在多个模块间多次拷贝，且时间同步未统一。优化后采用零拷贝共享内存和PTP时间同步，端到端时延从120 ms降至65 ms。
常见误区包括：
- 只看TOPS不看有效算力：实际可用算力受内存带宽、散热和调度影响。
- 忽视安全冗余：集中式架构一旦主SoC失效，必须有MCU或备用通道接管。
- 软件架构与硬件不匹配：Hypervisor隔离不足会导致实时任务被抢占。
- 接口预留不足：后期增加激光雷达或高像素摄像头时无法接入。
综上，域控制器架构的选择需要结合功能等级、算力需求、安全目标和量产成本综合权衡。集中式架构是ADAS向高阶自动驾驶演进的重要方向，但必须通过合理的软硬件分层、冗余设计和标准化接口，才能在提升集成度的同时守住安全与实时性底线。