企业官网建设流程全解析

简介：这份文档围绕Carsim与Simulink联合搭建AEB仿真平台展开，面向汽车主动安全、ADAS控制算法学习者及需要验证紧急制动策略的工程人员，重点解决道路场景建模、系统控制逻辑搭建与仿真结果评估之间的衔接问题。压缩包共1个docx文件，约15KB，内容以技术要点整理为主，便于快速浏览整体框架。文档从3D道路、前方车辆速度与雷达等环境要素切入，说明道路几何、路面附着、天气照明及前车运动状态的建模考虑，并梳理Simulink中感知器、决策器、执行器的分工，以及碰撞时间、碰撞速度、制动距离等输出分析和可视化思路。已有606人学习，适合作为AEB联调仿真的入门框架与方案索引，帮助读者理解Carsim与Simulink联调时各模块如何配合、需要准备哪些参数与验证指标。

1. AEB 算法要先在闭环里活下来：这套 Carsim + Simulink 联调仿真解决的是什么问题

做 AEB 的人迟早会撞上一个尴尬：策略在 MATLAB 脚本里跑得干干净净，曲线也漂亮，但一谈到制动距离、减速度峰值、到底该不该触发，就没人敢拍板。原因不复杂——纯脚本里没有轮胎滑移、没有纵向载荷转移、没有制动系统从建压到真正出力那几百毫秒的滞后，算出来的东西更接近一道数学题。基于 Carsim 和 Simulink 建立 AEB 联调仿真，填的正是这道缝：Carsim 提供带 3D 道路、前方车辆和雷达的车辆动力学环境，Simulink 承载感知、决策、执行三段逻辑，两边用 S-Function 打通，形成一个真正闭环、可以反复跑的实验台。它适合两类人：一类是要做 AEB 方向毕设或课程设计、需要一套能复现、能出图、能写进论文的完整仿真链路；另一类是手上已经有一版 AEB 策略、想在上实车之前先把它在各种附着和初速下压一遍的工程师。下面按需求、架构、建模、控制、排查、验收的顺序拆开讲，每个环节都给到能照着改的参数和代码。

2. 总体架构与联调链路：Carsim 管动力学、Simulink 管策略，接口只留三根线

联调仿真最容易做歪的地方，是把两边都做成"半个模型"——Carsim 里塞一段制动逻辑，Simulink 里又搭一个简化车辆模型，最后两边算出来的东西互相打架，谁都说不清哪个是真的。我在做这套东西时的第一条原则是：动力学只认 Carsim，策略只认 Simulink，中间用尽可能少的信号打通。这样一旦结果不对，排查范围立刻收缩到接口和策略两侧，不会陷入"到底是模型不准还是算法不对"的黑匣子。

2.1 职责边界：为什么动力学交给 Carsim，决策必须留在 Simulink

Carsim 的价值在于它把整车当成一个多体系统在算：悬架压缩、载荷转移、轮胎纵滑特性、制动系统的压力-力矩关系，这些恰好是 AEB 从"能刹"到"刹得住"之间最关键的非线性环节。你在 Simulink 里搭一个单自由度纵向模型，减速度给多少就是多少，制动距离自然永远比实车乐观，这种模型写进报告里，答辩老师一句"你的载荷转移怎么处理的"就能问穿。

反过来，AEB 的决策逻辑必须留在 Simulink，理由是可调试性。Carsim 里当然也能写控制，但它的调试手段基本停留在改参数—重跑—看曲线，一个状态机的跳转条件想加个断点、看个中间变量，成本高得离谱。Simulink 这边状态机、查表、滤波器全部图形化，加一个 Scope 或者 To Workspace 就能把 TTC、状态字、目标减速度全记录下来，出问题直接定位到某一帧。

所以职责划分是明确的：Carsim 侧负责道路、前车、雷达、车辆本体和制动执行机构，输出车速、加速度、相对距离这类"世界状态"；Simulink 侧只做一件事——拿到世界状态，算出该踩多深的刹车，把主缸压力请求回送给 Carsim。谁也别越界。

2.2 端口与信号清单：一份能直接照着连线的接口表

接口设计的原则是"够用即止"。很多教程会把几十个通道全导出来，结果模型连线像蜘蛛网，改一个信号要顺藤摸瓜半小时。我一般只保留下面这张表里的信号，多了不加。

这张表有两个地方要特别注意。一是单位，Carsim 的车速界面经常同时出现 km/h 和 m/s，接口里务必统一到 m/s，否则 TTC 会整体差 3.6 倍，这种错误在曲线上看起来"很像那么回事"，最难发现。二是制动输入的类型，有的配置走主缸压力（MPa），有的走制动踏板行程（0~1），取决于你在 Carsim 里选的制动系统模型，导入 S-Function 之后端口名会直接告诉你，别凭记忆接。

2.3 步长、求解器与采样率的对齐方式

联调里另一类高频翻车是步长。Carsim 内部的积分步长通常取 0.001 s，Simulink 侧如果设成变步长，两边的时间轴就对不上，雷达信号会出现莫名其妙的插值和台阶。我的做法是 Simulink 侧一律定步长 0.001 s、求解器用 ode4，控制器和雷达再用各自的采样周期做降采样，控制器 0.01 s、雷达 0.05 s，中间用 Rate Transition 块过渡。

参数不要散落在各个模块的对话框里，全部收进一个初始化脚本，用结构体喂给 Simulink 的 base workspace。这样批量扫工况的时候只改结构体字段，模型本身一个字都不用动。

% init_aeb_params.m 联调仿真统一参数入口 clear; clc; % ---- 车辆与道路 ---- veh.mass = 1500; % 整车质量 kg，需与 Carsim 里一致 veh.wheelbase = 2.70; % 轴距 m cas.mu = 0.85; % 路面附着系数，干沥青基准 cas.v0_kph = 50; % 初始车速 km/h % ---- 时间配置 ---- sim.ts_fixed = 0.001; % Simulink 定步长 s，与 Carsim 内部步长对齐 sim.ts_ctrl = 0.01; % AEB 控制器采样周期 s sim.ts_radar = 0.05; % 雷达输出周期 s sim.t_end = 10; % 单次仿真时长 s % ---- AEB 标定参数 ---- aeb.ttc_warn = 2.4; % 一级预警 TTC 阈值 s aeb.ttc_brake = 1.6; % 部分制动阈值 s aeb.ttc_full = 0.8; % 全力制动阈值 s aeb.hyst = 0.3; % 状态机迟滞带 s aeb.a_max = 8.0; % 目标减速度上限 m/s^2 aeb.d_min = 1.5; % 最小触发距离 m aeb.v_min = 0.5; % TTC 计算的速度门限 m/s % ---- 执行器标定（示意值，按自己车型重标）---- aeb.dec_axis = [0 2 4 6 8]; % 目标减速度 m/s^2 aeb.press_axis = [0 1.2 2.8 4.6 6.8]; % 对应主缸压力 MPa assignin('base','veh',veh); assignin('base','cas',cas); assignin('base','sim',sim); assignin('base','aeb',aeb);

这段脚本的关键不在参数值，而在结构：sim.ts_fixed与 Carsim 内部步长必须相等，否则雷达和车辆状态之间会引入一个恒定的时间偏移；aeb.press_axis这组压力值是整个执行层的地基，它不准，后面所有减速度曲线都是假的，通常的做法是先用 Carsim 做一次阶跃制动试验，扫几组主缸压力，拟合出"压力—稳态减速度"关系再填进来。aeb.hyst单独拎出来是因为状态机没有迟滞就会在阈值附近反复跳变，这一点在第 4 章展开。

3. 道路环境建模：3D 道路、前车速度曲线与雷达探测三件套

环境模型决定这套仿真有没有说服力。一个只有平直路面、前车匀速、雷达理想无噪声的场景，跑出来的结果和手算差不多，写进报告里也撑不起"验证"两个字。我一般会把环境拆成三个可以独立扫的维度：道路几何与附着、前车运动工况、雷达探测特性。三个维度组合起来，才是一张能拿去答辩的工况矩阵。

3.1 3D 道路几何与路面附着

Carsim 的道路由中心线加宽度定义，中心线可以用 X-Y 坐标点列导入，也可以用它内置的路径生成器拼直线、圆弧和回旋线。AEB 场景用不到太复杂的线形，一条 500 m 以上的直道加一段大半径弯道就够了，直道太短会导致初始加速还没稳定就进入危险区，前 2 s 的数据全是过渡态，没法用。

坡度通过中心线的高程列给出，纵坡对 AEB 的影响是实打实的：下坡时同样的主缸压力换来的减速度会明显小一截，如果你的工况矩阵里全是平路，验收结论就会偏乐观。我通常至少配一组 -3% 的下坡工况作为对照。

路面附着是这三个几何参数里最重要的一个。Carsim 里可以按路段给附着系数，也可以给一条随位置变化的 μ 曲线。做 AEB 验证时，我的习惯是把 μ 做成工况变量而不是某一段路的属性：干沥青 0.85、湿沥青 0.55、压实雪 0.30，三档扫一遍，就能看出策略在哪一档开始失效。μ 从 0.85 掉到 0.30，理论最大减速度直接从 8 m/s² 出头掉到 3 m/s² 以下，这时候如果你的目标减速度还是 8，控制器会一直把压力顶到限幅，实际减速度却上不去，曲线看起来像"刹不住"，其实是物理上就刹不住。

3.2 前车运动工况：把速度曲线做成可切换的查表函数

前车的运动不要写死在 Carsim 的交通车对话框里。写死之后每换一个工况就要回去改一次对话框、重新生成 S-Function，批量扫描基本没法做。我的做法是在 Simulink 侧用一个 MATLAB Function 给出前车速度，用一个字符串参数切换场景，扫描时只改这个字符串。

function v_lead = lead_speed_profile(t, scene) % 前车速度工况生成：t 为当前时刻(s)，返回 m/s % scene: 'cruise' 匀速 / 'hardbrake' 前车急刹 / 'cutin' 切入后缓减速 switch scene case 'cruise' v_lead = 16.7 * ones(size(t)); % 60 km/h 匀速巡航 case 'hardbrake' v_lead = 16.7 * ones(size(t)); idx = (t >= 3.0); % 3 s 时刻前车全力制动 v_lead(idx) = max(16.7 - 6.0 * (t(idx) - 3.0), 0); case 'cutin' v_lead = 16.7 * ones(size(t)); idx = (t >= 2.0); % 2 s 时刻切入并缓减速 v_lead(idx) = max(16.7 - 3.0 * (t(idx) - 2.0), 0); otherwise error('未知工况: %s', scene); end end

用函数而不是常数的好处不止是批量方便。v_lead直接参与相对速度计算，而相对速度又是 TTC 的分子，所以前车减速度的取值实际上决定了这套 AEB 的"难度等级"。6 m/s² 这一档是常用的高强度制动工况，能把只做预警、不做制动的策略直接打穿；3 m/s² 更接近日常跟车时前车的自然减速，考验的是策略会不会误触发。两种都要跑，只看一种看不出策略的真实边界。

另外注意max(..., 0)这个截断，前车速度不能为负，否则相对速度会突然反向，TTC 算出来是负数，状态机会出现莫名其妙的跳转。

3.3 雷达模型：量程、噪声、一阶滤波与丢目标处理

雷达是这套链路里最容易被做成"理想传感器"的一环，也是最能体现方案深度的一环。直接用 Carsim 给出的真实相对距离去算 TTC，跑出来的曲线平滑得像教科书，但真实控制器拿到的信号是有噪声、有延迟、偶尔还会丢目标的。我的做法是在 Carsim 输出和目标距离之间插一层雷达模型，把这三件事都模拟出来。

function [r_meas, vr_meas, valid] = radar_model(r_true, vr_true, p) % 前向毫米波雷达简化模型 % 输入：真实相对距离 r_true(m)、真实相对速度 vr_true(m/s)、参数结构体 p % 输出：测距 r_meas(m)、测速 vr_meas(m/s)、目标有效标志 valid persistent r_filt if isempty(r_filt) r_filt = p.r_max; % 滤波器初值取量程上限 end % 1) 视场与量程判断 valid = (r_true > p.r_min) && (r_true < p.r_max); % 2) 叠加高斯测距噪声（测速噪声一般更小，这里简化处理） r_raw = r_true + p.sigma_r * randn(); % 3) 一阶低通，模拟雷达内部跟踪滤波的滞后 alpha = p.Ts / (p.tau_f + p.Ts); r_filt = alpha * r_raw + (1 - alpha) * r_filt; if valid r_meas = r_filt; vr_meas = vr_true + p.sigma_v * randn(); else r_meas = p.r_invalid; % 丢目标时给无效值，不要给 0 vr_meas = 0; end end

三个参数值得说清楚。p.sigma_r是测距噪声标准差，毫米波雷达在 50 m 内通常能做到 0.1~0.3 m，取 0.2 比较接近实际；p.tau_f是跟踪滤波时间常数，取 0.1 s 左右，它直接决定了 AEB 对前车急刹的响应会晚多少；p.r_invalid是一个明显偏离量程的哨兵值（比如 999），丢目标时给这个值而不是 0——给 0 是最经典的坑，下游会把它当成"前车贴脸"，直接触发全力制动，而且这个错误在曲线上表现为"偶发误刹"，查起来极其痛苦。

3.4 天气与照明：为什么这个方案里它最终落到附着系数上

原始需求里提到了天气和照明条件。如果感知方案是摄像头，那天气和光照必须单独建模，逆光、夜间、雨雾对检测距离的影响是决定性的。但这套链路的主感知是雷达，雷达对光照基本免疫，对雨雾的敏感度也主要体现在衰减和杂波上，在仿真里很难做出有意义的差异。

所以我的处理是把"天气"折算成路面附着：干燥 0.85、雨天湿滑 0.55、积雪 0.30，照明条件直接不作为变量。这不是偷懒，而是让每一个工况变量都对应一个真实可解释的物理量——你答辩时能说清楚"μ=0.3 这一组模拟的是压实雪路面，此时轮胎能提供的最大减速度只有 2.9 m/s²，所以策略的 8 m/s² 请求必然饱和"，比笼统地说一句"考虑了恶劣天气"要有说服力得多。

4. AEB 控制逻辑落地：感知层算 TTC、决策层走状态机、执行层压主缸

Simulink 侧的结构我一般分成三段：感知层只做信号处理和风险度量，决策层只输出状态和目标减速度，执行层只负责把减速度翻译成主缸压力。三段之间用明确的信号名连接，不跨层引用，这样任何一段出问题都能单独拿出来测。

4.1 感知层：TTC 计算里那个容易被忽略的速度门限

TTC 的定义很朴素——相对距离除以接近速度。但直接照公式写会在一个场景下失效：高速同速跟车。此时真实相对速度接近 0，雷达测速噪声让 vr 在 0 附近抖动，除出来的 TTC 一会儿是 50 s，一会儿是 -30 s，状态机跟着乱跳。加一个速度门限就能压住。

function ttc = calc_ttc(r, vr, v_min) % TTC 计算：仅在目标确实在接近且接近速度足够大时才有意义 if isnan(r) || r <= 0 || r > 900 ttc = inf; % 无有效目标，视为无风险 return; end if vr < -v_min % 接近速度大于门限才算数 ttc = r / (-vr); else ttc = inf; % 同速跟车或远离，不产生碰撞风险 end end

v_min取 0.5 m/s 是个折中：太小压不住噪声，太大会漏掉"缓慢逼近"这种低速追尾场景。r > 900那个判断是配合上一节雷达的哨兵值用的，把无效目标在感知层就过滤掉，不要让它流进决策层。另外 TTC 出来后建议再过一道一阶低通或者滑动平均，否则状态机在阈值附近的抖动会让制动压力出现锯齿。

4.2 决策层：带迟滞的三级制动状态机

状态机是 AEB 的心脏，也是毕设里最容易写成"阈值比较"的地方。只用 if-else 比阈值，进入和退出用同一个数，结果就是在阈值附近反复触发—退出—再触发，压力曲线抖动得像心电图。加迟滞带能解决绝大部分问题。

function [state, dec_tgt] = aeb_fsm(ttc, r, v_ego, p) % 三级 AEB 状态机：0 待机 / 1 预警 / 2 部分制动 / 3 全力制动 persistent st if isempty(st) st = 0; end switch st case 0 % 待机 if ttc < p.ttc_warn && r > p.d_min st = 1; end case 1 % 预警 if ttc < p.ttc_brake st = 2; elseif ttc > p.ttc_warn + p.hyst % 退出阈值上抬，形成迟滞 st = 0; end case 2 % 部分制动 if ttc < p.ttc_full st = 3; elseif ttc > p.ttc_brake + p.hyst st = 1; end case 3 % 全力制动 if v_ego < 0.3 % 只有停稳才允许退出 st = 0; end end % 状态映射到目标减速度 switch st case 0, dec_tgt = 0; case 1, dec_tgt = 0; % 只报警，不动刹车 case 2, dec_tgt = p.a_max * 0.4; case 3, dec_tgt = p.a_max; end end

两个设计点值得单独拎出来讲。第一，状态 3 的退出条件只看车速，不看 TTC。原因是全力制动一旦开始，驾驶员（或者更上层的策略）没有"后悔药"可吃，中途因为 TTC 变大而松刹车，很可能造成二次碰撞，减速到停是最稳的选择。第二，状态 2 的减速度取a_max * 0.4而不是某个固定值，这样调整a_max时整个分级比例保持一致，标定时少改一处。迟滞带p.hyst取 0.3 s 是经验值，太小压不住抖动，太大会让退出变迟钝。

4.3 执行层：目标减速度到主缸压力的标定与限幅

决策层给出的是"想要多少减速度"，执行层要把它变成"踩多深"。这中间隔着制动系统的非线性：压力小的时候增益大，压力上去之后管路和卡钳的特性会让增益变小，再加上低速段的摩擦系数变化，一条线性换算根本对不上。

function p_bk = dec_to_pressure(dec_tgt, v_ego, p) % 目标减速度(m/s^2) -> 制动主缸压力请求(MPa) % 1) 低速段衰减：车速越低，允许的减速度越小，避免停车点头和负车速抖动 scale = min(1, max(v_ego, 0) / 2.0); dec_lim = dec_tgt * scale; % 2) 查表换算：dec_axis / press_axis 来自阶跃制动标定 p_bk = interp1(p.dec_axis, p.press_axis, dec_lim, 'linear', 'extrap'); % 3) 物理限幅，防止 extrap 给出不合理的负压或超压 p_bk = min(max(p_bk, 0), p.p_max); end

scale这一项看起来不起眼，实际上决定了停车瞬间的观感。不加的话，车速降到 1 m/s 时仍然请求 8 m/s²，Carsim 里的车会在停止线前后反复前后点头，纵向加速度曲线出现正负交替的尖峰，验收时这一段的图基本没法看。除以 2.0 意味着车速 2 m/s 以上才给满减速度，以下是线性衰减。p.p_max要按你的制动系统实际能力设，设太大没有意义，设太小会让高强度工况永远饱和。

执行器本身的延迟也不能省。CarSim 的制动系统有建压时间，Simulink 侧最好再串一个纯延迟加一阶惯性，纯延迟取 0.1~0.15 s 模拟管路传输，一阶惯性时间常数取 0.2 s 左右模拟压力建立过程。这两个数直接决定你的 TTC 阈值该设多激进——阈值设得紧、执行器又慢，结果就是"算到了但刹不住"。

4.4 数据输出与批量工况：一次点击跑出二十七组结果

单次仿真跑通只是开始，验收要的是矩阵。三个前车工况、三档附着、三档初速，组合起来 27 组，手工改参数跑一天也跑不完，而且中间难免出错。用脚本做参数扫描是必须的。

% run_aeb_sweep.m 批量工况扫描 scenes = {'cruise','hardbrake','cutin'}; mu_list = [0.85 0.55 0.30]; v0_list = [30 50 70]; % km/h results = table(); for i = 1:numel(scenes) for j = 1:numel(mu_list) for k = 1:numel(v0_list) in.scene = scenes{i}; in.mu = mu_list(j); in.v0_kph = v0_list(k); assignin('base','in',in); % 工况通过 base workspace 传给模型 sim('aeb_model.slx'); % 定步长运行，模型内部读 in 结构体 results = [results; summarize_run(logsout, in)]; %#ok<AGROW> end end end writetable(results, 'aeb_sweep_result.csv');

summarize_run是自己写的一个指标提取函数，输入是信号记录对象和工况参数，输出一行统计结果。这一步的字段设计比脚本本身更重要，我的字段清单是：初始车速、路面附着、前车工况、是否触发、首次触发时刻、首次触发时的 TTC、峰值减速度、最小 TTC、是否发生碰撞、碰撞时刻车速、制动距离。有了这一张表，后面画散点图、做敏感性分析、写论文里的结论段，全部从这里取数，不用再回头翻曲线。

信号记录一定要开，而且只记录需要的通道。全量记录 27 组会生成巨大的 MAT 文件，打开都费劲。通常记录七八个通道就够：车速、纵向加速度、主缸压力请求与实际、TTC、状态字、相对距离。

5. 常见问题排查：联调阶段最容易翻车的五个点

联调这套东西，跑通和不跑通之间往往只差一个小配置，但报错信息基本不会告诉你差在哪。下面五条是我和身边人踩过的坑，按出现频率排序，每条都按现象、原因、解决三步写，遇到问题可以直接对着查。

5.1 S-Function 加载失败或版本对不上

现象：Simulink 打开模型就弹错误，提示找不到某个 S-Function，或者一运行就崩溃退出。

原因：八成是 Carsim 生成 S-Function 时用的编译器版本和当前 MATLAB 的 mex 配置不一致，也可能是模型文件从另一台机器拷过来，绝对路径变了。这种情况和算法无关，属于纯环境问题，但排查起来最耗时间。

解决：先在 MATLAB 里执行mex -setup确认编译器可用，再回 Carsim 重新生成一次 S-Function，不要直接复用旧的 .dll 或 .mexw64。跨机器拷模型时，把 Carsim 的工作目录一起拷，并且在 Carsim 的 Run Control 里重新指定一次 Simulink 模型路径。

5.2 车不动、原地打滑，或者一开场就停车

现象：仿真跑起来车速曲线是一条平线，或者一开始就以某个减速度往下掉，但看模型连线又没发现问题。

原因：前者通常是油门没给——很多人的模型里只接了制动压力，油门保持默认 0，车自然不动；后者是制动初值没设对，Simulink 输出的压力初值是 0 但 Carsim 侧读到的是一个未初始化的值，或者 S-Function 的输入端口顺序接反了（把压力接到了油门口）。

解决：先在 Carsim 里单跑一次不带 Simulink 的工况，确认车辆能正常加速，再把 S-Function 加进来。接入后第一步不是跑 AEB，而是给一个固定 0 压力跑 2 s，看车速是否随油门正常上升。输入端口顺序一定要对着 Carsim 生成的端口列表逐个核对，别凭模块位置猜。

5.3 制动距离和减速度跟预期对不上

现象：策略明明请求了 8 m/s²，实际峰值减速度只有 5 出头，制动距离比手算长了一大截。

原因：分三种。一是单位没统一，车速用 km/h 直接参与了 m/s² 的运算；二是路面附着不够，μ=0.3 时物理上就到不了 8 m/s²，策略饱和但车不减速；三是执行器标定的dec_axis / press_axis是抄来的示意值，和自己 Carsim 里的制动系统模型完全不匹配。

解决：按顺序排除。先查单位，把所有接口信号在 Scope 里看一眼量级；再把 μ 设成 0.85 重跑，如果还是不够，就是标定问题。标定的正确做法是在 Carsim 里做阶跃压力试验，主缸压力从 1 MPa 扫到 8 MPa，每组跑 3 s，取稳态减速度，拟合成表填回press_axis。这一步偷懒，后面所有结论都站不住。

5.4 雷达距离曲线出现台阶、尖刺或者目标忽然消失

现象：相对距离曲线在某几个时刻突然跳变几十米，或者中途掉到哨兵值又跳回来，TTC 跟着出现尖峰，状态机误触发。

原因：三个常见来源。坐标系不一致，Carsim 输出的相对距离可能是全局坐标下的差值，而你的模型按车身坐标系理解；采样率不匹配，雷达模块 0.05 s 更新一次，但下游按 0.001 s 在读，中间没做零阶保持；丢目标处理不当，无效值用了 0。

解决：先在雷达模型输出端加一个 Scope，看原始曲线是否有台阶，有台阶就是采样率问题，加 Zero-Order Hold；没台阶但整体偏差一个固定量，就是坐标系问题，检查 Carsim 输出通道的定义。丢目标一律用远离量程的哨兵值，并且在感知层第一行就过滤掉。

5.5 同样的参数跑两遍结果不一样

现象：不动任何参数，连跑两次，制动距离差个零点几米，峰值减速度也对不上，答辩现场复现不出来。

原因：模型里有随机量但没有固定种子，雷达噪声每次都不一样；或者求解器设成了变步长，积分步长随信号变化；再或者某个模块的初始值依赖上一次运行的残留（比如 MATLAB Function 里的 persistent 变量没有清）。

解决：rng(0)放在初始化脚本最前面；求解器锁定定步长 ode4、步长 0.001；每次批量跑之前在脚本里clear掉 persistent 相关的函数，或者把初值改成通过参数传入而不是 persistent 保留。可复现性是仿真工作的底线，这一条不解决，前面所有结论都要打问号。

6. 验收与答辩：用一张工况矩阵表和三条曲线证明这套仿真站得住

做到这里，模型能跑、曲线能出，但离"能交"还差一步：怎么证明这套东西是对的。我的经验是，验收材料不要贪多，一张矩阵表加三条曲线足够，关键是每一项都能回答"为什么是这个数"。

6.1 验收工况矩阵与判据

矩阵的行是工况组合，列是判据，判据要可量化、可对照。下面这张表可以直接改成你自己的版本。

表里最容易被追问的是第四行和第五行。第四行考的是高速工况下 TTC 阈值够不够早，第五行考的是策略会不会过度反应——切入场景下前车只是缓减速，如果你的策略直接上全力制动，那就是误触发，实际装车会被投诉。这两行能过，策略的激进与保守就基本平衡了。

三条曲线分别是：相对距离与 TTC 的时程曲线（证明决策时机合理）、目标减速度与实际减速度的对比曲线（证明执行层跟得上）、制动压力与车速的联合曲线（证明整个闭环没有异常振荡）。三条曲线放在同一张图的三联子图里，一页纸说完全部故事。

6.2 答辩时最容易被追问的三个问题

第一个问题几乎必问："你的模型可信吗？"不要回答"Carsim 是行业标准"，这个回答等于没答。应该说清楚两件事：车辆参数从哪里来（整备质量、轴距、轮胎纵滑特性曲线），以及执行器标定是怎么做的（阶跃压力试验、几组、拟合误差多少）。参数有出处、标定有过程，可信度自然立得住。

第二个问题："为什么 μ=0.3 的时候刹不住？"这是送分题，答物理限制——轮胎能提供的最大纵向力就是 μ 乘以垂直载荷，μ=0.3 意味着理论最大减速度约 2.9 m/s²，策略请求 8 m/s² 只会让压力饱和，实际减速度不会更高。能把这个讲清楚，说明你真的理解模型在算什么。

第三个问题："如果换成摄像头，这套还成立吗？"诚实的回答是不完全成立。雷达链路对光照免疫，换成视觉就要重新建模逆光、夜间、雨雾对检测距离的影响，感知层的噪声模型也得重做。承认边界比硬撑全面要可信得多。

我自己在这套东西上吃过一次亏：第一批结果跑得很漂亮，所有工况都能避撞，兴冲冲拿去给导师看，被问了一句"你的雷达有没有延迟"，当场愣住。回来一查，雷达是理想直通，执行器也没加延迟，等于给 AEB 开了一个不存在的信息优势。加上 0.1 s 雷达滤波滞后和 0.15 s 建压延迟之后，70 km/h 那组直接撞了。从那以后我每次搭完闭环，都强制先把"传感器延迟、执行器延迟、噪声"这三样加进去跑一遍基线，再谈策略优化——先让模型变难，再去证明策略行得通，顺序反了，后面全是返工。希望这套结构和这几条经验，能帮你少走一段弯路。

本文还有配套的精品资源，点击获取