一辆车以 72km/h 的速度跟在货车后面行驶前车突然急刹。系统在 0.3 秒内识别出碰撞风险仪表盘弹出红色警告随后制动系统自动介入在最后阶段把车速降了下来。整个过程里驾驶员甚至还没来得及把脚从油门上移开。这不是电影特效而是 L2 级辅助驾驶中最基础也最关键的安全功能——AEBAutomatic Emergency Braking自动紧急制动的标准工作流程。很多朋友讨论辅助驾驶聊的都是“能不能识别红绿灯”“能不能自己变道超车”但真正决定一辆车安全底线的恰恰是这套看起来不那么性感的紧急制动系统。辅助驾驶行业竞争到今天已经很少再为一个“识别准不准”的问题打口水仗了。真正把头部玩家区分开的是一个更底层的问题系统是否理解真实世界的物理规律。前车刹车在摄像头眼里不应该只是一个“矩形框在变小”而是一个有质量、有惯性的物体正在减速它的运动受轮胎抓地力、路面湿滑程度和制动系统响应时间的共同约束。能够理解这一切的 AI行业里叫它物理AIPhysical AI。回头看今天的辅助驾驶市场我认为它已经进入一个“三国时代”。三股技术路线——纯视觉、多传感器融合、物理AI/世界模型——正在用不同的工程路径争取同一个终点让车辆在真实物理世界里安全、平顺地行驶。这篇文章不打算重复“辅助驾驶功能分类”之类的百科内容而是从工程师视角把两个问题讲透物理AI到底改变了什么以及作为安全底线的 AEB 系统其核心算法与工程实践应该如何落地。1. 辅助驾驶的“三国时代”三条路线在争什么1.1 为什么说是“三国”而非“百家争鸣”早期辅助驾驶的玩家很多方案五花八门有做单目视觉的有做毫米波雷达的有坚持激光雷达路线的也有走 V2X 车路协同的。经过这几年的市场淘汰和技术收敛主流方案逐渐集中到三类。第一类是纯视觉路线。核心思路是只靠摄像头获取图像信息用深度学习模型完成目标检测、车道线识别、可行驶区域分割再通过时序信息估计距离和速度。这条路线最大的优势是传感器成本低、硬件统一迭代周期短数据采集也相对容易。它的挑战在于对极端天气、光照变化和非常规障碍物的适应能力比如大雨、逆光、侧翻的货车、路面掉落的散落物。第二类是多传感器融合路线。摄像头负责识别语义毫米波雷达负责测距测速激光雷达负责三维空间建模三者输出在空间和时间上对齐后再交给融合模块做目标级或原始数据级融合。这条路线冗余度高单一传感器失效时系统仍然可以工作但硬件成本高、标定复杂高精地图的维护也是一个长期负担。第三类是物理AI/世界模型路线。它与前两类的区别不在传感器而在算法范式。前两类方案本质上还是“感知—预测—规划—控制”的模块化架构模型负责把传感器数据变成结构化信息规则负责做决策而物理AI路线试图让模型直接理解场景中的物理规律比如理解一辆货车急刹时需要多长的制动距离理解雨天路滑时附着系数会下降理解一个小孩从路边车辆后方突然跑出时遮挡关系会怎样变化。它可以用在端到端模型里也可以作为约束条件嵌入传统模块化架构中。1.2 三条路线的关键对比维度纯视觉路线多传感器融合路线物理AI/世界模型路线核心传感器摄像头为主摄像头毫米波雷达激光雷达多模态融合依赖大规模数据地图依赖轻地图或无地图高精地图局部实时构建算法范式端到端/大模型模块化规则模型数据驱动物理约束最大优势成本低、迭代快冗余度高、可靠性强泛化能力强理解物理规律主要挑战极端天气、长尾场景成本高、地图维护难算力要求高、可解释性弱1.3 竞争的本质从“看见”到“理解”传统辅助驾驶系统的工作方式可以概括为先识别物体再计算距离最后套用规则决策。这个流程在绝大多数场景下是有效的但一旦遇到超出规则库的 edge case系统就会暴露出“只看见、不理解”的问题。物理AI想解决的正是这个“理解”问题。它要求系统不仅知道“前方有一个矩形框”还要知道“这是一个正在减速的物体它的速度变化率是多少它和我的相对距离与相对速度在当前路面条件下是否构成碰撞风险”。这种理解能力不会凭空产生它来自对物理世界运行规律的建模要么体现在传感器融合算法里要么体现在神经网络的训练和约束设计里。这也解释了为什么“三国时代”的竞争不是互相消灭而是互相渗透。纯视觉路线需要引入更多物理约束来应对长尾场景多传感器融合路线正在把更多决策逻辑从规则转向模型物理AI路线也离不开前两者积累的感知工程能力。真正决定胜负的不是传感器数量不是某一个模型的精排分数而是谁能更早、更稳定地在真实道路上理解物理世界。2. 物理AI让机器理解真实世界的运行规律2.1 传统AI与物理AI的差别传统AI在智能驾驶里做的事情本质上是模式识别。给一张图像模型告诉你这里面有一辆车、一个行人、一条车道线给一段点云模型告诉你障碍物的轮廓和位置。这些任务解决的是“是什么”和“在哪里”并不涉及“接下来会发生什么”以及“为什么会这样发生”。物理AI向前走了一步。它把牛顿力学、运动学、光学成像规律、材质与摩擦特性等物理知识引入AI系统让模型在识别物体之后还能估计物体的质量量级、运动趋势、加速度上限以及自身的制动能力边界。一个形象的类比是传统AI像一个看图写标签的实习生能告诉你图片里有什么物理AI像一个有多年经验的老司机不仅知道前面有车还能基于前车的尾灯状态、车身姿态变化、路面湿滑程度预判它接下来大概率会怎么做以及自己此时猛踩刹车会不会失控。2.2 物理AI在智能驾驶中的三种体现第一种体现是从传感器数据中恢复物理量。摄像头图像是二维的要得到距离需要单目测距模型毫米波雷达直接输出目标距离和径向速度激光雷达输出三维点云。这些原始数据经过融合最终生成包含位置、速度、加速度、航向角、尺寸等信息的动态目标列表。这个过程不是简单拼接而是用物理运动模型对传感器噪声做约束让输出结果符合真实世界的运动规律。第二种体现是用物理约束限制预测和决策。没有物理约束的模型可能会预测出一个行人 0.5 秒内横向移动 5 米的极端场景物理AI会用人体运动学上限约束这个预测同样AEB决策也不会只看“能不能刹住”而是会同时计算“需要多大减速度”和“路面能给多大减速度”。当需求减速度超过物理极限时系统就必须采取更早、更强的干预。第三种体现是用世界模型和物理引擎增强泛化能力。在仿真环境里可以生成真实世界里很少见的极端场景比如对向车辆越过实线、高速上突然掉落轮胎、夜间横穿马路的行人。把物理规则编码进仿真引擎再让模型在这些场景里反复训练最终系统遇到类似真实场景时是从物理原理层面理解危险而不是匹配某个见过的数据样本。2.3 为什么AEB是物理AI的最佳落地场景AEB 是所有辅助驾驶功能里最依赖物理量计算的一个。它不关心目标是什么颜色、什么品牌它关心的是三件事相对距离、相对速度、以及当前路面能提供多大制动力。这三件事恰好都是物理量。相对距离和相对速度决定碰撞时间 TTCTime To Collision路面附着系数和车辆质量决定最大可执行减速度。AEB 的全部决策逻辑本质上就是在这两组物理量之间做权衡。正因为 AEB 的物理属性如此强烈它成了观察“物理AI如何改变辅助驾驶”的最佳窗口。一个能做好 AEB 的系统不一定是最聪明的系统但它一定是对物理世界理解最扎实的系统。3. L2级辅助驾驶与AEB从功能定义到安全底线3.1 L2级到底是什么L2级辅助驾驶的经典定义是系统能够同时提供转向控制和纵向控制加速与制动但驾驶员必须始终监控驾驶环境并随时准备接管车辆。换句话说系统可以帮你打方向盘、帮你踩刹车但出了问题的责任主体仍然是驾驶员。这是非常关键的一个边界。L2 不是自动驾驶它的一切功能设计都建立在“驾驶员随时可能接管”的假设之上。这也是为什么 AEB 在 L2 阶段就被强制要求因为在驾驶员走神、反应不及时的场景里AEB 是系统在责任移交窗口内唯一能主动降低碰撞风险的手段。3.2 AEB在ADAS功能矩阵中的位置现代车辆的主动安全功能一般按“警告—辅助—紧急介入”三个层级设计。最低层级是 FCWForward Collision Warning前向碰撞预警只做声光提醒中间层级是 ACCAdaptive Cruise Control自适应巡航在正常行驶中自动保持车距最高层级就是 AEB在系统判断碰撞无法避免时主动施加制动力。功能缩写主要作用是否主动制动自适应巡航ACC按设定车速和车距自动跟车常规制动不强刹前向碰撞预警FCW提醒驾驶员有碰撞风险否自动紧急制动AEB系统自动紧急制动是电子稳定控制ESC防止车辆打滑失控选择性制动从这张表可以看出AEB 是主动安全链条里最激进的一环。它不是帮驾驶员减轻操作负担而是在判断即将发生碰撞时代替驾驶员执行避险动作。3.3 AEB为什么被称为安全底线AEB 被称为安全底线原因很简单所有高级辅助驾驶功能都可以被关闭唯独 AEB 在很多国家已经变成新车出厂标配的强制性要求。它的价值不是提升驾驶体验而是减少碰撞事故尤其是追尾事故和行人碰撞事故。工程上的一个共识是AEB 的标定必须极端谨慎。漏触发该刹车时没刹会导致碰撞后果严重误触发不该刹车时突然急刹虽然不直接导致碰撞但会造成后车追尾、用户恐慌甚至让驾驶员主动关闭整个 AEB 系统。如何在这两者之间找到平衡是 AEB 工程实践的核心命题。4. AEB系统核心技术原理解析4.1 系统架构总览一个完整的 AEB 系统可以拆成四个部分感知层、预测层、决策层、执行层。理解这个分层就理解了 AEB 的全部运行逻辑。感知层的任务是回答“前方有什么障碍物”输出目标列表预测层的任务是回答“这个障碍物接下来怎么运动”输出目标在未来数百毫秒内的轨迹预测决策层的任务是回答“现在要不要制动、制动多猛”输出 AEB 场景模式与目标减速度执行层的任务是回答“怎么把减速度变成车轮制动力”通过 ESP、VCU 等底盘控制器完成建压和制动。层次输入输出典型技术感知层摄像头图像、雷达点云、毫米波数据目标位置、速度、类别目标检测、多传感器融合预测层结构化目标列表目标轨迹预测卡尔曼滤波、交互式轨迹预测决策层相对距离、相对速度、自车车速AEB等级、目标减速度TTC计算、阈值判断执行层减速度请求实际制动压力ESP、VCU、主动制动控制4.2 感知层摄像头、毫米波雷达、激光雷达如何协作摄像头负责语义理解能识别目标类别是车还是人、是静止物还是动物。但单目摄像头测距精度有限夜间和逆光场景容易失效。毫米波雷达不受光照影响能直接测出目标的相对距离和径向速度但对静态物体和横向移动目标的区分能力弱。激光雷达可以输出高密度三维点云空间建模能力最强但在雨雪雾天气下性能衰减明显。在典型的融合方案中系统会先用空间对齐和时间同步把三种传感器的数据放到同一个坐标系下再做目标级融合或特征级融合。目标级融合相对简单每个传感器独立输出目标列表融合模块通过匈牙利算法等做目标匹配再对距离、速度做加权估计。特征级融合则是在更早的数据层面融合精度更高但工程复杂度也更高。AEB对感知层有一个特殊要求必须在极端情况下仍然能输出稳定的目标。所以即使某个传感器短暂失效系统也要能降级运行不能直接丧失AEB能力。4.3 决策层TTC计算与分级制动逻辑AEB 决策的核心物理量是 TTC即碰撞时间。它的定义是当前相对距离除以当前相对速度TTC D / V_rel其中 D 是自车到前方障碍物的相对距离V_rel 是相对速度自车速度减去前车速度单位为 m/s。当 V_rel 大于 0 时表示自车比前车速度快距离正在缩短此时 TTC 越小碰撞风险越高当 V_rel 小于等于 0 时表示没有靠近趋势通常不触发 AEB。但 TTC 只是第一个判断条件。真实工程中还会引入“需求减速度”作为第二个维度即假设从当前时刻开始以恒定减速度制动刚好避免碰撞所需的最小减速度a_req V_rel² / (2D)这个公式来自匀减速运动学 v² v0² 2as 的变形。它比 TTC 更能反映车辆的实际制动能力因为如果 a_req 超出了车辆当前路面条件下的最大制动能力那么即使 TTC 看起来还有余量碰撞也许已经无法避免系统需要更早、更猛地介入。有了 TTC 和 a_req决策层就可以定义分级制动策略。常见的分级是FCW 阶段TTC 较大系统先做声光警告请求驾驶员接管。此时不主动制动避免打扰正常驾驶。部分制动阶段TTC 继续减小驾驶员没有反应系统施加一个中等减速度比如 3 到 5 m/s²目的是降低碰撞速度同时给驾驶员留下反应时间。全力制动阶段TTC 已经很小系统请求最大减速度尽可能避免碰撞或显著降低碰撞速度。需要强调的是阈值参数是整车厂根据自己的车型、制动系统能力、用户画像和安全策略标定出来的没有全局统一数值。本文用 0.6 秒、1.2 秒、2.6 秒作为示例阈值仅用于教学演示。4.4 执行层制动系统介入的工程约束决策层输出的是“目标减速度”但底盘系统从收到请求到真正建立制动压力有物理延迟。纯液压制动系统通常需要约 200 到 400 毫秒来建立压力如果系统提前预填充制动压力这个时间可以缩短到 100 毫秒以内。所以实际 AEB 执行策略会做“预制动”即在高风险场景下先让制动系统进入预备状态提高管路压力但还没有真正产生制动力。一旦决策层发出全力制动请求系统可以在最短时间内达到目标减速度。这个细节直接影响到“能不能刹住”。执行层还要考虑平顺性和稳定性。全力制动时减速度可能达到 8 到 10 m/s²接近普通驾驶员极限刹车水平。如果路面湿滑必须通过 ABS防抱死制动系统调节各轮制动力防止车轮抱死失去转向能力。这也是 AEB 与 ESC、ABS 深度耦合的原因。5. 环境准备与工程前置条件5.1 本文技术路径真实车端 AEB 系统运行在 AUTOSAR 或 Linux 环境下开发语言以 C/C 为主需要接入 CAN 总线、传感器驱动和底盘控制接口。直接复现一套真实 AEB 工程对大多数读者来说门槛太高。因此本文采用一种更轻量的方式用 Python 把 AEB 决策层的核心算法实现出来输入模拟的毫米波雷达输出也就是前方目标的相对距离和相对速度输出对应的 AEB 状态和决策结果。这个决策逻辑与真实车端算法在原理上是一致的只是省略了传感器信号处理、通信协议和底盘执行控制。5.2 环境要求本文代码只使用 Python 标准库不需要安装 numpy、opencv 等第三方依赖。建议使用 Python 3.8 及以上版本操作系统不限。代码在本地直接运行python aeb_demo.py5.3 数据约定在仿真中我们假设已经拿到了目标级融合后的数据包含两个关键字段relative_distance自车到前车的相对距离单位米relative_velocity相对速度由自车速度减前车速度得到单位 m/s当 relative_velocity 为正时表示自车比前车快距离在缩短为负时表示前车更快距离在拉大为 0 时表示两车速度相同距离保持不变。6. AEB决策算法完整实现6.1 项目文件结构aeb_demo/ ├── ttc_calculator.py # TTC 与需求减速度计算 ├── aeb_decision.py # AEB 分级决策逻辑 └── aeb_demo.py # 场景仿真主程序6.2 TTC 计算模块文件路径aeb_demo/ttc_calculator.py TTC 计算模块 本模块负责 AEB 决策所需的两个核心物理量计算 1. TTCTime To Collision碰撞时间 2. 需求减速度假设恒定减速避撞所需的最小减速度 注意真实车端算法通常使用 C 实现这里用 Python 做教学演示。 import math def calc_ttc(relative_distance: float, relative_velocity: float) - float: 计算碰撞时间 TTC。 公式TTC D / V_rel 参数说明 - relative_distance: 相对距离单位 m - relative_velocity: 相对速度自车速度 - 前车速度单位 m/s 返回值 - 若存在碰撞风险返回 TTC 值秒 - 若相对速度 0返回正无穷大表示无碰撞风险 if relative_distance 0: return 0.0 if relative_velocity 0: return float(inf) return relative_distance / relative_velocity def calc_required_deceleration(relative_distance: float, relative_velocity: float) - float: 计算避免碰撞所需的最小减速度。 公式a_req V_rel^2 / (2 * D) 当相对速度 0 时两车没有靠近趋势所需减速度为 0。 当距离小于等于 0 时碰撞已经发生返回一个极大值表示必须全力制动。 if relative_distance 0: return 20.0 # 超过真实制动能力表示必须全力制动 if relative_velocity 0: return 0.0 return (relative_velocity ** 2) / (2.0 * relative_distance)代码中把 TTC 和需求减速度拆成两个独立函数原因是它们在决策层分别承担不同作用TTC 用于判断“还有多长时间会发生碰撞”需求减速度用于判断“需要多大力度的制动才能避免碰撞”。两者结合起来才能避免只看单一指标导致误判。6.3 AEB 决策模块文件路径aeb_demo/aeb_decision.py AEB 分级决策模块 根据 TTC、需求减速度和自车车速输出当前 AEB 状态。 from enum import Enum from ttc_calculator import calc_ttc, calc_required_deceleration class AEBLevel(Enum): NO_WARNING 0 # 无风险不介入 FCW 1 # 前向碰撞预警只提醒 PARTIAL_BRAKE 2 # 部分制动中等减速度 FULL_BRAKE 3 # 全力制动最大减速度 # 阈值参数仅用于教学演示 # 真实车型需要通过大量实车测试标定不能直接套用 TTC_FCW 2.6 # 低于该值触发 FCW 预警 TTC_PARTIAL 1.2 # 低于该值触发部分制动 TTC_FULL 0.6 # 低于该值触发全力制动 MIN_SPEED_AEB 4.0 # 自车车速低于该值时不介入避免低速误触发 MAX_CAPABILITY 7.0 # 假设当前路面最大可执行减速度单位 m/s^2 def aeb_decision(relative_distance: float, relative_velocity: float, ego_speed: float) - tuple: 根据相对距离、相对速度和自车车速输出 AEB 决策。 返回 (AEBLevel, 说明文本) # 低速保护车速很低时即使有风险也应优先交给驾驶员处理 if ego_speed MIN_SPEED_AEB: return AEBLevel.NO_WARNING, 低速工况AEB 不介入 # 计算决策所需的物理量 ttc calc_ttc(relative_distance, relative_velocity) a_req calc_required_deceleration(relative_distance, relative_velocity) # 不存在碰撞风险 if ttc float(inf) and a_req 0.0: return AEBLevel.NO_WARNING, 安全状态无碰撞风险 # 需求减速度超过车辆物理能力上限时判定为碰撞不可避免 # 此时即使 TTC 还大于阈值也应该提前进入预警甚至制动阶段 if a_req MAX_CAPABILITY and ttc TTC_FCW: if ttc TTC_FULL: return AEBLevel.FULL_BRAKE, 物理极限内无法避撞全力制动 if ttc TTC_PARTIAL: return AEBLevel.PARTIAL_BRAKE, 碰撞风险极高部分制动 return AEBLevel.FCW, 碰撞风险预警请求驾驶员接管 # 常规 TTC 分级 if ttc TTC_FULL: return AEBLevel.FULL_BRAKE, 碰撞即将发生全力制动 if ttc TTC_PARTIAL: return AEBLevel.PARTIAL_BRAKE, 高碰撞风险部分制动 if ttc TTC_FCW: return AEBLevel.FCW, 碰撞风险预警请求驾驶员接管 return AEBLevel.NO_WARNING, 安全状态这里的一个关键设计是引入MAX_CAPABILITY。假设当前路面最大可执行减速度是 7 m/s²那么当需求减速度超过 7 时说明系统只有把制动能力全部压上去才可能避开碰撞此时 AEB 必须立即进入更高级别的干预而不是继续等到 TTC 跌破阈值。真实工程里这个值不是固定常量它会根据路面附着系数估算动态变化雨天可能降到 4 以下干地可能是 8 以上。6.4 场景仿真主程序文件路径aeb_demo/aeb_demo.py AEB 决策算法场景仿真 构造几种典型驾驶场景模拟毫米波雷达输出的相对距离和相对速度 观察 AEB 系统的决策结果。 from ttc_calculator import calc_ttc from aeb_decision import aeb_decision def run_scenario(scenario_name: str, frames, ego_speed: float 20.0): 运行一个场景序列。 frames 是 [(relative_distance, relative_velocity), ...] 列表 每隔 0.1 秒采样一次。 print(f\n 场景{scenario_name} ) print(时间(s) 相对距离(m) 相对速度(m/s) TTC(s) AEB状态) for i, (dist, rel_v) in enumerate(frames): ttc calc_ttc(dist, rel_v) level, desc aeb_decision(dist, rel_v, ego_speed) # TTC 为无穷大时显示 -1便于阅读 ttc_display -1.0 if ttc float(inf) else round(ttc, 3) print(f{i * 0.1:6.1f} {dist:10.3f} {rel_v:12.3f} f{ttc_display:7.3f} {level.name} | {desc}) if __name__ __main__: # 场景1前车急刹 # 自车以 20m/s约72km/h行驶前车开始急刹 # 相对距离不断减小相对速度持续增大 front_car_brake [ (35.0, 0.0), (32.0, 1.0), (28.0, 2.2), (22.0, 4.0), (15.0, 6.5), (9.0, 9.5), (4.0, 13.0), (1.5, 17.5), ] run_scenario(前车急刹, front_car_brake) # 场景2匀速巡航 # 前车与自车速度一致相对距离保持 50m无碰撞风险 normal_cruise [ (50.0, 0.0), (50.0, 0.0), (50.0, 0.0), (50.0, 0.0), (50.0, 0.0), ] run_scenario(匀速巡航, normal_cruise) # 场景3极端切入 # 旁车快速切入且明显减速相对距离快速缩短相对速度快速增大 dangerous_cut_in [ (25.0, 0.5), (18.0, 3.0), (10.0, 7.0), (4.0, 12.0), (1.8, 18.0), ] run_scenario(他车侧向切入, dangerous_cut_in, ego_speed25.0)这个主程序其实是一个轻量级的仿真器。它按时间采样毫米波雷达的目标输出每次采样调用一次 AEB 决策函数输出当前时刻的 AEB 状态。真实车端就是把这里的循环换成 CAN 总线上周期性到达的传感器帧处理频率一般在 20Hz 到 50Hz 之间。6.5 运行方式在aeb_demo目录下执行python aeb_demo.py不需要额外安装依赖所有代码均使用标准库。7. 运行结果与效果验证7.1 预期输出运行后可以看到三段场景输出。以“前车急刹”场景为例预期结果是 场景前车急刹 时间(s) 相对距离(m) 相对速度(m/s) TTC(s) AEB状态 0.0 35.000 0.000 -1.000 NO_WARNING | 安全状态无碰撞风险 0.1 32.000 1.000 32.000 NO_WARNING | 安全状态 0.2 28.000 2.200 12.727 NO_WARNING | 安全状态 0.3 22.000 4.000 5.500 NO_WARNING | 安全状态 0.4 15.000 6.500 2.308 FCW | 碰撞风险预警请求驾驶员接管 0.5 9.000 9.500 0.947 PARTIAL_BRAKE | 高碰撞风险部分制动 0.6 4.000 13.000 0.308 FULL_BRAKE | 碰撞即将发生全力制动 0.7 1.500 17.500 0.086 FULL_BRAKE | 碰撞即将发生全力制动匀速巡航场景应该全程都是NO_WARNING这是因为相对速度始终为 0TTC 为无穷大需求减速度也为 0。如果它触发了任何制动说明决策逻辑出现了错误。极端切入场景里由于相对速度增长更快TTC 会更早跌破阈值AEB 会在更短时间内从 FCW 跳到全力制动这符合“侧向切入比前方减速更危险”的直觉。7.2 如何验证逻辑正确验证这套 AEB 决策逻辑是否合理可以从三个维度检查。第一是状态迁移是否符合预期。正常流程应该是 NO_WARNING → FCW → PARTIAL_BRAKE → FULL_BRAKE不应该出现从 NO_WARNING 直接跳到 FULL_BRAKE 的情况。因为分级的目的是给驾驶员留出反应时间如果跳过所有中间状态直接全力制动说明阈值设计或条件判断有问题。第二是低速保护是否生效。把 ego_speed 参数改成 3.0也就是自车速度低于 4 m/s那么即使前车距离极近系统也会输出 NO_WARNING。之所以保留这个保护是因为低速场景下驾驶员本人更容易通过刹车或转向避开碰撞系统频繁制动反而会造成差的体验。第三是物理极限判断是否合理。观察“前车急刹”场景中 0.5 秒到 0.6 秒的输出TTC 从 0.947 降到 0.308需求减速度从 5.01 m/s² 增加到 21.1 m/s²超过 MAX_CAPABILITY 的 7.0。所以系统在 0.6 秒输出全力制动这个判断是符合物理直觉的。7.3 从仿真到实车的差距这里必须提醒一点跑通仿真只是理解了算法骨架真实 AEB 工程还有大量本文没有覆盖的问题。首先是数据源问题。仿真的传感器数据是理想值真实毫米波雷达的输出有噪声、有跳变、有虚警。其次是传感器延迟问题从摄像头曝光到决策层拿到目标延迟可能超过 100 毫秒直接导致 TTC 计算不准确。再次是执行层延迟前面已经提到制动建压时间这个延迟在仿真中完全没有体现。所以一个仿真效果好到完美的 AEB 算法到实车可能依然会因为一个传感器标定偏差而频繁误触发。这也是为什么 AEB 的标定和验证需要大量的场地测试而不是只看仿真通过率。8. 常见问题与排查思路问题现象可能原因排查方式解决方案AEB 该触发时不触发TTC 阈值过小或目标丢失查看目标融合日志确认感知层是否持续输出有效目标增大 TTC 阈值检查雷达/摄像头标定AEB 频繁误触发目标误检、阈值过大回放误触发时段的感知输出确认是否把路牌、护栏误识别为障碍物提高目标置信度门槛调整分级阈值制动介入明显偏晚制动系统建压慢缺少预填充分析纵向控制链路延迟查看制动压力曲线增加预制动请求优化底盘冗余低速场景异常制动未加最低车速保护检查 AEB 决策输入的车速信号是否可靠增加车速阈值和挡位判断排除倒挡场景传感器信号跳变导致误判线束屏蔽不良或传感器老化查看 CAN 信号波形比对雷达点云连续性检查硬件增加滤波和有效性校验排查 AEB 问题有一条通用路径先判断是感知问题、决策问题还是执行问题。感知问题看目标列表是否连续且准确决策问题看 TTC 和减速度是否计算正确执行问题看制动压力能否快速建立。很多现场问题并不是算法不对而是传感器没有把准确数据送过来。9. 最佳实践与工程建议9.1 标定原则漏报与误报之间找平衡AEB 标定最核心的取舍发生在漏报和误报之间。漏报的后果是真实碰撞误报的后果是用户恐慌和后车追尾。工程界的普遍原则是FCW 阶段可以激进宁可多提醒几次也要让驾驶员尽早知道危险全力制动阶段必须谨慎因为突然的急刹本身也是一种风险系统只有在相当确信碰撞即将发生时才能触发。这个原则对应到代码里就是分级阈值的设计思路。FCW 阈值可以放宽用于提示FULL_BRAKE 阈值要收紧同时结合需求减速度和相对距离做双重确认而不是单看 TTC 一个指标。9.2 传感器冗余与失效降级AEB 是安全功能不允许因为单个传感器失效就整体退出。工程上要求至少两个独立的传感器都能测距测速当毫米波雷达失效时视觉单目测距精度下降决策层应该自动进入降级模式比如禁止全力制动只保留 FCW同时通过仪表盘提示驾驶员尽快维修传感器。这个降级逻辑在功能开发阶段就要设计好不能等实车出了问题再补。因为系统在某些极限场景可能同时丢失多个传感器的数据此时 AEB 必须给出一个安全默认动作比如维持 FCW 但降低制动等级而不是愣在那里什么都不做。9.3 测试验证体系仿真、HIL、实车AEB 的验证不是一次性的而是三层递进。第一层是纯软件仿真用大量真实路采数据和仿真场景验证算法逻辑。第二层是 HILHardware-in-the-Loop测试把真实控制器接到仿真环境里验证的是软件在真实硬件上的运行时间、通信时序和稳定性。第三层是实车测试在封闭测试场完成从低速到高速的各种工况测试包括前车静止、前车缓行、 物理AI与AEB：L2级辅助驾驶安全底线算法解析
一辆车以 72km/h 的速度跟在货车后面行驶前车突然急刹。系统在 0.3 秒内识别出碰撞风险仪表盘弹出红色警告随后制动系统自动介入在最后阶段把车速降了下来。整个过程里驾驶员甚至还没来得及把脚从油门上移开。这不是电影特效而是 L2 级辅助驾驶中最基础也最关键的安全功能——AEBAutomatic Emergency Braking自动紧急制动的标准工作流程。很多朋友讨论辅助驾驶聊的都是“能不能识别红绿灯”“能不能自己变道超车”但真正决定一辆车安全底线的恰恰是这套看起来不那么性感的紧急制动系统。辅助驾驶行业竞争到今天已经很少再为一个“识别准不准”的问题打口水仗了。真正把头部玩家区分开的是一个更底层的问题系统是否理解真实世界的物理规律。前车刹车在摄像头眼里不应该只是一个“矩形框在变小”而是一个有质量、有惯性的物体正在减速它的运动受轮胎抓地力、路面湿滑程度和制动系统响应时间的共同约束。能够理解这一切的 AI行业里叫它物理AIPhysical AI。回头看今天的辅助驾驶市场我认为它已经进入一个“三国时代”。三股技术路线——纯视觉、多传感器融合、物理AI/世界模型——正在用不同的工程路径争取同一个终点让车辆在真实物理世界里安全、平顺地行驶。这篇文章不打算重复“辅助驾驶功能分类”之类的百科内容而是从工程师视角把两个问题讲透物理AI到底改变了什么以及作为安全底线的 AEB 系统其核心算法与工程实践应该如何落地。1. 辅助驾驶的“三国时代”三条路线在争什么1.1 为什么说是“三国”而非“百家争鸣”早期辅助驾驶的玩家很多方案五花八门有做单目视觉的有做毫米波雷达的有坚持激光雷达路线的也有走 V2X 车路协同的。经过这几年的市场淘汰和技术收敛主流方案逐渐集中到三类。第一类是纯视觉路线。核心思路是只靠摄像头获取图像信息用深度学习模型完成目标检测、车道线识别、可行驶区域分割再通过时序信息估计距离和速度。这条路线最大的优势是传感器成本低、硬件统一迭代周期短数据采集也相对容易。它的挑战在于对极端天气、光照变化和非常规障碍物的适应能力比如大雨、逆光、侧翻的货车、路面掉落的散落物。第二类是多传感器融合路线。摄像头负责识别语义毫米波雷达负责测距测速激光雷达负责三维空间建模三者输出在空间和时间上对齐后再交给融合模块做目标级或原始数据级融合。这条路线冗余度高单一传感器失效时系统仍然可以工作但硬件成本高、标定复杂高精地图的维护也是一个长期负担。第三类是物理AI/世界模型路线。它与前两类的区别不在传感器而在算法范式。前两类方案本质上还是“感知—预测—规划—控制”的模块化架构模型负责把传感器数据变成结构化信息规则负责做决策而物理AI路线试图让模型直接理解场景中的物理规律比如理解一辆货车急刹时需要多长的制动距离理解雨天路滑时附着系数会下降理解一个小孩从路边车辆后方突然跑出时遮挡关系会怎样变化。它可以用在端到端模型里也可以作为约束条件嵌入传统模块化架构中。1.2 三条路线的关键对比维度纯视觉路线多传感器融合路线物理AI/世界模型路线核心传感器摄像头为主摄像头毫米波雷达激光雷达多模态融合依赖大规模数据地图依赖轻地图或无地图高精地图局部实时构建算法范式端到端/大模型模块化规则模型数据驱动物理约束最大优势成本低、迭代快冗余度高、可靠性强泛化能力强理解物理规律主要挑战极端天气、长尾场景成本高、地图维护难算力要求高、可解释性弱1.3 竞争的本质从“看见”到“理解”传统辅助驾驶系统的工作方式可以概括为先识别物体再计算距离最后套用规则决策。这个流程在绝大多数场景下是有效的但一旦遇到超出规则库的 edge case系统就会暴露出“只看见、不理解”的问题。物理AI想解决的正是这个“理解”问题。它要求系统不仅知道“前方有一个矩形框”还要知道“这是一个正在减速的物体它的速度变化率是多少它和我的相对距离与相对速度在当前路面条件下是否构成碰撞风险”。这种理解能力不会凭空产生它来自对物理世界运行规律的建模要么体现在传感器融合算法里要么体现在神经网络的训练和约束设计里。这也解释了为什么“三国时代”的竞争不是互相消灭而是互相渗透。纯视觉路线需要引入更多物理约束来应对长尾场景多传感器融合路线正在把更多决策逻辑从规则转向模型物理AI路线也离不开前两者积累的感知工程能力。真正决定胜负的不是传感器数量不是某一个模型的精排分数而是谁能更早、更稳定地在真实道路上理解物理世界。2. 物理AI让机器理解真实世界的运行规律2.1 传统AI与物理AI的差别传统AI在智能驾驶里做的事情本质上是模式识别。给一张图像模型告诉你这里面有一辆车、一个行人、一条车道线给一段点云模型告诉你障碍物的轮廓和位置。这些任务解决的是“是什么”和“在哪里”并不涉及“接下来会发生什么”以及“为什么会这样发生”。物理AI向前走了一步。它把牛顿力学、运动学、光学成像规律、材质与摩擦特性等物理知识引入AI系统让模型在识别物体之后还能估计物体的质量量级、运动趋势、加速度上限以及自身的制动能力边界。一个形象的类比是传统AI像一个看图写标签的实习生能告诉你图片里有什么物理AI像一个有多年经验的老司机不仅知道前面有车还能基于前车的尾灯状态、车身姿态变化、路面湿滑程度预判它接下来大概率会怎么做以及自己此时猛踩刹车会不会失控。2.2 物理AI在智能驾驶中的三种体现第一种体现是从传感器数据中恢复物理量。摄像头图像是二维的要得到距离需要单目测距模型毫米波雷达直接输出目标距离和径向速度激光雷达输出三维点云。这些原始数据经过融合最终生成包含位置、速度、加速度、航向角、尺寸等信息的动态目标列表。这个过程不是简单拼接而是用物理运动模型对传感器噪声做约束让输出结果符合真实世界的运动规律。第二种体现是用物理约束限制预测和决策。没有物理约束的模型可能会预测出一个行人 0.5 秒内横向移动 5 米的极端场景物理AI会用人体运动学上限约束这个预测同样AEB决策也不会只看“能不能刹住”而是会同时计算“需要多大减速度”和“路面能给多大减速度”。当需求减速度超过物理极限时系统就必须采取更早、更强的干预。第三种体现是用世界模型和物理引擎增强泛化能力。在仿真环境里可以生成真实世界里很少见的极端场景比如对向车辆越过实线、高速上突然掉落轮胎、夜间横穿马路的行人。把物理规则编码进仿真引擎再让模型在这些场景里反复训练最终系统遇到类似真实场景时是从物理原理层面理解危险而不是匹配某个见过的数据样本。2.3 为什么AEB是物理AI的最佳落地场景AEB 是所有辅助驾驶功能里最依赖物理量计算的一个。它不关心目标是什么颜色、什么品牌它关心的是三件事相对距离、相对速度、以及当前路面能提供多大制动力。这三件事恰好都是物理量。相对距离和相对速度决定碰撞时间 TTCTime To Collision路面附着系数和车辆质量决定最大可执行减速度。AEB 的全部决策逻辑本质上就是在这两组物理量之间做权衡。正因为 AEB 的物理属性如此强烈它成了观察“物理AI如何改变辅助驾驶”的最佳窗口。一个能做好 AEB 的系统不一定是最聪明的系统但它一定是对物理世界理解最扎实的系统。3. L2级辅助驾驶与AEB从功能定义到安全底线3.1 L2级到底是什么L2级辅助驾驶的经典定义是系统能够同时提供转向控制和纵向控制加速与制动但驾驶员必须始终监控驾驶环境并随时准备接管车辆。换句话说系统可以帮你打方向盘、帮你踩刹车但出了问题的责任主体仍然是驾驶员。这是非常关键的一个边界。L2 不是自动驾驶它的一切功能设计都建立在“驾驶员随时可能接管”的假设之上。这也是为什么 AEB 在 L2 阶段就被强制要求因为在驾驶员走神、反应不及时的场景里AEB 是系统在责任移交窗口内唯一能主动降低碰撞风险的手段。3.2 AEB在ADAS功能矩阵中的位置现代车辆的主动安全功能一般按“警告—辅助—紧急介入”三个层级设计。最低层级是 FCWForward Collision Warning前向碰撞预警只做声光提醒中间层级是 ACCAdaptive Cruise Control自适应巡航在正常行驶中自动保持车距最高层级就是 AEB在系统判断碰撞无法避免时主动施加制动力。功能缩写主要作用是否主动制动自适应巡航ACC按设定车速和车距自动跟车常规制动不强刹前向碰撞预警FCW提醒驾驶员有碰撞风险否自动紧急制动AEB系统自动紧急制动是电子稳定控制ESC防止车辆打滑失控选择性制动从这张表可以看出AEB 是主动安全链条里最激进的一环。它不是帮驾驶员减轻操作负担而是在判断即将发生碰撞时代替驾驶员执行避险动作。3.3 AEB为什么被称为安全底线AEB 被称为安全底线原因很简单所有高级辅助驾驶功能都可以被关闭唯独 AEB 在很多国家已经变成新车出厂标配的强制性要求。它的价值不是提升驾驶体验而是减少碰撞事故尤其是追尾事故和行人碰撞事故。工程上的一个共识是AEB 的标定必须极端谨慎。漏触发该刹车时没刹会导致碰撞后果严重误触发不该刹车时突然急刹虽然不直接导致碰撞但会造成后车追尾、用户恐慌甚至让驾驶员主动关闭整个 AEB 系统。如何在这两者之间找到平衡是 AEB 工程实践的核心命题。4. AEB系统核心技术原理解析4.1 系统架构总览一个完整的 AEB 系统可以拆成四个部分感知层、预测层、决策层、执行层。理解这个分层就理解了 AEB 的全部运行逻辑。感知层的任务是回答“前方有什么障碍物”输出目标列表预测层的任务是回答“这个障碍物接下来怎么运动”输出目标在未来数百毫秒内的轨迹预测决策层的任务是回答“现在要不要制动、制动多猛”输出 AEB 场景模式与目标减速度执行层的任务是回答“怎么把减速度变成车轮制动力”通过 ESP、VCU 等底盘控制器完成建压和制动。层次输入输出典型技术感知层摄像头图像、雷达点云、毫米波数据目标位置、速度、类别目标检测、多传感器融合预测层结构化目标列表目标轨迹预测卡尔曼滤波、交互式轨迹预测决策层相对距离、相对速度、自车车速AEB等级、目标减速度TTC计算、阈值判断执行层减速度请求实际制动压力ESP、VCU、主动制动控制4.2 感知层摄像头、毫米波雷达、激光雷达如何协作摄像头负责语义理解能识别目标类别是车还是人、是静止物还是动物。但单目摄像头测距精度有限夜间和逆光场景容易失效。毫米波雷达不受光照影响能直接测出目标的相对距离和径向速度但对静态物体和横向移动目标的区分能力弱。激光雷达可以输出高密度三维点云空间建模能力最强但在雨雪雾天气下性能衰减明显。在典型的融合方案中系统会先用空间对齐和时间同步把三种传感器的数据放到同一个坐标系下再做目标级融合或特征级融合。目标级融合相对简单每个传感器独立输出目标列表融合模块通过匈牙利算法等做目标匹配再对距离、速度做加权估计。特征级融合则是在更早的数据层面融合精度更高但工程复杂度也更高。AEB对感知层有一个特殊要求必须在极端情况下仍然能输出稳定的目标。所以即使某个传感器短暂失效系统也要能降级运行不能直接丧失AEB能力。4.3 决策层TTC计算与分级制动逻辑AEB 决策的核心物理量是 TTC即碰撞时间。它的定义是当前相对距离除以当前相对速度TTC D / V_rel其中 D 是自车到前方障碍物的相对距离V_rel 是相对速度自车速度减去前车速度单位为 m/s。当 V_rel 大于 0 时表示自车比前车速度快距离正在缩短此时 TTC 越小碰撞风险越高当 V_rel 小于等于 0 时表示没有靠近趋势通常不触发 AEB。但 TTC 只是第一个判断条件。真实工程中还会引入“需求减速度”作为第二个维度即假设从当前时刻开始以恒定减速度制动刚好避免碰撞所需的最小减速度a_req V_rel² / (2D)这个公式来自匀减速运动学 v² v0² 2as 的变形。它比 TTC 更能反映车辆的实际制动能力因为如果 a_req 超出了车辆当前路面条件下的最大制动能力那么即使 TTC 看起来还有余量碰撞也许已经无法避免系统需要更早、更猛地介入。有了 TTC 和 a_req决策层就可以定义分级制动策略。常见的分级是FCW 阶段TTC 较大系统先做声光警告请求驾驶员接管。此时不主动制动避免打扰正常驾驶。部分制动阶段TTC 继续减小驾驶员没有反应系统施加一个中等减速度比如 3 到 5 m/s²目的是降低碰撞速度同时给驾驶员留下反应时间。全力制动阶段TTC 已经很小系统请求最大减速度尽可能避免碰撞或显著降低碰撞速度。需要强调的是阈值参数是整车厂根据自己的车型、制动系统能力、用户画像和安全策略标定出来的没有全局统一数值。本文用 0.6 秒、1.2 秒、2.6 秒作为示例阈值仅用于教学演示。4.4 执行层制动系统介入的工程约束决策层输出的是“目标减速度”但底盘系统从收到请求到真正建立制动压力有物理延迟。纯液压制动系统通常需要约 200 到 400 毫秒来建立压力如果系统提前预填充制动压力这个时间可以缩短到 100 毫秒以内。所以实际 AEB 执行策略会做“预制动”即在高风险场景下先让制动系统进入预备状态提高管路压力但还没有真正产生制动力。一旦决策层发出全力制动请求系统可以在最短时间内达到目标减速度。这个细节直接影响到“能不能刹住”。执行层还要考虑平顺性和稳定性。全力制动时减速度可能达到 8 到 10 m/s²接近普通驾驶员极限刹车水平。如果路面湿滑必须通过 ABS防抱死制动系统调节各轮制动力防止车轮抱死失去转向能力。这也是 AEB 与 ESC、ABS 深度耦合的原因。5. 环境准备与工程前置条件5.1 本文技术路径真实车端 AEB 系统运行在 AUTOSAR 或 Linux 环境下开发语言以 C/C 为主需要接入 CAN 总线、传感器驱动和底盘控制接口。直接复现一套真实 AEB 工程对大多数读者来说门槛太高。因此本文采用一种更轻量的方式用 Python 把 AEB 决策层的核心算法实现出来输入模拟的毫米波雷达输出也就是前方目标的相对距离和相对速度输出对应的 AEB 状态和决策结果。这个决策逻辑与真实车端算法在原理上是一致的只是省略了传感器信号处理、通信协议和底盘执行控制。5.2 环境要求本文代码只使用 Python 标准库不需要安装 numpy、opencv 等第三方依赖。建议使用 Python 3.8 及以上版本操作系统不限。代码在本地直接运行python aeb_demo.py5.3 数据约定在仿真中我们假设已经拿到了目标级融合后的数据包含两个关键字段relative_distance自车到前车的相对距离单位米relative_velocity相对速度由自车速度减前车速度得到单位 m/s当 relative_velocity 为正时表示自车比前车快距离在缩短为负时表示前车更快距离在拉大为 0 时表示两车速度相同距离保持不变。6. AEB决策算法完整实现6.1 项目文件结构aeb_demo/ ├── ttc_calculator.py # TTC 与需求减速度计算 ├── aeb_decision.py # AEB 分级决策逻辑 └── aeb_demo.py # 场景仿真主程序6.2 TTC 计算模块文件路径aeb_demo/ttc_calculator.py TTC 计算模块 本模块负责 AEB 决策所需的两个核心物理量计算 1. TTCTime To Collision碰撞时间 2. 需求减速度假设恒定减速避撞所需的最小减速度 注意真实车端算法通常使用 C 实现这里用 Python 做教学演示。 import math def calc_ttc(relative_distance: float, relative_velocity: float) - float: 计算碰撞时间 TTC。 公式TTC D / V_rel 参数说明 - relative_distance: 相对距离单位 m - relative_velocity: 相对速度自车速度 - 前车速度单位 m/s 返回值 - 若存在碰撞风险返回 TTC 值秒 - 若相对速度 0返回正无穷大表示无碰撞风险 if relative_distance 0: return 0.0 if relative_velocity 0: return float(inf) return relative_distance / relative_velocity def calc_required_deceleration(relative_distance: float, relative_velocity: float) - float: 计算避免碰撞所需的最小减速度。 公式a_req V_rel^2 / (2 * D) 当相对速度 0 时两车没有靠近趋势所需减速度为 0。 当距离小于等于 0 时碰撞已经发生返回一个极大值表示必须全力制动。 if relative_distance 0: return 20.0 # 超过真实制动能力表示必须全力制动 if relative_velocity 0: return 0.0 return (relative_velocity ** 2) / (2.0 * relative_distance)代码中把 TTC 和需求减速度拆成两个独立函数原因是它们在决策层分别承担不同作用TTC 用于判断“还有多长时间会发生碰撞”需求减速度用于判断“需要多大力度的制动才能避免碰撞”。两者结合起来才能避免只看单一指标导致误判。6.3 AEB 决策模块文件路径aeb_demo/aeb_decision.py AEB 分级决策模块 根据 TTC、需求减速度和自车车速输出当前 AEB 状态。 from enum import Enum from ttc_calculator import calc_ttc, calc_required_deceleration class AEBLevel(Enum): NO_WARNING 0 # 无风险不介入 FCW 1 # 前向碰撞预警只提醒 PARTIAL_BRAKE 2 # 部分制动中等减速度 FULL_BRAKE 3 # 全力制动最大减速度 # 阈值参数仅用于教学演示 # 真实车型需要通过大量实车测试标定不能直接套用 TTC_FCW 2.6 # 低于该值触发 FCW 预警 TTC_PARTIAL 1.2 # 低于该值触发部分制动 TTC_FULL 0.6 # 低于该值触发全力制动 MIN_SPEED_AEB 4.0 # 自车车速低于该值时不介入避免低速误触发 MAX_CAPABILITY 7.0 # 假设当前路面最大可执行减速度单位 m/s^2 def aeb_decision(relative_distance: float, relative_velocity: float, ego_speed: float) - tuple: 根据相对距离、相对速度和自车车速输出 AEB 决策。 返回 (AEBLevel, 说明文本) # 低速保护车速很低时即使有风险也应优先交给驾驶员处理 if ego_speed MIN_SPEED_AEB: return AEBLevel.NO_WARNING, 低速工况AEB 不介入 # 计算决策所需的物理量 ttc calc_ttc(relative_distance, relative_velocity) a_req calc_required_deceleration(relative_distance, relative_velocity) # 不存在碰撞风险 if ttc float(inf) and a_req 0.0: return AEBLevel.NO_WARNING, 安全状态无碰撞风险 # 需求减速度超过车辆物理能力上限时判定为碰撞不可避免 # 此时即使 TTC 还大于阈值也应该提前进入预警甚至制动阶段 if a_req MAX_CAPABILITY and ttc TTC_FCW: if ttc TTC_FULL: return AEBLevel.FULL_BRAKE, 物理极限内无法避撞全力制动 if ttc TTC_PARTIAL: return AEBLevel.PARTIAL_BRAKE, 碰撞风险极高部分制动 return AEBLevel.FCW, 碰撞风险预警请求驾驶员接管 # 常规 TTC 分级 if ttc TTC_FULL: return AEBLevel.FULL_BRAKE, 碰撞即将发生全力制动 if ttc TTC_PARTIAL: return AEBLevel.PARTIAL_BRAKE, 高碰撞风险部分制动 if ttc TTC_FCW: return AEBLevel.FCW, 碰撞风险预警请求驾驶员接管 return AEBLevel.NO_WARNING, 安全状态这里的一个关键设计是引入MAX_CAPABILITY。假设当前路面最大可执行减速度是 7 m/s²那么当需求减速度超过 7 时说明系统只有把制动能力全部压上去才可能避开碰撞此时 AEB 必须立即进入更高级别的干预而不是继续等到 TTC 跌破阈值。真实工程里这个值不是固定常量它会根据路面附着系数估算动态变化雨天可能降到 4 以下干地可能是 8 以上。6.4 场景仿真主程序文件路径aeb_demo/aeb_demo.py AEB 决策算法场景仿真 构造几种典型驾驶场景模拟毫米波雷达输出的相对距离和相对速度 观察 AEB 系统的决策结果。 from ttc_calculator import calc_ttc from aeb_decision import aeb_decision def run_scenario(scenario_name: str, frames, ego_speed: float 20.0): 运行一个场景序列。 frames 是 [(relative_distance, relative_velocity), ...] 列表 每隔 0.1 秒采样一次。 print(f\n 场景{scenario_name} ) print(时间(s) 相对距离(m) 相对速度(m/s) TTC(s) AEB状态) for i, (dist, rel_v) in enumerate(frames): ttc calc_ttc(dist, rel_v) level, desc aeb_decision(dist, rel_v, ego_speed) # TTC 为无穷大时显示 -1便于阅读 ttc_display -1.0 if ttc float(inf) else round(ttc, 3) print(f{i * 0.1:6.1f} {dist:10.3f} {rel_v:12.3f} f{ttc_display:7.3f} {level.name} | {desc}) if __name__ __main__: # 场景1前车急刹 # 自车以 20m/s约72km/h行驶前车开始急刹 # 相对距离不断减小相对速度持续增大 front_car_brake [ (35.0, 0.0), (32.0, 1.0), (28.0, 2.2), (22.0, 4.0), (15.0, 6.5), (9.0, 9.5), (4.0, 13.0), (1.5, 17.5), ] run_scenario(前车急刹, front_car_brake) # 场景2匀速巡航 # 前车与自车速度一致相对距离保持 50m无碰撞风险 normal_cruise [ (50.0, 0.0), (50.0, 0.0), (50.0, 0.0), (50.0, 0.0), (50.0, 0.0), ] run_scenario(匀速巡航, normal_cruise) # 场景3极端切入 # 旁车快速切入且明显减速相对距离快速缩短相对速度快速增大 dangerous_cut_in [ (25.0, 0.5), (18.0, 3.0), (10.0, 7.0), (4.0, 12.0), (1.8, 18.0), ] run_scenario(他车侧向切入, dangerous_cut_in, ego_speed25.0)这个主程序其实是一个轻量级的仿真器。它按时间采样毫米波雷达的目标输出每次采样调用一次 AEB 决策函数输出当前时刻的 AEB 状态。真实车端就是把这里的循环换成 CAN 总线上周期性到达的传感器帧处理频率一般在 20Hz 到 50Hz 之间。6.5 运行方式在aeb_demo目录下执行python aeb_demo.py不需要额外安装依赖所有代码均使用标准库。7. 运行结果与效果验证7.1 预期输出运行后可以看到三段场景输出。以“前车急刹”场景为例预期结果是 场景前车急刹 时间(s) 相对距离(m) 相对速度(m/s) TTC(s) AEB状态 0.0 35.000 0.000 -1.000 NO_WARNING | 安全状态无碰撞风险 0.1 32.000 1.000 32.000 NO_WARNING | 安全状态 0.2 28.000 2.200 12.727 NO_WARNING | 安全状态 0.3 22.000 4.000 5.500 NO_WARNING | 安全状态 0.4 15.000 6.500 2.308 FCW | 碰撞风险预警请求驾驶员接管 0.5 9.000 9.500 0.947 PARTIAL_BRAKE | 高碰撞风险部分制动 0.6 4.000 13.000 0.308 FULL_BRAKE | 碰撞即将发生全力制动 0.7 1.500 17.500 0.086 FULL_BRAKE | 碰撞即将发生全力制动匀速巡航场景应该全程都是NO_WARNING这是因为相对速度始终为 0TTC 为无穷大需求减速度也为 0。如果它触发了任何制动说明决策逻辑出现了错误。极端切入场景里由于相对速度增长更快TTC 会更早跌破阈值AEB 会在更短时间内从 FCW 跳到全力制动这符合“侧向切入比前方减速更危险”的直觉。7.2 如何验证逻辑正确验证这套 AEB 决策逻辑是否合理可以从三个维度检查。第一是状态迁移是否符合预期。正常流程应该是 NO_WARNING → FCW → PARTIAL_BRAKE → FULL_BRAKE不应该出现从 NO_WARNING 直接跳到 FULL_BRAKE 的情况。因为分级的目的是给驾驶员留出反应时间如果跳过所有中间状态直接全力制动说明阈值设计或条件判断有问题。第二是低速保护是否生效。把 ego_speed 参数改成 3.0也就是自车速度低于 4 m/s那么即使前车距离极近系统也会输出 NO_WARNING。之所以保留这个保护是因为低速场景下驾驶员本人更容易通过刹车或转向避开碰撞系统频繁制动反而会造成差的体验。第三是物理极限判断是否合理。观察“前车急刹”场景中 0.5 秒到 0.6 秒的输出TTC 从 0.947 降到 0.308需求减速度从 5.01 m/s² 增加到 21.1 m/s²超过 MAX_CAPABILITY 的 7.0。所以系统在 0.6 秒输出全力制动这个判断是符合物理直觉的。7.3 从仿真到实车的差距这里必须提醒一点跑通仿真只是理解了算法骨架真实 AEB 工程还有大量本文没有覆盖的问题。首先是数据源问题。仿真的传感器数据是理想值真实毫米波雷达的输出有噪声、有跳变、有虚警。其次是传感器延迟问题从摄像头曝光到决策层拿到目标延迟可能超过 100 毫秒直接导致 TTC 计算不准确。再次是执行层延迟前面已经提到制动建压时间这个延迟在仿真中完全没有体现。所以一个仿真效果好到完美的 AEB 算法到实车可能依然会因为一个传感器标定偏差而频繁误触发。这也是为什么 AEB 的标定和验证需要大量的场地测试而不是只看仿真通过率。8. 常见问题与排查思路问题现象可能原因排查方式解决方案AEB 该触发时不触发TTC 阈值过小或目标丢失查看目标融合日志确认感知层是否持续输出有效目标增大 TTC 阈值检查雷达/摄像头标定AEB 频繁误触发目标误检、阈值过大回放误触发时段的感知输出确认是否把路牌、护栏误识别为障碍物提高目标置信度门槛调整分级阈值制动介入明显偏晚制动系统建压慢缺少预填充分析纵向控制链路延迟查看制动压力曲线增加预制动请求优化底盘冗余低速场景异常制动未加最低车速保护检查 AEB 决策输入的车速信号是否可靠增加车速阈值和挡位判断排除倒挡场景传感器信号跳变导致误判线束屏蔽不良或传感器老化查看 CAN 信号波形比对雷达点云连续性检查硬件增加滤波和有效性校验排查 AEB 问题有一条通用路径先判断是感知问题、决策问题还是执行问题。感知问题看目标列表是否连续且准确决策问题看 TTC 和减速度是否计算正确执行问题看制动压力能否快速建立。很多现场问题并不是算法不对而是传感器没有把准确数据送过来。9. 最佳实践与工程建议9.1 标定原则漏报与误报之间找平衡AEB 标定最核心的取舍发生在漏报和误报之间。漏报的后果是真实碰撞误报的后果是用户恐慌和后车追尾。工程界的普遍原则是FCW 阶段可以激进宁可多提醒几次也要让驾驶员尽早知道危险全力制动阶段必须谨慎因为突然的急刹本身也是一种风险系统只有在相当确信碰撞即将发生时才能触发。这个原则对应到代码里就是分级阈值的设计思路。FCW 阈值可以放宽用于提示FULL_BRAKE 阈值要收紧同时结合需求减速度和相对距离做双重确认而不是单看 TTC 一个指标。9.2 传感器冗余与失效降级AEB 是安全功能不允许因为单个传感器失效就整体退出。工程上要求至少两个独立的传感器都能测距测速当毫米波雷达失效时视觉单目测距精度下降决策层应该自动进入降级模式比如禁止全力制动只保留 FCW同时通过仪表盘提示驾驶员尽快维修传感器。这个降级逻辑在功能开发阶段就要设计好不能等实车出了问题再补。因为系统在某些极限场景可能同时丢失多个传感器的数据此时 AEB 必须给出一个安全默认动作比如维持 FCW 但降低制动等级而不是愣在那里什么都不做。9.3 测试验证体系仿真、HIL、实车AEB 的验证不是一次性的而是三层递进。第一层是纯软件仿真用大量真实路采数据和仿真场景验证算法逻辑。第二层是 HILHardware-in-the-Loop测试把真实控制器接到仿真环境里验证的是软件在真实硬件上的运行时间、通信时序和稳定性。第三层是实车测试在封闭测试场完成从低速到高速的各种工况测试包括前车静止、前车缓行、