FCP-001_Clocks: Discrete States and Time Events in FMI

[modelica-trac-importer]

Reported by rfranke on 4 Nov 2015 09:09 UTC
FCP-001 builds on material being developed since 4 years and proposes a way forward. It focuses on the most important features that can be provided with minimal extensions of FMI 2.0.

This enables the online application of mixed discrete continuous models and the implementation of controller code using FMI. Such applications are currently only possible with other executable model formats, such as Simulink S-function.

Partial test implementations exist in the tool Dymola since a while. New test implementations exist in the exporting tool OpenModelica and in the importing tool HQP.

Design rationale / Requirements

1. FMI shall support discrete-time models with discrete-time states and basic sample periods, including inferred sample times. This covers a broad range of sampled data systems, such as control systems.
2. Discrete-time models shall extend FMI 2.0 in a backwards and forwards compatible way. They can be mixed with continuous-time models and generic events.
3. The introduced extensions shall be minimized. A new XML Clock type is introduced along with the API functions fmi2SetClock and fmi2GetClock as well as fmi2SetInterval and fmi2GetInterval. The extensions can be ignored by the importing environment to achieve FMI 2.0 behavior, lacking synchronization of time events and discrete-time states.
4. Time events shall be synchronized with the environment and among multiple connected FMUs.
5. Discrete-time states are updated inside each FMU with the existing function fmi2NewDiscreteStates (or with fmi2GetXXX while clocks are active). It is possible to set states from outside prior to the update. This is needed for algebraic loops spanning discrete-time equations of multiple FMUs and for model-based applications such as state estimation or model-based control.

---

Migrated-From: https://trac.fmi-standard.org/ticket/353

[modelica-trac-importer]

Modified by andreas.junghanns on 4 Nov 2015 13:01 UTC

[modelica-trac-importer]

Modified by dietmarw on 5 Nov 2015 12:44 UTC

[modelica-trac-importer]

Comment by rfranke on 25 Jun 2016 05:21 UTC
Note: the new version of FMI_Proposal_DiscreteStates_TimeEvents.docx does not introduce the startInterval attribute in the XML schema for triggered clocks as discussed at the 90th design meeting. This is because it appears sufficient if the startInterval is known to the FMU internally and can be inquired by the environment with fmi2GetInterval.

[modelica-trac-importer]

Comment by cbertsch on 26 Jun 2016 17:55 UTC
This proposal is about ME FMUs extended by clocks. I would like to understand, what the difference are compared to the proposal e.g. by the Berkeley and IBM people from the last years. Can the use-cases (reactive systems) described, e.g.,in http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-157.pdf be realized with the new proposal? I would think so.
I do not yet understand, how clocks are exchanged between connected FMUs or FMUs connected to e.g. a Clocked Modelica Model. Is the clock information an input property? Can a period of a periodic clock be set as a parameter of the FMU or is it fixed within the FMU? I assume this is already contained in the proposal, but a picture with some examples of some connected FMUs with different kinds of clocks (and what is defined where) would help me understanding the proposal.
If this proposal will become a ME feature: Will all tools supporting ME have to support the clock feature? What is the consequence, if they cannot do this? (e.g., because they do not have clock support): Will they be able to produce meaningful results from FMUs that use the clock features? Or is “ME with clocks” a new flavor of FMI?

[modelica-trac-importer]

Comment by andreas.junghanns on 26 Jun 2016 20:15 UTC
Can we have a "Modelica-free" proposal?

I am missing a definition of the different clocks to Modelica-free people (sub-clocks, inferred clocks, intervals,...).

Where is the word document with details?

We should store FCP documents in https://svn.fmi-standard.org/fmi/trunk/FMI_ChangeProposals/...

[modelica-trac-importer]

Comment by rfranke on 3 Jan 2017 17:22 UTC

I do not yet understand, how clocks are exchanged between connected FMUs or FMUs connected to e.g. a Clocked Modelica Model. Is the clock information an input property?

The clocks are declared in the XML file. The importing environment synchronizes clocks between connected FMUs using the functions fmi2Get/SetClock.

Can a period of a periodic clock be set as a parameter of the FMU or is it fixed within the FMU?

An Inferred clock should be used in the case of variable period. The period of a Periodic clock is fixed and given in the XML file. A Triggered clock may be based on a parameter (or other variable) that defines the period.

If this proposal will become a ME feature: Will all tools supporting ME have to support the clock feature?

Triggered clocks do not need any support from an importing environment. The environment must activate Inferred clocks and it should activate Periodic clocks. This is considered simple because the environment can determine the fixed period of a clock by reading its XML attributes and boiling them down to two values: sample period and offset.

What is the consequence, if they cannot do this? (e.g., because they do not have clock support): Will they be able to produce meaningful results from FMUs that use the clock features? Or is “ME with clocks” a new flavor of FMI?

It is not a new flavor; it is an extension of ME. One FMU may have both: continuous states and discrete states. The importing environment should be extended with handling of sample period and offset -- as known from other simulation environments like Simulink.

One could also think of a generic FMU wrapper that treats Inferred and Periodic clocks internally and lets them appear like generic events to the importing environment. The wrapper might also have a parameter to define the period of an Inferred clock.

[modelica-trac-importer]

Modified by cbertsch on 1 Jun 2018 14:16 UTC

[chrbertsch]

Is this covered by FCP-007 or what are the differences?

[KarlWernersson]

It was decided to merge this FCP with others to form FCP 007, this part of the FCP 007 was prototyped and ready two years ago.
I think we can close this ticket.

[APillekeit]

I agree