1. 课程导入与MIL验证全景

在控制系统研发中，最昂贵的错误往往不是代码写错，而是需求理解错、控制逻辑设计错、接口定义错。这些问题如果等到台架试验甚至实车阶段才暴露，修复成本会成倍上升。MIL（Model-in-the-Loop，模型在环）验证的核心价值，就是在还没有真实控制器、还没有被控对象样机之前，用可执行的模型把控制功能"跑起来"，尽早发现逻辑缺陷、边界问题和接口不一致。

本课程围绕"控制系统功能建模与MIL验证"展开，目标不是单纯学会某个工具的操作，而是建立一条完整的能力链：从功能需求出发，建立可执行的控制模型，设计测试用例，在MIL环境中运行并判读结果，最终形成可追溯的验证证据。本章作为导入，先讲清三个问题：MIL验证是什么、它在V流程中处于什么位置、本课程用什么工具链和项目来贯穿。

一、什么是功能建模与MIL验证

功能建模是指用图形化或数学化的方式，把控制系统的功能行为描述成可执行的模型。它关注的不是代码怎么写，而是"输入什么、经过什么处理、输出什么、在什么条件下状态如何变化"。常见的建模对象包括：信号采集与滤波、模式管理、闭环控制律、限幅与保护逻辑、故障降级策略等。

MIL验证则是在纯软件环境中，把控制器模型和被控对象模型连接起来运行，用测试用例激励控制器，观察输出是否符合预期。此时控制器还不是C代码，被控对象也不是真实硬件，但控制逻辑、采样周期、信号量纲、接口关系已经可以验证。MIL能发现的问题包括：逻辑分支遗漏、状态机死锁、单位换算错误、限幅值不合理、初始化顺序错误、边界条件处理不当等。

需要明确的是，MIL不是"随便跑跑看看波形"。有效的MIL验证必须有明确的测试目的、可判读的通过准则、可复现的输入激励和可追溯的结果记录。否则仿真跑得再多，也无法证明功能正确。

二、MIL在V流程中的位置

在典型的V流程中，左侧是设计分解：系统需求→系统架构→子系统需求→软件需求→软件架构→详细设计；右侧是验证集成：单元测试→软件集成测试→软件合格性测试→系统集成测试→系统合格性测试。MIL位于左侧模型建立之后、右侧代码生成与HIL之前，属于模型级验证环节。

它与相邻环节的关系可以这样理解：

• 与SIL的关系：MIL验证模型逻辑，SIL验证由模型生成的C代码与模型行为是否一致；MIL通过不代表SIL一定通过，但MIL是SIL的基础。
• 与HIL的关系：HIL把真实控制器接入仿真环境，验证实时性和硬件接口；MIL阶段发现的问题不应留到HIL。
• 与台架/实车的关系：越往后成本越高，MIL的价值就是把问题拦截在最便宜的阶段。

下图给出MIL在V流程中的位置及其与前后环节的输入输出关系，同时标出本课程工具链的对应关系。

三、工具链概览

本课程以MATLAB/Simulink为主工具链。选择它的原因是：Simulink天然支持图形化功能建模，Stateflow适合描述模式管理和状态机，Simulink Test提供测试用例管理、基线对比和报告生成，Simulink Coverage可以统计模型覆盖率。这条工具链在汽车、航空、工业控制中应用广泛，学习成果可直接迁移。

具体到本课程，工具链分工如下：

需要提醒的是，工具只是载体。真正决定MIL验证质量的，是测试用例是否覆盖了功能需求中的每一条正常路径和异常路径，以及通过准则是否量化、可判读。工具能帮你跑仿真、出报告，但不能替你判断"这个结果算不算通过"。

四、课程项目说明

为了让知识形成闭环，本课程贯穿一个完整的教学项目：直流电机转速闭环控制系统。选择这个对象的原因是它足够简单、便于理解，又包含真实控制系统的典型要素：设定值输入、反馈采集、PI控制律、PWM输出、饱和限幅、过流保护、模式管理。

项目按阶段推进，每个阶段都对应MIL验证的一个具体任务：

1. 需求梳理：明确转速范围、稳态误差、超调量、响应时间、保护阈值等指标。
2. 功能建模：建立电机数学模型、PI控制器模型、PWM调制模型和保护逻辑。
3. MIL环境搭建：连接控制器与被控对象，配置采样周期和信号量纲。
4. 测试用例设计：覆盖阶跃响应、负载扰动、超速保护、过流降级、模式切换等场景。
5. 运行与判读：观察转速、电流、PWM占空比波形，对照通过准则判定。
6. 覆盖率与报告：检查分支和状态覆盖，输出可追溯的验证记录。

教学示例参数如下（属于合理假设，用于课程演示，不代表任何实际电机实测数据）：额定转速3000 rpm，额定电压24 V，采样周期1 ms，PI控制器比例增益Kp=0.8、积分增益Ki=12，转速限幅0～3200 rpm，电流保护阈值8 A。这些参数会在后续章节中逐步使用和调整。