⋮

# 通过第三方平台仿真 FMU

此应用场景下，FMU 由 Sysplorer 平台导出，请确保该 FMU 导入到 Sysplorer 平台后能正常编译与仿真。此外，第三方平台可能是成熟的工具，如 Simulink、Dymola 等，可能是开源或用户自研的调用程序，如FMI4cpp，还可能应用于实时仿真平台，如 dSPACE。

# 导入阶段

# #2101 解析 XML 失败

  • 问题现象：解析modelDescription.xml失败，原因是XML文件中缺少某些元素或属性。

  • 问题分析：modelDescription.xml文件由若干层级结构的元素（如模型变量元素<ModelVariables>）及其子元素（如标量元素<ScalarVariable>）组成。元素中包含多个属性，例如标量元素具有变量名属性name、变量索引属性valueReference、因果性属性causality等。这些属性可显式生成到XML文件中，如果未生成则使用默认值或基于其它属性推导。FMU 导出程序避免生成部分默认值属性能够提升导入程序的解析效率，第三方平台的导入程序必须兼容这种情况。

  • 问题定位：使用 FMI 官网验证工具 FMPy 导入 FMU，验证modelDescription.xml文件的正确性。

    提示

    FMI 官方网站提供多种 FMU 验证工具，详情请参见验证工具 (opens new window)。其中， FMPy 工具的介绍请参见本手册 FMU 验证工具。

  • 解决方案：使用文本编辑器打开XML文件，补充缺失的属性以修复解析错误。

# #2102 黑盒 FMU 导入失败

  • 问题现象：通过 MWORKS 导出黑盒 FMU，且原模型无任何输入与输出端口，该黑盒 FMU 导入第三方平台时失败。

  • 问题分析：导出 FMU 时，具有对外输入或输出端口的模型才具备实际应用价值。如果模型无输入与输出端口，则无论导出为 ModelExchange 或 Co-Simulation 类型 FMU，都无法与其它模型集成。黑盒 FMU 最大程度隐藏原模型的变量细节，仅暴露输入与输出端口。若原模型无对外端口，则生成的modelDescription.xml文件中<ModelVariables>元素将为空，导致第三方平台导入失败。

  • 问题定位：

    1. 解压 FMU 文件并使用文本编辑工具打开modelDescription.xml；
    2. 检查<ModelVariables>元素是否为空。

  • 解决方案：若原模型无任何输入与输出端口，避免使用黑盒导出模式。

# 仿真阶段

# 离线仿真

# #2201 Linux 平台运行报错

  • 问题现象：在 Windows 交叉编译生成的 FMU 拷贝到 Linux 上运行时出错。

  • 问题分析：某些 Linux 发行版解压 FMU 后，.so文件可能没有执行权限（尤其是在跨机器拷贝时）。

  • 问题定位：使用ls -l查看解压后文件的权限。

  • 解决方案：使用chmod +x binaries/linux64/*.so设置文件为可执行，确保权限正常。

# #2202 在不同 Linux 发行版无法运行

  • 问题现象：在某个 Linux 发行版生成的 FMU 能正常运行，但直接拷贝到另一 Linux 发行版时运行出错或仿真结果差异明显。

  • 问题分析：FMU 内部封装了动态库（.so），其运行依赖系统的 glibc 版本、编译器 ABI，以及数学库（libm、libstdc++）等。不同 Linux 发行版（例如 Ubuntu 和 CentOS）之间可能存在较大版本差异，导致 FMU 无法直接兼容。

  • 问题定位：确认两个 Linux 系统的 glibc 版本及相关数学库版本。

  • 解决方案：

    1. 在低版本 glibc 环境下构建 FMU；
    2. 在目标环境重新构建 FMU。

# #2203 改变通信步长报错

  • 问题现象：导出Co-Simulation类型 FMU 时选用定步长算法并设置了积分步长，在第三方平台仿真时如果设置不同的通信步长，可能导致仿真结果差异，甚至报错。

  • 问题分析：Co-Simulation类型 FMU 内部包含独立求解器，外部调度程序通过调用fmiDoStep接口推进 FMU 内部计算。当 FMU 内部采用定步长算法时，外部调用fmiDoStep时提供的通信步长communicationStepSize必须是内部定步长步长的整数倍。

  • 问题定位：

    1. 解压 FMU 文件；
    2. 使用文本查看工具打开modelDescription.xml文件；
    3. 检查仿真通信步长是否与DefaultExperiment元素的stepSize属性保持整数倍关系。

  • 解决方案：设置仿真通信步长时，保证其为 FMU 内部积分步长的整数倍。

# 实时仿真

# #2301 单步仿真超时

  • 问题现象：在实时仿真平台运行 FMU 时可能出现单步超时。

  • 问题分析：实时仿真的单步计算包括接收输入、设置 FMU 输入、单步计算 FMU、获取 FMU 输出、发送输出值等步骤。输入与输出处理耗时与变量数量直接相关。有些实时平台在导入 FMU 时可能将非输出类型的local变量也处理为输出（如 dSPACE），导致单步处理的输出变量数量急剧增加，从而增加不必要的运行开销。此外，FMU 单步计算耗时还与模型复杂度及所选算法有关。实时仿真通常采用定步长算法，算法阶数越高单步计算耗时越大，例如选择 Rkfix2 相比 Euler 算法需要额外调用一次导数计算。

    提示

    有关local变量的详细信息，请参见：

  • 问题定位：

    1. 确认第三方平台认定的输出变量是否包含对外不可见的local变量，以及 FMU 是否具有大量local变量；
    2. 重新导出 FMU 并选用低阶定步长算法，测试是否仍存在单步超时。

  • 解决方案：

    1. 导出 FMU 时使用变量过滤功能，如黑盒模式仅导出输入、输出以及可调参量；
    2. 根据模型求解情况选择低阶算法，同时确保低阶算法能正确计算模型。

# #2302 设置参数后单步超时

  • 问题现象：实时仿真过程中设置模型参数后立即出现单步超时。

  • 问题分析：FMU 支持在仿真过程中设置可调参数。当可调参数发生变化时，FMU 内部需更新该参数及其依赖参数，并基于更新结果完整更新模型。当模型规模较大（如 FMU 包含大量依赖参量或复杂方程系统）时，此类更新可能显著增加当前步的计算量，导致超时。

    提示

  • 问题定位：

    1. 翻译原模型后检查输出报表中的时变变量与依赖参量数量，这两类变量的数量在一定程度上反映模型复杂度。

  • 解决方案：

    1. 调整建模逻辑，将需要动态调整的参数定义为输入变量，在 FMU 仿真过程中修改输入变量值的开销远小于在线调参；
    2. 建模时通过Modelica注解Evaluate=true将无需调参的参数估值为常量，以减少运行负担。

    提示

    有关Modelica的Evaluate注解的详细信息，请参见 18.3 Symbolic Processing (opens new window)。

# #2303 设置参数一段时间后单步超时

  • 问题现象：实时仿真过程中，设置模型参数运行一段时间后出现单步超时。

  • 问题分析：若模型参数影响内部逻辑判断，在参数修改后可能导致某些时间段内出现条件不相容的情况。此时 FMU 内部需通过迭代计算来寻找一组相容条件，从而引发超时。

  • 问题定位：

    1. 在 MWORKS 中仿真原模型，验证模型逻辑设计是否合理；
    2. 进入主页>仿真设置>调试 ，勾选仿真中的事件，然后翻译模型；
    3. 进入主页>结果查看器，勾选在线调参，运行模型并在目标时刻修改参数；
    4. 检查输出信息中是否存在异常的事件迭代记录。

  • 解决方案：优化建模逻辑，避免模型参数取值导致不相容的逻辑情况。

# #2304 在非强实时操作系统上单步超时

  • 问题现象：在非强实时操作系统上执行 FMU 实时仿真时出现单步超时。

  • 问题分析：非强实时操作系统（如常规的 Windows 或 Ubuntu）的设计目标是提升平均吞吐量与任务公平性，而非保证严格的响应时间。因此容易引入多种导致单步超时的延迟与不确定性，其来源包括：

    • 不可抢占的内核
    • 中断屏蔽
    • 动态中断负载
    • 虚拟内存与缺页中断
    • 调度器抖动等

  • 问题定位：

    1. 运行一个逻辑简单但计算量适中的 FMU 模型（例如在for循环中执行数千次x = sin(time)）；
    2. 长时间仿真并观察是否存在单步超时或计算耗时的突变。

  • 解决方案：使用强实时操作系统，或为 Linux 内核打上 PREEMPT_RT 实时补丁。通过深度改造内核以最大限度消除不确定性，确保仿真任务在有界且可预期的时间内得到响应。

# #2305 在实时仿真平台卡死

  • 问题现象：FMU 空跑无问题，但其在实时仿真平台上连接输入输出后仿真时出现卡死现象。

  • 问题分析：由于实时仿真平台需要和 FMU 的输入输出进行数据传输和接收，若 FMU 在仿真过程中失败则可能会导致实时仿真平台因接收不到 FMU 的输出信号导致仿真卡死。FMU 连接外部输入后导致的仿真失败，可能是如下原因导致：

    1. 外部输入导致 FMU 运行过程中出现了非法运算（如除零运算或负数开方），且原模型导出 FMU 时勾选了【运行时检查错误】。运行时检查错误选项会严格检查模型仿真过程中的非法运算（如除零，负数开方等）并终止仿真；
    2. 外部输入导致 FMU 运行过程中触发了原模型内部断言，导致 FMU 仿真终止。

  • 问题定位：

    1. 检查原模型在 Sysplorer 中导出 FMU 时是否勾选【运行时检查错误】选项，并分析原模型中是否可能存在除零运算或负数开方等非法数值运算行为；
    2. 若为初始时刻仿真卡死，则可在 Sysplorer 中打开原模型，指定与实时仿真平台的相同初始时刻输入，在仿真设置页面调试选项卡中勾选【运行时检查错误】选项后仿真原模型，查看初始时刻是否出现非法运算报错；
    3. 可通过查看 FMU 仿真日志信息，搜索assert字段，查看是否有断言触发。

  • 解决方案：

    1. 若确认为非法运算导致的仿真失败，需要判断该非法运算是否符合预期，若符合预期，则建议原模型导出 FMU 时取消勾选【运行时检查错误】，避免仿真终止的情况；若不符合预期，建议排查模型，避免出现因非法运算可能导致的数值误差和不稳定性；
    2. 若确认为断言触发导致的仿真失败，需要判断原模型中断言条件的设置是否符合预期，若符合预期，则建议逐一排查导致 FMU 内部触发断言的外部输入信号；若不符合预期，建议排查模型，取消或重新设置断言条件。