Giter VIP home page Giter VIP logo

fmu-proxy's Introduction

FMU-proxy (work in progress)

License: MIT contributions welcome

Join the chat at https://gitter.im/NTNU-IHB/FMU-proxy CI

The main goal of the Functional Mock-up Interface (FMI) standard is to allow simulation models to be shared across tools. To accomplish this, FMI relies on a combination of XML-files and compiled C-code packaged in a zip archive. This archive is called a Functional Mock-up Unit (FMU) and uses the extension .fmu. In theory, an FMU can support multiple platforms, however this is not always the case and depends on the type of binaries the exporting tool was able to provide. Furthermore, a library providing FMI support may not be available in a particular language or platform, and/or it may not support the whole standard. Another issue is related to the protection of Intellectual Property (IP). While an FMU is free to only provide the C-code in its binary form, other resources shipped with the FMU may be unprotected.

In order to overcome these challenges, we present an open-source framework for working with FMUs across languages and platforms.

FMU-proxy is different from other frameworks for distributed FMU invocations such as DACCOSIM, FMI GO! and Coral in that it completely separates itself from the master algorithm (logically and physically). FMU-proxy is a completely standalone project, which provides access to FMUs over the wire. And just that.

The idea is that other applications should use FMU-proxy whenever FMUs are required to run distributed, rather than having each application creating their own solution.


fmu-proxify

fmu-proxify is a CLI that transforms a co-simulation FMU compatible with either version FMI 1.0 or 2.0 into a proxified version of the same FMU. Internally, the proxy FMU wraps the original FMU in a server program. Each new instance of the original FMU runs in a separate process.

This allows you to:

  • Import FMI 1.0 models in software that otherwise only supports FMI 2.0.
  • Instantiate multiple instances of FMUs that only allows one instance per process.
  • The ability to run the FMU on some remote resource
    • Which in turn allows FMUs to run on otherwise unsupported platforms.
Usage: fmu-proxify [-h] [-d=<destFile>] [-r=<remoteAddress>] FMU-FILE
      FMU-FILE            Path to the FMU to proxify.
  -d, --dest=<destFile>   Where to save the FMU (defaults to current folder).
  -h, --help              Print this message and quits.
  -r, --remote=<remoteAddress>
                          Optional host to connect to. e.g. 127.0.0.1:9090

By default, the generated FMU seemingly behaves like a regular FMU. However, internally the FMU is communicating with the original FMU over TCP/IP. When targeting localhost, this all happens automatically.

To install the necessary tools, run ./gradlew build. The CLI tool is then located under fmu-proxify/build/install
Likewise, the booter executable needed to spawn processes on a different computer when not targeting localhost is located under fmu-proxy-booter/build/install

Running the FMU on another computer

  1. The target computer needs to start fmu-proxy-booter
    ./fmu-proxy-booter <port>

  2. Generate the FMU with the option --remote <hostname:port>
    (or modify proxySettings.txt inside an existing FMU)

  3. Load the FMU as usual.

Environment setup

FMU-proxy relies on Java and thus requires a suitable environment to run.

Windows
  1. JAVA_HOME should point to a JDK8+ installation.
  2. %JAVA_HOME%\jre\bin\server must be added to PATH.
Linux

On linux things should just work after installing the JDK.

Publications


Want to import FMUs in C++? Check out FMI4cpp
Want to develop or import FMUs in Java? Check out FMI4j
Want to develop FMUs in Python? Check out PythonFMU
Need a complete co-simulation framework with SSP support? Check out Vico

fmu-proxy's People

Contributors

gitter-badger avatar markaren avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fmu-proxy's Issues

Automatic distribution of FMUs over the network

In the future, it should be possible to upload FMUs to the discovery service, which will automatically find a suitable proxy to run it on.

As a bare minimum, the allocator will have to consider things tool requirements, license requirements and platform requirements.

Should each proxy host multiple FMUs?

Currently, you spawn one proxy per FMU. The original reason for that was that the proxy provided instance specific getter and setters for variables. This feature has since been removed as it is considered to hard to use by the end user.

Remove vcpkg support

Supporting vcpkg is time-consuming since it always changes.. Lets use conan only.
I.e thrift is constantly changing, and sources generated with 0.12.0 is not compatible with vcpkg thrift.

Wrap client as FMU

As suggested in #71 , it would be nice if we were able to wrap one of the clients as an FMU.
This would allow distributed simulation to any FMI compliant tool without modification.

Obvious problem: The modelDescription.xml refers to a specific model.
Solution: Do not provide a modelDescription.xml. Let the user copy it from the target FMU and paste it into the archive we provide.

Similarly the IP and port could be put into a .txt file inside the archive.

Implement bulk read/write using FMI4j extension

Bulk read/write should lead to considerable performance gain as fewer RPC calls per time-step are required.
FMI does not support this operation, but FMI4j is working on an extension in NTNU-IHB/FMI4j#125.

However, only frameworks that uses the extension, like Vico, will benefit from this.

Conan conflicts

The C++ project cannot be built using conan at this point. Conan is introducing a lot of breaking changes lately. Should just wait it out I guess.

Remove JSON-RPC support (?)

While immensely powerful, the JSON-RPC support is difficult to maintain. Especially if supported by multiple server implementations. As far as I know, this feature is not used. Should it just be removed?

Consider caching read variables

Some co-simulation framework does not perform caching of variables. Thus it may repeat calls on getXXX. This is ok when network calls are not involved, but adds considerable overhead when getXXX leads to a RPC call.

Rename project

The project should not be tied to gRPC as more options will be added.

So should find a more suitable name.

Should Avro be removed?

As it is, the Avro support provides very little benefit. Avro RPC is not supported in many languages, and code generation exist in even fewer.

I think it is safe to remove this feature..

Remove gRPC proto generation feature

Currently the fmu-proxy-gen (JVM) project generates FMU specific .proto files that allows users to get client side access to all variables in an FMU.

However, the feature is very hard to use. For each FMU a custom client has to be built....

We are better of removing this feature.

Remove singleread/write from RPC

Having both single and bulk read definitions in the RPC adds a lot of extra code. The FMI standard itself only have bulk read, and real production code will have to rely on bulk read for efficiency.

Retire cpp server

In practice there is no need to support two server implementations other than as a proof of concept. The JVM server is the preferred choice. This will make it easier to introduce new features.

Unable to change the value of boolean inputs when running FMUs under FMU-Proxy.

I run a setup using the Cosim demo app together with FMU-Proxy version 0.6.2.

The FMUs are hosted in an Nginx docker container and served to another container running the Cosim demo app through http.
FMU-proxy runs in a third docker container.

However, when running this setup I am not able to change the value of boolean inputs to the FMUs, and some boolean values are flickering between true and false.

I have confirmed that the same setup works when running the FMUs directly in the same container as the Cosim demo app.

Feedback from users

Hi,
I would very much like to hear from you, the person reading this.
Why are you interested in this project, have you tried it?
What is unclear, what can be improved?

Note that it is also possible to chat on gitter!

no main manifest attribute, in FMU-proxy.jar

Hello,
First of all, great work! The fmu-proxify feature is awesome! Working great when running all in the localhost.

I am getting "no main manifest attribute, in FMU-proxy.jar" both in windows 10 and Linux when I trying to "java -jar FMU-proxy.jar " on the target computer.

Remove ZMQ and WS JSON-RPC transports

These transports have had a history of causing hang-ups during testing. Better to remove them. It's easy to re-add them later if there is a strong wish for them to be present.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.