前两年我头一回在测试车上把AEB（Automatic Emergency Braking，自动紧急制动）触发的那一脚刹车“踩”在自己身上，不是靠脚，而是靠系统自己。那一瞬间车速从60多直接往下掉，安全带勒紧，车内所有东西都在往前滑，而面前那只充气靶车越来越近、越来越近，最后整台车稳稳停在距离靶车不到半米的位置。说来有点夸张，但那种“它自己知道要刹住”的感觉，确实会让你对这套技术产生一种复杂的敬畏。AEB这套东西，很多人把它理解成“自动踩一脚刹车”，但真正做过标定、跑过测试、分析过失效数据之后你会发现，它远不止踩刹车这么简单。它是一个横跨感知、决策、底盘控制、人机交互的复杂系统，是ADAS里对安全边界要求最高的功能之一。这篇文章我打算把这些年在AEB上积累的架构理解、算法逻辑、标定心得、测试过程和踩坑记录拿出来，尽量讲透，也尽量讲得让正准备入行ADAS的朋友能少走弯路。1. AEB到底由什么组成：一段从传感器到刹车卡钳的完整链路AEB的全链路可以拆成三段：感知、决策、执行。听起来简单，但每一段展开都有大量耐人寻味的细节。很多项目开发到后期，你会发现性能瓶颈往往不在某一颗芯片算得快不快，而在这三段能否顺畅协作。1.1 感知端：一个负责丈量，一个负责辨认AEB的感知方案目前主流是摄像头加毫米波雷达融合。这两类传感器真的是性格完全不同的两个搭档。毫米波雷达的核心优势是直接测距、测速，对天气不敏感，雨天、雾天、夜间都能稳定工作。它发射毫米波，通过多普勒效应直接算相对速度，所以在纵向距离和相对速度的精度上非常有优势，误差通常能控制在厘米级到分米级。但它的短板同样明显：角度分辨率低，很难判断目标到底是车还是路边的铁护栏；对静止目标的检测能力也有瓶颈，尤其在城市复杂环境里，杂波多，容易把井盖、隧道墙壁、路边铁箱当成可疑目标。摄像头则相反。它能“认出”前方的东西是轿车、卡车、行人还是骑行者，目标分类能力强，横向位置精度也高。但它本质上是个光学器件，受光照影响极大。晚上没路灯的时候、大灯直射的逆光场景、隧道出入口光线突变，这些情况下摄像头性能会大幅下降。所以你会看到AEB的感知端基本都是双传感器融合，让雷达负责纵向测量，摄像头负责目标分类和横向判断，再通过目标关联算法把两者的检测结果融合成同一份目标列表。如果只靠单一传感器，要么雨天晚上识别不出行人，要么晴天白天把路边金属路牌误判成障碍物。融合并不是凑热闹，而是用两套物理原理完全不同的传感器互相兜底。1.2 从目标到风险：看AEB是怎么“下决心”的感知端输出的是目标列表，每个目标带着距离、相对速度、横向偏移、目标类型、存在概率等一堆信息。但这些信息不会直接被用来踩刹车，它们要先经过一个决策链：第一个环节是目标筛选。系统把护栏、路牌、对向车道车辆、静止的高大障碍物等信息放进场景模型里，排除掉那些不在本车行驶通道内的目标，留下潜在威胁。第二个环节是轨迹预测。系统要判断这个目标接下来怎么动。前车是正在减速还是匀速？行人是在横穿还是站在路边不动？预测越准，决策越从容。可惜预测永远有误差，所以系统必须给误差留余量。第三个环节是风险评估。根据本车速度、目标距离、相对速度算碰撞时间，再结合本车能达到的最大减速度，判断我现在刹车来不来得及。如果来不及，就要触发系统介入。最后才是执行端发出制动请求。制动请求会发给ESP或底盘域控制器，由它分配制动力到四个轮子，同时点亮刹车灯、收紧安全带、弹出仪表报警。这条链路每多一层，就多一点延迟，但也多一层安全保障。系统设计时必须对每一步的延迟做预算，比如感知40毫秒、融合20毫秒、决策10毫秒、执行30毫秒，全链路算下来，从目标出现到最后制动器响应，100到200毫秒是常见量级。别小看这100多毫秒，在高速场景下可能意味着几米的差距。1.3 功能边界：AEB不是神，也不是保险杠很多刚接触AEB的人容易把它神化，觉得有了这个功能就不会撞车。实际做功能开发的人都知道，AEB的设计目标从来不是“绝对避免碰撞”，而是“最大程度降低碰撞速度”。欧洲很多主机厂在宣传时也说得比较保守，AEB能处理的场景、速度区间都有严格限制，超出边界它就是一套不启动的系统。比如前方车辆静止但本车速度超过系统标定上限，或者行驶在有侧向坡度的弯道里，传感器的视线被前车遮挡，再或者暴雨天气雷达多径反射导致目标跳变严重，这些场景下AEB都可能失效。开发者要做的不是让系统在所有场景下都能刹住，而是明确画出系统的工作边界，在边界内把性能做扎实，同时用失效降级策略保证任何情况下都不能因为误触发造成更大的危险。AEB还有一个容易被忽略的定位：它是驾驶员的辅助，不是替代。所以我一直跟团队说，功能标定的核心哲学是“不要打扰”。如果系统动不动就无预警地来一脚重刹，那驾驶体验会很差，也会让驾驶员逐渐丧失对系统的信任，紧急时刻反而不敢依赖它。2. 那一秒钟的决定：碰撞风险评估与制动策略的核心逻辑如果说AEB的骨架是传感器加执行器，那它的灵魂就是决策层里的碰撞风险评估算法。AEB一个完整的判断周期往往只有几百毫秒到一秒多，在这么短的时间里，系统要从大量目标中锁定最危险的那个，并决定采取什么等级的动作，全靠一套逻辑严密的风险模型。2.1 TTC是什么：一切决策的锚点讨论AEB绕不开TTC，全称Time To Collision，碰撞时间，定义为本车与前方目标按当前相对速度和相对距离推算，预计发生碰撞所需的时间。计算公式很简单：TTC = 相对距离 / 相对速度这里相对速度是本车速度减去目标速度，也就是接近速率。如果相对速度小于等于0，说明本车不比目标快，没有逼近趋势，系统不会做干预。当TTC越小时，碰撞风险越高。举一个具体数据例子。假设本车以72km/h行驶，前方有一辆静止的故障车，相对距离是40米。72km/h换算成20m/s，那么TTC = 40 / 20 = 2秒。这2秒里系统要完成目标确认、风险评估、驾驶员警告、部分制动、全力制动这一整套动作。看起来充裕，实际上考虑到感知延迟和执行延迟，留给策略真正做决定的时间也就是1.5秒左右，非常紧张。我经常用超车场景做类比帮助新人理解TTC：你在高速上准备超越一辆慢车，发现对面车道有来车，你用两车距离除以相对速度，心里估摸还有几秒会相接，然后判断现在超不超。AEB做的事情本质上跟你的本能一样，只不过它每时每刻都在算，而且算得比你快、比你准。下面用一段简化的Python示例演示TTC计算与分级决策的基本逻辑，实际工程里的代码比这复杂得多，但核心思路就是这样：def compute_ttc(relative_dist, relative_speed): # relative_speed > 0 表示本车速度大于目标，正在逼近 if relative_speed <= 0: return None # 不存在碰撞风险 return relative_dist / relative_speed def brake_decision(ttc, ego_speed): if ttc is None: return "no_action" if ttc < 1.0: return "full_brake" if ttc < 1.8: return "partial_brake" if ttc < 2.6: return "warning" return "no_action"这个逻辑只是示意，真实的工程代码不会用这么死板的固定阈值，但可以帮新手理解基本思想：TTC越小，输出的制动等级越高。2.2 分级制动策略：预警、部分制动、全力制动的配合实际量产车的AEB几乎不会一上来就全力制动，因为那既不安全也不舒适。行业里普遍采用分级策略：第一级是预警。当TTC进入设定阈值，比如2.6秒左右，系统会在仪表或HUD上弹出报警图标，同时发出声音提示，目的是唤醒驾驶员，让他赶紧接管油门刹车。报警本身不产生制动力。第二级是部分制动。如果驾驶员仍然没有反应，TTC继续降低到1.8秒附近，系统会主动建立制动压力，产生约0.3g到0.4g的减速度。这个力度的作用是提前降低车速，争取更多反应时间，同时通过顿挫感引起驾驶员注意。第三级是全力制动。当碰撞已经无法避免，TTC跌破1.0秒甚至更小的阈值，系统会请求最大减速度，目标是把碰撞能量降到最低。正常情况下，AEB全力制动的减速度可以做到接近车辆物理极限，有些车型在良好路面甚至能到1g以上。用表格描述更直观：制动等级典型触发TTC减速度范围主要目的预警2.6s左右0唤醒驾驶员，提前接管部分制动1.8s左右0.3g ~ 0.4g降速、提示、争取时间全力制动1.0s左右最大可达1g尽量减轻或避免碰撞为什么要分级，不直接一脚刹死？这里有两个层面的考虑。先谈安全性：高速行驶时如果轮胎制动力瞬间拉满，车辆可能出现车轮抱死或甩尾，对驾驶员和后方车辆都是危险；再谈乘员体验：毫无预兆的全力制动会让车上乘员猛烈前倾，轻则不适重则受伤，对颈部的伤害尤其明显。分级制动的逻辑是给驾驶员留出接管窗口，只有确认驾驶员“真的不管了”，系统才会逐步加大介入力度。2.3 置信度融合：雷达说“目标存在”但摄像头说“没有”，听谁的AEB决策绕不开的一个难题是传感器不一致。雷达在前方检测到一个反射点，摄像头却没识别出任何目标，怎么办？如果直接采信雷达，可能会在路过的铁箱、桥下悬挂物前面突然刹车；如果直接忽略雷达，又可能在夜间低照度场景下漏掉真实行人。工程上的做法是计算目标的“存在概率”和“危险概率”，再把这两个概率映射到决策逻辑里。比如雷达置信度高但摄像头没有确认，系统可能把目标标记为“待确认”，只做预警，不做制动；如果雷达和摄像头都确认目标，则进入完全激活的AEB判定。如果是行人目标，由于身份特殊，决策逻辑会更谨慎，完全依赖单一传感器触发制动的条件会更苛刻。这背后还牵扯到整车对安全等级的分级：一个传感器确认目标时，系统默认置信度较低，允许降级为报警；双传感器都确认，置信度高，可以触发制动。这种“冗余触发”策略的目的，是在保证安全性的前提下，最大限度降低误触发概率。2.4 本车状态与路面附着：同样的TTC，不同结论同样一个TTC值，在干燥柏油路和雨后湿滑路面上的处理方式完全不同。高速行驶时如果路面附着系数低，一上来就请求大减速度可能导致车轮打滑，车辆失控。制动策略要和车辆的稳定控制功能联动。比如系统估算当前路面附着系数只能支持0.5g的减速度，那么它在评估“来不来得及刹停”时，就会用0.5g而不是1g来算，如果发现刹不住，就提前进入预警和制动请求，而不是等到TTC跌破阈值才做动作。所以AEB开发通常会定义多个不同的状态模型，分别对应高附、低附、冰雪等工况，不同模型里同一套TTC阈值映射出的制动等级是有差异的。此外，车辆本身是转弯还是直行也影响决策。转弯时前方目标的横向运动趋势会更强，系统需要结合横摆角速度、方向盘转角等信息判断目标是否真的会撞上，这也是防止弯道护栏误触发的重要一环。3. 从标定到调参：工程里真正磨人的部分算法和策略搭建起来之后，真正的硬仗在标定。AEB标定是一项极度依赖数据、经验和耐心的系统工程。我见过不少拓扑设计得很漂亮的方案，一到实车标定就被各种边缘场景打回原形。原因其实很简单：真实世界里的场景分布是长尾的，标定做得好的团队，本质上是把那根长长的尾巴梳理得足够顺。3.1 标定的本质：在误报与漏报之间反复走钢丝做AEB标定，首先要接受一个现实：误报和漏报是一对无法同时降到零的矛盾。如果你把触发条件调得很激进，那确实能在很多真实碰撞场景中自动刹住，但伴随而来的是路边的铁皮、路面接缝、迎面对向车辆的误触发，这些误动作可能带来追尾，比漏报更麻烦。反过来，如果调得保守，误报少了，但真实碰撞里系统反应又太慢，评测成绩也不好看。标定工作就变成了一项在两者之间找平衡点的艺术。实际操作中，团队会根据功能安全目标定一个误报率上限，比如某车型要求每万公里误触发不超过多少次，再在这个约束下尽可能提升对真实危险场景的检测率。理解了这个逻辑，你就明白为什么很多标定工程师手机里存着大量“诡异触发”的短视频——每一个误报案例都价值连城，它们是调整阈值最直接的证据。3.2 关键标定参数的量级与调整手感标定阶段反复磨的参数主要有这几类：各级制动触发的TTC阈值、目标横向重叠比例、目标类型权重、感知延迟补偿量。这里给出一些常见经验量级，具体数值因车型、传感器配置和法规目标而异，但也足够让你理解量级关系。预警触发TTC通常设在2.2到3.0秒之间；部分制动触发TTC在1.5到2.0秒；全力制动触发TTC在0.8到1.2秒。这些值看起来只是几个数字，实际上每个数字背后都是上百条测试数据的积累。调整手感上，我个人的经验是：预警阈值可以放得稍微宽一点，多响警报顶多遭人嫌弃，但部分制动和全力制动阈值要慎之又慎，每改动0.1秒都可能带来完全不同的路面表现。目标横向重叠度也很关键。所谓重叠度，指本车行驶轨迹与目标在横向上重合的比例。如果只是车头一角扫过路边停着的车，横向重叠率低，系统不该触发全力制动；如果正对目标尾部，重叠率接近100%，那肯定要重点响应。这个参数的标定难点在于如何定义相对横向位置，它通常要经过目标轨迹预测模块来估算。还有一个容易被忽视但影响巨大的参数：感知延迟补偿。从传感器探测到目标，到决策层收到信息，再到制动器真正建压，中间每条链路都有延迟。如果你不在风险评估模型里把延迟折算进去，系统在高速场景下会晚半拍，导致实际减速度请求不足。工程上常用的做法是给目标的纵向位置和速度做前向预测补偿，把几十到上百毫秒的延迟当成一个可估的未来提前量。下面用一个更贴近实际思路的伪代码展示延迟补偿对决策的影响：def compensate_delay(target_dist, target_speed, delay): # 在 delay 秒后，目标相对距离会因相对速度而减小 compensated_dist = target_dist - target_speed * delay return max(compensated_dist, 0)3.3 感知不确定性的处理：同样一个目标，置信度不是恒定的感知模块给出的目标置信度不是一个固定值，它会随环境动态变化。夜间摄像头图像质量差，行人检测置信度会明显掉下来；雨天雷达回波被地面水膜反射干扰，目标位置抖动变大。如果标定时不看这些置信度变化规律，只在白天干路面上标定，系统一到恶略天气就会表现得不可控。合理的做法是把置信度作为决策的一个权重因子：高置信度目标可以更早触发制动，低置信度目标则要求更多确认条件。比如白天行人识别置信度0.9，夜间可能只有0.6，那么系统在夜间就需要更近的触发距离，或者等待雷达也确认目标后才允许制动。这种动态调整逻辑看着容易，实车上逐个场景调过去的工程量非常大。另外，多目标场景下如何选主目标也常常让新手头疼。原则是选择对自车威胁最大的目标，但“威胁最大”不只是距离最近，还要结合相对速度、横向位置、目标类型来综合判断。比如近处有一个静止护栏，远处有一个快速接近的行人，谁更危险？很多时候答案并不是直觉上那个最近的。选错了主目标，AEB就可能跟空气较劲，真正的危险目标被晾在一边。3.4 制动与底盘控制协同：刹得稳比刹得住更难AEB的最终执行端是底盘系统，刹得住、刹得稳是两码事。制动请求发出去之后，ESP要负责轮缸建压、制动力分配，还要监测每个车轮的滑移状态。如果路面两边附着系数不同，左右轮制动力不一致，车辆会产生横摆，这时候就需要ESP介入修正。整套协同做不好，可能出现刹停瞬间车身猛烈抖动、点头严重甚至跑偏的现象。我们曾经在测试中遇到一个典型案例：车辆触发AEB全力制动后，车速减到接近零的瞬间，车身出现一次明显的前后顿挫，有点像手动挡车急刹熄火那一下。后来排查发现，是制动力在低速段切换时，液压控制阀响应时序和轮速信号错位，导致制动力波动。这类问题只能在测试中反复复现，然后联合底盘团队一点一点调整控制参数。这里也提一个实用建议：不管你做策略还是做感知，一定要抽时间去看底盘制动控制的数据，理解ABS和ESP怎么协调轮缸压力。那些能把AEB标定做得又快又准的工程师，普遍都是对底盘控制有足够理解的，因为他们知道每次策略改动最终会怎么映射到轮端动作上。4. AEB的考试周：测试方法、经典失效案例与排查思路AEB开发有一半时间在路上。在我看来，AEB测试就像给学生排考试周，场景设计、工具准备、数据打分，环环相扣。测试做得扎实，问题暴露得早，标定迭代效率就高；测试做得敷衍，后面到了用户手里就会以各种匪夷所思的方式爆发。4.1 主流测试场景：从最基础到最刁钻AEB测试有一整套基本的场景库，覆盖了日常道路的主要碰撞形态。前车静止场景是最基础的，本车以不同初速度接近一个静止目标车，验证系统能否在距离前车足够远时完全刹停。前车慢行场景模拟的是市区跟车，前车以20km/h左右匀速行驶，本车以更高速度接近，观察系统能否减速到与前车同步。前车急减速场景则更严苛，两车保持安全距离行驶，前车突然大力制动，本车AEB必须快速响应，避免追尾。行人横穿场景也就是大家常说的“鬼探头”，对感知和决策的实时性要求极高。骑行者场景因为目标尺寸小、运动轨迹灵活，对识别算法的挑战更大。这些场景的测试速度区间通常从低速一直做到系统标定上限，横向上还要做不同重叠率组合。一个完整的AEB测试矩阵往往包含几百上千条测试用例，每一条用例在测试场里跑下来，加上准备和复跑时间，工作量非常可观。4.2 测试工具准备：靶车、假人与数据采集AEB测试离不开专业工具：用于扮演障碍车的靶车，用来扮演行人的假人，还有用于扮演骑行者的自行车平台。靶车不是普通租来的车，它的车身覆盖着专门的材料，视觉上跟真实车辆接近，同时雷达反射截面也要跟真实车辆相当，这样才能骗过两个传感器。假人更讲究，成年人形、儿童形、坐轮椅形，各有各的体态和移动规律，而且臀部、膝关节等位置还要有适当的热/雷达反射特征，否则感知系统会识别异常。数据采集是测试中绝对不能省的一环。车端需要同步记录CAN总线信号、雷达和摄像头原始数据、视频流、GPS轨迹。这里最容易被忽视的是时间同步。所有数据源的时钟必须严格对齐，否则你对着视频看到一个目标，再看CAN数据却对不上号，整个排查过程会非常痛苦。建议在测试开始前先做一次完整的数据链路核查，确认时间戳同步机制正常，再开跑。评价一次测试结果时，我习惯看重复性。同样一条用例，今天跑三遍，三次结果可能有细微差异，因为风速、路面温度、传感器噪声都会影响系统行为。只要结果落在合理范围内，就不必纠结某一次是刹住了还是减了速；但如果同一条用例出现一次刹住一次没刹住的极端差异，那一定存在感知或决策的不稳定因素，需要重点排查。4.3 经典失效案例与排查速查表这些年我整理过不少AEB实车测试中的经典失效模式，很多都很有代表性，这里列一个速查表，方便你遇到类似问题时有排查方向可以参考。失效现象可能原因排查方向隧道出入口偶发误触发摄像头曝光突变丢帧、感知目标短暂丢失检查摄像头自动曝光策略、融合模块状态机雨天前方无车却报警雷达多径反射、地面水膜产生虚假回波调低低置信目标权重、增加目标确认条件路过金属井盖触发制动雷达把井盖当成静止障碍物增加目标横向生命周期判断、引入连续帧特征夜间行人漏报不制动摄像头置信度下降、雷达反射弱调整夜间置信度阈值，增加雷达权重弯道处对路边护栏误触发轨迹预测未考虑弯道曲率引入本车横摆角速度修正目标运动模型前车刚起步时出现误制动目标分类从静止切换为运动延迟优化目标状态机，增加启动抑制逻辑排查这类问题的通用思路是先复现，再把感知原始数据、决策日志、执行请求三段数据拉出来做时间对齐回放，找到究竟是哪一段链路先出现异常。我见过很多团队卡在某个问题上很久，原因是花了大量时间调决策参数，后来才发现根源是摄像头标定偏移导致的感知位置偏差——所以排查时一定不要预设结论，先用数据说话。4.4 结果评价与验收心得AEB测试的评价指标通常就三个维度：漏报率、误报率、制动舒适性。漏报率衡量真实危险场景中有多少没触发，误报率衡量无风险场景中有多少错误干预，制动舒适性则通过减速度变化率、车身姿态等数据来量化。这三个指标互相牵制，验收时要放到一起看。我个人的一条心得是：验收AEB性能，不能只看某条测试用例过了没有，而要看整个测试矩阵的成绩分布。比如有一项高速前车静止用例过了，但低速行人横穿场景成绩波动大，这种偏科式表现往往意味着某个感知场景的置信度处理还有问题。以偏概全式地宣告“AEB标定完成”，后面量产了大概率会被用户教做人。另外，AEB实车测试的安全管理也很重要。做高速场景时，靶车要有远程控制急停机制，测试车辆要配备紧急制动开关，驾驶员必须是经验丰富的测试员。这不是小题大做，系统总有失效的那一刻，测试安全的底线永远不能松。做AEB这几年，我最大的体会是：这东西就像一个沉默的副驾，平时默默看着路，关键时刻拉你一把。它不完美，会误判，会误报，但每一次成功刹停背后都是无数工程师对策略逻辑的精雕细琢。最后分享一个我自己一直保持的习惯：每次回看测试录像，先看驾驶员表情，再看车外视角。因为AEB不只是在刹车上做文章，它真正改变的是驾驶员对一台车的信任感——而信任，才是主动安全功能最值钱的产出。
前两年我头一回在测试车上把AEB（Automatic Emergency Braking，自动紧急制动）触发的那一脚刹车“踩”在自己身上，不是靠脚，而是靠系统自己。那一瞬间车速从60多直接往下掉，安全带勒紧，车内所有东西都在往前滑，而面前那只充气靶车越来越近、越来越近，最后整台车稳稳停在距离靶车不到半米的位置。说来有点夸张，但那种“它自己知道要刹住”的感觉，确实会让你对这套技术产生一种复杂的敬畏。AEB这套东西，很多人把它理解成“自动踩一脚刹车”，但真正做过标定、跑过测试、分析过失效数据之后你会发现，它远不止踩刹车这么简单。它是一个横跨感知、决策、底盘控制、人机交互的复杂系统，是ADAS里对安全边界要求最高的功能之一。这篇文章我打算把这些年在AEB上积累的架构理解、算法逻辑、标定心得、测试过程和踩坑记录拿出来，尽量讲透，也尽量讲得让正准备入行ADAS的朋友能少走弯路。1. AEB到底由什么组成：一段从传感器到刹车卡钳的完整链路AEB的全链路可以拆成三段：感知、决策、执行。听起来简单，但每一段展开都有大量耐人寻味的细节。很多项目开发到后期，你会发现性能瓶颈往往不在某一颗芯片算得快不快，而在这三段能否顺畅协作。1.1 感知端：一个负责丈量，一个负责辨认AEB的感知方案目前主流是摄像头加毫米波雷达融合。这两类传感器真的是性格完全不同的两个搭档。毫米波雷达的核心优势是直接测距、测速，对天气不敏感，雨天、雾天、夜间都能稳定工作。它发射毫米波，通过多普勒效应直接算相对速度，所以在纵向距离和相对速度的精度上非常有优势，误差通常能控制在厘米级到分米级。但它的短板同样明显：角度分辨率低，很难判断目标到底是车还是路边的铁护栏；对静止目标的检测能力也有瓶颈，尤其在城市复杂环境里，杂波多，容易把井盖、隧道墙壁、路边铁箱当成可疑目标。摄像头则相反。它能“认出”前方的东西是轿车、卡车、行人还是骑行者，目标分类能力强，横向位置精度也高。但它本质上是个光学器件，受光照影响极大。晚上没路灯的时候、大灯直射的逆光场景、隧道出入口光线突变，这些情况下摄像头性能会大幅下降。所以你会看到AEB的感知端基本都是双传感器融合，让雷达负责纵向测量，摄像头负责目标分类和横向判断，再通过目标关联算法把两者的检测结果融合成同一份目标列表。如果只靠单一传感器，要么雨天晚上识别不出行人，要么晴天白天把路边金属路牌误判成障碍物。融合并不是凑热闹，而是用两套物理原理完全不同的传感器互相兜底。1.2 从目标到风险：看AEB是怎么“下决心”的感知端输出的是目标列表，每个目标带着距离、相对速度、横向偏移、目标类型、存在概率等一堆信息。但这些信息不会直接被用来踩刹车，它们要先经过一个决策链：第一个环节是目标筛选。系统把护栏、路牌、对向车道车辆、静止的高大障碍物等信息放进场景模型里，排除掉那些不在本车行驶通道内的目标，留下潜在威胁。第二个环节是轨迹预测。系统要判断这个目标接下来怎么动。前车是正在减速还是匀速？行人是在横穿还是站在路边不动？预测越准，决策越从容。可惜预测永远有误差，所以系统必须给误差留余量。第三个环节是风险评估。根据本车速度、目标距离、相对速度算碰撞时间，再结合本车能达到的最大减速度，判断我现在刹车来不来得及。如果来不及，就要触发系统介入。最后才是执行端发出制动请求。制动请求会发给ESP或底盘域控制器，由它分配制动力到四个轮子，同时点亮刹车灯、收紧安全带、弹出仪表报警。这条链路每多一层，就多一点延迟，但也多一层安全保障。系统设计时必须对每一步的延迟做预算，比如感知40毫秒、融合20毫秒、决策10毫秒、执行30毫秒，全链路算下来，从目标出现到最后制动器响应，100到200毫秒是常见量级。别小看这100多毫秒，在高速场景下可能意味着几米的差距。1.3 功能边界：AEB不是神，也不是保险杠很多刚接触AEB的人容易把它神化，觉得有了这个功能就不会撞车。实际做功能开发的人都知道，AEB的设计目标从来不是“绝对避免碰撞”，而是“最大程度降低碰撞速度”。欧洲很多主机厂在宣传时也说得比较保守，AEB能处理的场景、速度区间都有严格限制，超出边界它就是一套不启动的系统。比如前方车辆静止但本车速度超过系统标定上限，或者行驶在有侧向坡度的弯道里，传感器的视线被前车遮挡，再或者暴雨天气雷达多径反射导致目标跳变严重，这些场景下AEB都可能失效。开发者要做的不是让系统在所有场景下都能刹住，而是明确画出系统的工作边界，在边界内把性能做扎实，同时用失效降级策略保证任何情况下都不能因为误触发造成更大的危险。AEB还有一个容易被忽略的定位：它是驾驶员的辅助，不是替代。所以我一直跟团队说，功能标定的核心哲学是“不要打扰”。如果系统动不动就无预警地来一脚重刹，那驾驶体验会很差，也会让驾驶员逐渐丧失对系统的信任，紧急时刻反而不敢依赖它。2. 那一秒钟的决定：碰撞风险评估与制动策略的核心逻辑如果说AEB的骨架是传感器加执行器，那它的灵魂就是决策层里的碰撞风险评估算法。AEB一个完整的判断周期往往只有几百毫秒到一秒多，在这么短的时间里，系统要从大量目标中锁定最危险的那个，并决定采取什么等级的动作，全靠一套逻辑严密的风险模型。2.1 TTC是什么：一切决策的锚点讨论AEB绕不开TTC，全称Time To Collision，碰撞时间，定义为本车与前方目标按当前相对速度和相对距离推算，预计发生碰撞所需的时间。计算公式很简单：TTC = 相对距离 / 相对速度这里相对速度是本车速度减去目标速度，也就是接近速率。如果相对速度小于等于0，说明本车不比目标快，没有逼近趋势，系统不会做干预。当TTC越小时，碰撞风险越高。举一个具体数据例子。假设本车以72km/h行驶，前方有一辆静止的故障车，相对距离是40米。72km/h换算成20m/s，那么TTC = 40 / 20 = 2秒。这2秒里系统要完成目标确认、风险评估、驾驶员警告、部分制动、全力制动这一整套动作。看起来充裕，实际上考虑到感知延迟和执行延迟，留给策略真正做决定的时间也就是1.5秒左右，非常紧张。我经常用超车场景做类比帮助新人理解TTC：你在高速上准备超越一辆慢车，发现对面车道有来车，你用两车距离除以相对速度，心里估摸还有几秒会相接，然后判断现在超不超。AEB做的事情本质上跟你的本能一样，只不过它每时每刻都在算，而且算得比你快、比你准。下面用一段简化的Python示例演示TTC计算与分级决策的基本逻辑，实际工程里的代码比这复杂得多，但核心思路就是这样：def compute_ttc(relative_dist, relative_speed): # relative_speed > 0 表示本车速度大于目标，正在逼近 if relative_speed <= 0: return None # 不存在碰撞风险 return relative_dist / relative_speed def brake_decision(ttc, ego_speed): if ttc is None: return "no_action" if ttc < 1.0: return "full_brake" if ttc < 1.8: return "partial_brake" if ttc < 2.6: return "warning" return "no_action"这个逻辑只是示意，真实的工程代码不会用这么死板的固定阈值，但可以帮新手理解基本思想：TTC越小，输出的制动等级越高。2.2 分级制动策略：预警、部分制动、全力制动的配合实际量产车的AEB几乎不会一上来就全力制动，因为那既不安全也不舒适。行业里普遍采用分级策略：第一级是预警。当TTC进入设定阈值，比如2.6秒左右，系统会在仪表或HUD上弹出报警图标，同时发出声音提示，目的是唤醒驾驶员，让他赶紧接管油门刹车。报警本身不产生制动力。第二级是部分制动。如果驾驶员仍然没有反应，TTC继续降低到1.8秒附近，系统会主动建立制动压力，产生约0.3g到0.4g的减速度。这个力度的作用是提前降低车速，争取更多反应时间，同时通过顿挫感引起驾驶员注意。第三级是全力制动。当碰撞已经无法避免，TTC跌破1.0秒甚至更小的阈值，系统会请求最大减速度，目标是把碰撞能量降到最低。正常情况下，AEB全力制动的减速度可以做到接近车辆物理极限，有些车型在良好路面甚至能到1g以上。用表格描述更直观：制动等级典型触发TTC减速度范围主要目的预警2.6s左右0唤醒驾驶员，提前接管部分制动1.8s左右0.3g ~ 0.4g降速、提示、争取时间全力制动1.0s左右最大可达1g尽量减轻或避免碰撞为什么要分级，不直接一脚刹死？这里有两个层面的考虑。先谈安全性：高速行驶时如果轮胎制动力瞬间拉满，车辆可能出现车轮抱死或甩尾，对驾驶员和后方车辆都是危险；再谈乘员体验：毫无预兆的全力制动会让车上乘员猛烈前倾，轻则不适重则受伤，对颈部的伤害尤其明显。分级制动的逻辑是给驾驶员留出接管窗口，只有确认驾驶员“真的不管了”，系统才会逐步加大介入力度。2.3 置信度融合：雷达说“目标存在”但摄像头说“没有”，听谁的AEB决策绕不开的一个难题是传感器不一致。雷达在前方检测到一个反射点，摄像头却没识别出任何目标，怎么办？如果直接采信雷达，可能会在路过的铁箱、桥下悬挂物前面突然刹车；如果直接忽略雷达，又可能在夜间低照度场景下漏掉真实行人。工程上的做法是计算目标的“存在概率”和“危险概率”，再把这两个概率映射到决策逻辑里。比如雷达置信度高但摄像头没有确认，系统可能把目标标记为“待确认”，只做预警，不做制动；如果雷达和摄像头都确认目标，则进入完全激活的AEB判定。如果是行人目标，由于身份特殊，决策逻辑会更谨慎，完全依赖单一传感器触发制动的条件会更苛刻。这背后还牵扯到整车对安全等级的分级：一个传感器确认目标时，系统默认置信度较低，允许降级为报警；双传感器都确认，置信度高，可以触发制动。这种“冗余触发”策略的目的，是在保证安全性的前提下，最大限度降低误触发概率。2.4 本车状态与路面附着：同样的TTC，不同结论同样一个TTC值，在干燥柏油路和雨后湿滑路面上的处理方式完全不同。高速行驶时如果路面附着系数低，一上来就请求大减速度可能导致车轮打滑，车辆失控。制动策略要和车辆的稳定控制功能联动。比如系统估算当前路面附着系数只能支持0.5g的减速度，那么它在评估“来不来得及刹停”时，就会用0.5g而不是1g来算，如果发现刹不住，就提前进入预警和制动请求，而不是等到TTC跌破阈值才做动作。所以AEB开发通常会定义多个不同的状态模型，分别对应高附、低附、冰雪等工况，不同模型里同一套TTC阈值映射出的制动等级是有差异的。此外，车辆本身是转弯还是直行也影响决策。转弯时前方目标的横向运动趋势会更强，系统需要结合横摆角速度、方向盘转角等信息判断目标是否真的会撞上，这也是防止弯道护栏误触发的重要一环。3. 从标定到调参：工程里真正磨人的部分算法和策略搭建起来之后，真正的硬仗在标定。AEB标定是一项极度依赖数据、经验和耐心的系统工程。我见过不少拓扑设计得很漂亮的方案，一到实车标定就被各种边缘场景打回原形。原因其实很简单：真实世界里的场景分布是长尾的，标定做得好的团队，本质上是把那根长长的尾巴梳理得足够顺。3.1 标定的本质：在误报与漏报之间反复走钢丝做AEB标定，首先要接受一个现实：误报和漏报是一对无法同时降到零的矛盾。如果你把触发条件调得很激进，那确实能在很多真实碰撞场景中自动刹住，但伴随而来的是路边的铁皮、路面接缝、迎面对向车辆的误触发，这些误动作可能带来追尾，比漏报更麻烦。反过来，如果调得保守，误报少了，但真实碰撞里系统反应又太慢，评测成绩也不好看。标定工作就变成了一项在两者之间找平衡点的艺术。实际操作中，团队会根据功能安全目标定一个误报率上限，比如某车型要求每万公里误触发不超过多少次，再在这个约束下尽可能提升对真实危险场景的检测率。理解了这个逻辑，你就明白为什么很多标定工程师手机里存着大量“诡异触发”的短视频——每一个误报案例都价值连城，它们是调整阈值最直接的证据。3.2 关键标定参数的量级与调整手感标定阶段反复磨的参数主要有这几类：各级制动触发的TTC阈值、目标横向重叠比例、目标类型权重、感知延迟补偿量。这里给出一些常见经验量级，具体数值因车型、传感器配置和法规目标而异，但也足够让你理解量级关系。预警触发TTC通常设在2.2到3.0秒之间；部分制动触发TTC在1.5到2.0秒；全力制动触发TTC在0.8到1.2秒。这些值看起来只是几个数字，实际上每个数字背后都是上百条测试数据的积累。调整手感上，我个人的经验是：预警阈值可以放得稍微宽一点，多响警报顶多遭人嫌弃，但部分制动和全力制动阈值要慎之又慎，每改动0.1秒都可能带来完全不同的路面表现。目标横向重叠度也很关键。所谓重叠度，指本车行驶轨迹与目标在横向上重合的比例。如果只是车头一角扫过路边停着的车，横向重叠率低，系统不该触发全力制动；如果正对目标尾部，重叠率接近100%，那肯定要重点响应。这个参数的标定难点在于如何定义相对横向位置，它通常要经过目标轨迹预测模块来估算。还有一个容易被忽视但影响巨大的参数：感知延迟补偿。从传感器探测到目标，到决策层收到信息，再到制动器真正建压，中间每条链路都有延迟。如果你不在风险评估模型里把延迟折算进去，系统在高速场景下会晚半拍，导致实际减速度请求不足。工程上常用的做法是给目标的纵向位置和速度做前向预测补偿，把几十到上百毫秒的延迟当成一个可估的未来提前量。下面用一个更贴近实际思路的伪代码展示延迟补偿对决策的影响：def compensate_delay(target_dist, target_speed, delay): # 在 delay 秒后，目标相对距离会因相对速度而减小 compensated_dist = target_dist - target_speed * delay return max(compensated_dist, 0)3.3 感知不确定性的处理：同样一个目标，置信度不是恒定的感知模块给出的目标置信度不是一个固定值，它会随环境动态变化。夜间摄像头图像质量差，行人检测置信度会明显掉下来；雨天雷达回波被地面水膜反射干扰，目标位置抖动变大。如果标定时不看这些置信度变化规律，只在白天干路面上标定，系统一到恶略天气就会表现得不可控。合理的做法是把置信度作为决策的一个权重因子：高置信度目标可以更早触发制动，低置信度目标则要求更多确认条件。比如白天行人识别置信度0.9，夜间可能只有0.6，那么系统在夜间就需要更近的触发距离，或者等待雷达也确认目标后才允许制动。这种动态调整逻辑看着容易，实车上逐个场景调过去的工程量非常大。另外，多目标场景下如何选主目标也常常让新手头疼。原则是选择对自车威胁最大的目标，但“威胁最大”不只是距离最近，还要结合相对速度、横向位置、目标类型来综合判断。比如近处有一个静止护栏，远处有一个快速接近的行人，谁更危险？很多时候答案并不是直觉上那个最近的。选错了主目标，AEB就可能跟空气较劲，真正的危险目标被晾在一边。3.4 制动与底盘控制协同：刹得稳比刹得住更难AEB的最终执行端是底盘系统，刹得住、刹得稳是两码事。制动请求发出去之后，ESP要负责轮缸建压、制动力分配，还要监测每个车轮的滑移状态。如果路面两边附着系数不同，左右轮制动力不一致，车辆会产生横摆，这时候就需要ESP介入修正。整套协同做不好，可能出现刹停瞬间车身猛烈抖动、点头严重甚至跑偏的现象。我们曾经在测试中遇到一个典型案例：车辆触发AEB全力制动后，车速减到接近零的瞬间，车身出现一次明显的前后顿挫，有点像手动挡车急刹熄火那一下。后来排查发现，是制动力在低速段切换时，液压控制阀响应时序和轮速信号错位，导致制动力波动。这类问题只能在测试中反复复现，然后联合底盘团队一点一点调整控制参数。这里也提一个实用建议：不管你做策略还是做感知，一定要抽时间去看底盘制动控制的数据，理解ABS和ESP怎么协调轮缸压力。那些能把AEB标定做得又快又准的工程师，普遍都是对底盘控制有足够理解的，因为他们知道每次策略改动最终会怎么映射到轮端动作上。4. AEB的考试周：测试方法、经典失效案例与排查思路AEB开发有一半时间在路上。在我看来，AEB测试就像给学生排考试周，场景设计、工具准备、数据打分，环环相扣。测试做得扎实，问题暴露得早，标定迭代效率就高；测试做得敷衍，后面到了用户手里就会以各种匪夷所思的方式爆发。4.1 主流测试场景：从最基础到最刁钻AEB测试有一整套基本的场景库，覆盖了日常道路的主要碰撞形态。前车静止场景是最基础的，本车以不同初速度接近一个静止目标车，验证系统能否在距离前车足够远时完全刹停。前车慢行场景模拟的是市区跟车，前车以20km/h左右匀速行驶，本车以更高速度接近，观察系统能否减速到与前车同步。前车急减速场景则更严苛，两车保持安全距离行驶，前车突然大力制动，本车AEB必须快速响应，避免追尾。行人横穿场景也就是大家常说的“鬼探头”，对感知和决策的实时性要求极高。骑行者场景因为目标尺寸小、运动轨迹灵活，对识别算法的挑战更大。这些场景的测试速度区间通常从低速一直做到系统标定上限，横向上还要做不同重叠率组合。一个完整的AEB测试矩阵往往包含几百上千条测试用例，每一条用例在测试场里跑下来，加上准备和复跑时间，工作量非常可观。4.2 测试工具准备：靶车、假人与数据采集AEB测试离不开专业工具：用于扮演障碍车的靶车，用来扮演行人的假人，还有用于扮演骑行者的自行车平台。靶车不是普通租来的车，它的车身覆盖着专门的材料，视觉上跟真实车辆接近，同时雷达反射截面也要跟真实车辆相当，这样才能骗过两个传感器。假人更讲究，成年人形、儿童形、坐轮椅形，各有各的体态和移动规律，而且臀部、膝关节等位置还要有适当的热/雷达反射特征，否则感知系统会识别异常。数据采集是测试中绝对不能省的一环。车端需要同步记录CAN总线信号、雷达和摄像头原始数据、视频流、GPS轨迹。这里最容易被忽视的是时间同步。所有数据源的时钟必须严格对齐，否则你对着视频看到一个目标，再看CAN数据却对不上号，整个排查过程会非常痛苦。建议在测试开始前先做一次完整的数据链路核查，确认时间戳同步机制正常，再开跑。评价一次测试结果时，我习惯看重复性。同样一条用例，今天跑三遍，三次结果可能有细微差异，因为风速、路面温度、传感器噪声都会影响系统行为。只要结果落在合理范围内，就不必纠结某一次是刹住了还是减了速；但如果同一条用例出现一次刹住一次没刹住的极端差异，那一定存在感知或决策的不稳定因素，需要重点排查。4.3 经典失效案例与排查速查表这些年我整理过不少AEB实车测试中的经典失效模式，很多都很有代表性，这里列一个速查表，方便你遇到类似问题时有排查方向可以参考。失效现象可能原因排查方向隧道出入口偶发误触发摄像头曝光突变丢帧、感知目标短暂丢失检查摄像头自动曝光策略、融合模块状态机雨天前方无车却报警雷达多径反射、地面水膜产生虚假回波调低低置信目标权重、增加目标确认条件路过金属井盖触发制动雷达把井盖当成静止障碍物增加目标横向生命周期判断、引入连续帧特征夜间行人漏报不制动摄像头置信度下降、雷达反射弱调整夜间置信度阈值，增加雷达权重弯道处对路边护栏误触发轨迹预测未考虑弯道曲率引入本车横摆角速度修正目标运动模型前车刚起步时出现误制动目标分类从静止切换为运动延迟优化目标状态机，增加启动抑制逻辑排查这类问题的通用思路是先复现，再把感知原始数据、决策日志、执行请求三段数据拉出来做时间对齐回放，找到究竟是哪一段链路先出现异常。我见过很多团队卡在某个问题上很久，原因是花了大量时间调决策参数，后来才发现根源是摄像头标定偏移导致的感知位置偏差——所以排查时一定不要预设结论，先用数据说话。4.4 结果评价与验收心得AEB测试的评价指标通常就三个维度：漏报率、误报率、制动舒适性。漏报率衡量真实危险场景中有多少没触发，误报率衡量无风险场景中有多少错误干预，制动舒适性则通过减速度变化率、车身姿态等数据来量化。这三个指标互相牵制，验收时要放到一起看。我个人的一条心得是：验收AEB性能，不能只看某条测试用例过了没有，而要看整个测试矩阵的成绩分布。比如有一项高速前车静止用例过了，但低速行人横穿场景成绩波动大，这种偏科式表现往往意味着某个感知场景的置信度处理还有问题。以偏概全式地宣告“AEB标定完成”，后面量产了大概率会被用户教做人。另外，AEB实车测试的安全管理也很重要。做高速场景时，靶车要有远程控制急停机制，测试车辆要配备紧急制动开关，驾驶员必须是经验丰富的测试员。这不是小题大做，系统总有失效的那一刻，测试安全的底线永远不能松。做AEB这几年，我最大的体会是：这东西就像一个沉默的副驾，平时默默看着路，关键时刻拉你一把。它不完美，会误判，会误报，但每一次成功刹停背后都是无数工程师对策略逻辑的精雕细琢。最后分享一个我自己一直保持的习惯：每次回看测试录像，先看驾驶员表情，再看车外视角。因为AEB不只是在刹车上做文章，它真正改变的是驾驶员对一台车的信任感——而信任，才是主动安全功能最值钱的产出。