Better explain recommended usage and limitations of SE

[chrbertsch]

(from a discussion with Pierre)

We should better explain, under which conditions and for which use cases to use SE (e.g. realtime conditions on a HiL system with mutliple vECUs on a a platform, where the actual code execution takes place) and when better not to use it (and use e.g. CS)

There should be a short text in the standard, and more explanation and discussion of this topic in the implementers (/users) guide

[chrbertsch]

This is related to modelica/fmi-standard#1439. Without such extensions, SE seems mainly to be usable for realtime simualtion, and this should be clearly stated.

[chrbertsch]

Regular Design Meeting:

Andreas: what should we write in the standard?

Christian: A short version could be "use SE only for realtime or you should very well know what you do"

Andreas: CS is the most general. Explain why one would need ME or SE.

Klaus: why? One could give examples, but generally I would not put this in the standard, but in the implementers guide

Andreas: One could give the practical hint that CS is more supported

Markus: But ME could be more stable.

Klaus: we should not recommend any interface type.

Andreas: We should give in the implementers guide hints when to use what.
Edo suggested to have only CS. But this seems to be too radical. Recommendations should go into the implementers guide.

Andreas: current description explains it (e.g., advancing time section)

Klaus: non-normative text in activation time is misleading

Klaus: I do not understand what "time has a more discrete form" has.

Andreas: you have to read this in context of 2.5.5.

Klaus: in SE there are only discrete points.

@pmai : could you make a proposal?

[pmai]

Proposed content from @oliverkotte:

To simulate externally scheduled virtual ECUs in virtual time, the FMI for Co-Simulation with Event Mode is a viable alternative to the FMI for Scheduled Execution. Using CS instead of SE for the virtual ECU has benefits when it comes to integration with the CS-FMUs of the remaining system.

Consider a virtual ECU as FMU for CS that is implemented such that (1) No computation is done in StepMode, i.e. doStep() only advances internal simulation time. (2) All computations are done in Event Mode by way of clocks activating model partitions.

Then, the effect of the call sequence doStep(dt to activationTime), enterEventMode(), setClock (clock), updateDiscreteStates(), enterStepMode() of CS becomes analogous to the call activateModelPartition (clock, activationTime) of SE and thus, for this use case, the FMIs for SE and CS become interchangeable in virtual time simulation.

[andreas-junghanns]

While the basic mechanisms proposed here do not even require Event Mode if you are willing to deal with the vagaries of floating point time and the computation at the beginning of properly spaced doSteps (enforced by the FMU using nextTimeEvent), this idea here might need a bit more elaboration on the semantics of the clocks (such as clock priorities). When mutliple clocks tick at the same time, how would the importer know when one modelPartition ended and the next started to get/set the appropriate input and output variables? This text would also need to discuss preemption control.

We need to make sure that all intended use cases work with this proposed solution, or at least properly define the constraints under which this solution (?) would work. When all this is said/written and done, it might not look as clean anymore as Oliver tries to make it look now.

[MBlesken]

Without having read the discussion before I suggest that once https://github.com/modelica/fmi-standard/pull/1546 is done and hopefully lead to a much clearer explanation of SE in the standard itself the need and intention of this issue should be evaluated again. FYI @pmai @andreas-junghanns @chrbertsch