3. 实时仿真基本约束

把 Modelica 模型降阶之后，下一步往往不是“跑得更快”，而是“跑得准时”。实时仿真的核心问题不是平均计算速度，而是每一次计算是否能在规定的时间窗口内完成。理解硬实时与软实时的区别、步长与抖动的来源、计算预算的分配方式，以及实时操作系统和代码生成对模型的要求，是让降阶模型真正进入硬件在环（HIL）或嵌入式控制回路的前提。

硬实时与软实时：错过截止时间的后果不同

实时并不等于“快”，而是“可预测地按时完成”。硬实时系统要求每个控制周期都必须在截止时间前完成计算并输出结果，一旦超时，后果可能是物理系统失稳、设备损坏或安全事故。典型场景包括电机电流环、ABS 制动控制、飞行控制律执行。软实时系统允许偶发超时，超时只导致画面卡顿、数据刷新延迟或仿真精度下降，例如驾驶模拟器视景更新、非安全关键的状态监测。

在 Modelica 实时仿真中，硬实时通常对应固定步长求解器加实时操作系统，软实时则可以使用变步长求解器或非实时操作系统加缓冲。判断标准不是模型复杂度，而是“错过截止时间是否会造成不可接受后果”。

步长、抖动与计算预算

实时仿真的时间轴由采样周期 Ts 划分。每个周期内，仿真程序需要完成状态更新、代数方程求解、输出计算和通信。设单步计算耗时为 Tc，则计算预算必须满足 Tc_max < Ts - Tmargin，其中 Tmargin 是留给操作系统调度、中断和通信的余量。例如 Ts = 1 ms，若通信和 I/O 占用 0.2 ms，则求解器可用预算约为 0.7 ms。

抖动（jitter）指实际周期与理想周期之间的偏差。抖动来源包括：操作系统调度延迟、中断响应时间、缓存未命中、垃圾回收、通信阻塞。硬实时系统通常要求抖动小于周期的 5%～10%。例如 1 ms 周期下，抖动应控制在 50～100 μs 以内。抖动过大时，即使平均计算时间足够，也会出现偶发超时。

降阶模型在这里的价值非常直接：减少状态变量和方程数量，降低单步计算量，从而为抖动留出更多余量。一个 200 阶模型降到 20 阶后，单步耗时可能从 0.8 ms 降到 0.15 ms，使 1 ms 周期从“勉强可行”变为“稳定可行”。

实时操作系统与代码生成要求

通用操作系统（Windows、标准 Linux）的调度策略面向吞吐量而非确定性，中断延迟和调度抖动可达毫秒级，不适合硬实时。实时操作系统（RTOS）如 VxWorks、QNX、RT-Linux（PREEMPT_RT）提供优先级抢占调度、确定性中断处理和内存锁定，可将抖动控制在微秒级。选择 RTOS 时需关注：最大中断延迟、调度器最坏响应时间、是否支持 CPU 亲和性绑定、是否提供高精度时钟。

Modelica 模型要进入实时环境，通常需要经过代码生成。以 OpenModelica 或 Dymola 为例，模型先被翻译为 C 代码，再编译为实时可执行程序。代码生成阶段的关键要求包括：

• 固定步长求解器：实时仿真通常使用 Euler、Runga-Kutta 4 或显式固定步长求解器，避免变步长带来的不确定计算量。
• 无动态内存分配：实时循环内不应出现 malloc/free，所有数组和状态应在初始化阶段静态分配。
• 无阻塞 I/O：文件读写、网络通信应放在非实时线程或使用无锁缓冲。
• 确定性执行路径：避免依赖运行时条件分支导致的最坏执行时间不可预测。
• 代码可重入与线程安全：若模型在多任务环境中调用，需保证无全局可变状态。

一个可参考的实时化检查清单

下面给出一个面向 Modelica 降阶模型的实时化检查清单，可用于 HIL 或嵌入式部署前的自检。表中参数为示例值，实际应根据目标硬件和周期要求调整。

实际部署时，建议先用目标硬件跑一个“空转”测试，测量操作系统本身的调度抖动；再逐步加入模型计算、通信和 I/O，观察单步耗时分布。若发现 Tc_max 接近预算上限，优先考虑进一步降阶或简化代数环，而不是盲目提高 CPU 主频。实时仿真的目标不是最快，而是最稳。