简介AEB自动紧急制动系统控制策略源代码是一套基于Simulink与Prescan的完整工程面向自动驾驶、ADAS及汽车安全方向的开发者和学习者可帮助理解AEB从障碍物检测、相对距离与车速评估、碰撞风险判定到分级制动控制的完整闭环。资源包为RAR压缩格式共725个文件约7.51MB文件类型以OSG仿真场景、JPG/PNG实景图、MAT数据文件为主配合MDL模型、VWRS场景和XML配置可搭建Prescan虚拟测试环境并回放雷达、车速与制动力等关键数据。核心算法涉及传感器数据融合、目标识别、模糊决策或状态机逻辑并输出Simulink控制信号给制动系统资源内含AEBS速度曲线图、雷达图等仿真结果便于对照调试。整个包体目录清晰既包含可直接运行的Simulink模型也提供配套数据与图表方便按模块拆解学习。已有3682人学习下载适合希望通过工程级代码和仿真场景快速上手AEB策略、进一步优化标定的读者也为后续融合感知与决策研究提供基础。 做AEB控制策略这段时间最大的感受就是这玩意儿看着简单真正落地时全是在跟“边界条件”较劲。自动紧急制动Autonomous Emergency BrakingAEB作为辅助驾驶系统里最后一道安全防线它的控制策略代码不复杂复杂的是“什么时候该刹、刹多重、以及刹完之后怎么收场”。这篇文章我打算把AEB控制策略的源代码逻辑拆开揉碎从整体架构讲到具体实现再把我实际踩过的坑一并交代清楚。无论你是准备入行智驾领域的工程师、在读学生还是已经在做其他模块想横向了解AEB的同行这篇文章都能给你一份可以直接参考的工程实践笔记。1. 整体设计思路与方案选型1.1 AEB控制策略到底在解决什么问题AEB系统一句话概括就是在车辆行驶过程中系统实时感知前方危险当驾驶员没有及时反应时车辆自动介入制动以避免碰撞或减轻碰撞后果。控制策略源代码的核心就是解决三个关键问题什么时候触发、触发后怎么制动、以及什么时候退出。这三个问题看似简单放到实际场景里就非常复杂。举个典型例子车辆在高速公路上以100km/h行驶前方车辆突然减速系统检测到相对距离在不断缩小。此时如果过早触发紧急制动会造成不必要的驾乘惊吓甚至引发追尾如果触发太晚又无法避免碰撞。控制策略需要在这里找到一条安全、舒适、可靠的“决策曲线”。我在设计代码结构时把整个控制策略拆成三条主线状态感知、决策判定、执行仲裁。状态感知负责从感知层接收目标信息并做可靠性分析决策判定基于目标信息计算风险指标执行仲裁决定是否请求制动以及请求多大制动强度。这种分层设计的最大好处是每一层都可以单独做单元测试和故障注入调试效率会高很多。1.2 状态机的引入与决策架构AEB控制策略最适合用一种带时间约束的有限状态机Finite State Machine, FSM来表达。状态机的核心思路是把系统的运行过程划分成若干个明确的状态每个状态里处理特定的事情状态之间的跳转必须满足明确的迁移条件。我常用的状态集合是待机Standby、预警FCW、部分制动Partial Braking、紧急制动Full Braking、介入结束End of Intervention五个状态。每个状态都有对应的触发条件和退出条件。这个设计参考了ISO 15623和Euro NCAP AEB测试规程中关于前向碰撞预警和自动紧急制动的功能定义既能满足法规测试场景也给实车标定留了足够空间。为什么不用简单的if-else连续判断因为连续判断在控制领域会带来两个问题一是状态不清晰系统在某个瞬间到底处于什么工况无法直观描述二是缺乏时间一致性AEB功能对时间连续性要求很高如果在连续几个控制周期内判定条件反复成立又不成立就会出现刹车一抖一抖的情况。状态机配合驻留计时器dwell timer可以很好地解决这个问题。1.3 控制周期和执行器约束的考虑AEB控制策略的运行周期在量产项目上通常是10ms到20ms一个循环我开发时选的是20ms。这个周期综合考虑了感知输入的更新频率、底盘制动系统的响应时间以及控制器负载。代码里所有的时间判断都要基于运行周期累加不能依赖操作系统的时间戳做长时间计时因为不同任务调度的延迟会导致计时漂移。执行器约束也是方案选型时的重要考虑因素。紧急制动时车辆减速度请求可以达到6~9m/s²甚至更高但液压制动系统从请求到建立压力需要时间一般有150ms~300ms的延迟。因此控制策略代码必须做预填充Prefill——在判定危险即将来临但还不需要全力制动时先向制动系统发出一个小压力请求让制动片提前贴合制动盘这样可以显著缩短全制动时的响应时间。2. 核心细节解析与实操要点2.1 目标筛选——不是所有障碍物都值得刹车AEB控制策略的第一个核心细节是目标筛选。感知层通常会输出多条障碍物轨迹包括车辆、行人、骑行者、路障、护栏等。控制策略要做的是从这些目标中选出当前车道内、影响车辆行驶路径的“最危险目标”。我的实现方式是建立危险目标评分表评分项包括目标横向距离相对于本车预测轨迹、目标类型、相对速度、目标的置信度和存在概率。每个评分项都有对应权重最终选取得分最高的目标作为主目标。这样比单一阈值判断要稳健得多因为实际场景中目标的运动状态变化很快单一维度很容易误判。比较关键的一点是目标丢失处理。雷达和摄像头在目标遮挡、强光、恶劣天气下都可能短暂丢失目标如果控制策略一检测到目标丢失就撤销制动请求那是很危险的。我的做法是设计一个“目标保持窗口”在目标丢失后继续沿用上一帧的目标运动状态进行外推窗口通常设置为0.5~1秒超过这个时间才判定目标真正退出。窗口太短容易误撤销太长又可能在目标已经离开的情况下继续刹车这个时间需要通过实际道路测试来标定。2.2 TTC与风险指标的计算逻辑AEB决策里最经典的风险指标有两个碰撞时间Time To Collision, TTC和头部时距Time Headway, THW。TTC的计算公式是当前相对距离除以相对速度含义是按照当前相对速度逼近下去多久之后会撞上前方目标。TTC d / v_rel其中d是相对距离v_rel是相对速度。需要特别注意的是当v_rel接近零或者为负前车比本车快时TTC会趋近无穷大或变为负值这时候不能直接参与阈值比较。我在代码里做了保护当相对速度小于某个值例如0.1m/s时TTC设为无效值不触发AEB。THW则是相对距离除以本车车速表示按当前车速行驶多久会到达前车当前位置。THW主要用于判断“跟车距离是否过近”在低速拥堵场景下比TTC更实用因为此时相对速度小TTC会显得很安全但实际跟车距离已经很近了。实际操作中预警FCW一般采用TTC和THW联合判断而AEB紧急制动更多依赖TTC阈值。因为紧急制动需要非常明确的碰撞紧迫性TTC物理意义清晰也不容易受低速场景干扰。分级阈值可以通过参数表配置我在标定时一般参考NHTSA和Euro NCAP推荐范围再结合自身车队测试数据做调整。2.3 制动分级策略——从警告到全力制动的阶梯AEB的制动策略极少设计成一个“要么不刹、要么刹死”的开关量而是会分成多个等级。我实现的是三级制动策略预警、舒适制动、紧急制动。部分车型还会再加一级“增强制动”。预警阶段不请求制动只发出声光报警提示驾驶员接管。判断条件是TTC在2.6秒左右有研究表明大多数驾驶员在收到警告后约0.8~1.2秒内会做出反应。舒适制动阶段请求0.3~0.5g的减速度目的是降低车速为驾驶员争取更多反应时间。这个阶段要求制动请求变化率不能太快否则乘员会很不舒服。紧急制动阶段请求最大可用减速度通常在0.8g以上目标是最大化碰撞能量削减。这个阶段可以接受较高的制动冲击。研发阶段最容易犯的错误是三级之间的切换条件设置得过于简单比如只靠TTC一个维度切换。实际上切换时还需要考虑当前车速、目标类型、系统状态传感器是否健康以及驾驶员是否在操控例如油门踩到底或急打方向时要抑制AEB请求否则会与驾驶员意图冲突。3. 实操过程与核心环节实现3.1 源码目录结构与模块划分好的代码模块划分能省掉后续无数麻烦。我当前项目的AEB控制策略源码目录大概是这样的src/ ├── aeb_main.c // 主调度入口定时调用各子模块 ├── aeb_state_machine.c // 状态机逻辑实现 ├── aeb_target_selection.c // 危险目标选择 ├── aeb_risk_assessment.c // TTC、THW等风险指标计算 ├── aeb_brake_strategy.c // 分级制动逻辑与减速度请求生成 ├── aeb_driver_override.c // 驾驶员意图识别与仲裁 ├── aeb_output.c // 对外输出信号、故障诊断 ├── inc/ │ ├── aeb_types.h // 公共数据类型定义 │ ├── aeb_config.h // 参数配置宏定义 │ └── aeb_interface.h // 与其他模块的接口声明 └── config/ └── aeb_params.json // 可标定参数外部化配置这么划分的核心思路是“核心逻辑与参数分离”。状态机、目标选择这些算法代码尽量保持稳定而所有阈值、时间窗口、制动强度等标定量都放进配置文件中。这样做的好处是当实车标定时需要调整参数不需要重新编译代码只需要通过标定工具在线刷新参数即可。团队协作时也能避免多人同时改动同一份代码带来的合入冲突。3.2 核心代码执行流程解析以下是主调度函数的基本骨架展示了AEB控制策略运行的主循环逻辑void AEB_MainTask_20ms(void) { // 1. 获取感知融合后的目标列表 TargetList_t targetList Perception_GetTargetList(); // 2. 数据有效性检查 if (!AEB_CheckInputValid(targetList)) { AEB_Output_RequestMode(AEB_MODE_FAULT); return; } // 3. 筛选主目标 Target_t mainTarget AEB_SelectMainTarget(targetList); // 4. 计算风险指标 RiskMetrics_t risk; AEB_CalcRiskMetrics(mainTarget, risk); // 5. 状态机迁移 AEB_StateMachine_Update(risk); // 6. 生成制动请求 float decelRequest AEB_BrakeStrategy_CalcDecel(risk); // 7. 驾驶员意图仲裁与输出 if (!AEB_DriverOverride_IsBlocking()) { AEB_Output_RequestBrake(decelRequest); } else { AEB_Output_RequestBrake(0.0f); } }这段代码看着简单但每个函数内部都有着大量的边界保护。在AEB_CalcRiskMetrics里TTC计算的保护逻辑就是关键点。如果相对距离是有效值但相对速度小于0.05m/s不能直接除否则会产生极大值如果相对距离超过100米通常也不做紧急制动评估因为制动距离不足或目标太远意义不大。还有一个容易被忽视的细节目标列表的时戳对齐。感知层的目标来自不同传感器雷达、摄像头、融合模块各自的时间基准可能不完全一致。我在代码里用了队列缓存上一周期的目标数据通过时间对齐插值来保证计算时使用的距离和速度来自同一时刻否则在高相对速度工况下几十毫秒的时差都可能带来两三米的距离误差。3.3 状态机核心迁移条件的实现状态机的实现是AEB代码的重中之重。我贴一段状态迁移的核心逻辑说明一下迁移条件是怎么组织和判断的AEB_State_t AEB_StateMachine_Update(AEB_State_t current, RiskMetrics_t *risk) { AEB_State_t next current; switch (current) { case AEB_STATE_STANDBY: if (risk-ttc PARAM_FCW_TTC_THRESHOLD risk-ttc 0) { next AEB_STATE_FCW_WARNING; AEB_Timer_Start(fcwTimer); } break; case AEB_STATE_FCW_WARNING: // 驻留计时器判断防止瞬时噪声触发AEB if (risk-ttc PARAM_AEB_PARTIAL_TTC_THRESHOLD) { next AEB_STATE_PARTIAL_BRAKE; AEB_Timer_Start(partialTimer); } else if (risk-ttc PARAM_FCW_RESET_TTC) { next AEB_STATE_STANDBY; } break; case AEB_STATE_PARTIAL_BRAKE: if (risk-ttc PARAM_AEB_FULL_TTC_THRESHOLD) { next AEB_STATE_FULL_BRAKE; } else if (risk-ttc PARAM_AEB_PARTIAL_RESET_TTC AEB_Timer_Elapsed(partialTimer) PARAM_T_DWELL_MS) { next AEB_STATE_FCW_WARNING; } break; case AEB_STATE_FULL_BRAKE: // 全制动后不直接退出需满足速度阈值与时间阈值 if (risk-egoSpeed PARAM_AEB_EXIT_SPEED_KMPH AEB_Timer_Elapsed(fullBrakeTimer) PARAM_AEB_EXIT_DWELL_MS) { next AEB_STATE_END; } break; case AEB_STATE_END: if (AEB_Timer_Elapsed(endTimer) PARAM_AEB_END_TIMEOUT_MS) { next AEB_STATE_STANDBY; } break; } return next; }关于状态机有一个需要特别注意的问题状态跳转的阈值要避免“抖振”也就是临界点附近反复横跳。比如某个TTC值正好在阈值附近波动系统会频繁在FCW和STANDBY之间切换驾驶员会看到仪表盘报警灯闪来闪去体感很不好。解决方案是使用“回滞阈值”也就是进入条件的阈值和退出条件的阈值之间留有一定余量代码里我用PARAM_FCW_RESET_TTC和PARAM_FCW_TTC_THRESHOLD两个参数来实现这个回滞区间。3.4 可标定参数的配置与保护AEB是安全件参数标定必须极度谨慎。我把所有可标定参数都集中在aeb_params.json中并且对每个参数都带有上下限范围检查。加载参数时如果发现越界直接拒绝加载并上报标定错误。这样可以防止标定工程师在调试时不小心把TTC阈值填成0导致功能全失效。{ FCW: { ttc_warning_threshold_s: 2.6, ttc_reset_threshold_s: 3.2, thw_warning_threshold_s: 1.8 }, AEB: { ttc_partial_threshold_s: 1.5, ttc_full_threshold_s: 0.8, partial_decel_mps2: 3.0, full_decel_mps2: 8.5, exit_speed_kmph: 3.0, target_keep_time_s: 0.8, dwell_time_ms: 300 } }这里特别说明一下exit_speed_kmph这个参数。AEB全制动后车辆不会直接刹到零就立刻退出因为驾驶员此时可能还没接管如果系统瞬间释放制动车辆可能在坡道或者低速蠕行状态下再次向前溜车可能与前方目标继续接近。所以我在全制动退出条件里加了一个速度阈值和驻留时间确保车辆稳定停车一段时间后再退出实际标定时这个值一般取3~5km/h驻留时间取300~500ms。4. 常见问题与排查技巧实录4.1 误触发的前因后果AEB误触发是我做这个功能以来被投诉最多的问题。典型的误触发场景有三种前车转弯驶离本车道时、路侧金属护栏或龙门架被雷达识别为静止目标时、以及经过弯道时对向车辆切入本车轨迹预判范围内时。排查误触发问题时我建议先抓取日志回放数据重点检查当时感知层目标的ID切换记录。很多时候误触发的根因是感知目标ID发生了瞬移即目标在某一帧突然从一个位置跳到另一个位置导致目标筛选逻辑认为有目标切入。AEB控制策略能做的事情是增加目标运动轨迹连续性检查如果目标的新位置与上一帧位置相差超过物理可能的最大位移则把该目标标记为不可信需要连续多帧确认后再参与计算。还有一种工程上容易忽略的情况传感器标定漂移。摄像头与雷达的外参如果发生微小偏移目标横向距离可能产生持续偏差对目标所在车道的判断就会出错。我的做法是在AEB模块里额外接收底盘信号中的转向角、横摆角速度等信息建立一个简化的本车轨迹预测模型目标是否在本车未来轨迹内需要结合这个模型来判断而不是只看当前时刻的横向距离。4.2 制动请求被底盘拒掉的排查思路控制策略算出了减速度请求但实际车辆有没有执行、执行了多少是另一个需要密切关注的问题。我遇到过的现象是TTC明明已经触发紧急制动但车辆减速度没有立刻建立起来究其原因往往在制动系统的介入条件。底盘域和智能驾驶域之间通常会约定一个“制动可用状态”信号只有当底盘报出“自动制动可用”时AEB发出的减速度请求才会被响应。如果底盘因为自身故障、制动盘过热、ESP未初始化等原因发出不可用状态AEB控制策略必须能够感知到并做降级处理。我在代码里加了制动请求超时监控如果连续500ms请求的减速度与底盘反馈的实际减速度差值超过1.5m/s²就上报AEB功能降级并点亮相应故障灯。另外也要注意制动请求的平滑性。即使是在紧急制动下减速度请求的变化率也不能是阶跃式的。底盘执行机构有自身的响应带宽如果请求信号从0跳变到8m/s²底盘根本无法精确跟随反而可能引发车身抖动和噪音。我在制动策略里增加了一阶惯性滤波紧急制动时滤波时间常数取50ms舒适制动时取200ms。这个滤波时间常数也是标定量需要结合具体车型的制动系统响应特性来调整。4.3 驾驶员干预怎么处理才不打架AEB再厉害也不能和驾驶员的明确意志对着干。实际驾驶中经常出现的情况是系统触发紧急制动后驾驶员同时猛踩油门想加速脱离危险或者猛打方向盘进行紧急变道避让。这时候系统必须识别出驾驶员意图并合理弱化或取消AEB请求。我实现了一套驾驶员过控逻辑判定优先级从高到低大致是方向盘转角及转角速度是否超过阈值、油门踏板深度及变化率是否超过阈值、制动踏板是否被踩下驾驶员主动制动时AEB不干预。油门过控的阈值需要仔细标定。全油门瞬间驾驶员确实可能在避险但低速路口场景下驾驶员也可能因为误踩油门导致车辆突然前冲这时候AEB反而应该更早介入。所以油门过控逻辑里我加了一个车速条件车速低于30km/h时即使油门踩得很深AEB仍保留部分介入能力车速高于30km/h时更相信驾驶员的主动加速意图。这个逻辑在实车测试中效果不错能在不干扰正常驾驶行为的同时保留安全兜底功能。4.4 常见问题速查表问题现象可能原因排查方向高速无征兆突然制动雷达识别路侧金属物为危险目标检查感知目标ID稳定性、引入轨迹连续性检查静止目标完全不触发AEB感知后端对静止目标可靠性标签过低检查感知融合模块的静止目标输出策略制动请求执行延迟大制动系统预填充未启动检查AEB预警阶段是否发送了预填充请求低速跟车时频繁介入THW权重过高导致误判调整低速场景下的风险指标计算逻辑仪表故障灯频繁闪烁控制器超时或参数加载失败抓取诊断事件码检查通信链路心跳雨天测试误触发率上升传感器受水雾干扰建议联合感知团队评估传感器降级策略5. 代码测试与验证的工程实践5.1 模型在环与硬件在环测试AEB控制策略代码在走向实车之前至少要通过三层验证模型在环MIL、软件在环SIL和硬件在环HIL。我开发时使用的是MATLAB/Simulink与嵌入式C代码联合仿真的方式控制策略在Simulink中完成原型开发然后通过自动代码生成工具转换成C代码再部署到实车控制器里。MIL阶段主要验证控制策略的逻辑正确性我会搭建各种极端场景前车急刹、行人横穿、摩托车切入、静止车辆、隧道出口阳光直射等。SIL阶段验证代码生成后的行为与模型一致。HIL阶段则是把真实的控制器接入仿真环境模拟各类传感器信号和底盘响应验证代码在目标硬件上的实时性、内存占用和故障诊断逻辑。5.2 测试用例设计的几个关键场景AEB测试场景设计要覆盖“危险程度从低到高”的完整谱系。我常用的测试场景包括CCRsCar-to-Car Rear stationary前方静止车辆本车从50km/h、80km/h分别接近。这是验证低速与高速静止目标识别能力的典型场景。CCRmCar-to-Car Rear moving前方车辆以20km/h匀速行驶本车以更高速度接近。这个场景考验相对速度计算的准确性。CCRbCar-to-Car Rear braking前方车辆从50km/h急刹减速本车跟随行驶。这个场景最能反映TTC计算的灵敏度。VRUVulnerable Road User行人横穿、行人同向行走、骑行者等场景考验感知和控制的联合响应。每个场景至少要跑三遍以上确认状态机迁移时间、制动介入点、减速度峰值都在合理区间。同时要做参数敏感性分析把每个关键阈值上下调整15%确认系统依然不会出现测试不可接受的误触发或漏触发。这个过程中发现的大部分逻辑缺陷都属于状态迁移顺序和时序保护问题。5.3 从代码到量产还需要补齐哪些能力如果这个控制策略代码要走向量产单靠前面这些还不够。还需要补齐诊断覆盖、降级策略和安全监控。诊断方面要对传感器信号做合理性检查比如目标距离突变超过物理极限时要报信号不可信降级方面当感知、制动、通信任一环节出问题时要明确AEB功能的可用等级安全监控方面需要通过独立的监控路径确认控制器的决策是否合理一旦发现决策异常要能及时降级或退出。这个安全监控链路在代码层面表现为一个独立的“看门狗任务”它运行在同一个控制器上但逻辑独立。监控任务不问“当前该不该刹车”而是问“当前刹车请求是不是明显不合理”。比如车速只有10km/h但制动请求达到了8m/s²监控任务就会判定请求异常并触发安全路径降级。这个双轨制的设计思路是AEB量产项目里非常核心的安全架构。最后分享一点个人体会做AEB控制策略这几年我愈发觉得这个功能的难点不在算法模型有多高级而在于代码是否足够鲁棒、参数是否足够完善、测试是否足够充分。很多问题在仿真里根本不会暴露一上实车就现出原形。比如雷达对路侧金属护栏的反射、大雨天的传感器衰减、前车急刹时驾驶员油门还踩着一半的工况……这些边界情况才是真正吃时间的地方。如果你正准备自己写一套AEB控制策略我的建议是先把状态机框架搭稳再把每一项输入信号的异常处理写全最后再追求决策算法的丝滑。代码里每一个“如果信号无效”的分支都可能在真实道路上救你一命。整个过程踩坑很多但每一次实测通过那种踏实感也是无可替代的。本文还有配套的精品资源点击获取