Simulink模型比较实战：从PID到模糊控制，数据驱动选型指南

1. 项目概述：模型比较的价值与场景

在工程研发和学术研究的日常里，我们经常会遇到一个看似简单却无比纠结的问题：面对一个复杂的系统设计，比如一个电机控制器、一个通信算法，或者一个整车的能量管理策略，手头有好几个备选的仿真模型方案，到底该选哪一个？是选那个响应最快但有点“抖”的滑模控制模型，还是选那个超调小但反应慢一拍的模糊PID模型？这个决策过程，如果只靠“感觉”或者“拍脑袋”，不仅效率低下，更可能把项目引入歧途，浪费大量时间在调试和返工上。这正是“模型比较”这项技术要解决的核心痛点。

“Leveraging Model Comparison to find what you need”，这个标题直译过来是“利用模型比较找到你所需”，它精准地概括了在Simulink这类仿真环境下，一种系统化、数据驱动的决策方法论。这绝不仅仅是打开几个示波器窗口看看波形那么简单。它是一套完整的流程，从明确你的设计目标（是追求动态响应速度、稳态精度、还是鲁棒性？），到搭建或获取不同的候选模型（比如经典的PID、先进的滑模控制SMC、或者基于人工智能的MPC、ANN等），再到设计公平、全面的测试场景（如光照突变、负载阶跃、局部遮挡等），最后通过关键性能指标的量化对比，客观地选出最适合当前任务的那个“最优解”。

对于经常使用Simulink进行控制系统、电力电子、通信系统甚至整车仿真的工程师和学生来说，掌握模型比较的技能，就如同拥有了一双“火眼金睛”。它能帮助你在纷繁复杂的算法和参数中，快速定位到性能瓶颈，理解不同模型结构（如Stateflow的状态机、FIS的模糊推理系统）的优劣，甚至指导你进行模型的融合与优化。无论是做四旋翼的飞控、柴油发电机的励磁调节、还是光伏MPPT算法的研究，模型比较都是将仿真从“看起来差不多”提升到“数据证明它更好”的关键一步。接下来，我将结合多年在Simulink中“折腾”各种模型的经验，拆解如何系统化地进行模型比较，并分享那些在官方手册里不会写的实操技巧和避坑指南。

2. 模型比较的核心思路与设计框架

2.1 明确比较目标：从需求到指标

进行模型比较的第一步，也是最容易犯错的一步，就是盲目开始仿真。你必须先回答一个问题：“我需要这个模型做什么？”这个问题的答案，直接决定了后续所有比较工作的方向和评判标准。

以搜索热词中的几个典型场景为例：

  • 四旋翼滑模控制：核心目标可能是抗干扰能力（如抵抗突风）和轨迹跟踪精度。那么比较指标就应该侧重于调节时间、超调量，以及在加入外部扰动后姿态角的恢复能力。
  • 模糊PID控制：目标往往是在非线性、模型不确定的系统中获得比传统PID更优的动态性能。比较时就需要关注上升时间、稳态误差，以及当系统参数（如被控对象增益）发生变化时，两种控制器性能的衰减程度。
  • MPC光储制氢系统波形优化：目标可能是在多约束条件下（如蓄电池SOC、制氢设备电流限制）实现经济性最优或可再生能源消纳最大化。这时比较指标就变成了综合成本、氢产量、光伏弃光率等经济与技术指标，而不仅仅是某个电压或电流的跟踪波形。

因此，在Simulink中开始任何比较之前，务必在纸上或文档中清晰定义：

  1. 核心需求：快速响应？绝对稳定？能耗最低？成本最优？
  2. 关键性能指标：将这些需求转化为可量化的仿真输出信号。例如：
    • 时域指标：上升时间、调节时间、超调量、稳态误差。
    • 频域指标：带宽、相位裕度、增益裕度（可通过线性化工具获得）。
    • 能量/经济指标：总能耗、效率、特定工况下的积分量。
    • 鲁棒性指标：在参数摄动或干扰下的性能保持度。
  3. 测试场景：模型将在什么条件下被考验？是标准的阶跃响应，还是搜索词中提到的“光照突变”、“局部遮挡”这类极端工况？设计覆盖典型、边界和故障情况的测试用例库。

实操心得：我习惯在Simulink中专门建立一个“Test Harness”（测试框架）或者使用“Simulation Scenarios”来管理这些测试场景。把不同的输入信号（阶跃、正弦扫频、自定义的工况序列）做成可切换的模块，这样在切换模型时，测试环境是完全一致的，保证了比较的公平性。

2.2 候选模型的准备与标准化

有了明确的目标，接下来就是准备参与“竞赛”的选手——各个候选模型。这些模型可能来源多样：

  • 自建模型：自己从头搭建的Simulink模型。
  • 参考模型：从MATLAB官方示例、教科书或论文中复现的模型。
  • 模型库/社区模型：从Simulink库、File Exchange或CSDN等平台下载的模型（如热词中的“风电场并网仿真模型”）。

这里有一个至关重要的步骤：模型接口标准化。无论模型内部多么复杂，它们与被控对象（Plant）或测试环境的输入输出接口必须统一。例如，所有控制器模型的输出都应该是占空比信号或转矩指令，并且信号名称、数据类型（double,single）最好一致。这可以通过Simulink中的Inport,Outport,Bus对象以及模型引用（Model Reference）来规范。

为什么强调标准化？如果不统一接口，在切换模型进行批量仿真时，你会陷入无穷无尽的信号线连接错误和数据类型匹配问题中，比较效率大打折扣。我通常的做法是创建一个“控制器外壳”子系统，内部用一个“Model”模块来引用不同的.slx文件，而外壳的输入输出端口是固定不变的。

2.3 工具选型：Simulink内置与自定义工具链

Simulink本身提供了强大的工具来辅助模型比较，但很多时候需要组合使用。

  1. 仿真数据检查与记录：这是基础。务必使用To Workspace模块或Simulink.sdi（Simulation Data Inspector）来记录需要比较的关键信号。SDI的优势在于能同时可视化多条运行结果，并直接计算差异。
  2. 参数化管理：使用MATLAB工作空间的变量、Simulink.Parameter对象或者数据字典（Data Dictionary）来管理模型参数。这样，你可以用MATLAB脚本一键切换不同控制器模型的参数集（比如一组PID参数和一组模糊逻辑表），实现自动化比较。
  3. 自动化脚本：这是实现高效、可重复比较的核心。编写MATLAB脚本（.m文件）来自动完成以下工作：
    • 批量修改模型参数（如热词中提到的.m生成simulink参数）。
    • 依次加载和运行不同候选模型。
    • 从SDI或工作空间提取仿真数据。
    • 计算预设的各项性能指标（如ISE， IAE）。
    • 将结果汇总到表格或图形化报告中。
  4. 自定义评估模块：对于复杂的指标，可以在Simulink中直接搭建评估子系统。例如，用一个积分器计算误差的平方（ISE），或者用逻辑判断模块统计超调次数。

注意事项：使用Simulink.sdi时，注意每次运行前最好用Simulink.sdi.clear清空之前的数据，或者给每次运行打上清晰的标签（如RunName），防止数据混淆。对于大量数据的比较，SDI的图形界面可能会变慢，此时用脚本直接从Simulink.sdi.Run对象中提取数据数组进行离线分析更高效。

3. 实施模型比较的详细操作流程

3.1 搭建统一的测试仿真环境

我们以一个具体的例子贯穿本流程：比较传统PID和模糊PID对一个直流电机速度环的控制效果。这是热词“双闭环直流调速simulink”中的一个典型子问题。

  1. 建立被控对象模型：首先，搭建一个尽可能准确的直流电机数学模型（包含电枢电感、电阻、机电时间常数等）。可以将其封装成一个子系统，命名为DC_Motor_Plant。
  2. 创建测试输入与干扰：在模型顶层，添加信号源模块。至少包括：
    • 参考速度信号：一个从0到额定转速的阶跃信号，用于测试动态响应。
    • 负载转矩干扰：在仿真中后期加入一个阶跃负载，用于测试抗扰性能。
    • 测量噪声：可以在反馈通道上加一个小功率的白噪声模块，测试控制器的滤波特性（可选）。
  3. 设计“控制器插槽”：这是关键。不要将PID控制器直接连在电机模型上。而是：
    • 创建一个名为Controller_Slot的子系统。
    • 在该子系统内，放置一个Model模块（来自Ports & Subsystems库）。
    • 将Model模块的Model name参数设置为PID_Controller.slx（这是一个独立的PID控制器模型文件）。
    • 在Controller_Slot子系统的边界上，定义好输入端口（如速度误差,积分复位）和输出端口（如电枢电压）。
  4. 配置数据记录：在电机速度输出端、控制器输出端连接To Workspace模块，并设置变量名为speed_PID,voltage_PID， 保存格式选Structure With Time。同时，也打开SDI进行记录。

这样，我们就有了一个标准的“擂台”。接下来，我们只需要替换Controller_Slot里引用的模型文件，就可以让不同的“选手”在完全相同的“赛道”（被控对象和测试输入）上比赛。

3.2 创建并封装候选控制器模型

现在，创建两位“选手”模型。

  1. 创建PID控制器模型(PID_Controller.slx)：
    • 使用Simulink自带的PID Controller模块，或者用增益、积分、微分模块自己搭建。
    • 调整其输入输出端口，使其与Controller_Slot的接口定义完全匹配。
    • 将PID的Kp,Ki,Kd参数设置为MATLAB工作空间变量（如Kp_val,Ki_val），而不是硬编码的数字。这样便于脚本调整。
  2. 创建模糊PID控制器模型(Fuzzy_PID_Controller.slx)：
    • 使用Fuzzy Logic Controller模块。首先在MATLAB命令行用fuzzy打开模糊逻辑设计器，设计一个二维模糊控制器（输入：误差e和误差变化率ec；输出：控制量增量u）。
    • 定义模糊集和规则表。例如，e和ec分为{NB, NM, NS, ZO, PS, PM, PB}，规则可以是“if e is PB and ec is NB then u is PB”。
    • 设计完成后，将设计好的FIS结构导出到工作空间（如myFIS），并在Fuzzy Logic Controller模块中指定该变量。
    • 同样，确保其输入输出端口与标准接口一致。
  3. 参数初始化脚本：编写一个init_controllers.m脚本。在这个脚本里，分别定义两套参数：
    % PID 参数 PID_params.Kp = 1.5; PID_params.Ki = 0.8; PID_params.Kd = 0.05; % 模糊PID参数（这里主要指论域范围缩放因子） Fuzzy_params.Ke = 0.5; % 误差缩放因子 Fuzzy_params.Kec = 0.1; % 误差变化率缩放因子 Fuzzy_params.Ku = 2.0; % 输出缩放因子 % 保存参数，供Simulink模型使用 assignin('base', 'PID_params', PID_params); assignin('base', 'Fuzzy_params', Fuzzy_params);

3.3 编写自动化比较与评估脚本

这是将整个流程串联起来，并产出决定性结论的大脑。创建一个run_model_comparison.m脚本。

%% 1. 清空环境，加载参数 clear; close all; clc; run('init_controllers.m'); % 初始化参数 %% 2. 加载顶层测试模型 top_model = 'DC_Motor_TestBench'; % 你的顶层测试模型名 load_system(top_model); %% 3. 定义要测试的控制器模型列表 controller_list = {'PID_Controller', 'Fuzzy_PID_Controller'}; results = struct(); % 用于存储结果的结构体 %% 4. 循环遍历每个控制器进行仿真 for i = 1:length(controller_list) ctrl_name = controller_list{i}; fprintf('正在测试控制器: %s\n', ctrl_name); % 4.1 动态修改顶层模型中的控制器引用 % 找到Controller_Slot子系统中的Model模块路径 model_block_path = [top_model '/Controller_Slot/Controller_Model']; % 设置其引用的模型文件 set_param(model_block_path, 'ModelName', ctrl_name); % 4.2 根据控制器类型设置对应参数（这里需要更精细的参数传递，示例简化） % 实际中可能需要通过set_param设置模块内部参数，或使用模型工作空间 if strcmp(ctrl_name, 'PID_Controller') % 设置PID参数到对应变量，假设PID模块直接读取base workspace的PID_params % 已在init中完成 else % 配置模糊控制器参数，可能需要加载并设置FIS fis = readfis('myFuzzyPID.fis'); % 假设已保存为文件 % 调整FIS的输入输出范围（通过缩放因子） fis.Input(1).Range = [-Fuzzy_params.Ke, Fuzzy_params.Ke]; fis.Input(2).Range = [-Fuzzy_params.Kec, Fuzzy_params.Kec]; fis.Output(1).Range = [-Fuzzy_params.Ku, Fuzzy_params.Ku]; assignin('base', 'myFIS', fis); end % 4.3 运行仿真 simOut = sim(top_model, 'SaveOutput', 'on', 'SaveState', 'on'); % 4.4 提取仿真数据并计算性能指标 time = simOut.tout; speed = simOut.logsout.get('speed').Values.Data; % 假设信号已命名并记录 ref_speed = ... % 获取参考信号数据 control_effort = simOut.logsout.get('voltage').Values.Data; % 计算误差 error = ref_speed - speed; % 计算关键指标 % a. 上升时间 (10% -> 90%) rise_time = calculateRiseTime(time, speed, ref_speed(end)); % b. 调节时间 (进入±2%误差带) settling_time = calculateSettlingTime(time, error, 0.02); % c. 超调量 overshoot = (max(speed) - ref_speed(end)) / ref_speed(end) * 100; % d. 稳态误差 (取最后一段时间均值) steady_state_error = mean(error(round(end*0.9):end)); % e. 控制量总变化 (衡量控制平滑度/能耗) control_variation = sum(abs(diff(control_effort))); % 4.5 存储结果 results.(ctrl_name).RiseTime = rise_time; results.(ctrl_name).SettlingTime = settling_time; results.(ctrl_name).Overshoot = overshoot; results.(ctrl_name).SteadyStateError = steady_state_error; results.(ctrl_name).ControlVariation = control_variation; results.(ctrl_name).Time = time; results.(ctrl_name).Speed = speed; results.(ctrl_name).ControlEffort = control_effort; fprintf(' 上升时间: %.3f s, 调节时间: %.3f s, 超调: %.2f%%\n', ... rise_time, settling_time, overshoot); end %% 5. 结果可视化与报告生成 % 5.1 绘制速度响应对比曲线 figure('Position', [100, 100, 1200, 500]); subplot(1,2,1); hold on; for i = 1:length(controller_list) ctrl_name = controller_list{i}; plot(results.(ctrl_name).Time, results.(ctrl_name).Speed, 'LineWidth', 1.5, 'DisplayName', ctrl_name); end plot([time(1), time(end)], [ref_speed(end), ref_speed(end)], 'k--', 'DisplayName', '参考值'); xlabel('时间 (s)'); ylabel('转速 (rpm)'); title('速度响应对比'); legend('show'); grid on; % 5.2 绘制控制量对比曲线 subplot(1,2,2); hold on; for i = 1:length(controller_list) ctrl_name = controller_list{i}; plot(results.(ctrl_name).Time, results.(ctrl_name).ControlEffort, 'LineWidth', 1.5, 'DisplayName', ctrl_name); end xlabel('时间 (s)'); ylabel('控制电压 (V)'); title('控制量输出对比'); legend('show'); grid on; % 5.3 生成性能指标对比表格 fprintf('\n========== 性能指标汇总 ==========\n'); fprintf('控制器\t\t上升时间(s)\t调节时间(s)\t超调(%%)\t稳态误差\t控制变化量\n'); fprintf('-----------------------------------------------------------------------------\n'); for i = 1:length(controller_list) ctrl_name = controller_list{i}; r = results.(ctrl_name); fprintf('%-20s\t%.3f\t\t%.3f\t\t%.2f\t\t%.4f\t\t%.2f\n', ... ctrl_name, r.RiseTime, r.SettlingTime, r.Overshoot, r.SteadyStateError, r.ControlVariation); end %% 6. 基于权重的综合评分（示例） % 根据项目需求定义权重 weights.RiseTime = 0.25; weights.SettlingTime = 0.25; weights.Overshoot = 0.20; weights.SteadyStateError = 0.20; weights.ControlVariation = 0.10; % 希望控制平滑 fprintf('\n========== 综合评分 (加权平均，分数越低越好) ==========\n'); for i = 1:length(controller_list) ctrl_name = controller_list{i}; r = results.(ctrl_name); % 对每个指标进行归一化（假设以PID结果为基准） % 这里采用简单的线性归一化，实际可能需要更复杂的处理（如log缩放） score = weights.RiseTime * (r.RiseTime / results.PID_Controller.RiseTime) + ... weights.SettlingTime * (r.SettlingTime / results.PID_Controller.SettlingTime) + ... weights.Overshoot * (r.Overshoot / max(1, results.PID_Controller.Overshoot)) + ... % 避免除零 weights.SteadyStateError * (abs(r.SteadyStateError) / max(1e-6, abs(results.PID_Controller.SteadyStateError))) + ... weights.ControlVariation * (r.ControlVariation / results.PID_Controller.ControlVariation); fprintf('%s: %.3f\n', ctrl_name, score); end

这个脚本自动化了整个比较流程。你只需要运行它，就能得到清晰的对比曲线和量化的指标表格，甚至一个根据你偏好加权的综合评分。

4. 高级技巧与深度分析

4.1 处理复杂模型与联合仿真

当模型变得复杂，比如涉及热词中的“Carsim与Simulink联合仿真”、“Prescan和Simulink联合仿真”或“Stateflow”状态机时，比较的复杂度会增加。

  • 联合仿真：关键在于时钟同步和数据交换接口。确保主仿真器（如Simulink）和从仿真器（如Carsim）的步长设置合理，数据通过S-Function或专用的接口模块（如Carsim的S-Function Block）正确传递。在进行模型比较时，联合仿真的配置（如IP地址、端口、共享内存设置）必须作为测试环境的一部分严格保持一致。比较的指标可能更侧重于高层性能，如车辆轨迹跟踪误差、碰撞时间（TTC）等，而非底层控制信号。
  • Stateflow状态机：比较包含Stateflow的模型时，除了输入输出性能，还应关注状态转移的逻辑正确性和时序。可以利用Stateflow的调试和动画功能，观察在相同测试用例下，不同设计的状态迁移路径是否一致、是否出现了非预期的状态跳转。也可以将关键状态（Stateflow.State）作为信号输出记录，比较状态序列的差异。
  • 模型离散化与求解器配置：对于“simulink模型一键离散化”的需求，如果比较的模型中既有连续又有离散部分，或者离散化速率不同，必须统一求解器设置。使用Fixed-Step求解器并指定一个合适的、能覆盖所有模型动态的步长。不匹配的求解器设置是导致比较结果失真的常见原因。

4.2 不确定性分析与鲁棒性测试

一个优秀的模型不仅要在标称工况下表现好，更要在不确定性面前保持稳健。这就是鲁棒性。我们可以扩展我们的比较框架来评估这一点。

  1. 参数摄动分析：使用Simulink的Parameter Estimation或Sensitivity Analysis工具，也可以手动编写脚本。例如，在电机模型中，让转动惯量J和阻尼系数B在±20%范围内随机变化，然后运行蒙特卡洛仿真（比如100次）。

    num_runs = 100; J_nominal = 0.01; B_nominal = 0.001; variation = 0.2; % ±20% for run_idx = 1:num_runs J_perturbed = J_nominal * (1 + variation*(2*rand-1)); B_perturbed = B_nominal * (1 + variation*(2*rand-1)); assignin('base', 'J', J_perturbed); assignin('base', 'B', B_perturbed); % ... 运行仿真并记录每次的性能指标 ... end

    最后，统计每个控制器在参数摄动下，各项性能指标（如调节时间）的均值、方差和极值。方差小的控制器鲁棒性更优。

  2. 干扰与噪声测试：除了标准的负载干扰，可以加入不同频率和幅值的正弦干扰、随机脉冲干扰，或者像热词中提到的“光照突变”（对应光伏系统的辐照度阶跃）、“局部遮挡”等特定场景的干扰模型。观察控制器恢复稳态的速度和最大偏差。

  3. 模型失配测试：故意使用一个简化或有误差的“被控对象模型”来设计控制器，然后在更接近真实情况的“评估对象模型”上进行测试。这能检验控制器的模型不敏感性。

通过引入这些不确定性测试，你的模型比较就从“理想环境下的选美”，升级为“复杂战场上的实战考核”，选出的结果也更具工程指导意义。

4.3 结果解读与决策支持

拿到一堆数据和图表后，如何做出最终选择？这需要结合工程直觉和量化分析。

  1. 权衡分析：很少有控制器在所有指标上都完胜。通常会出现“跷跷板”现象，比如响应快了但超调大了，或者稳态精度高了但控制量抖动了（高频分量多）。这时就需要根据项目优先级进行权衡。前面脚本中的“综合评分”就是一种量化权衡的方法，但权重的设定本身就需要经验。
  2. 可视化辅助决策：除了时域曲线，可以绘制帕累托前沿图。以两个关键指标（如上升时间和超调量）为坐标轴，将每个控制器的性能点画在图上。那些落在左下角（两者都小）且不被其他点“支配”的点，就是帕累托最优解。这能直观展示不同控制器在性能权衡中所处的位置。
  3. 考虑实现复杂度：模糊PID的控制效果可能略好于传统PID，但其需要在线计算模糊推理，对处理器的计算资源要求更高，且参数整定（模糊规则和隶属度函数）更依赖经验。如果目标硬件资源紧张，传统PID可能是更务实的选择。Simulink提供的代码生成和处理器在环（PIL）测试功能，可以帮助评估不同算法在真实硬件上的开销和表现。
  4. 生成专业报告：使用MATLAB的Report Generator工具，可以将你的比较脚本、生成的图表、指标表格自动整合成一份PDF或HTML格式的专业报告，方便与团队或导师分享讨论。

5. 常见陷阱、问题排查与实战心得

即使流程看起来完美，实际操作中依然会遇到各种“坑”。以下是一些高频问题和我的解决经验。

5.1 仿真结果不一致或不可复现

  • 问题：两次运行同一个模型，结果有微小差异；或者在别人的电脑上无法复现你的结果。
  • 排查与解决：
    1. 检查随机种子：如果模型中使用了随机数源（如白噪声），务必使用rng函数固定随机种子，例如rng(0, 'twister')。
    2. 确认求解器与步长：确保模型配置参数中的求解器类型、步长（特别是固定步长）、容差设置完全一致。这是导致结果差异的最常见原因之一。
    3. 清理工作空间：在运行脚本前，使用clear,close all,clc清理环境，避免残留变量干扰。
    4. 检查模型版本与库链接：确保Simulink版本一致，并且所有引用的自定义库或模块路径正确。有时模型会包含绝对路径，换台电脑就失效了。尽量使用相对路径或MATLAB搜索路径管理。
    5. 禁用加速模式：在调试和比较阶段，将仿真模式设置为Normal而非Accelerator或Rapid Accelerator，虽然慢一点，但能排除代码生成优化带来的潜在不一致。

5.2 性能指标计算异常

  • 问题：计算出的上升时间、调节时间是NaN或明显不合理。
  • 排查与解决：
    1. 检查信号数据：首先绘制出原始的响应曲线，肉眼观察是否收敛。可能系统本身就不稳定，导致响应发散。
    2. 验证算法逻辑：检查自定义的calculateRiseTime,calculateSettlingTime等函数。确保它们能正确处理非单调上升的曲线（有震荡时），并且对稳态值的容差判断（如±2%）设置合理。
    3. 处理初始瞬态：如果系统在初始时刻有较大的非零状态或冲击，可能会干扰指标计算。可以考虑忽略仿真开始的一小段时间数据。
    4. 数据类型与维度：确保从仿真输出中提取的数据是期望的向量或矩阵，没有意外的封装（如timeseries对象套timeseries）。使用squeeze或(:)操作符来确保数据维度正确。

5.3 模型切换与参数管理混乱

  • 问题：在脚本中切换模型引用时，参数没有正确传递，导致仿真错误或结果不对。
  • 排查与解决：
    1. 使用模型工作空间：对于每个独立的控制器模型（.slx），使用其自身的“模型工作空间”来管理私有参数。这样能避免不同模型间的参数名冲突。在脚本中，可以使用hws = get_param(ctrl_name, 'ModelWorkspace')和assignin(hws, 'varName', value)来赋值。
    2. 显式传递参数：如果使用基础工作空间变量，确保在切换模型后，脚本重新为当前模型所需的变量赋值。不要依赖之前模型运行后残留的变量值。
    3. 善用回调函数：在模型的“模型属性”->“回调函数”中，如PreLoadFcn或InitFcn，编写一小段代码来初始化该模型专用的参数。这样当模型被加载时，参数会自动设置好。

5.4 仿真速度过慢，影响比较效率

  • 问题：模型复杂，加上蒙特卡洛分析等，跑一次循环耗时很长。
  • 排查与解决：
    1. 启用加速模式：在最终确认脚本无误后，可以尝试使用Accelerator模式。它会编译部分代码，显著提升后续仿真速度。
    2. 使用parfor并行计算：如果循环迭代（如蒙特卡洛仿真）之间完全独立，可以使用MATLAB的并行计算工具箱，用parfor替代for循环，充分利用多核CPU。
    3. 简化模型：在比较的早期阶段，可以使用被控对象的简化降阶模型来快速筛选掉明显不合适的控制器，节省时间。待范围缩小后，再用高保真模型进行精细比较。
    4. 调整求解器：对于纯离散系统，使用Fixed-Step Discrete求解器；对于刚性问题，尝试ode15s或ode23t。选择合适的求解器能大幅提升速度。

我个人最深刻的一个教训是：曾经为了比较三个不同的MPC控制器，花了大量时间手动切换模型、运行、记录数据、画图。整个过程繁琐易错，一旦测试用例改动就要全部重来。自从建立了本文所述的自动化脚本框架后，同样的工作现在只需要修改一下测试输入的定义和控制器列表，然后泡杯咖啡，等待脚本运行完毕并生成图文并茂的报告即可。这不仅仅是效率的提升，更重要的是保证了比较过程的严谨性和可复现性，让决策从“我觉得”变成了“数据表明”。模型比较不是一次性的任务，而应成为你Simulink建模工作流中的一个标准环节。