Standardizing FMU-import

[HansOlsson]

As discussed on the coordination meeting. The goal was not to standardize on an implementation, but instead standardize the interface of an FMU in Modelica.

Having an "FMU-external-object" is one way, but regardless we need to explain how an FMU behaves as Modelica class, specifically:

• [ ] Mapping of FMU-parameters (to Modelica parameters; similarly, below)
• [ ] Mapping of FMU-inputs
• [ ] Mapping of FMU-inputs
• [ ] For Model Exchange: Mapping of states and derivatives.
• [ ] Mapping of other variables?
• [ ] For both Model Exchange and CoSimulation: Parameters of the FMU (like logging and co-simulation interval/triggering).
• [ ] Graphics? I haven't investigated Terminals and Icons for this; and I don't know how important it is.
• [ ] Clocks?
• [ ] Is there any ambiguity regarding the semantics?

Notes:

• Even if a co-simulation FMU cannot be imported as standard Modelica we can still standardize the interface for it.
• It might be that we only standardize some sub-set, perhaps only structured naming as in Modelica - or only names that are valid Modelica names.

Note that tools may have special options for this, and it is not clear if should only standardize one way or the options. E.g., Dymola has:

• Black-box import, but also the possibility to expose everything or a specific list of variables.
• Structured or non-structured naming.
• For co-simulation either a regular sampling interval or a triggering Boolean (not clocked sub-system).

Additionally, it would be desirable that tools that do generate Modelica code, that code is at least standard-conformant, even if non-standard extensions are needed for performance reasons.

[casella]

As I understand (I'm not an expert here), we also need to define some primitives so that FMU actions like rejecting a step can be communicated to the Modelica tool runtime. This seems to me the really thorny issue.

[HansOlsson]

As I understand (I'm not an expert here), we also need to define some primitives so that FMU actions like rejecting a step can be communicated to the Modelica tool runtime. This seems to me the really thorny issue.

That seems to be part of the implementation (as well as step-events), and thus not something to standardize on.