modelica
Standardizing FMU-import
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.
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.
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.
Discussed at language meeting, not clear how to progress. @HansOlsson could start from Dymola import.
Henrik: Roundtripping is important (including hierarchy). Hans: We also view it as important, needed vendor-specific annotation for preserving variable order.
Dag: Works fairly well if no loops. Direct feed-through depends: no problem if functional, but problem in other cases.
Initialization problem. Need to standardize how to specify the steps to take in co-simulation FMU. Henrik: Using a clock to control communication step; to make sure they are synchronized or dynamically updated. Hans: Dymola has the possibility to use a trigger instead of regular sampling. (Needs to include in standardization - @HansOlsson update above.) Or global option?
Will FMI layered standards be mapped too?
FMI-LS-BUS adds particularly interesting capabilities for simulating communication networks and being that accesible from modelica would open new possibilities (e.g. implementing a model of a sensor that sends data to an ECU over can bus)
