4. 感知系统电子电气架构

感知系统的装车集成，本质上不是把摄像头、毫米波雷达、激光雷达简单“接上线”，而是围绕域控制器构建一套可供电、可通信、可同步、可采集、可诊断的电子电气架构。架构设计是否合理，直接决定后续标定效率、数据质量与功能安全边界。本节从域控制器、传感器接口、通信协议、时间同步和数据采集五个维度展开。

一、核心原理：以域控制器为中心的感知架构

在传统分布式架构中，每个传感器各自输出结果，由多个 ECU 分别处理，线束复杂、算力分散、时间基准不统一。进入 ADAS 域控阶段后，感知系统通常采用“传感器 → 接口层 → 域控制器 → 融合/决策”的集中式架构。域控制器承担多路图像、点云、雷达目标与车辆信号的接入、预处理、时间对齐和融合计算。

典型感知域控内部可划分为：传感器接口模块、数据预处理模块、时间同步模块、融合计算模块、诊断与安全监控模块。外部则通过不同物理介质连接摄像头、雷达、激光雷达、组合惯导和整车网络。架构设计的核心矛盾是：带宽、实时性、同步精度、成本与可维护性之间的平衡。

二、传感器接口与通信协议选型

不同传感器对接口的需求差异很大。摄像头原始图像数据率高，通常采用LVDS类串行链路（GMSL、FPD-Link、MIPI CSI-2 over LVDS），通过同轴或屏蔽双绞线传输，具备抗干扰和长距离优势。毫米波雷达输出目标级或点云级数据，带宽需求中等，常用CAN FD或100BASE-T1以太网。激光雷达点云数据量大，普遍采用1000BASE-T1车载以太网。整车信号如车速、方向盘转角、挡位等，仍以CAN/CAN FD为主。

三、时间同步：多传感器融合的隐形地基

如果摄像头、雷达、激光雷达各自使用本地时钟，融合时就会出现“同一目标在不同传感器中处于不同时刻”的问题，导致鬼影、漏检或跟踪抖动。因此，域控架构必须建立统一时基。常见做法是：以 GNSS 的 PPS 秒脉冲和 UTC 时间为基准，域控制器作为 gPTP（IEEE 802.1AS）主时钟，通过车载以太网向交换机、雷达、激光雷达分发时间；摄像头则通过曝光触发信号或串行链路同步信号对齐帧起始。

工程上要重点关注：同步精度（通常要求微秒级）、链路延迟补偿、交换机透明时钟、传感器内部时间戳的生成位置。若时间戳在传感器内部生成，需确认其时钟是否已同步；若在域控接收端生成，则需补偿传输与解串延迟。

四、数据采集基础与典型误区

数据采集是标定、算法迭代和问题复盘的输入。采集系统通常需要同步记录：多路视频、点云、雷达目标、CAN/CAN FD 报文、GNSS/IMU 组合导航数据以及域控内部融合结果。采集链路应尽量靠近传感器原始输出，避免只记录“融合后结果”而丢失原始证据。

# 典型采集配置片段（示意）
record:
  cameras: [front_120, front_30, left, right, rear]
  lidar: [top_128]
  radar: [front, corner_fl, corner_fr, corner_rl, corner_rr]
  can: [chassis, adas_private]
  gnss_imu: enabled
  sync: gPTP + PPS
  timestamp_source: sensor_internal
  storage: NVMe RAID0
  duration: 3600s

常见误区包括：只关注带宽而忽略存储写入稳定性；只记录融合结果不记录原始数据；时间同步未验证就开展标定；CAN FD 与 CAN 混用导致网关丢帧；以太网 VLAN 与 QoS 未规划导致大流量挤占控制报文。复盘时应从“数据是否可复现、时间是否可对齐、链路是否可诊断”三个角度检查。

五、架构落地检查清单

• 域控接口数量、类型与传感器清单是否一一匹配，是否预留扩展位。
• CAN/CAN FD 报文矩阵、周期、超时与信号有效性是否定义完整。
• 以太网 IP、VLAN、QoS、组播与交换机端口规划是否明确。
• gPTP 主从关系、PPS 路由、触发信号极性是否确认。
• 采集系统存储带宽、掉电保护、时间戳来源是否验证。
• 诊断故障码、降级策略与安全监控是否覆盖感知链路。

综上，感知系统电子电气架构不是单一协议的选择题，而是域控、接口、协议、同步与采集五者协同的系统工程。只有把时间同步和数据采集作为一等公民纳入架构设计，后续的标定与算法迭代才有可靠基础。