modelica / fmi-standard

Specification of the Functional Mock-up Interface (FMI)
https://fmi-standard.org/
Other
266 stars 84 forks source link

Webassembly FMUs #1542

Open chrbertsch opened 3 years ago

chrbertsch commented 3 years ago

Idea from the Modelica Conference:

Extend FMU model representations from Source Code and target specific binaries to target-independent ByteCode, e.g. using Webassembly.

See https://2021.international.conference.modelica.org/proceedings/papers/Modelica2021session6A_paper3.pdf for a prototype, currently not standardized or standard-conform.

Benefit:

t-sommer commented 3 years ago

Can't this be achieved with a generic front-end (native binary) that runs the WASM code?

sjoelund commented 3 years ago

Can't this be achieved with a generic front-end (native binary) that runs the WASM code?

You would then need one for each platform, right? So you lose the benefit of being able to run on any platform. Similar things have been done for JVM bytecode FMUs that actually embedded a whole JDK...

You could also consider WASM as source code FMUs, but then you would need an extra compilation step anyway.

pmai commented 3 years ago

Of course WASM can just be packaged as normal native binary FMUs that just embed the interpreter.

However the point of WASM-based FMUs would be to establish a binary triple that directly states the FMU is WASM-based, thus not shipping an interpreter (or only shipping those additionally for some native platforms if so wanted). This would establish portable binary FMUs, if done right, which have a much better chance of working out of the box than source FMUs ever will; would also solve some of the IP issues with source FMUs.

I think this idea would be very good to try to achieve, however probably needs some analysis of how best to achieve portability for the commonly required features of FMUs (i.e. what native OS services do actual native FMUs rely on that would need portable hooks in the WASM-based world).

andreas-junghanns commented 3 years ago

Not knowing much about the specifics of WASM, I would still like to know why WASM isn't just another platform?

chrbertsch commented 3 years ago

Currently we share binaries e.g. for Windows as DLLs, with a C-API. But to my understanding a WASM FMU should use the native WASM representation. I would expect differences in data types etc.

pmai commented 3 years ago

@andreas-junghanns to a first approximation it is (just another platform). However it would be the first platform that does not depend on an established OS C-based ABI, and a portable ABI for WASM (the WASI) is just being established.

So there are going to be some friction elements, and some additional definitions we probably would like to make, in order to ensure portability and decent functionality. But in the end it would just be another binary platform, just one that has a decent chance of portability, ease-of-use and decent speed...

chrbertsch commented 3 years ago

Webmeeting: TorstenS: we discussed something similar w.r.t to Java and dismissed it. Pierre: I find it intersing. Could be a portable binary. Could be interesting for several use cases. One would have to defines how this maps to the ABI. Could be realized perhaps as layered standard.

traversaro commented 2 years ago

See https://2021.international.conference.modelica.org/proceedings/papers/Modelica2021session6A_paper3.pdf for a prototype, currently not standardized or standard-conform.

Just for people reading about this like me, the prototype is also available at https://github.com/siemens/dtasm (the link is provided in the paper, but it is a bit hidden among the citations. As an outside observer from the scientific research world, having WebAssembly-based FMUs would be convenient to explore their use in purely Browser-based environments such as JupyterLite ( https://blog.jupyter.org/jupyterlite-jupyter-%EF%B8%8F-webassembly-%EF%B8%8F-python-f6e2e41ab3fa ) or Pyodide ( https://pyodide.org/en/stable/ ).

chrbertsch commented 1 year ago

This should perhaps be realized as a layered standard, as the in interface will be Web-assembly-specific, see https://github.com/siemens/dtasm for the Siemens approach for an ABI. A WASM representation of could be in a suitable /extra folder of an FMU.

chrbertsch commented 1 year ago

See also https://github.com/creative-connections/Bodylight.js-FMU-Compiler for compilation of Source Code FMUs to Web Assembly