第二章 开发环境搭建：MATLAB/Simulink安装与配置、必备工具箱介绍、项目文件夹结构设计
好，咱们正式开始动手了。
做MIL测试，第一件事就是把“战场”给铺好。说白了，就是装好MATLAB/Simulink，配好工具箱，再把项目文件夹结构搭起来。这一步要是马虎了，后面有你头疼的。
我记得刚入行那会儿，带我的老工程师第一句话就是：“先把环境整利索了，再谈测试。”当时我不理解，觉得装个软件有啥难的？后来自己带项目了才明白——环境乱，项目就乱；项目乱，测试结果就没人敢信。
2.1 MATLAB/Simulink安装与配置
先说说版本选择。我个人习惯是：不追新，不守旧。什么意思呢？
- 别装最新版：最新版往往有兼容性问题，第三方工具箱可能还没适配。我在2021年吃过这个亏，装了R2021a，结果公司用的一个老版CAN通信库死活跑不起来，折腾了两天。
- 也别用太老的：比如R2018b之前的版本，对MIL测试的一些新特性支持不好，比如Test Manager里的参数化测试功能。
- 推荐版本：目前来看，R2020b到R2022b这几个版本最稳。如果你跟主机厂合作，他们通常指定版本，那就按他们的来。
安装过程我就不啰嗦了，一路Next就行。但有几点配置你得注意：
安装后的关键配置：
- 设置中文界面：虽然我建议用英文（避免一些奇怪的编码问题），但如果你英文看着费劲，可以在预设项里把语言改成中文。
- 配置编译器：Simulink编译模型需要C编译器。Windows上我推荐装MinGW-w64，MATLAB里直接运行
matlab.addons.install('MinGW-w64')就能装。千万别用VS，太笨重了。 - 设置工作路径：把项目文件夹加到MATLAB路径里。用
addpath(genpath('你的项目路径'))一次性搞定。
小技巧： 在MATLAB启动文件 startup.m 里写好路径配置，这样每次打开MATLAB，环境就自动配好了。省心。
2.2 必备工具箱介绍
做MIL测试，不是装个Simulink就完事了。你得配齐“家伙什儿”。我按重要性排了个序：
| 工具箱名称 | 用途 | 我的评价 |
|---|---|---|
| Simulink Test | 测试用例管理、测试执行、覆盖率分析 | 核心中的核心，没有它你没法做正规的MIL测试 |
| Simulink Coverage | 模型覆盖率分析（语句、分支、MC/DC） | 主机厂审核必查项，尤其是MC/DC覆盖率 |
| Simulink Design Verifier | 形式化验证、自动生成测试用例 | 高级功能，但能帮你发现隐藏很深的逻辑错误 |
| Stateflow | 状态机建模与测试 | 如果你的模型里有状态逻辑，这个必须装 |
| MATLAB Report Generator | 自动生成测试报告 | 省去你手动写报告的痛苦，一键生成PDF |
| Simulink Requirements | 需求链接与追溯 | 做ASPICE或功能安全项目时必备 |
嗯，这里要注意：Simulink Test和Simulink Coverage是底线。没有这两个，你做的MIL测试在评审时根本站不住脚。我曾经见过一个项目，测试团队没装Coverage工具箱，结果客户审核时问“你们的覆盖率数据呢？”全场鸦雀无声……
避坑指南： 工具箱的许可证类型要搞清楚。很多公司买的是“命名用户”许可证，换台电脑就得重新激活。我建议用“网络浮动许可证”，团队里谁用谁取，灵活得多。
2.3 项目文件夹结构设计
这部分看着简单，但其实是整个MIL测试流程的“地基”。
你想想看，一个项目跑下来，模型文件、测试用例、测试结果、报告……几十上百个文件。如果随便往一个文件夹里堆，找东西能找疯掉。
我个人的项目结构是这样的：
Project_Root/
│
├── 01_Requirements/ # 需求文档（.slreqx, .docx, .xlsx）
│ ├── Customer_Req/ # 客户原始需求
│ └── Technical_Req/ # 技术需求分解
│
├── 02_Model/ # 模型文件
│ ├── Plant_Model/ # 被控对象模型
│ ├── Controller_Model/ # 控制器模型（待测）
│ └── Test_Harness/ # 测试夹具模型
│
├── 03_Test_Specification/ # 测试规范
│ ├── Test_Cases/ # 测试用例（.m, .xlsx）
│ └── Test_Sequences/ # 测试序列（.mldatx）
│
├── 04_Test_Results/ # 测试结果
│ ├── MIL_Results/ # MIL测试结果
│ └── Coverage_Reports/ # 覆盖率报告
│
├── 05_Reports/ # 生成的报告
│ ├── Test_Report/ # 测试报告PDF
│ └── Review_Report/ # 评审报告
│
├── 06_Scripts/ # 辅助脚本
│ ├── Utility/ # 工具函数
│ └── Post_Processing/ # 后处理脚本
│
├── 07_Configuration/ # 配置数据
│ ├── Parameter_Sets/ # 参数集
│ └── Calibration/ # 标定数据
│
└── README.md # 项目说明文件为什么这么分？我解释一下：
- 数字前缀：01、02……这样排序，文件夹在资源管理器里自然按顺序排列，找起来一目了然。
- 模型和测试分离：模型归模型，测试归测试。别混在一起，否则版本管理会乱套。
- 测试结果单独存放：每次跑完测试，结果自动存到
04_Test_Results下，按日期或版本号建子文件夹。这样回溯问题很方便。
我的习惯： 在项目根目录放一个 init_project.m 脚本，里面写好路径添加、参数加载、模型初始化等操作。每次打开项目，先跑这个脚本，环境就全好了。省得每次手动配来配去。
说到版本管理，我强烈建议用Git。虽然Simulink模型是二进制文件，不好做diff，但至少能记录谁在什么时候改了什么东西。我在项目里一般这样配：
# .gitignore 文件内容
*.slxc # 忽略Simulink缓存
*.mex* # 忽略编译文件
slprj/ # 忽略生成代码目录
04_Test_Results/*.mat # 忽略大的结果文件（可选）
好了，环境搭好了，结构也理清了。下一步，咱们就可以正式开始写测试用例了。
记住一句话：好的开始是成功的一半。环境搭建花点时间，后面能省你十倍的时间。