1. 课程导入
在正式进入功能链与系统集成工程之前，我们需要先建立一套共同的“语言坐标系”。智能驾驶行业最常见的沟通障碍，不是技术难度，而是同一个词在不同团队口中含义不同：算法团队说的“L2+”可能指高速领航，产品团队说的“L2+”可能指城市记忆行车，而测试团队关心的却是接管率与最小风险状态。本章的目标，是把这些概念对齐到可工程化的定义上。
一、从SAE分级看L2、L2+与L3的边界
目前行业普遍采用SAE J3016的六级划分（L0–L5），其核心判据不是“车能做什么”，而是动态驾驶任务（DDT）由谁执行、谁负责监控、谁在失效时兜底。L2的关键特征是：系统同时控制横向与纵向运动，但驾驶员必须持续监控环境并随时接管；L3则在限定运行设计域（ODD）内，由系统完成DDT并承担监控责任，驾驶员可在系统请求时接管。
所谓“L2+”，并非SAE的正式等级，而是产业界对能力显著超出基础L2、但责任主体仍为驾驶员的一类功能的统称。它通常具备导航辅助驾驶、自动变道、匝道通行等能力，但驾驶员仍需保持注意力。理解这一点，是后续所有功能链设计的前提。
二、L2+的典型功能场景
L2+的落地场景高度依赖ODD设计。当前量产车型主要集中在三类场景：
- 高速/城市快速路领航：基于导航路径完成跟车、车道保持、自动变道、匝道进出，是L2+最成熟的场景。
- 城市记忆行车：用户示教一条固定路线后，车辆在该路线上实现点到点辅助驾驶，常见于通勤场景。
- 泊车辅助：记忆泊车、遥控泊车等，虽速度低，但同样涉及感知、规划、控制全链路。
这些场景的共同工程特征是：功能链长、耦合点多、失效模式复杂。一个自动变道动作，背后要串联感知、预测、决策、规划、控制、人机交互六大模块，任何一环的时序或接口偏差都会导致体验降级甚至安全风险。
三、课程知识框架与学习目标
本课程围绕“功能链”与“系统集成”两条主线展开。功能链回答“一个功能从传感器到执行器如何逐级实现”，系统集成回答“多个功能如何共享资源、协同调度、统一验证”。整体知识框架如下表所示：
| 模块 | 核心问题 | 关键交付物 |
|---|---|---|
| 感知与融合 | 环境如何被准确建模？ | 目标列表、占用栅格、定位输出 |
| 预测与决策 | 他车意图与自车行为如何选择？ | 轨迹预测、行为决策状态机 |
| 规划与控制 | 轨迹如何生成并稳定跟踪？ | 参考线、轨迹、横纵向控制量 |
| 系统集成 | 多模块如何协同与降级？ | 接口定义、调度策略、降级矩阵 |
| 测试与验证 | 如何证明功能安全可靠？ | 场景库、覆盖率报告、接管分析 |
学习目标：完成本课程后，你应能够——① 用统一术语描述L2+功能边界；② 画出典型功能链的数据流与时序关系；③ 识别系统集成中的接口风险与降级策略；④ 设计覆盖关键场景的测试验证方案。
四、常见误区与复盘
误区一：把“L2+”当作L3宣传。部分营销话术模糊了责任主体，导致用户误以为可以脱手脱眼。工程上必须明确：L2+的驾驶员监控与接管请求机制不可省略。
误区二：只关注算法指标，忽视系统集成。很多项目在单模块测试中表现优异，但实车出现时序抖动、资源抢占、降级混乱。功能链的端到端时延与接口契约，往往比单点精度更决定体验。
误区三：ODD定义过宽。把“高速+城区+泊车”全部纳入同一版本，会导致降级策略复杂、测试矩阵爆炸。建议按场景分版本迭代，逐步扩展ODD。
下面用一段伪代码说明功能链中“变道请求”从感知到执行的典型触发条件，帮助建立工程直觉：
if (本车道前方存在慢车 && 相邻车道后方无快速接近目标) {
预测相邻车道目标轨迹;
if (预测冲突时间 TTC > 安全阈值 && 车道线为虚线) {
发起变道决策;
规划横向轨迹;
请求横向控制执行;
同步HMI提示驾驶员监控;
} else {
保持车道，降级为跟车;
}
} else {
保持车道;
}