search

modelica / fmi-standard

Specification of the Functional Mock-up Interface (FMI)
https://fmi-standard.org/
Other
271 stars 84 forks source link

External Scheduling using FMU 3.0 for Co-Simulation with Event Mode #1380

Closed oliverkotte closed 3 years ago

oliverkotte commented 3 years ago

We have a concept for using Co-Simulation FMU 3.0s with Event Mode to implement virtual ECUs with external scheduling. One FMU contains the external scheduler, another FMU the scheduler-less functional virtual ECU.

The trick is for the virtual ECU to not have any computations done in StepMode, i.e. doStep() only advances internal simulation time. All computations are done in Event Mode, i.e. in updateDiscreteStates(). The second trick is that timing information is conveyed from the external scheduler FMU to the functional FMU by way of clock activations.

I am of the opinion that some text passages of the current FMI spec should probably be adjusted. Most prominently, Table 1 contains a row stating that CS has "Scheduler Included" and SE has not. But this notion is I believe wrong at least for virtual time single-threaded ECUs as FMU, I thus suggest to delete the row. There are further sections in the spec that carry this notion, at least those below, maybe they should be changed as well?

Beyond this, at least for virtual time single-threaded use cases, with New Clocks and model partitions (representing e.g. ECU tasks) unified across SE and CS, and with StepMode doing nothing but advancing internal simulation time, it appears to me that activateModelPartition (clock, activationTime) of SE reduces to being just a convenience function for shortening the sequence doStep(dt to activationTime), enterEventMode(), setClock (clock), updateDiscreteStates(), enterStepMode() of CS However, using Co-Simulation FMUs instead of Scheduled Execution FMUs allows us to more easily co-simulate with the FMUs of the remaining system, and to move the scheduler itself into an FMU, so implementing external scheduling with CS is more beneficial to our use case. I wonder how far this CS-approach can be taken to cover use cases of the "SE domain".

--- Further text passages with the notion that virtual ECUs as SE but not as CS may have external schedulers ---

in Appendix A. SE is defined as FMI type that externalizes the scheduler to run model partitions, potentially synchronized between more than one FMU and exchanging input and output variables accordingly. -> Can be done with CS as well at least in some cases.

1.1 addition of the new interface type FMI for Scheduled Execution (see Section 5) that allows activation of individual model partitions (or tasks) from an external scheduler. -> SE does not enable it (for virtual time single-threaded sim), it can be done with CS as well at least in some cases.

  1. As another example, FMUs representing controller code, an internal scheduling algorithm will trigger tasks at the correct time and order while advancing time to the next communication point --> just an example, but as well carries the notion that CS does not work with external schedulers

andreas-junghanns commented 3 years ago

@oliverkotte : What you describe has been done since 1.0 to package vECU into CS, albeit without the comfort of an Event Mode, but always at the beginning of each doStep. However, there are aspects of RTOS that cannot be captured, like preemption and packaging parts of one vECU into multiple FMUs.

There are different levels of detail for vECUs and SE is trying to give a "proper" (RTOS-like) scheduler more control when running tasks. Just like you, specialists will figure out that special cases can be packaged in non-SE interface types. But for didactic purposes, we are trying to describe the "normal", more general use case for each interface type.

I propose to close this ticket and add your observations to the list of issues to be discussed in the implementer´s guide #1029. If you agree, close here and start a list there.

oliverkotte commented 3 years ago

@andreas-junghanns, thanks for your suggestion to move the concrete concept to the implementer's guide, I will do that.

But what's with the Table 1 entry? I understand your didactics argument, however by some Table 1 is interpreted as normative and the argument "It violates the FMI standard if you externalize the scheduler of a Co-Simulation FMU, look at Table 1" has been made. The entry created discussion and confusion.

In Table 1, "Scheduler Included" is not an inherent property of Co-Simulation FMUs, it does not even make sense for non-virtual ECU FMUs, and in virtual time the scheduler can be included or not. I would delete the row, but expect opposition. Thus, I suggest to at least change the item "Scheduler Included" to "Scheduler can be included". I feel this is a more proper name for the 'feature'. Additionally, I suggest to also state that Table 1 is non-normative. I have made a suggestion in a PR #1384.

Also, the bullet point that motivates SE in 1.1

addition of the new interface type FMI for Scheduled Execution (see Section 5) that allows activation of individual model partitions (or tasks) from an external scheduler.

has been used in a similar argument ("if SE specifically allows it, doing so in CS is violating the standard").

To me, it seems the principal separator between CS and SE, and motivator for SE, is RTOS simulation and not the location of the scheduler. I suggest to append the above bullet point with "on real-time platforms", as this is the use case that is actually being enabled. I have included this in the PR #1384 also.

chrbertsch commented 3 years ago

Regular Design Meeting:

Pierre: in table 1 the term "scheduler" is problematic. E.g. one cold als have an internal schedular in SE. The intention of the table is very good, but it can be misunderstood Karl: the same e.g. for ME, we could have a solver inside. TorstenS: the big picture is good. One would need more comments ... Klaus: Shouldn't this be part of the implementer's guide? Torsten: We should write that this is non normative and add a sentence that this is "typical" ....

Second point: mentioning "realtime platform" in the introduction of SE Christian: SE is not limited to realtime platforms Pierre: but make sense mostly for resouce-limited platforms. Klaus: people have different understandings of realtime platforms Pierre: SE makes the calculation structure exposed to the outside (runnable structure in AUTOSAR speak)

@oliverkotte : I will modify the PR