做ADAS这几年，自动紧急制动系统仿真真是被反复折腾得最多的方向。AEB这东西，放在日常场景里就是：前车突然急刹，或者路口冷不丁窜出一台两轮车，驾驶员还没来得及踩一脚，系统已经自动把车刹住。它的价值在于，碰撞风险发现得比人早，动作比人快。为什么先提仿真？因为用真车去试这些极限场景，危险性太高，成本也扛不住，而仿真能在一个可控的数字化环境里把AEB从感知到决策再到执行全链路跑通。这篇文章就是围绕我最近实操的一套AEB仿真实战流程来写的，把方案选型、控制逻辑、场景搭建、参数标定和问题排查完整展开，适合正在做ADAS算法或测试的工程师参考，刚入门的学生也能从中了解AEB工程落地的基本套路。
1. 自动紧急制动系统整体设计与仿真思路
1.1 AEB的核心定位：比人反应更快的一脚刹车
AEB全称Automatic Emergency Braking，自动紧急制动系统，属于主动安全功能里的核心成员。从工作链路看，它分三段：感知系统发现前方风险目标，决策系统判断碰撞即将发生，执行系统主动介入制动。翻译成大白话，就是系统要在驾驶员分神的一瞬间，把“快撞了”这个判断做得足够准、动作足够快。
这里有一个容易混淆的点：AEB不是ACC自适应巡航那种长时间跟车功能。ACC负责“跟得住”，保持安全车距；AEB负责“刹得掉”，只在紧急状态下介入。两者的风险判定逻辑有本质区别。ACC关心的是如何维持距离的稳定，AEB关心的是“当前存不存在碰撞趋势”。所以AEB算法设计上必须有一个非常明确的触发边界，不到边界不动，过了边界果断动作，不能拖泥带水。
做这个项目初期，我们组对“边界”的理解特别容易走极端。有人倾向把触发阈值调得很敏感，结果路上跑仿真模型时，稍远一点的行人就让车辆频繁点刹，乘坐体验差到离谱；有人又追求“绝对不能误制动”，把阈值调得非常保守，结果真遇到前车急刹场景，制动介入晚了大半拍，停车距离直接超目标。这里面的取舍，就是整个AEB标定工作的核心矛盾。
1.2 为什么坚持先做仿真再上实车
实车测试的痛点，干过的人心里都有数。第一，危险场景复现难。比如要做“前车90km/h突然急刹”这种工况，场地安全条件、驾驶员心理素质、车辆防护措施都得很到位，稍微出点差错就是事故。第二，费用高。封闭试验场按时间段收费，车辆、油料、设备、人力都要投入，跑一组场景下来成本很客观。第三，初版算法稳定性差。逻辑里可能存在明显bug，贸然上车测试，轻则测试中断，重则导致碰撞事故。
仿真把这些痛点基本都解决了。场景可控、参数可调、批量可跑，改完算法之后几百组工况可以挂机自动跑一遍，早上来看结果就行。我在最早做这个项目的时候吃过亏：没搭建自动化回归体系，每次改完逻辑都要手动点跑、手动记录结果，一个场景漏掉就得整个版本返工。后来改成“仿真作为第一道把关，实车验证作为第二道把关”，迭代节奏明显顺畅了。
需要说清楚的是，我并不是反对实车测试。恰恰相反，仿真的最终目的是让实车一次通过率更高。通过仿真把算法逻辑、边界条件、失控场景都扫过一遍之后，把为数不多的实车验证集中在最关键的几个标定点上，成本是最省的。这个思路在我后来几个项目里都验证了是走得通的。
1.3 工具组合怎么选：稳定比花哨重要
现在市面上能用的仿真工具相当多，各有各的生态。我最后选定的组合是：场景建模与传感器仿真用PreScan，车辆动力学用CarSim，控制算法在Simulink里搭建，三者通过联合仿真接口跑在一起。选这个组合有几点实际考虑，列个表说清楚：
| 环节 | 我用的工具 | 选择理由 | 需要留意的坑 |
|---|---|---|---|
| 场景/传感器 | PreScan | 场景库丰富，摄像头和雷达模型参数可调，场景编辑器顺手 | 传感器输出比真实情况理想，必须加噪声与延迟修正 |
| 车辆动力学 | CarSim | 轮胎、悬架、制动系统模型精度高，适合底盘级联合仿真 | 极限工况下轮胎模型仍有误差，需用实车数据校准 |
| 算法开发 | Simulink | 搭建控制逻辑直观，与动力学工具联合仿真接口成熟 | 步长设置很关键，不建议用自动变步长 |
| 批量回归 | Python脚本驱动 | 自动改场景参数、自动读取结果，适合夜间挂机 | 日志格式必须统一，否则解析阶段会非常痛苦 |
这里想多说一句：仿真不是拼谁的工具更高精尖，而是拼谁的链路能稳定复现。总有人问我为什么不直接用更时髦的开源端到端平台，我的看法是，在AEB这类功能安全属性很强的领域，你需要对传感器模型、车辆动力学模型、决策逻辑每一层都有极强的可解释性。出了问题要知道该改哪一层，而不是看到一个抽象的结果去猜。开源平台的灵活度高，但调试链路往往更长，对初版算法验证并不友好。等这套链路跑通了，再去探索新的工具生态也不迟。
2. AEB核心逻辑的工程拆解
2.1 感知层：最容易低估的多传感器融合难题
很多人一开始以为，在仿真场景里放一个摄像头和一个毫米波雷达就完事了。实际把仿真跑起来才发现，传感器模型输出的数据和真实传感器特性差距非常大，尤其是毫米波雷达。
毫米波雷达有一个要命的特性：对静止目标的反射信号，很容易被雷达内部的多普勒滤波算法当成地面杂波滤掉。很多量产雷达默认会过滤“零速目标”，这本来是为了防止护栏、井盖这类静态物体反复报警，但AEB恰恰需要识别静止的故障车辆和临时路障。仿真平台如果不把这个特性模拟出来，算法在仿真里一路绿灯，一上车面对静止假目标就可能完全失效。
我当时处理的办法是：在雷达目标输出里加一个属性标签，区分静止、运动和未知。融合算法对“未知”和“静止”目标做二次确认，结合摄像头的目标分类结果决定是否保留。这套思路从感知层面解决了“静止目标漏检”这个AEB最典型的痛点，后来也成为我们传感器融合模块的保留设计。
摄像头模型的坑在于测距误差和标定漂移。仿真平台给出的摄像头测距往往比真实摄像头准很多，如果直接把那个距离给到TTC计算，结果看起来会非常漂亮，但实车一测就露馅。所以我坚持在摄像头输出上加一个距离噪声模型，噪声幅度随距离增大而增大，基本按照均方根误差与距离成正比来设置。这个细节做完，仿真结果的置信度才真正上来了。
2.2 决策层：TTC风险判定与三档制动策略
AEB决策最核心的输入是TTC，Time To Collision，碰撞时间。计算很简单：两个目标的纵向相对距离除以纵向相对速度。举个例子，自车以64km/h接近一个静止目标，换算下来约17.8m/s，间距40米，那TTC就是2.25秒左右。含义是：如果双方都不做任何干预，2.25秒之后就撞上了。
但这里有两个细节很容易被忽略。
第一，TTC在相对速度为零的时候会变成无穷大，所以不能只用TTC当唯一判据。比如前车和自车同速行驶，间距从20米慢慢缩短到5米，相对速度是0，TTC是无穷大，系统如果不做任何处理就完全失效了。通常做法是引入最小安全距离模型做兜底，或者用固定时间阈值法，确保相对速度趋近于零时也能启动预警。
第二，路面附着条件不同，车辆可用的最大减速度是不同的。干燥沥青路面最大减速度能到8到9m/s²，但湿滑路面能达到3m/s²就不错了。AEB的制动减速度必须根据路面附着系数做降级处理，否则轮胎抱死之后，反而会失去转向能力，碰撞风险不降反升。
我的分级策略参考了常见的AEB分级制动思路，设计成三档：
- 预备警告阶段：TTC小于2.0秒，仪表盘弹图标加蜂鸣器短鸣，提示驾驶员接管。
- 部分制动阶段：TTC小于1.2秒，施加约2至3m/s²减速度，目的是在驾驶员反应之前先减速，即使马上取消制动，车身也不会有剧烈点头。
- 全力制动阶段：TTC小于0.6秒，减速度目标设定在6至8m/s²，此时不考虑乘坐舒适性，以避撞为第一优先。
这几档阈值不是拍脑袋定的，必须结合制动系统的物理响应时间。制动执行器从收到指令到压力建立完毕，通常有150到300毫秒的延迟，所以算法里必须把这段延迟提前补偿进去。仿真里我就踩过这个坑：阈值给得很激进，结果实际制动压力还没建立起来，TTC就已经归零了，碰撞自然避不开。
2.3 执行层：制动力过渡、退出机制与驾驶员接管
执行层的核心任务，是把决策状态“翻译”成车辆实际动作。在Simulink里，这一层做的是把无动作、预警、部分制动、全力制动这几个状态映射成目标减速度，再换算成制动主缸压力请求，发给车辆动力学模型。
特别要处理的是平滑过渡。如果决策状态在部分制动和全力制动之间直接跳变，减速度会出现一个很陡的台阶，实车表现就是强烈顿挫，严重时直接触发ABS工作。我当时的实现方式是在两个目标减速度之间加一个变化率限制，比如全力制动的减速度变化率不超过每秒20m/s³。这样既能保证刹车足够快，又不会造成机械冲击。
退出机制同样重要。触发AEB之后，系统不能一直刹到车辆完全停止就不管了，尤其是高速公路工况，前车虽然刹停了，但后面可能还有其他车辆。因此当目标相对速度低于一定值，且自车已经明显减速时，系统要释放制动让驾驶者继续接管。退出条件在仿真里必须单独写成状态机，不然很容易出现“刹停后一直锁死”的怪bug。我们有一次联合仿真就碰到这种情况，车辆撞上前的确停了，但停完之后制动请求一直不撤，导致模型里后车从侧面直接撞上来，问题暴露得相当及时。
3. 实操过程：从场景搭建到联合仿真跑通
3.1 场景库搭建：先做质量再做数量
AEB仿真测试不能只跑一种“前车静止”的工况，否则算法很容易过拟合。行业里常见的测试场景一般分四类：
- 前车静止（CCRs）：模拟高速上故障车辆停在行车道。
- 前车低速匀速（CCRm）：模拟前方车流缓慢行驶，自车高速接近。
- 前车突然急刹（CCRb）：两车同速跟随，前车突然以高减速度刹车。
- 行人或两轮车目标横穿、同向行走（VRU）。
我搭建场景库的时候，把每一类场景做成可参数化的模板。起步速度、横向偏移、目标初始距离、相对速度、道路曲率、天气条件，全部抽成变量。然后用脚本批量生成组合参数，跑完自动收集结果。这样一轮冒烟测试下来，基本可以把绝大部分逻辑问题暴露出来。
这里有一条真实经验：不要盲目堆场景数量，先把标准场景的质量做高。比如CCRb场景，前车开始刹车的时刻必须控制在自车和目标间距处于设定范围之后，且前车制动减速度要精确到设定值。如果场景里前车制动时机不合逻辑，跑出来的数据就会污染整个测试结论，甚至误导标定方向。
3.2 Simulink算法模型搭建的关键细节
算法模型我分成几个子模块：目标列表输入接口、目标筛选与融合、风险判定、制动决策状态机、控制量输出。每个子模块单独做成Simulink Library，方便其他项目复用。
几个关键细节必须说清。
输入接口统一成总线信号，包含目标ID、纵向距离、横向距离、纵向相对速度、横向相对速度、目标类型、置信度。如果不统一，后面换传感器模型或者接硬件时，要改一大堆接口定义，非常痛苦。
目标筛选时要定义自车车道中心线。横向距离大于某个阈值的目标直接丢弃，比如自车半宽加1.5米安全裕度，避免对隔壁车道车辆误触发。但这个阈值必须和场景里目标横向偏移动态匹配。高速弯道场景要特别小心，不能简单用直线车道的规则硬套。
仿真步长设置是很多人忽视的点。整个模型我用固定步长跑，习惯设在1毫秒。为什么不是变步长？变步长虽然仿真耗时短，但雷达目标更新周期是20到50毫秒，步长一变，目标更新时间戳就对不齐，查数据、查时序会非常痛。固定步长可以保证雷达目标更新周期能整除对齐，排查问题的时候，每个时间点对应的帧都是确定的。
3.3 一次完整仿真调试记录
用一次典型调试来复盘：车辆初速60km/h，前方40米有一辆静止轿车目标，路面干燥。整个仿真链路跑完后，关键时间点记录如下：
- 0.0秒：仿真开始，自车以16.7m/s匀速行驶，摄像头和雷达模型同时检测到前方目标。
- 0.3秒：融合模块输出稳定目标信息，纵向相对距离38.5米，相对速度-16.7m/s。
- 0.9秒：TTC计算值达到2.1秒，进入预备警告阶段，仪表短鸣。
- 1.5秒：TTC到1.18秒，进入部分制动阶段，减速度加载到-2.6m/s²。
- 2.3秒：TTC到0.55秒，进入全力制动阶段，减速度爬升至-7.8m/s²，车速急速下降。
- 3.4秒：自车完全停止，距离目标前端约0.8米。
这个结果还算达标，但其实是在修掉两个问题之后才跑出来的。第一版没加制动执行器延迟，停车距离接近2米，虽然也刹停了，但和真实车辆预期不一致。第二版加上延迟模型之后，又发现全力制动阶段的减速度爬坡太陡，触发了ABS标志。把爬升率调低之后才稳定下来。这两次返工给团队的印象都很深，也是从那时候起，我们把“执行器延迟”和“减速度爬坡限制”写进了模型参数的必填项。
3.4 封闭场地泡沫假目标对照验证
仿真跑通之后，我们在封闭场地用泡沫假目标做了一次对标验证。用高密度泡沫拼出一个轿车轮廓，放置在直线车道上，测试车以30km/h左右低速通过，观察系统真实响应。
结果印证了一个判断：算法逻辑本身没有问题，但与仿真结果存在可量化的差距。第一是传感器延迟，真实雷达从目标触发到数据输出，会有几十毫秒的处理时间，仿真模型通常把这个时间设为零。第二是制动执行器响应，真车液压建立压力的过程比仿真里的理想模型慢得多，同样的目标减速度请求，实车达到目标减速度的时间明显更长。
改进办法是给仿真模型补上两个延迟环节，再按实测制动曲线标定压力与减速度的映射关系。这部分工作做完，仿真结果和实车测试的吻合度才真正提升到可接受水平。如果没有做过实车对标，单看仿真结果确实很容易自信过头。
4. 常见问题与排查技巧实录
4.1 误触发：弯道护栏被识别成障碍物
这类问题在仿真里极为常见。场景稍微复杂一点，比如自车在弯道行驶，弯道护栏恰好落在传感器探测范围内，目标横向距离又短暂落入自车行驶轨迹区间，系统就会误判为碰撞风险而触发刹车。
排查路径基本分三步：
- 先看融合层输出的目标特征，确认是不是护栏产生的静态目标，再看摄像头分类结果是否标成了障碍物。
- 再看目标横向距离与自车预测轨迹的贴合程度。弯道里出误触发，往往是因为轨迹预测太简单，只把当前前轮转角外推，没有考虑道路曲率变化。
- 最后查风险判定层的TTC计算，是否使用了经过横向偏移修正后的有效距离。
我最后的解法是引入一个可行驶区域校验环节。用车道线信息和目标类别做联合判断，护栏、路沿这类路面外目标，即使纵向距离很近也不触发AEB，只有目标真正落在可行驶区域内才参与TTC判定。这个逻辑上线之后，弯道误触发率从高频出现直接降为零。
4.2 漏检：静止目标为什么在雷达模型中看不见
新手最容易困惑的问题之一：场景里明明放了静止车辆，雷达模型就是不输出目标，或者输出了又被算法过滤掉。这个问题的排查顺序很重要，我建议按这个顺序来：
- 确认雷达参数：最大探测距离、水平视场角、垂直视场角是否覆盖目标。
- 查看雷达信号处理模型里“静态目标抑制”开关有没有打开。这个参数如果开启，零多普勒目标会被直接丢弃，AEB场景下必须关闭。
- 查融合过滤逻辑，有些算法会错误地用相对速度为0作为目标无效条件，导致运动目标减速到静止后被误删。
我这边真正修好的案例就是因为第二步。把静态目标抑制开关关闭后，静止目标正常进入目标列表，算法立刻开始工作。这类问题回想起来很简单，但如果在多级模型链路里没有逐层排查的意识，确实能卡住一整周。
4.3 仿真结果与实车测试对不齐，核心原因在哪
很多团队仿真阶段跑得很漂亮，一到封闭场地测试就翻车，问题基本集中在下面这三处。我整理了一个对照表，方便排查时快速定位：
| 差异来源 | 表现特征 | 排查与修正方法 |
|---|---|---|
| 传感器噪声模型过于理想 | 仿真里目标距离非常稳定，实车数据跳变得厉害 | 按真实雷达数据手册设置噪声幅度，再做灵敏度分析 |
| 制动执行器延迟没建模 | 仿真中停车距离偏短，实车明显变长 | 在仿真链中加入150至300毫秒的执行延迟补偿 |
| 车辆动力学极限工况误差 | 仿真里车辆能轻松刹停，实车却提前触发ABS | 用实车制动试验数据反向校准轮胎与制动模型参数 |
这里我再补一个经验：仿真和实车的差异，不能只靠“把噪声调大”来糊弄。关键是把每条数据链路的时间延迟、增益和饱和特性都搞准。误差是逐步逼近的，不是一次调参就能一劳永逸的。每版仿真模型更新后，都应该拿最近一版实车标定数据做一次回归对比，确保模型没有越改越偏。
5. 实操心得与后续扩展方向
5.1 值得长期坚持的几条项目经验
这套AEB仿真实战做下来，我最想保留的经验有三条。
第一，AEB仿真的核心不是“把算法跑起来”，而是“让结果可信”。可信来自每一层误差被显式建模：传感器延迟、目标漏检率、制动执行器响应时间，哪怕模型简陋，也要明确写在参数表里。结果可信之后，后续做标定、做汇报、做功能安全评审，才有底气。
第二，参数矩阵自动化回归是必须从第一天就开始投入的工程能力。我早期偷懒，手动跑几个场景觉得差不多了，结果算法改一版，隐藏问题就从来没跑到的场景里冒出来。后来用脚本把场景参数自动扫描一遍，预警、误报、漏报全部落到表格里，代码评审会上每个决策都有数据支撑，沟通成本低了很多。
第三，仿真工具链的熟练度值得长期积累。同样的模型，不同的人搭出来效率差距很大，关键就在对工具细节的掌握程度。比如Simulink里总线信号怎么设计更合理，CarSim怎么批量导出工况，PreScan里传感器参数怎么与真实雷达对标，这些都是经验资产，越沉淀越值钱。
5.2 后续扩展：从算法仿真走向系统级验证
这个项目后续的扩展空间其实很大，对我而言，下一步最值得做的就是HIL硬件在环测试。把真实的AEB控制器接进仿真回路，前面跑场景模型和动力学模型，控制器跑真实代码，验证控制器硬件和软件在环下的实际表现。这一步能把仿真环境的价值进一步放大，很多单纯算法仿真发现不了的接口问题和时序问题都会暴露出来。
另外可以引入功能安全的故障注入测试。比如模拟传感器失效、执行器卡死、通信超时这类失效模式，验证AEB系统的降级策略是否合理。这也是法规之外越来越被关注的领域。
对刚开始接触AEB仿真的同学，我的建议是：先踏踏实实把最简单的“前车静止”场景跑通，然后逐步加传感器噪声、加执行器延迟、加复杂路况。一步一个坎踩过去，比囫囵吞枣刷一百个Demo有用得多。这行当里，仿真跑得再漂亮，最终也要回到“关键时刻刹得住”这个朴素目标上。
