📚 课程目录第4章多领域统一建模语言与工具链

4. 多领域统一建模语言与工具链

复杂机电产品通常同时包含机械、电气、液压、控制、热流等多个物理域，各域模型往往由不同团队、用不同工具建立。若每个域各自仿真、靠人工传递曲线，系统级耦合效应（如电机发热导致转矩下降、液压迟滞引起控制振荡）几乎无法在早期被发现。本节讨论的核心问题就是：用什么语言描述各域模型，用什么方式把异构模型组织起来，以及用什么接口让它们在同一个时间轴上协同求解。

三类语言的分工：Modelica、SysML 与 FMI 不是替代关系

Modelica 是面向方程的、非因果的物理建模语言。所谓非因果，是指建模者写的是“v = R*i”这样的守恒与构成关系，而不指定谁算谁；求解器在编译期通过符号处理决定计算顺序。这使得同一个电阻模型既能用于电路分析，也能被反向使用。Modelica 适合描述连续时间动态行为，典型对象是电机、液压缸、换热器、传动系。

SysML 是系统建模语言，关注的是需求、结构、行为与参数约束的组织，而不是求解。它回答“系统由哪些部件组成、接口如何定义、状态如何迁移、需求如何被满足”。SysML 的 IBD（内部块图）和参数图常被用来定义模型边界与接口契约，是模型组织的骨架。

FMI（Functional Mock-up Interface）是模型交换与联合仿真的接口标准，它不规定模型内部怎么写，只规定一个编译后的模型如何被外部调用：通过 fmi2SetReal、fmi2GetReal、fmi2DoStep 等函数暴露输入输出与推进时间。一个符合 FMI 的模型打包为 FMU（Functional Mock-up Unit），内含模型描述文件与动态库。

三者的关系可以概括为：SysML 定义“系统怎么分、接口是什么”，Modelica 描述“每个连续域部件内部怎么动”，FMI 解决“不同工具生成的模型怎么连起来跑”。下图给出这一工具链的层次与数据流关系。

模型组织方式：从“一个巨大模型”到分层可替换

工程上最容易犯的错误是把所有物理域塞进一个 Modelica 模型里。这样虽然求解一致性好，但模型难以并行开发、难以替换单个部件、也难以把供应商提供的黑盒模型接进来。更实用的组织方式是分层：

系统层用 SysML 定义顶层块、端口与接口类型，明确每个子系统的输入输出物理量、单位与方向约定。
部件层用 Modelica 建立白盒模型，通过标准连接器（如 Modelica.Mechanics.Translational.Interfaces.Flange）保证跨域连接语义一致。
交付层把需要保密的或由外部工具生成的部件导出为 FMU，只暴露接口变量，隐藏内部实现。

这样，系统集成者面对的是若干带明确端口的 FMU，而不是一堆源码。替换一个电机 FMU 不需要改动其他部件，只需保证端口变量名、单位、因果方向一致。

联合仿真接口的关键约定

FMI 2.0 定义了两种模式：模型交换（Model Exchange）与联合仿真（Co-Simulation）。前者导出方程供主控求解器统一积分，后者自带求解器、由主控调用 DoStep 推进。复杂机电产品中，机械与液压常用模型交换以获得更好的刚性处理，而带自身求解器的商用控制器模型多用联合仿真。

接口配置中最容易出问题的是三件事：单位与量纲、因果方向、步长匹配。下面给出一段典型的 FMU 变量映射配置示例（示例参数，用于说明结构，非实测结果）：

<ScalarVariable name="motor.Torque" valueReference="12"
    causality="output" variability="continuous">
  <Real unit="N.m" start="0.0"/>
</ScalarVariable>
<ScalarVariable name="load.AngularVelocity" valueReference="31"
    causality="input" variability="continuous">
  <Real unit="rad/s" start="0.0"/>
</ScalarVariable>

# 主控侧连接（伪代码）
connect(motor.Torque        -> load.Torque)
connect(load.AngularVelocity -> motor.AngularVelocity)
master.stepSize = 0.5e-3   # 取各 FMU 步长的最小公倍约束
master.relativeTolerance = 1e-4

若单位写成 N.m 与 Nmm 混用，主控不会报错，但转矩会被放大 1000 倍，表现为负载瞬间饱和。因此接口检查必须包含单位一致性核对，而不是只看变量名能否匹配。

联合仿真的稳定性不仅取决于单个 FMU 是否正确，还取决于主控步长与各 FMU 内部步长的关系。当主控步长大于某 FMU 的稳定步长时，即使每个模型单独仿真都正常，耦合后也可能发散。判断依据是：逐步减小主控步长，若振荡幅度显著下降，则问题来自步长匹配而非模型本身。

一个可复现的联合仿真检查流程

以“电机驱动丝杠加载”为例，可按下述顺序推进，每一步都有明确的观察对象：

在 SysML 中定义顶层块 ActuatorSystem，端口为 cmdVoltage（V）、loadForce（N），输出 position（m）。
用 Modelica 建立电机与丝杠白盒模型，单独仿真：给定 24 V 阶跃，观察电流上升时间与稳态转速，确认与设计指标一致。
把控制器导出为 FMU，把电机+丝杠导出为另一个 FMU，在联合仿真主控中按上面的连接关系接线。
先做开环测试：给 cmdVoltage 恒定 12 V，观察 position 是否单调上升、loadForce 是否在合理范围。若位置出现高频抖动，优先检查主控步长与控制器 FMU 步长之比。
再做闭环测试：接入位置反馈，给定 0.1 m 阶跃，记录超调量与调节时间。若超调远大于单域仿真结果，检查接口是否存在单位换算遗漏或一阶保持引入的额外延迟。

这套流程的价值在于：每一步都能把问题定位到“模型本身”还是“接口与调度”。当单域仿真正确、联合仿真异常时，排查重点应放在端口映射、步长与代数环，而不是重新推导物理方程。

模型组织的一条实用原则：接口变量只暴露物理量，不暴露内部状态。例如暴露 Torque 与 AngularVelocity，而不是暴露 rotorFlux。这样替换 FMU 时，接口契约保持稳定，系统级连接无需重做。

综上，Modelica 负责把每个物理域写成可求解的方程系统，SysML 负责把系统拆成有明确接口的层次结构，FMI 负责把异构工具生成的模型封装成可互换的单元，联合仿真主控负责在统一时间轴上调度它们。四者配合，才能让复杂机电产品的多域耦合在虚拟样机阶段被真实地跑起来，而不是停留在各自孤立的单域曲线里。