3. 被控对象模型开发与集成
在HIL（硬件在环）系统中，被控对象模型是连接真实控制器与虚拟环境的桥梁。控制器输出的PWM、CAN报文或模拟电压，需要由被控对象模型实时计算成电机转速、液压压力、电池SOC等物理量，再通过I/O板卡回馈给控制器。因此，被控对象模型的质量直接决定了HIL测试的可信度。本节围绕Simulink/AMESim建模、模型接口定义、代码生成、实时性校验与模型版本管理五个关键环节展开。
一、建模工具选型：Simulink与AMESim的分工
被控对象建模并非单一工具可以覆盖。工程实践中常见的做法是：控制逻辑、信号处理、电气系统用Simulink/Stateflow建模；液压、气动、热管理、多体动力学等物理域用AMESim建模。两者通过FMI/FMU标准进行联合仿真或模型交换。
以新能源汽车电机控制器HIL为例，被控对象包括：永磁同步电机（电气+机械）、减速器（机械）、电池包（电化学+热）、冷却回路（液压+热）。其中电机与电池的电特性适合Simulink建模，冷却回路和减速器润滑适合AMESim建模。若全部用Simulink搭建，液压管路动态需要大量微分方程，建模效率低且精度难以保证；若全部用AMESim，控制信号接口和代码生成又不够灵活。
二、模型接口定义：从信号清单到端口映射
接口定义是模型集成中最容易出错的环节。一个典型的HIL被控对象模型接口包含三类信号：
- 控制器输出→模型输入：如PWM占空比、使能信号、目标扭矩、CAN指令帧。
- 模型输出→控制器输入：如实际转速、母线电流、温度、故障标志、CAN状态帧。
- 模型内部参数/标定量：如电机定子电阻、电感、转动惯量、电池内阻、冷却液比热容。
接口定义需要形成一份信号映射表，明确每个信号的名称、方向、数据类型、物理单位、量程、采样率和I/O通道。例如：
| 信号名 | 方向 | 类型 | 单位 | 量程 | 采样率 | I/O通道 |
|---|---|---|---|---|---|---|
| MCU_PWM_A | 控制器→模型 | uint16 | % | 0~100 | 10 kHz | PWM_IN_0 |
| MotorSpeed | 模型→控制器 | int16 | rpm | -12000~12000 | 1 kHz | DAC_OUT_1 |
| BusCurrent | 模型→控制器 | uint16 | A | 0~500 | 1 kHz | DAC_OUT_2 |
| CoolantTemp | 模型→控制器 | int16 | ℃ | -40~150 | 100 Hz | CAN_MSG_0x18 |
接口定义完成后，需要在Simulink模型顶层建立对应的Inport/Outport，并配置信号属性（数据类型、采样时间）。对于AMESim模型，则需要在FMU导出时勾选对应的输入输出变量，并确保变量名与信号映射表一致。
三、代码生成：从模型到实时可执行代码
Simulink模型无法直接在实时目标机上运行，必须通过Embedded Coder生成C代码，再编译为实时目标机可加载的模块。代码生成的关键配置包括：
- 求解器选择：定步长求解器（如ode4或ode1），步长与HIL仿真步长一致，通常为0.1 ms~1 ms。
- 数据类型：所有信号必须显式指定数据类型，避免自动推导导致double类型在实时目标机上性能下降。
- 代码优化：开启“inline parameters”和“remove root level I/O”，减少函数调用开销。
- 目标硬件：选择与实时目标机匹配的硬件配置，如Speedgoat、dSPACE或NI PXI。
对于AMESim模型，通常导出为FMU 2.0 Co-Simulation格式，由HIL平台的FMU导入功能加载。此时需注意FMU的通信步长与Simulink模型的步长匹配，否则会出现代数环或数值不稳定。
% Simulink代码生成配置示例
cs = getActiveConfigSet('MotorPlant');
set_param(cs, 'Solver', 'FixedStepDiscrete');
set_param(cs, 'FixedStep', '0.0005'); % 0.5 ms
set_param(cs, 'SystemTargetFile', 'ert.tlc');
set_param(cs, 'TargetLang', 'C');
set_param(cs, 'GenCodeOnly', 'on');
set_param(cs, 'InlineParams', 'on');
rtwbuild('MotorPlant');四、实时性校验：模型能否在步长内算完
实时性校验的核心问题是：模型在每一个仿真步长内，能否完成全部计算并输出结果？如果计算时间超过步长，就会发生超时（overrun），导致HIL系统时序错乱，控制器可能接收到错误或延迟的信号。
校验方法分为静态分析和动态测试两类。静态分析通过Simulink的“Execution Time”报告估算模型的计算负载；动态测试则在实时目标机上运行模型，通过CPU占用率、任务执行时间等指标判断。工程上通常要求模型计算时间不超过步长的50%，留出余量给I/O通信和操作系统调度。
若发现超时，可采取以下措施：降低模型复杂度（如用查表替代微分方程）、增大步长（需评估精度损失）、将部分模型拆分到多个CPU核心并行计算、或使用定点数替代浮点数。
五、模型版本管理：让每一次测试都可追溯
HIL测试中，同一个控制器版本可能对应多个被控对象模型版本。如果模型版本管理混乱，会出现“测试通过了但不知道用的是哪个模型”的问题。因此，被控对象模型必须纳入版本控制系统，与控制器软件版本、HIL配置版本形成对应关系。
版本管理的基本要求包括：
- 模型文件、生成代码、标定数据三者必须同版本提交，不能只提交模型而遗漏生成的C代码或A2L文件。
- 版本号规则建议采用“主版本.次版本.修订号”，主版本变更表示接口不兼容，次版本变更表示功能增加但接口兼容，修订号表示参数修正或bug修复。
- 变更记录需注明修改内容、修改人、修改日期、关联的测试用例编号。
- 与HIL配置绑定：在HIL测试报告中记录模型版本号，确保测试结果可复现。
六、集成检查清单
在模型交付HIL测试前，建议逐项确认以下内容：
| 检查项 | 判断依据 | 常见问题 |
|---|---|---|
| 接口信号完整性 | 信号映射表与模型Inport/Outport一一对应 | 遗漏故障标志信号 |
| 数据类型一致性 | 模型信号类型与I/O板卡配置匹配 | double类型导致精度或性能问题 |
| 步长匹配 | 模型步长 = HIL仿真步长 | AMESim FMU步长与Simulink不一致 |
| 实时性余量 | 计算时间 ≤ 50%步长 | 复杂液压模型超时 |
| 版本一致性 | 模型/代码/标定数据版本号相同 | 代码未重新生成 |
| 初始状态 | 模型初始条件与控制器上电状态匹配 | 转速初始值不为零导致控制器误判 |
被控对象模型的开发与集成是一个迭代过程。第一版模型往往只关注功能正确性，后续再逐步优化实时性和精度。关键是在每个迭代周期结束时，都确保模型版本、接口定义和测试结果三者一致，这样才能让HIL测试真正成为控制器验证的可信手段。