4. 实时仿真基础

在机器人HIL（硬件在环）测试中，实时仿真不是“跑得快”这么简单，而是要求仿真模型在确定的时间边界内完成计算、采样与输出。若仿真步长抖动过大，电机控制器可能收到延迟的反馈信号，导致测试结果失真，甚至误判控制器稳定性。因此，理解实时系统、步长、抖动、确定性调度与实时性能指标，是搭建可信HIL平台的基础。

一、实时系统的本质：正确性依赖时间

通用操作系统追求平均吞吐量，而实时系统追求截止时间满足率。在HIL中，被控对象模型（如机械臂动力学、电机模型）必须在每个仿真周期内完成一次计算，并将结果通过I/O板卡输出给真实控制器。若某次计算超时，控制器看到的就不是“真实世界”，而是被扭曲的时序。

实时系统通常分为硬实时、软实时和固实时。机器人HIL中的电流环、力矩环仿真往往属于硬实时，截止时间错过一次就可能导致保护动作或测试无效；而温度、电池SOC等慢变量仿真可归为软实时。

二、步长：仿真时间与物理时间的桥梁

步长（Step Size）是仿真器推进模型状态的时间间隔，常用 Ts 表示。例如 Ts = 100 μs 表示每100微秒计算一次模型。步长越小，数值精度越高，但CPU负载越大；步长越大，计算压力小，但可能丢失高频动态，甚至使闭环系统失稳。

选择步长时需考虑：被控对象最高动态频率、控制器采样周期、I/O板卡更新率、求解器稳定性。经验上，仿真步长应至少比控制器采样周期小5～10倍，或满足奈奎斯特频率的10倍以上。例如控制器PWM频率为10 kHz，则HIL步长常取1～10 μs；若只测试路径规划，步长可放宽到1 ms。

# 典型HIL步长配置示例
控制器电流环周期: 50 μs
HIL仿真步长:     10 μs
I/O更新率:       10 μs
求解器:          ode4 (定步长)

三、抖动与确定性调度

抖动（Jitter）是实际执行时刻与理想时刻之间的偏差。理想情况下，每个仿真周期应严格在 t = n × Ts 触发；但CPU中断延迟、任务抢占、缓存未命中、内存抖动都会造成实际触发时刻漂移。抖动分为周期抖动、释放抖动和输出抖动，其中输出抖动对HIL影响最大。

确定性调度是抑制抖动的关键。常见策略包括：

• 优先级抢占调度：为仿真任务分配最高优先级，确保其优先于非实时任务。
• 时间触发调度：基于硬件定时器触发，避免软件轮询带来的不确定延迟。
• CPU隔离：将仿真核心与操作系统核心隔离，减少干扰。
• 内存锁定：防止仿真任务被换页到磁盘。
• 中断亲和性：将I/O中断绑定到固定CPU核心，降低跨核通信延迟。

在Linux实时内核（如PREEMPT_RT）或实时OS（如VxWorks、QNX）上，这些策略可组合使用。若使用普通Windows或非实时Linux，抖动可能达到毫秒级，无法满足硬实时HIL需求。

四、实时性能指标与评估方法

衡量HIL实时性能不能只看“平均执行时间”，而应关注最坏情况。常用指标如下表：

指标	含义	典型目标
周期抖动	实际周期与设定步长的偏差	< 5% Ts
最坏执行时间（WCET）	单次仿真任务最长耗时	< 70% Ts
截止时间错过率	超时周期占总周期比例	0（硬实时）
CPU负载	仿真任务占用CPU时间比例	< 80%
I/O延迟	从模型输出到物理端口更新	< 10% Ts
时钟同步误差	仿真时钟与真实时钟偏差	< 1 μs

评估时可用示波器测量I/O翻转沿，或用实时系统自带的跟踪工具记录任务执行时间。若发现抖动超标，应优先检查中断延迟、CPU频率调节、后台进程和内存交换。

五、案例：电机HIL测试中的抖动排障

某团队在测试电机控制器时，发现电流环在高速段出现周期性振荡。排查后发现：HIL仿真步长为50 μs，但实际输出抖动达到200 μs，原因是仿真任务与日志记录任务共享同一CPU核心，且日志任务未限制优先级。将日志任务迁移到隔离核心，并启用PREEMPT_RT后，抖动降至8 μs，振荡消失。

六、确定性调度的落地清单

1. 选择实时OS或实时内核，关闭CPU频率调节与节能模式。
2. 为仿真任务设置最高优先级，并采用定步长求解器。
3. 将仿真任务绑定到隔离CPU核心，避免与网络、日志、GUI争抢。
4. 锁定内存，禁用交换分区。
5. 使用硬件定时器触发仿真周期，减少软件定时器误差。
6. 用示波器或实时跟踪工具验证抖动与WCET。
7. 在HIL测试报告中记录步长、抖动、CPU负载和错过率。

总之，实时仿真基础不是单一参数问题，而是步长、抖动、调度和指标共同构成的系统工程。只有把时间确定性作为第一优先级，HIL测试才能真实反映机器人控制器的实际表现。