1. 项目全景与系统架构：车道保持系统（LKA）的功能定义、行业标准（ISO 11270）、系统架构概览（感知-决策-控制）、开发流程（V模型）与量产交付物

1.1 车道保持系统到底在干什么？

说实话，很多人一听到LKA，就觉得「不就是让车自己沿着车道跑嘛」。嗯，这话对了一半。

LKA的全称是Lane Keeping Assist，中文叫车道保持辅助。它的核心任务就一句话：当车辆无意中偏离车道时，系统主动施加转向力矩，把车拉回来。

注意我强调了「无意中」。如果你打了转向灯，系统知道你是有意变道，它就不会跟你抢方向盘。我在早期做的一个项目中，有个测试工程师没打灯就变道，结果方向盘突然自己转回来，差点把他吓一跳。从那以后，我们团队把「转向灯优先级」写进了需求文档的第一页。

LKA和LDW（车道偏离预警）是两码事。LDW只报警，不干预。LKA是真正会动手的。你想想看，如果只报警不拉方向，驾驶员可能正在看手机，等反应过来已经压线了。所以LKA的定位是「安全兜底」。

1.2 行业标准ISO 11270说了什么？

做量产项目，标准就是法律。ISO 11270是专门针对LKA系统的国际标准。我建议你把它打印出来放在工位上，因为审核的时候专家会一条一条对。

这个标准主要规定了以下几点：

• 激活条件：车速通常要高于60 km/h（不同OEM可以调整）
• 横向控制精度：车辆中心线与车道中心线的偏差要控制在某个范围内
• 干预力矩：最大转向力矩不能超过驾驶员轻易克服的阈值（一般是3-5 Nm）
• 退出机制：驾驶员只要用力反打方向盘，系统必须立即让权

1.3 系统架构：感知-决策-控制

LKA的架构其实不复杂，但每个环节都有坑。我习惯把它拆成三层：

1.3.1 感知层

感知层负责回答一个问题：「车道线在哪？」

主流方案有两种：

• 视觉方案：单目或双目摄像头，通过图像处理提取车道线像素点，再拟合成三次曲线方程
• 融合方案：视觉+高精地图（HD Map），用于曲率较大的弯道或车道线模糊场景

我在项目中遇到过最头疼的问题，是逆光场景下车道线完全看不见。后来我们加了「车道线置信度」这个参数，低于阈值就直接降级为LDW，不触发LKA干预。这个策略救了我们好几次路测。

1.3.2 决策层

决策层回答：「要不要干预？干预多少？」

这里有一个关键概念叫预瞄时间（Look-ahead Time）。系统不是看当前车辆位置，而是预测未来0.5-1.5秒后的位置。如果预测到会压线，就提前介入。

决策逻辑通常用PID控制或模型预测控制（MPC）。我个人更倾向于MPC，因为它能同时考虑转向舒适性和安全性。但MPC计算量大，需要硬件支持。

1.3.3 控制层

控制层负责执行。它把决策层算出的目标转向角，转换成EPS（电动助力转向系统）能理解的扭矩指令。

这里有个细节：扭矩斜坡。你不能一下子把最大扭矩怼上去，否则驾驶员会感觉被「拽」了一下。我们一般设计成200ms内线性增加，这样体感更自然。

1.4 开发流程：V模型

量产项目必须走V模型。这不是选择题，是必答题。

V模型的左侧是「自上而下」的需求分解，右侧是「自下而上」的集成验证。我画个简化的流程：

阶段	左侧（设计）	右侧（验证）
系统级	功能需求定义（ISO 11270）	整车路试验收
子系统级	感知/决策/控制模块设计	HIL（硬件在环）测试
组件级	算法单元开发	MIL/SIL（模型/软件在环）

我曾经在一个项目里跳过HIL测试，直接上了实车。结果发现EPS响应延迟比模型里多了50ms，导致车辆在弯道里来回震荡。嗯，从那以后我再也不敢省HIL了。

1.5 量产交付物清单

量产不是代码写完就完事了。交付物清单很长，我挑几个关键的：

• 软件需求规格书（SRS）：每条需求都要可测试、可追溯
• 算法设计文档（ADD）：包括感知、决策、控制的详细设计
• 测试报告：MIL/SIL/HIL/实车，四层测试结果
• 安全分析文档：基于ISO 26262的HARA分析、FMEA、FTA
• 标定参数文件：不同车型的转向力矩、预瞄时间等参数
• 诊断规范：系统故障时的降级策略和故障码定义

1.6 我的建议

如果你刚开始接触LKA，我建议你先从「感知层」入手。因为决策和控制相对成熟，但感知层的鲁棒性才是量产的最大瓶颈。你想想看，车道线检测不准，后面再好的控制算法都是白搭。

另外，多花时间在「标定」上。算法只占30%的工作量，标定和测试占了70%。这不是夸张，是实战经验。

好了，第一章就到这里。下一章我们会深入感知层，聊聊车道线检测的那些坑。