2. ADAS系统与数据闭环架构

ADAS 的数据闭环不是“车端采数据、云端存数据”这么简单，它是一条从传感器原始信号出发，经过感知、融合、规划、控制，再通过车端记录、云端回传、工具链复现，最终反哺算法迭代的完整链路。理解这条链路的关键，是先把车端内部的数据流看清楚，再把车端、云端、工具链三者的闭环拓扑串起来。

一、车端内部：从信号到控制的数据流

以 Bosch 典型的 L2 级 ADAS 项目为例，车端数据流大致分为四层。第一层是感知层：前视摄像头输出图像帧与目标列表，毫米波雷达输出距离、速度、角度，超声波雷达输出近距障碍物，部分项目还接入激光雷达点云。这些数据带有各自的时间戳和坐标系，摄像头通常在图像坐标系，雷达在车辆坐标系。第二层是融合层：把不同传感器对同一物理目标的多源观测关联起来，输出统一的目标级融合结果，包括目标 ID、位置、速度、加速度、类别和置信度。第三层是规划层：基于融合后的环境模型和自车状态，生成横向与纵向的期望轨迹或期望加速度。第四层是控制层：把规划输出转换为转向扭矩、驱动扭矩或制动压力，通过 CAN 或以太网发给执行器。

这里有一个容易被忽略的细节：时间同步。摄像头、雷达、CAN 信号如果不在同一时间基准上，融合出来的目标位置会出现“鬼影”或抖动。Bosch 项目中通常用 PTP 或 gPTP 做传感器时间同步，并在融合模块里做时间对齐和运动补偿。例如，雷达目标时间戳比摄像头晚 20 ms，就需要按自车速度把雷达目标位置外推到同一时刻再关联。

二、车端、云端、工具链的闭环拓扑

车端负责“产生数据”和“执行控制”，云端负责“汇聚数据”和“训练评测”，工具链负责“复现问题”和“验证修复”。三者构成一个闭环：车端触发事件后把数据回传云端，云端清洗、打标签、入场景库，再把场景包下发给工具链；工具链在 SIL/HIL 或数据回灌环境中复现问题，定位到具体模块后修复，修复后的模型或参数再刷回车端。

这个闭环里，触发策略决定了数据回传的效率。如果全量回传，带宽和存储成本极高；如果只回传碰撞或急刹事件，又会漏掉“差点发生”的边界场景。Bosch 项目中常见的做法是分层触发：A 类事件（碰撞、AEB 触发、驾驶员接管）全量回传；B 类事件（TTC 低于阈值、车道偏离、目标丢失）回传关键片段，比如事件前后各 10 秒；C 类事件（常规行驶）只回传统计特征或低采样率摘要。这样既控制成本，又保留复现所需的最小数据集。

三、Bosch 典型 ADAS 项目数据链路解析

以一个前向 AEB 功能为例，完整链路可以拆成以下环节。车端前视摄像头以 30 fps 输出图像和目标列表，雷达以 20 Hz 输出目标距离和速度。融合模块把两者关联后，输出前方目标列表，规划模块计算 TTC，控制模块在 TTC 低于 1.5 s 时请求制动。如果实际发生了 AEB 触发，车端记录模块会把触发前 10 s 到触发后 5 s 的原始图像、雷达目标、CAN 报文和融合结果打包，通过 5G 回传云端。

云端收到数据包后，先做脱敏和切片，再按“AEB 触发”标签入场景库。工具链从场景库拉取该场景包，在 HIL 台架上回灌传感器数据，复现融合模块的目标关联结果。假设复现发现：在雨天场景下，摄像头目标置信度从 0.9 降到 0.4，融合模块因为置信度低于阈值而丢弃了该目标，导致 AEB 未触发。定位到问题后，调整融合模块的置信度门限或增加雷达主导的关联策略，重新训练或重新标定，再通过 OTA 刷回车端。车端在同样场景下再次触发并回传数据，形成第二轮闭环。

四、数据链路中的常见断点与排查方向

实际项目中，闭环最容易断在三个位置。第一是时间戳不一致：车端记录用 UTC，云端入库用本地时间，工具链回放用相对时间，三者没有统一基准，导致复现时目标对不上。排查方法是检查各环节的时间戳字段和同步协议，确保从传感器到云端全程使用同一时间源。第二是坐标系转换错误：摄像头图像坐标、雷达车辆坐标、融合世界坐标之间的转换矩阵如果标定不准，目标位置会偏移。排查时可以用已知位置的标定靶验证转换链路。第三是数据切片边界丢失：只回传事件片段，但片段起点之前的状态没有记录，导致复现时初始条件不完整。解决办法是在触发点之前多保留一段“预热”数据，通常不少于 5 s。