HIL（Hardware-in-the-Loop，硬件在环）是把真实控制硬件接入实时仿真环境，让硬件在闭环中与“被模拟的真实世界”交互，从而验证控制逻辑、接口时序、I/O 映射和故障响应的测试方法。
核心问题
纯仿真可以快速测试算法，但无法覆盖真实控制器、板卡、驱动、线束、总线、采样周期和电气接口问题。直接上实机又可能昂贵、危险、不可重复。HIL 的目标是在真实部署前，把“真实硬件 + 可控环境”放进一个安全、可重复的闭环。
典型例子是：真实机器人控制器输出电机命令，实时仿真器模拟 机器人动力学、传感器和故障，再把传感器数据回灌给控制器。控制器以为自己连着真实机器人，但实际上它面对的是可控仿真环境。
核心对象
| 对象 | 作用 |
|---|---|
| 被测硬件 | 真实控制器、ECU、嵌入式板卡、驱动器或 I/O 模块 |
| 实时仿真器 | 在固定步长内模拟被控对象、环境、传感器和执行器 |
| I/O 接口 | CAN、EtherCAT、串口、模拟量、数字量、PWM、以太网等连接 |
| 测试场景 | 正常工况、边界工况、故障注入、回归用例 |
| 观测指标 | 延迟、抖动、超时、控制误差、故障响应、日志和安全状态 |
核心机制
HIL 是离散时间闭环。可以把一个仿真步写成：
其中 k 是第 k 个仿真周期；x_k 是当前仿真状态，例如位置、速度、温度、故障位；u_k 是真实硬件发来的控制输入，例如目标力矩、阀门开度或电机命令；d_k 是测试注入的扰动或故障；f 是被控对象和环境的状态更新模型；h 是传感器模型；n_k 是噪声或量化误差；y_k 是回灌给硬件的模拟传感器读数。
工程上每个周期要完成：
- 实时仿真器读取硬件输出，例如 CAN 总线 报文、GPIO、电压或以太网帧。
- 将硬件输出映射成模型输入
u_k。 - 在周期截止时间内更新环境状态
x_{k+1}。 - 根据新状态生成传感器输出
y_k。 - 把
y_k按真实接口协议回灌给硬件。 - 记录延迟、抖动、超时、断联、保护动作和业务断言。
如果控制周期是 T_s = 1 ms，仿真计算、I/O 读写和调度开销必须在 1 ms 内稳定完成。偶发超时会让被测硬件看到不真实的传感器延迟，进而掩盖或制造控制问题。
工程用途
- 机器人控制器验证：测试 实时伺服控制、安全停止、关节限位、传感器丢包和故障降级。
- 汽车 ECU 测试：验证发动机、制动、转向、BMS 或车身控制逻辑。
- 飞控和工业控制：在危险场景上机前验证控制律和保护策略。
- 回归测试：把关键场景固化成自动化用例，支撑 回归测试。
- 故障注入：模拟传感器漂移、执行器卡滞、通信延迟、电源波动和断线。
边界与常见坑
- HIL 不是最终实机测试替代品：仿真模型可能遗漏摩擦、接触、温升、线缆干扰和机械装配误差。
- 实时性是硬约束：模型再准确，如果跑不进采样周期，就会变成不可信测试。
- 接口映射比算法更容易出错：单位、坐标系、字节序、量程、极性和报文周期错误会让测试结论失真。
- 仿真模型必须标注适用边界：低速有效的模型不一定能覆盖冲击、饱和、打滑或接触切换。
- 故障注入要可观测：只注入故障但没有断言和日志，很难判断系统是否按预期降级。
- HIL 缩写有歧义：在 AI 和产品流程中 HIL 也可能指 Human-in-the-Loop；本卡片只讨论 Hardware-in-the-Loop。