UniFMU v0.12.0-beta

Extended FMI3 support

This prerelease version extends UniFMUs coverage of the FMI3 API and adds further programming language support for FMI3 FMUs.
Full Changelog: v0.11.1...v0.12.0-beta

FMI3 coverage

UniFMU now includes the part of the FMI3 API necessary for Event mode and Clocks.

Programming language support

In addition to Python based FMI3 FMUs, it is now possible to generate files for C3 and Java based FMUs. Furthermore, the README for Python based FMUs has been updated with a note on using virtual environments.

Pre-release status

This release has less test coverage than our normal releases. This is due to one of our test dependencies not currently supporting the full FMI3 API. The release will be in beta until we can remedy this. Expect more bugs, and do open an issue if any are encountered.

UniFMU v0.11.1

Versioning update

This update does not come with new functionality, but the dependencies for the binaries have changed.

Full Changelog: 0.0.11...v0.11.1

New versioning scheme

The previous two releases were bug-fixes to release 0.0.9. They added no new functionality. This wasn't obvious from their versioning. To remedy this going forward, UniFMU now follows a basic semantic versioning with the caveat that until version 1.X.X any changes to MINOR version might come with changes to API. For example, the command structure of the UniFMU tool and the formatting of the generated files might change.

Any API changes will be disclosed in the new versions release notes.

All previous versions will be considered MINOR versions of MAJOR version 0. Thus, the previous release will be considered 0.11.0, and this release will be its first revision, 0.11.1.

Common versioning across subcrates

The versioning of the fmiapi subcrate will now follow the versioning of the primary unifmu crate. This is done to communicate compatibility between the crates, and to reflect the tight dependencie between the two crates and the overall UniFMU tool.

This will also be the case for any future subcrates.

Fixed versioning of Rust dependencies

Up until now the UniFMU tool has had wildcard version numbers for most of its dependencies, while the few with specified versioning had been specified down to their revision. This has been changed so that now all dependencies are set at an expected API stable versioning (MINOR number for all 0.X.X dependencies, MAJOR number for all 1.X.X or above, wtih a few exceptions).

This is done to ensure that UniFMU doesn't break due to a dependency update, while allowing dependency bug-fixes and security patches to automatically propagate into new releases.

0.0.11

Hotfix 2 for 0.0.9

Som unencountered bugs meant that Distributed Co-Simulation with black box FMUs wasn't working. These bugs have been squashed.

Full Changelog: 0.0.10...0.0.11

0.0.10

Hotfix for 0.0.9

• Backends will now be able to run their FreeInstance code without being rudely terminated by the rust code.
• The models of Java based FMUs are now serializeable enabling FMUstate functions. With this all FMI2 FMUs have functional FMUstate functions.
• Java FMUs are now actually tested by the test suite.

Full Changelog: 0.0.9...0.0.10

0.0.9

This release adds a new feature, increases the number of supported FMI functionality and increases codebase robustness.

New feature: Distributed Co-Simulation

With this release it is now possible to generate FMUs that act as a bridge to a simulation model hosted on a separate machine. These FMUs have the same interface as any other FMU, but only a thin communication layer is actually run locally when imported. This layer sends and receives messages to and from the core of the model which can be run from anywhere with an internet connection to the importer.
The core can be implemented in python, c# or java like other FMUs generated with UNIFMU, or it can be an already existing black box model for which the distributed FMU simply acts as a convenient communication layer.
This feature is currently implemented for FMI2 FMUs.

Expanded functionality: FMI2 State

fmi2GetFMUstate, fmi2SetFMUstate and fmi2FreeFMUstate along with the serialization functions have now been properly implemented for FMUs generated with UNIFMU. Using these functions it is now possible to explore multiple evolutions of an FMU without having to reevaluate the FMU from initialization.
EDIT 10/3-2025: Is not functional in Java. See issue #75

Increased robustness: New test suite and debug logging

A new testsuite has been build for the codebase using fmpy to evaluate the generated FMUs. fmpy is widely used by the community and has a solid implementation of the FMI specifications, which is why we trust it in the testing of our codebase. Using it we have been able to build better covering tests, and we expect that our new testsuite will help catch code errors earlier and more often than before.
Along with this we've added initial logging to the communication layer in the FMUs generated with UNIFMU which should help both us and users troubleshoot problems as they appear.

Full Changelog: 0.0.8...0.0.9

0.0.8

Updated minor things:

• fixed fmu zipping
• issues with build
• updated instructions for usage, build, and deployment

0.0.7

Add Java support

Implemented support for Java as a language for implementing FMUs.
The build system is based on Gradle

0.0.6

Removed automatic parsing of modelDescription.xml

Previously, the UniFMU binary would attempt to read and parse the modelDescription.xml file at runtime.
However, the specification does not guarantee that the file structure of a FMU is preserved or that the file is available in any capacity.
In these cases, the model's implementation would raise an exception.

0.0.5

Added option to zip the FMU during generation #39

0.0.4

Rewrite CLI in Rust

The python CLI has been replaced with one written in Rust. Some of the benefits are:

• No runtime dependencies.
• All resources are embedded in the executable.
• Generation speed.
• Fewer languages in the codebase.
• Easy to embed in other applications.

Cross-compile using Docker image

A unique challenge of building the tool is the fact that FMU is that the CLI must embed binaries for all target OSs.
Previously, GitHub Actions was used to build the binaries for each different OS and then commit the result.
This lead to a relatively complex build process where the binaries would have to be checked into the repo.

This has been replaced with a docker image that cross compiles the binary for all OSs which are in turn embedded into the CLI which is also cross-compiled.

Fewer communication backends

Previously, the serialization used to encode and decode messages between the binary and slave was based on those provided by the Rust Serde library.
To simplify the codebase this idea was abandoned in favor of using protobuf.