Connecting discrete FMUs is ambiguous

[modelica-trac-importer]

Modified by dietmarw on 19 Mar 2012 09:28 UTC When FMUs are connected, there is an ambiguity for discrete signals. There are several semantics possible:

1. According to Modelica: Discrete signals are instantaneously communicated, i.e., the output of an FMU can be utilized as input of the connected FMU at the same event instant. This may lead to algebraic loops between FMUs. In Modelica one has to explicitly model the delay (either infinitesimal delay or a real delay).
2. According to VHDL-AMS: There is always an infinitesimal delay at the input: all outputs are computed from the last known input values. Then an event iteration is started and the output computed in the last event iteration is used as input for the next event iteration.
3. According to embedded systems: There is a delay of one event instant: all outputs are computed from the input values of the previous event instant.

This issue can probably be fixed by introducing a new attribute, e.g., "ConnectionSemantics", that defines the behavior of discrete input variables: "immediate" (case 1 above), "lastIterate" (case 2 above), "delayed" (case 3 above).

---

Reported by otter on 4 Dec 2009 21:08 UTC When FMUs are connected, there is an ambiguity for discrete signals. There are several semantics possible:

1. According to Modelica: Discrete signals are instantaneously communicated, i.e., the output of an FMU can be utilized as input of the connected FMU at the same event instant. This may lead to algebraic loops between FMUs. In Modelica one has to explicitly model the delay (either infinitesimal delay or a real delay).
2. According to VHDL-AMS: There is always an infinitesimal delay at the input: all outputs are computed from the last known input values. Then an event iteration is started and the output computed in the last event iteration is used as input for the next event iteration.
3. According to embedded systems: There is a delay of one event instant: all outputs are computed from the input values of the previous event instant.

This issue can probably be fixed by introducing a new attribute, e.g., "ConnectionSemantics", that defines the behavior of discrete input variables: "immediate" (case 1 above), "lastIterate" (case 2 above), "delayed" (case 3 above).

---

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

[modelica-trac-importer]

Modified by otter on 20 Jan 2010 13:29 UTC

[modelica-trac-importer]

Modified by dietmarw on 19 Mar 2012 09:28 UTC

[modelica-trac-importer]

Modified by dietmarw on 7 Sep 2012 10:18 UTC

[modelica-trac-importer]

Comment by otter on 3 Dec 2012 00:09 UTC This will be less critical once clocked variables are introduced. It is unclear how to fix this in FMI 2.0 and therefore it is moved to FMI 2.1

[modelica-trac-importer]

Changelog removed by otter on 3 Dec 2012 00:09 UTC

[modelica-trac-importer]

Modified by rerbacher on 25 Jan 2013 16:58 UTC

[modelica-trac-importer]

Modified by torstenblochwitz on 7 Feb 2013 09:13 UTC

[modelica-trac-importer]

Modified by otter on 14 Oct 2013 06:28 UTC

[modelica-trac-importer]

Comment by cbertsch on 1 Jun 2018 12:12 UTC Does the Clock FCP fix this?

[APillekeit]

The ticket is out of the FMI scope in my view. FMI does not cover master algorithms. Therefore no special flag required.

The master can decide to wait with transporting the new information or send it directly to another FMU. Thus the clock and hybrid co-simulation FCP allows a master to cover all listed connection semantics (Modelica, VHDL-AMS, embedded systems)

[chrbertsch]

Added "discussion" label: shall we close this?

[chrbertsch]

Regular FMI design webmeeting: Masoud: where can we define how to propagate an event from one FMU to another one ->this is another issue. We discuss this issue in the clocks group. Andreas: the FMU defines the definition of the clocks and when it ticks?

Closing it, as this ticket is about the master and not the FMU --> out of scope of the standard.