2、测试环境搭建：MATLAB/Simulink环境配置、必要的工具箱安装、模型在环测试框架介绍、仿真参数设置

2.1 MATLAB/Simulink环境配置——别小看这一步

说实话，我见过太多工程师一上来就急着写模型，结果环境没配好，后面折腾半天。咱们做MIL测试，第一步就是把MATLAB/Simulink的窝搭舒服了。

我个人习惯用R2021b以上的版本。为什么？因为从这版开始，对汽车电子相关的工具箱支持更稳定了。你想想看，要是用个老版本，装个工具箱还得打补丁，多闹心。

环境配置的几个关键点：

  • 工作路径设置：别把项目文件丢在MATLAB默认路径下。我建议单独建一个文件夹，比如 D:\MIL_Project\，然后通过 Set Path 添加进来。我在项目中遇到过，有人把文件散落在桌面，结果模型引用路径全乱了，排查了一下午。
  • 编码格式统一：Simulink模型默认用UTF-8，但有些老项目是GBK。嗯，这里要注意，混用会导致中文注释乱码。我一般统一用UTF-8，省心。
  • 版本兼容性检查：如果你团队里有人用R2020a，有人用R2022b，那模型来回传的时候，记得用 slxmlcomp 做差异对比。我曾经因为版本不一致，模型里一个模块参数自动变了，仿真结果对不上，差点把锅甩给算法同事。
小技巧：在MATLAB启动时，可以写个 startup.m 脚本，自动加载你常用的工具箱路径和项目配置。这样每次打开MATLAB，环境就自动就绪了。

2.2 必要的工具箱安装——少了哪个都不行

做MIL测试，工具箱就像工具箱里的扳手，少一个你就拧不动螺丝。我列个清单，你看看自己装全了没。

工具箱名称 用途 备注
Simulink 基础建模与仿真 必装，不用多说
Simulink Test 测试用例管理、测试执行、结果评估 MIL测试的核心工具箱
Simulink Coverage 代码覆盖率分析 判断测试是否充分
Stateflow 状态机建模 做逻辑控制必用
Vehicle Dynamics Blockset 车辆动力学模型 做整车级MIL测试时用
Embedded Coder 生成嵌入式代码 虽然MIL阶段用不到，但为后续SIL/HIL做准备

我记得有一次，项目组新来了个同事，装了半天环境，结果Simulink Test没装。他跑测试用例的时候，发现没有 sltest.testmanager 这个命令，急得满头大汗。说白了，工具箱装不全，后面全是坑。

注意：工具箱安装后，记得重启MATLAB。有些工具箱的许可证需要重新激活，尤其是网络版许可证。我遇到过装完工具箱，仿真时提示“License checkout failed”，就是因为忘了激活。

2.3 模型在环测试框架介绍——MIL到底怎么玩

MIL测试，说白了就是把你的控制算法模型，放到一个虚拟的“车”里跑一圈。这个“车”就是被控对象模型，比如发动机模型、电机模型、整车动力学模型。

典型的MIL测试框架长这样：

+-------------------+       +-------------------+
|                   |       |                   |
|  测试用例生成器    | ----> |  控制器模型       |
|  (Test Harness)   |       |  (Controller)     |
|                   |       |                   |
+-------------------+       +--------+----------+
                                      |
                                      v
                            +-------------------+
                            |                   |
                            |  被控对象模型     |
                            |  (Plant Model)    |
                            |                   |
                            +--------+----------+
                                     |
                                     v
                            +-------------------+
                            |                   |
                            |  测试结果评估器   |
                            |  (Test Assessment)|
                            |                   |
                            +-------------------+

我个人习惯用 Test Harness 来搭建这个框架。Simulink Test里自带这个功能，你只需要右键点击控制器模型，选择“Create Test Harness”，它会自动帮你生成一个包含输入输出接口的测试环境。

你想想看，如果没有这个框架，你得手动搭信号源、手动接示波器、手动比对结果。有了Test Harness，这些活都自动化了。

框架搭建的几个要点：

  • 接口对齐：控制器模型的输入输出，必须和被控对象模型一一对应。名字、数据类型、维度都不能错。我曾经因为一个信号名字写成了 speed_ref 而不是 Speed_Ref，结果仿真报错，查了半天。
  • 测试用例独立：每个测试用例应该是一个独立的 .m 文件或 .xlsx 文件，不要写在模型里。这样方便管理和复用。
  • 结果自动评估：用 sltest.TestCase 里的 Assessment 模块，设定好通过/失败的条件。比如“信号A的上升时间小于100ms”，或者“稳态误差小于1%”。
核心思想：MIL测试不是“跑一遍看看结果”，而是“用自动化框架，批量跑用例，自动判结果”。这才是工程化的做法。

2.4 仿真参数设置——细节决定成败

仿真参数设置，看着简单，其实门道不少。我见过有人直接用默认参数跑MIL，结果仿真步长太大，信号都失真了，还在那分析结果呢。

几个关键参数，我一个个说：

  1. 求解器选择：
    • 连续系统用 ode45 或 ode23t。我一般用 ode23t，因为它对刚性系统更友好。
    • 离散系统用 discrete。如果你的控制器模型是离散的（比如采样时间1ms），那就选这个，别选连续求解器，否则仿真速度会慢得离谱。
  2. 步长设置：
    • 固定步长：比如 1e-3（1ms）。适合离散系统，仿真结果可重复。
    • 可变步长：适合连续系统，但结果可能因步长变化而略有差异。我建议在MIL阶段用固定步长，保证结果一致性。
  3. 仿真时间：
    • 别设太短。比如你测一个加速过程，至少得跑10秒以上。我习惯先设个30秒，看看信号是否稳定，再调整。
  4. 数据记录：
    • 勾选 Log signals to workspace，这样仿真结束后，数据会存到MATLAB工作区，方便后续分析。
    • 我一般会把关键信号都打勾，比如 speed、torque、current。别怕数据多，后面分析时你就知道好处了。
避坑指南：我曾经因为仿真步长设得太小（比如1e-6），结果一个10秒的仿真跑了半小时。后来发现，对于MIL测试，1ms的步长完全够用。别盲目追求小步长，仿真速度也很重要。

好了，环境搭好了，工具箱装齐了，框架也建起来了，参数也设对了。下一步，咱们就可以开始写测试用例了。别急，下一章我跟你聊聊怎么设计一个靠谱的MIL测试用例。

← 上一章 📖 返回目录 下一章 →