简介：面向自动驾驶算法工程师、车辆安全领域学生及Simulink/Prescan仿真入门者，这份辅助驾驶AEB（自动紧急制动）控制策略源代码提供了一套完整的算法参考实现。资源围绕AEB实时防碰撞核心流程设计，依次覆盖障碍物检测（雷达/视觉数据处理）、相对距离与速度评估、分级刹车决策（预警、部分制动、全力制动）以及控制信号生成等关键环节，并配套Euro NCAP测试场景截图与速度曲线图形，便于对照真实工况理解算法逻辑。从源码中可深入理解卡尔曼滤波、模糊逻辑、状态机等典型实现思路。压缩包共725个文件，主要包含osg三维场景、png/jpg图像、mat实验数据、mdl模型、m脚本及fig图窗文件，类型覆盖仿真场景、算法模型与结果可视化，整体仅7.51MB，轻量易获取。已有3682人学习使用，适合用来快速掌握AEB控制策略的核心框架，并在Prescan环境中进行二次开发、参数标定与效果验证。 刚接触AEB控制策略代码时，我一度以为核心就是一段“距离太近就刹车”的判断。后来一次测试场里的经历彻底改变了这个想法——同一套辅助驾驶AEB控制策略源代码，上午跑得好好的，下午换了光照，系统在距目标还很远时突然给了一脚重刹，全车人差点栽个跟头。那趟之后我才真正明白，AEB的难点从来不在“刹不刹”，而在“什么时候才能认定这件事是真的危险”。
这篇文章围绕“控制策略源代码”这个主题，把我在项目里拆过的AEB决策模块、核心算法、状态仲裁、标定与评估思路整理成文。适合正在做ADAS域控、底盘控制或自动驾驶安全功能开发的朋友参考，也适合想入行但还没系统接触过AEB的学生阅读。市面上很少看到完整开源的量产级AEB代码，这很正常，既涉及知识产权也有车规安全等级约束；但控制策略的通用实现思路是可以公开讲的，你照这个思路搭出的代码，基本能覆盖AEB的主流功能。
1. AEB控制策略的先决问题：系统凭什么替驾驶员踩刹车
1.1 “距离太近就刹车”为什么行不通
很多刚接触辅助驾驶的同学会下意识把AEB理解成一个简单规则：前向传感器检测到障碍物，距离小于某个阈值就触发制动。这个思路放在PPT里没有问题，但放到真实道路上，几乎没法用。
原因在于，真实场景里的“危险”不是一个标量距离能描述的。同样距离100米，前车静止和前车以80km/h同向行驶，危险程度完全不同；同样是行人，他站在路边不动和正在横穿马路，系统该做的反应也不同。再加上传感器本身有噪声、目标有可能被遮挡、路口可能突然窜出骑行者，任何一个固定阈值都会在某个场景下变成“该刹不刹”或者“不该刹乱刹”。
所以量产AEB的控制策略，本质上不是判断一个“点”，而是维护一个“概率”：当前场景有多大的可能演变成碰撞，以及系统在多大程度上可以确信这个判断。这个确信度由多个维度共同决定，包括相对距离、相对速度、目标类型、目标生命周期、自车速度、横向运动状态等等。源代码里反映出来的，就是一套多维特征的综合判定逻辑，而不是单个if-else。
1.2 分层介入：预警、部分制动、全力制动
AEB真正落地的时候，也不会只有“刹或不刹”两种状态。目前主流控制策略都会把介入过程拆成几个阶梯，典型的是：
- 预警阶段（FCW）：只点亮报警、发出声音或轻微点刹提醒驾驶员，不主动强减速；
- 部分制动阶段：系统请求0.3g到0.5g左右的减速度，目的是降低碰撞能量，同时给驾驶员留出反应时间；
- 全力制动阶段：系统请求接近车辆物理极限的减速度，默认驾驶员已经来不及接管；
- 制动后处理：碰撞已无法避免或已经发生，系统维持制动、点亮双闪、解除AEB请求。
分层的好处很明显。如果系统一检测到风险就全力刹死，后车追尾的概率会急剧上升，驾驶员也会被频繁吓到，早早就把功能关了。部分制动和全力制动之间，还要配合不同的介入时间点：预警介入最早，部分制动其次，全力制动最后。这样一套递进逻辑，才是“控制策略”四个字的真正含义——不是求一键刹停，而是在可用性和可靠性之间不断做平衡。
2. 源码入口：AEB决策模块的输入、输出与模块拆分
2.1 输入侧：你要的不是“某个障碍物”，而是“被确认的目标列表”
AEB控制策略代码拿到手的，通常不是摄像头原始图像或雷达原始点云，而是感知融合模块输出的目标列表。这一点非常关键，直接决定了模块接口怎么设计。
一个典型的AEB目标结构体，最少要有这些东西：
struct AEBTarget { uint32_t id; // 目标ID，用于跨帧跟踪 float distance; // 纵向相对距离，单位m float relativeSpeed; // 纵向相对速度，单位m/s，大于0表示正在接近 float confidence; // 目标置信度，0.0~1.0 uint8_t type; // 0=未知, 1=轿车, 2=行人, 3=骑车人, 4=卡车 uint16_t frames; // 连续检测到的帧数，用于生命周期过滤 float lateralOffset; // 横向相对位置，用于判断是否在本车轨迹上 };写控制策略代码的第一步，不是急着写判断逻辑，而是把这些输入结构体定义清楚。比如lateralOffset要不要做，取决于AEB是否具备“只对自车轨迹内目标响应”的能力；type字段则决定了后续走车辆模型还是VRU模型。接口定得越清晰，后续写标定和测试的人就越省心。
2.2 模块划分与控制周期
量产项目里，我会把AEB决策模块拆成四个子模块：
- 目标筛选：从感知目标列表中剔除不在本车预测轨迹内的目标、置信度低于门槛的目标，以及生命周期尚未确认的目标。
- 危险评估：对筛选后的每个目标计算碰撞风险指标，常用的包括TTC和需求减速度。
- 策略仲裁：基于风险指标、驾驶员状态、系统故障状态，决定当前处于哪个AEB状态。
- 执行输出：把仲裁结果换算成减速度请求，通过CAN或SOME/IP发送给底盘执行器，同时控制报警信号。
控制周期上，常见的是10ms或20ms跑一次。为什么不能太慢？因为AEB是高速动态场景，100ms的延迟对应的是高速下多走好几米，决策晚了就物理上刹不住了。但也不是越快越好，域控算力有限，目标列表本身也有帧率限制，10ms已经是比较通用的工程折中。
这里有一个常见的模块间关系：AEB和ACC（自适应巡航）是上下位关系。ACC正常跟车时，如果前方有目标且驾驶员未干预，ACC会先主动减速；只有ACC无法处理、风险继续升高时，AEB才介入。这个优先级在代码里通常体现为：ACC的控制请求先走，AEB请求更高优先级、可以覆盖ACC请求。很多跑测试的同事容易把这两个模块当成并列关系，实际架构上它们是“功能正常时ACC主导，风险临界时AEB越过ACC”。
3. 灵魂算法：TTC计算的工程化修正与目标生命周期管理
3.1 TTC公式的工程化修正
AEB控制策略里最核心的算法，绕不开TTC（Time to Collision，碰撞时间）。教科书定义很简单：
TTC = distance / relativeSpeed但这个公式直接拿来做工程实现，坑非常多。首先是相对速度接近零的情况：如果前车和自车几乎同速，但距离在缓慢缩短，按公式算出来TTC是一个很大的数，可能得出“没有风险”的结论；可实际情况是前车可能随时急刹，风险正在快速积累。其次，它假设相对速度恒定，没有考虑双方加速度的影响。
所以我在实际项目里，会至少做两层修正。第一，对输入的距离和相对速度做低通滤波，别直接用原始值，否则单帧噪声会直接传导到决策结果里。第二，用带加速度项的改进模型，估算一个更贴近物理过程的TTC：
a_rel = target.acceleration - self.acceleration disc = relativeSpeed * relativeSpeed + 2 * a_rel * distance if disc >= 0 && a_rel != 0: ttc = (-relativeSpeed + sqrt(disc)) / a_rel else: ttc = distance / max(relativeSpeed, 0.01)这段代码看起来不复杂，但它决定了系统对“前车突然急刹”这类场景的反应速度。还有一个工程上常用的并行指标，叫需求减速度，即按当前状态要刹停所需的减速度：
requiredDecel = relativeSpeed * relativeSpeed / (2 * distance)把requiredDecel和车辆当前可用的最大减速度做比较，如果接近或超过极限，就说明已经到了“物理上可能刹不住”的临界点，系统应当从预警切到全力制动。TTC负责判断“什么时候会撞”，requiredDecel负责判断“是不是已经刹不住了”，两者配合着用，比单看TTC可靠得多。
3.2 目标生命周期与置信度过滤
控制策略代码里最容易出错的地方，其实不在算法多高深，而在目标过滤顺序。我见过不止一次，代码先算危险评估，再做生命周期确认，导致某个传感器单帧噪声直接触发了AEB预警，在隧道口连续误报。
正确顺序是：目标先经过筛选和确认，再进入危险评估。具体来说，一个感知目标至少要连续出现N帧（比如5帧，即50ms到100ms）且置信度超过门槛，才会被视为“稳定目标”，才有资格参与TTC计算。这个门槛就是系统对“目标是否真实存在”的投票机制，也是最有效的误触发过滤器。
不同目标类型的生命周期策略也有差异。对于静止物体，比如路侧金属护栏、高架桥墩，系统要额外小心，因为这些物体在车辆转弯时横向位置会快速变化，容易瞬间进入轨迹再瞬间离开；如果生命周期做得太短，就会在过弯曲面道路上出现幽灵刹车。对于行人目标，运动模型和车辆完全不同，行人可能停顿、转身、突然加速，需要更长的稳定跟踪窗口，同时要接受目标运动状态的不确定性。
4. 控制权仲裁：什么时候让驾驶员接管，什么时候必须介入
4.1 驾驶员意图识别：油门、转向和刹车如何参与仲裁
AEB代码里还有一个容易写“飘”的部分，就是驾驶员意图仲裁。系统不能在驾驶员已经主动避险时还强行刹车，但也不能因为驾驶员踩了一脚油门就彻底放弃介入。
实际操作中，主流策略会这样处理：
- 如果驾驶员深踩加速踏板，且车辆还处于较低风险等级，AEB可以退出或降低介入强度，默认驾驶员明白自己在做什么；
- 如果风险等级已经很高，TTC已经接近全力制动门槛，即使驾驶员踩着油门，系统也不能完全解除制动请求，最多只是降低目标减速度；
- 如果驾驶员有明显的转向避让动作，且转向后目标已经不在自车预测轨迹内，AEB应该提前退出，避免在避让过程中给驾驶员添乱；
- 如果驾驶员已经踩下制动踏板，系统要检测到制动减速度达到预期，自动让位给驾驶员的制动请求。
这些规则落到代码里，就是一堆条件判断，但它们的先后顺序、优先级、迟滞设计，直接决定了这套功能在真实道路上顺不顺手。优先级排错的典型现象是：驾驶员已经把车扭向旁边车道，AEB还按原轨迹判断目标在正前方，硬生生把车刹在避让的半路上，这种体验非常糟糕。
4.2 状态机设计与迟滞：从if-else堆砌到可测试的仲裁逻辑
成熟的AEB控制策略代码，不会用一长串if-else嵌套，而是用状态机来组织。原因很简单：状态机可追踪、可测试、可回溯，出了问题能明确知道“它当时为什么在这个状态”。
典型状态定义如下：
enum AEBState { AEB_DISABLED, // 功能关闭，比如故障 AEB_IDLE, // 系统待命，无风险 AEB_WARN, // 预警阶段 AEB_BRAKE_PARTIAL, // 部分制动 AEB_BRAKE_FULL, // 全力制动 AEB_POST_BRAKE // 制动后处理 };状态迁移时要特别重视迟滞设计。所谓迟滞，就是“进入某个状态”和“退出某个状态”不应该使用同一个阈值，否则系统会在临界区反复抖动。比如TTC小于1.0s进入全力制动，退出阈值不应该也是1.0s，而是应该设成比如1.5s，留出一个缓冲量。这个思路和家用空调的温控逻辑类似，25度开制冷、22度关制冷，不会让压缩机在临界温度来回跳。AEB一旦抖动，车辆会反复点头，乘客体验和安全性都会变差。
状态机的另一个关键点是故障安全。AEB请求的减速度最终要通过ESC或底盘域控制器执行，CAN通信一旦超时，或者执行器反馈异常，AEB必须能安全降级到预警或退出状态，同时点亮故障提示灯。源代码里至少要有三处看护：输入数据超时检查、输出执行反馈超时检查、状态机自身卡死看护。这些“看不见”的代码，才是量产和Demo之间的真正分水岭。
5. 量产路上的评估闭环与两个环境坑
5.1 阈值不能写死在代码里：标定配置与场景参数化
AEB控制策略最不能做的事，就是把介入阈值写死在代码里。不同车型的整备质量、制动系统响应时间、轮胎附着极限、传感器安装位置都不一样，同一套代码装到两台车上，标定参数必然不同。
我习惯的做法是建立一个配置结构体，把所有可调参数集中管理：
struct AEBConfig { float ttcWarn; // 预警TTC阈值，单位s float ttcPartial; // 部分制动TTC阈值 float ttcFull; // 全力制动TTC阈值 float ttcWarnExit; // 预警退出阈值，带迟滞 float ttcPartialExit; // 部分制动退出阈值 float ttcFullExit; // 全力制动退出阈值 float minConfidence; // 最小目标置信度 uint16_t minFrames; // 目标确认所需帧数 float maxDecelPartial; // 部分制动最大减速度，单位m/s^2 float maxDecelFull; // 全力制动最大减速度 };标定工程师通过配置文件调整这些值，不需要重新编译代码。源代码如下定要设计成支持热加载参数或离线标定工具下发参数，否则生产阶段每次调参都要重新刷写控制器，效率低到没法接受。
5.2 正向场景与负向场景：评估AEB不只是看碰撞测试
评估一套AEB控制策略好不好，不能只盯着Euro NCAP这类碰撞测试场景。碰撞测试场景是“正向场景”，验证的是该触发时必须触发；但量产更怕的是“负向场景”——不该触发时被误触发。
我的项目里会维护两个场景集合：
- 正向场景集：前车静止、前车慢行、前车急刹、行人横穿、骑车人切入、鬼探头等；
- 负向场景集：高架桥阴影、路侧金属护栏、隧道墙壁、井盖、对向车辆远光灯、道路施工区域反光锥等。
每次修改AEB控制策略源代码，先跑负向场景集，再跑正向场景集。这个顺序看起来反直觉，但能有效避免“为了抓住某些目标而引入新的误触发”。指标上要同时看两个维度：真阳率，也就是该触发时触发成功的比例，以及误触发率，也就是每千公里或每百小时触发中属于误报的比例。任何一次参数调整，都是在这两个指标之间来回权衡。
我还养成了一个习惯：每次在测试场踩出一次误触发，就把日志存下来，起名带上日期和场景描述，回写进负向场景库。几年下来，这个场景库比任何理论书都有用，很多问题看一眼数据就能回忆起当时的现象。
5.3 顺带说两个开发环境里的小坑
最后聊两个和AEB源码本身无关、但能卡你一个下午的问题。
第一个，开发机上的应用程序控制策略。有一回同事用PyInstaller打包了一个内部标定工具，在一台启用了Windows应用程序控制策略的工作站上运行时，直接报“应用程序控制策略已阻止此文件”。乍一看像是安装包损坏或被杀毒软件清理，实际上是因为工具的数字签名不在该机器的允许名单里。解决办法是联系管理员把工具加入白名单，或者用受信证书重新打包。这类环境策略问题一旦遇到，先怀疑环境，别先怀疑代码。
第二个，安全关键代码的仓库管理。AEB控制策略我强烈建议单独仓库、单独受保护分支管理，不要和算法验证的demo混在一起。每次提交的commit message里，最好带上场景编号或需求ID，标注这次改动对应的是哪个控制策略行为调整。平时多花这十几秒，真出了误触发或漏触发，你能直接通过git blame定位到哪次改动、哪份参数、哪个场景，这是保命级的习惯。
AEB控制策略源码本身并不复杂，复杂的是你永远要为真实世界里的各种意外留着余量。写代码只是第一步，真正把它从测试场带到量产车上，靠的是对目标生命周期的敬畏、对仲裁逻辑的反复推敲，以及对每一份测试数据的较真。
本文还有配套的精品资源，点击获取
