Common FMU/FMI Co-Simulation Errors Between Amesim and Simulink

Real-world practitioners running Amesim-exported FMUs inside Simulink (and vice versa) repeatedly hit a small set of environment/packaging problems rather than deep numerical issues. These are collected from MATLAB Central Q&A threads and a GitHub issue tracker, not from official Siemens documentation.

"Cannot load AMELicXXXX.dll" / "initialization failed"

A user on MATLAB Answers reported this exact failure sequence when running an Amesim-exported cosimulation FMU inside Simulink:

"Cannot load AMELic2304.dll" "Simcenter Amesim model: initialization failed."

The FMU's own log revealed the root cause was two-fold:

1. "the AME environment variable is undefined"
2. The Amesim runtime dynamic library could not be located on the system

Fix: the AME environment variable must be set (pointing at the Amesim installation folder) and visible to the process that loads the FMU — in practice this means it has to be propagated into the MATLAB/Simulink environment, not just set in a shell that MATLAB wasn't launched from.

Source: FMU Amesim Cosimulation Error – MATLAB Answers

"Cannot find AMELic170 dynamic library" (Model Exchange FMUs)

A related but distinct thread involved a Model Exchange (not Co-Simulation) FMU exported from Amesim, which nonetheless still requires Amesim's runtime licensing library at import time in Simulink:

"Cannot find AMELic170 dynamic library..." "Simcenter Amesim model: initialization failed." "master_Z612L0507E01_14_FMU_fmi2ExitInitializationMode failed"

A follow-up commenter reported the identical failure mode on a newer release: "ERROR: Cannot load AMELic2304.dll!" — confirming this is a recurring, version-spanning packaging issue rather than a one-off bug.

Why this is surprising: Model Exchange FMUs are supposed to only need the importing tool's own solver (no external solver embedded), yet the Amesim-generated FMU still depends on an Amesim licensing DLL at initialization. This is a real practical gotcha for anyone assuming Model Exchange = fully self-contained.

Fixes suggested across the thread:

• Verify a complete, valid Amesim installation (the AMELic*.dll ships with Amesim; a partial/corrupt install is a common cause).
• Match FMU version to the installed Amesim version — an FMU built for AMELic2304 will not resolve against an older/newer installed runtime.
• Check FMU generation settings in Amesim to ensure all required dependencies were bundled into the FMU package.
• Propagate the relevant Amesim environment variables into MATLAB's process environment.
• As of Amesim 2404, Siemens added the ability to generate fully standalone FMUs that only require runtime licensing — this specifically targets and resolves this class of DLL-dependency failure. This is a concrete, version-specific improvement worth knowing if you're on an older release and hitting these errors.
• A user also noted a practical follow-up step: after importing an Amesim FMU into Simulink, use bus-flattening utilities on the resulting Simulink bus mappings to avoid unwanted auto-generated bus objects cluttering the model.

Source: Error in run FMU block in Simulink from AMESIM – MATLAB Answers

Duplicate scalar variable names when importing a Simulink-exported FMU into Amesim

The reverse direction (Simulink → FMU → Amesim import) has its own failure class. A GitHub issue against the "Simulix" Simulink-to-FMU export tool (reported against Simcenter Amesim 2019.1) shows the Amesim FMU import validator rejecting an FMU with:

• "Duplicate scalar variable name TSamp_WtEt"
• "Duplicate scalar variable name UnitDelay2_InitialCondition"
• "Duplicate scalar variable name UnitDelay1_InitialCondition"
• "Missing InitialUnknown index 154"

Key practical detail: some duplicate names came from custom-named blocks and could be manually fixed by renaming in Simulink, but TSamp_WtEt originated from a protected standard Simulink library block (Discrete Derivative), so the user had no way to rename it from the model side — a structural limitation of the export tool rather than something fixable in the Amesim import.

There was also a type mismatch surprise: the user expected a Model Exchange FMU but the Amesim import log identified the file as a Co-Simulation FMU 2.0 — worth double-checking FMU kind before debugging variable-name errors, since the two workflows are validated differently.

Environment for this report: MATLAB/Simulink R2018a, Simcenter Amesim 2019.1, Windows 32-bit compilation with MinGW. The issue was reported as unresolved in the tracker.

Source: FMU Import in Amesim · Issue #28 · Kvixen/Simulix

Practical takeaways

• Most Amesim↔Simulink FMU failures reported by practitioners are environment/packaging problems (missing AME env var, missing licensing DLL, version mismatch between the FMU and the installed Amesim runtime) — not solver or causality problems.
• Check the FMU "kind" (Model Exchange vs. Co-Simulation) explicitly; assumptions about which one you exported/received are a common source of confusion.
• If exporting FMUs to be consumed by tools that auto-generate variable names from protected library blocks (e.g., Simulink's own standard blocks), expect potential duplicate-name conflicts on import that cannot be resolved by renaming in the source model.
• Amesim 2404 specifically addressed the DLL-dependency pain point by supporting standalone FMU export requiring only runtime licensing — a concrete reason to prefer newer Amesim releases for FMU distribution to third parties.