1. 课程导入与ADAS感知系统全景

在整车智能化演进中，ADAS（Advanced Driver Assistance System，高级驾驶辅助系统）已经从“选装亮点”变成“平台能力”。Continental（大陆）作为全球主流Tier 1，其ADAS产品线覆盖从毫米波雷达、摄像头、激光雷达（部分场景）到域控制器与感知融合软件。理解这套体系，关键不是记住型号，而是看清感知系统在整车电子电气架构中的位置，以及从需求到量产集成的完整链路。

一、Continental ADAS产品线的三条主线

Continental的ADAS产品可以按“传感器—域控—软件与算法”三条主线来理解。传感器侧，前向毫米波雷达（如ARS系列）负责远距测距测速，角雷达（如SRR系列）覆盖盲区与变道辅助，摄像头模组（如MFC系列）承担车道线、交通标志与目标分类，环视与超声波则服务于泊车场景。域控侧，ADCU（ADAS Domain Control Unit）作为计算与融合中心，承接多传感器输入并输出驾驶决策。软件侧，Continental提供感知融合、功能安全与OTA升级框架，支持从L2到L2+的功能扩展。

这三条主线并非孤立：传感器提供原始或目标级数据，域控完成时间同步、坐标统一与目标关联，软件层再输出给整车执行器。理解产品线时，应始终带着“数据从哪来、在哪融合、往哪去”的问题。

二、感知系统在整车EEA中的位置

在整车电子电气架构（EEA）中，感知系统处于“环境输入—中央计算—执行输出”的中间层。以典型的域集中式架构为例：前视摄像头与毫米波雷达通过CAN FD或车载以太网接入ADAS域控制器；域控制器与整车中央网关交换车辆状态（车速、横摆角速度、转向角）；最终通过底盘域或动力域执行加减速与转向请求。

这里有一个容易被忽视的要点：感知系统并不直接“控制车”，它输出的是目标列表、车道线方程、可行驶区域等环境模型，决策与执行由下游模块完成。因此，集成时必须明确接口边界——感知输出什么坐标系、什么时间戳、什么置信度，下游才能正确使用。

三、从需求到量产的开发流程

Continental的ADAS开发通常遵循V模型，但真正决定集成成败的是“左端需求”与“右端验证”的对应关系。左端从整车功能需求出发，分解为感知性能指标：例如前向目标检测距离≥150m、测距精度±0.5m、车道线检测横向误差≤10cm。这些指标再分配到摄像头与雷达的选型与布置方案。

右端验证则分为台架、封闭场地与实车道路三层。台架阶段用回放注入的方式验证感知算法对已知场景的响应；封闭场地用标准目标物（如Euro NCAP气球车、车道线标定板）验证检测距离与误报率；实车阶段则关注长尾场景与系统稳定性。每一层验证都要有明确的通过判据，而不是“看起来没问题”。

四、集成挑战：感知系统落地的四个硬骨头

第一是时间同步。摄像头曝光时刻、雷达 chirp 周期与域控处理延迟不同，若时间戳对齐误差超过10ms，高速场景下目标位置就会产生米级偏差。工程上通常用PTP（精确时间协议）或硬件触发同步，并在融合前做时间补偿。

第二是坐标系统一。摄像头坐标系、雷达坐标系与车辆坐标系之间的外参标定误差，会直接放大为横向定位误差。量产下线标定与在线动态校准必须配合使用。

第三是功能安全与降级策略。感知模块失效时，系统不能直接退出，而应按ASIL等级进入降级模式：例如摄像头失效后，仅靠雷达维持AEB基础功能，同时通过HMI提示驾驶员接管。

第四是数据闭环与OTA。量产车采集的corner case需要回传、标注、训练并重新部署，这要求感知系统在设计初期就预留影子模式与数据触发机制。

五、一个可操作的集成检查清单

在项目启动阶段，可以用以下清单快速对齐团队认知。它不替代详细设计，但能暴露早期风险：