3. 实时仿真与模型集成
硬件在环（HIL）测试的核心价值，在于让真实的飞控计算机（或航电设备）面对一个"像真飞机一样"的虚拟世界。这个世界由飞行动力学、发动机、大气环境、传感器与作动器等模型共同构成，它们必须运行在实时目标机上，并在每个仿真周期内完成"读输入—算模型—写输出"的闭环。本节要解决的就是：这些模型如何被部署到实时目标机，以及如何保证仿真步长与实时性满足测试要求。
一、实时目标机与模型部署的基本结构
典型的 HIL 系统由三部分组成：被测设备（如飞控计算机）、实时目标机（运行仿真模型）、以及信号调理与 I/O 接口。实时目标机通常采用 x86 多核处理器或 PowerPC 架构，运行实时操作系统（如 VxWorks、RT-Linux、QNX），其关键特征是"确定性"——每个仿真步必须在规定时间内完成，不能因为操作系统调度、内存交换或网络中断而抖动。
模型部署的一般流程是：在宿主机（如 MATLAB/Simulink）中完成建模与离线验证，然后通过自动代码生成工具（如 Simulink Coder、TargetLink）生成 C 代码，再交叉编译为目标机可执行文件，最后下载到实时目标机运行。这一过程需要保证模型中的连续状态、离散状态、代数环、查表等结构都能被正确转换为实时可执行的代码。
二、仿真步长的选择与实时性判据
仿真步长 Δt 是 HIL 系统最关键的参数之一。步长过大，飞行动力学的高频模态（如短周期、结构弹性）无法被准确捕捉，模型可能发散或产生虚假振荡；步长过小，则每个周期内的计算量增加，容易导致实时超时。工程上通常根据模型最快时间常数来选取步长，经验规则是 Δt ≤ 1/(10~20) × 最小时间常数。
以某型固定翼无人机为例，其短周期模态自然频率约为 2 Hz，对应时间常数约 0.08 s，则步长可取 4~8 ms。若发动机模型包含转速动态（时间常数约 0.05 s），传感器模型包含一阶滤波（截止频率 50 Hz），则整体步长应取 1 ms 左右，才能同时覆盖飞行动力学与传感器动态。实际项目中，1 ms 是较为常见的 HIL 仿真步长，部分高动态场景会用到 0.5 ms 甚至 0.25 ms。
实时性判据可以形式化为：在每个仿真周期内，模型计算、I/O 读写、任务间通信与同步的总耗时 T_total 必须小于等于步长 Δt，即 T_total ≤ Δt。若 T_total 接近 Δt（例如超过 80%），则系统缺乏余量，一旦出现额外中断或缓存未命中，就可能超时。因此工程上通常要求 CPU 占用率不超过 70%~80%，并保留至少 20% 的时间余量。
三、模型集成的关键操作
将模型部署到实时目标机，并不是简单地把 Simulink 模型"一键下载"。实际集成过程中需要处理以下几类问题：
- 模型分割与任务分配：飞行动力学、发动机、传感器、大气环境等模型可以放在同一任务中顺序执行，也可以按速率分组。例如，飞行动力学以 1 ms 运行，发动机以 2 ms 运行，传感器以 0.5 ms 运行，通过多速率调度减少单周期计算量。
- 代数环与求解器选择：实时目标机通常使用定步长求解器（如 Euler、RK4）。模型中若存在代数环，需要引入单位延迟或代数约束求解，否则代码生成会失败或产生不可预期的迭代。
- I/O 映射与信号调理：模型中的物理量（如角速度、舵面偏度）需要映射到真实的 D/A、A/D、离散量通道，并考虑量程、偏置、比例因子与电气隔离。
- 状态初始化与一致性：HIL 开始时，模型状态必须与被测设备当前状态一致，否则会出现跳变。常用做法是让模型先进入"配平"状态，再切换到闭环运行。
四、一个可参考的集成检查清单
下表给出一个面向工程实践的模型集成检查清单，可用于项目评审或调试前自检。表中参数为示例值，实际项目应根据具体机型与测试需求调整。
| 检查项 | 示例要求 | 判断依据 |
|---|---|---|
| 仿真步长 | 1 ms（飞行动力学+传感器） | 最小时间常数 ≥ 10 倍步长 |
| CPU 占用率 | ≤ 70% | 实时目标机性能监视器 |
| 单周期最大耗时 | ≤ 0.8 ms | 示波器/逻辑分析仪测量 |
| 超时次数 | 连续运行 30 min 内 0 次 | RTOS 超时计数器 |
| I/O 延迟 | ≤ 0.1 ms | 回环测试 |
| 模型状态初始化 | 配平误差 ≤ 0.5% | 初始时刻状态对比 |
总结来说，实时仿真与模型集成的核心是"确定性"：模型必须在规定步长内完成计算，I/O 必须在规定时刻完成读写，整个闭环不能出现时间抖动。只有把步长选择、任务分配、求解器配置、I/O 映射和实时性验证都做到位，HIL 系统才能真正成为飞控软件可信的"虚拟试飞场"。