INTO-CPS-Association / unifmu

A universal mechanism for implementing Functional Mock-up Units (FMUs) in various languages
41 stars 4 forks source link

Instead of Docker did you consider using Shiv from LinkedIn #51

Closed phipsitn closed 4 months ago

phipsitn commented 1 year ago

I came across your tool and am intrigued by the use of Dockerized python in an FMU. I've tended to steer away from docker if i'm certain that python will be on the end user machine and instead use Shiv by LinkedIn. Shiv eliminates the need to include python but does include the dependencies in a PEP441 zipapp. I'm also interested in your concept from the modelica conference about using a remote docker container connected to an FMU. If you have a paper on that where could I find that? Thanks.

clegaard commented 1 year ago

The core goal of the tool is to provide a means for specifying how to spawn a process that handles incoming calls to the FMI api. You can use any tool to spawn the FMU by modifying the launch.toml file stored inside the resources directory of an FMU:

https://github.com/INTO-CPS-Association/unifmu/blob/45697e7ec9964b4399ea50c9a3b34ac07537db90/assets/python/launch.toml#L1-L3

For instance, the docker FMU is implemented by modifying the launch.toml file such that it spawns a container, which then executes the same code inside. If you have some other means of deploying like Shiv the code you would modify this code to something along the lines of: `linux = ["shiv", "command that installs dependencies and executes backend.py"]

Remote deployment can be implemented without modifying the C-binary by modifying whatever files are lunched by the launch.toml. In a nutshell, whenever a UniFMU FMU is instantiated the following happens:

  1. Tool importing the FMU executes fmi2Instantiate
  2. C-binary binds a TCP socket to "127.0.0.1:0" (0 being a wildcard for any available port)
  3. C-binary reads launch.toml and executes the command for the appropriate OS
  4. C-binary waits for a handshake to be made to 127.0.0.1:0
  5. Calls to fmi2SetReal, fmi2DoStep, etc. are forward to remote process

The idea would be that in step 3 you could specify a command that launches a process on a remote machine. I'm sure that there are plenty of existing tools that can be used for this. If you want to roll out your own solution, you could make a bash script that SSHs into a remote machine and executes a script that implements the FMI.

Eventually I would like to document this behavior but have simply not found the time. In case you are interested you can reach me via mail (see my contact info on my website christianlegaard.com)