2. 实时ROM开发全流程与工具链
实时ROM（Reduced Order Model，降阶模型）开发不是“把大模型压缩一下”这么简单，它是一条从高保真物理模型出发、经过实验设计与数据采集、离线训练、精度校验，最终部署为可实时求解的在线模型的完整链路。理解这条链路的每个环节及其衔接方式，是掌握实时ROM工程化开发的核心。
一、完整工作流的五个阶段
一条典型的实时ROM开发链路可以划分为五个阶段，各阶段的输入输出关系如下：
二、数据采集与实验设计
降阶模型的质量高度依赖训练数据的覆盖度。如果采样点只集中在某个工况附近，ROM在边界工况下会迅速失准。因此，实验设计（DOE）阶段需要明确三个要素：参数空间范围、采样策略和激励信号类型。
以某热交换器ROM为例，假设关注参数为入口温度 T_in ∈ [280, 360] K、流量 m_dot ∈ [0.5, 3.0] kg/s，输出为出口温度 T_out。采用拉丁超立方采样（LHS）在二维空间生成200个训练点、50个测试点。每个采样点对应一次高保真仿真，仿真时长60秒，采样步长0.01秒，最终得到200×6000的输入-输出快照矩阵。
激励信号的选择同样关键。对于动态ROM，阶跃、正弦扫频和PRBS（伪随机二进制序列）是三种常用激励。阶跃信号适合捕捉稳态增益，扫频信号覆盖频域响应，PRBS则能在较短时间内激发宽频动态。实际工程中常将三者组合使用，确保训练数据包含足够丰富的动态模式。
三、离线训练与在线部署的衔接
离线训练完成后，ROM需要以某种形式“搬进”在线系统。衔接方式主要有三类：
- FMI/FMU封装：将降阶模型导出为FMU，在线仿真平台通过FMI接口调用。优点是接口标准化，支持Model Exchange和Co-Simulation两种模式；缺点是FMU内部若包含Python运行时，部署环境需预装对应依赖。
- 代码生成：将训练好的神经网络权重或POD系数矩阵导出为C代码或静态库，直接嵌入实时控制器。这种方式延迟最低，但灵活性差，模型更新需重新编译。
- API服务：ROM以微服务形式部署，在线系统通过HTTP/gRPC调用。适合非硬实时场景，延迟通常在毫秒到十毫秒级。
无论哪种方式，离线与在线之间必须保持输入输出接口一致。具体来说，离线训练时使用的输入变量顺序、单位、归一化参数（均值、标准差）必须完整传递到在线端。一个常见的错误是离线训练时对输入做了Z-score归一化，但在线部署时忘记加载均值方差文件，导致输入尺度不匹配，ROM输出完全错误。
四、常用工具链选型与集成
| 工具 | 在ROM开发中的角色 | 典型集成方式 |
|---|---|---|
| Python | 数据预处理、POD分解、神经网络训练、精度评估 | NumPy/SciPy/PyTorch；通过FMPy调用FMU |
| MATLAB/Simulink | 系统辨识、状态空间降阶、Simulink Real-Time部署 | System Identification Toolbox；FMU Import模块 |
| Modelica | 高保真物理建模、多域系统描述 | Dymola/OpenModelica导出FMU |
| FMI | 模型交换与协同仿真标准接口 | FMU 2.0/3.0；FMPy、PyFMI、Simulink |
工具链集成的核心原则是数据格式统一和接口契约明确。建议在项目初期就确定：仿真数据用HDF5或CSV存储，模型参数用JSON或YAML描述，FMU版本号与训练数据版本号绑定。这样在后期排查精度问题时，可以快速定位是数据问题、训练问题还是部署问题。
五、一个可复用的工作流检查清单
在实际项目中，可以按以下顺序逐项确认，避免遗漏关键衔接点：
- 高保真模型是否已通过独立验证（与实验数据或更高精度模型对比）？
- 参数空间范围是否覆盖了在线运行的全部工况？边界是否留有余量？
- 采样策略是否保证空间均匀性？是否包含动态激励信号？
- 训练集/测试集是否严格分离？测试集是否包含外推工况？
- 降阶维数 r 是否通过奇异值衰减曲线确定？是否权衡了精度与延迟？
- 离线归一化参数是否已随模型一同导出？
- 在线推理延迟是否在目标硬件上实测？是否满足实时步长要求？
- ROM输出是否设置了物理边界保护（如温度不超出合理范围）？
这条工作流的本质，是把“高保真模型的精度”和“实时系统的速度”通过数据驱动的方式桥接起来。工具链的选择服务于这个目标，而不是反过来让流程去适应工具。理解每个阶段的输入输出和衔接约束，比记住某个具体工具的操作步骤更重要。