fmi-standard
fmi-standard copied to clipboard
modelica
Standard is not clear about the information flow of Clocks
Apparently it is common understanding that input Clocks are able to provide information to other input Clocks (of another FMU).
This is not clear by reading the standard document.
In 2.2.7. Variables, causality is described as follows: "The attribute causality defines the direction of the information flow with respect to the FMU (e.g. input, output, parameter)."
Table 17 says for causality: = input: The variable value may be provided by the importer. [For example, the importer could forward the output of another FMU into this input.]
= output: The variable value may be used by the importer. [For example, this value can be forwarded to an input of another FMU.] The algebraic relationships to the inputs may be defined via the dependencies attribute of <fmiModelDescription><ModelStructure><Output>.
If information flows from one input clock to another input Clock, the direction is not defined, which contradicts the general description of causality.
Example:
If Clocks are handled differently regarding the meaning of causality, it should be pointed out in the document.
On the interface level, we cannot specify more: an input clock is an input during simulation. The tick of the clock will come from the importer - we made that clear in the standard, I believe.
The definition flow is a different issue: there the FMU(s) provide to the importer when the clock is defined to tick.
The image above is not correct: neither for the definition, nor for the simulation phase. While during the definition phase, the definition information goes from the FMU(s) to the importer, during the simulation, the clock ticks run strictly from the importer to the FMU(s) - combining them on a system level (unifying and resolving compatibility issues) is up to the importer and the system designer.
FMI Design Meeting: Klaus: Add non-normative text explaining the separation between "definition and simulation phase" as defined by Andreas! Many colleagues got confused about this. The "information flow" of clocks is "in the other direction". "information flow" is not clearly defined. Pierre: Differentiate between "API information flow" and "notional / clock propagation / clock tick triggering" information flow Klaus: Differentiate between "who decides that a clock should tick" and "who ticks it".
I believe, and I could be mistaken, that relying solely on the causality of clock ports may not be sufficient. I implemented the clock connection and propagation in a complex model by taking into account both the causality of clock variables and their intervalVariability. For example, in your model, the compiler should infer that the "input countdown" TX clocks serve as the actual source of clock ticks that feed the other "input triggered" RX clock. If the compiler identifies multiple sources of clocks ("input time-based" or "output triggered" clocks) in a clock connection, it should generate an error. The compiler should find only one actual clock source.
That there are different kinds of input clocks (one kind functioning as a clock source and the other only as a consumer) with the connection rules you mentioned above is even another way to look at input clock handling. It makes use of the phrase "clock source", that is also not defined for clocks in the standard. I don't see why we should make this restriction, though. If you have two time based input clocks connected together both of them can be activated by the importer when one of them is about to tick.
However, the discussion shows that there is a lack of specification in the document and too much room for interpretation of how an FMU/importer should handle (input) clocks. Although we only want to specify the interface and not the importer behavior it should be mentioned which connections are allowed and which not and what it means when they are connected. A common understanding beyond the interface description is necessary for the importer as well as the FMU exporter to be able to interact correctly.
The image above is not correct: neither for the definition, nor for the simulation phase. While during the definition phase, the definition information goes from the FMU(s) to the importer, during the simulation, the clock ticks run strictly from the importer to the FMU(s) - combining them on a system level (unifying and resolving compatibility issues) is up to the importer and the system designer.
The standard already contains at least one sentence about clock connections, in section "2.2.8.2. Clock Types, input clock" we have:
While the importer is the source of the actual Clock activations, the timing of the Clocks is defined by the FMU, either through the modelDescription.xml or calling fmi3GetInterval, or by another Clock connected to a triggered input Clock.
I suggest to split this it up and make it more explicit, e.g.: The importer is the source of the actual Clock activations of input Clocks. For time-based input Clocks, the timing is defined by the FMU, either through the modelDescription.xml or by the importer calling fmi3GetInterval. For triggered input clocks, the timing is determined by the importer. [The timing could be given by a triggered output Clock, or a time-based input Clock of a connected FMU, or any other source.]"
