Provide guidance for real-time simulation with HiL

[k-a-le13]

Could the FMI Design committee provide guidance on issues with real-time execution?

• Pausing simulation: is there a mechanism to pausing the entire simulation? Or is that not allowed?

• Lengthy initialization mode: Initialization mode requires that the startTime matches with the currentCommunicationPoint on the first fmi3DoStep. What happens if an FMU takes a long time to initialize and the actual startTime no longer matches up with the currentCommunicationPoint from the importer?

  • Over-framing: where the execution of doStep is greater than the communication step size. What are we allowed to do?
    • Limitations and restrictions on our side:
      • Some FMU will throw out requests where the time is not properly synced with their internal time so jumping into the past or future will not be feasible.
      • When actual hardware is hooked up that is in sync with actual time trying to communicate with FMU’s, those will be using real time stamps and what is sent between the two need to line up or messages may get discard as stale or invalid.

[chrbertsch]

Pierre: we have lots of customers that use FMI in realtime. During initialization time typically you do not start the clock ...There is nothing special about using FMI .... The deeper question is about system design: who is the timekeeper, is really hard realtime needed? With FMI you can distinguish real time and simulation time (e.g. run some FMUs in soft realtime) Christian: can we give some guidence Pierre: The guidance depends on the use case ...

[rjoshc]

Let me try to explain what we have done and what we are trying to do.

Real Time Clock vs Simulation Time Clock

A simulation time clock is completely managed by the simulation. We can move time forward at whatever rate we want relative to real time. This is great if you are completely inside the simulation world but once you start integrating with real hardware components, this starts to become problematic.

In our world, real hardware components have their own method of getting time and run completely in parallel with the simulation. If we want the simulation to run in sync with the hardware, we are forced to try and synchronize through time. This is important because data coming through may be time stamped and the system is designed to handle validating stale or invalid data based on bad times.

We could devise a time FMU that handles synchronizing with the external time source and passing around a time variable to the various FMU's. This forces the burden of synchronizing time with the outside world to be internally inside the FMU's and not at the framework level. This requires much greater coordination between models than having the real time clock value passed into the simulation and makes the time passed in for event based FMUs completely useless.

We would like to pass in the real-time clock information instead of the simulation clock. We started down that path and quickly ran into problems.

Initialization Problem

Like our non-realtime scheduler, our current realtime scheduler always starts time at 0 or a fixed offset. In this instance, it is easy to not move time until initialization is complete. However, if we want the time we send into the FMU to match the real time clock we need to send in a time representative of when the scheduling of the first FMU's begin. It is impossible to know what time in the future this would begin at since our real time clock is ticking while initialization is happening.

Frame Overruns

When everything is running smoothly there are no issues but sometimes our simulations experience hiccups where a model take a little longer to run and misses a deadline. In these cases we prefer to try on recover whenever possible. We thought of a couple options.

Option 1 Start the model that missed the frame immediately. By the standard, time needs to be continuous so we pass in not the current time but a time in the past. Depending on how much the deadline is missed by, we might try and give a larger communication step size to make up the lost frame(s). This can work well for missing just a frame or two but if the model does miss more frames then the time range sent in becomes too large for the model to be able to do its required time validation on stale messages coming in from external systems.

Option 2 When a frame overrun gets large, the best option for many models is to skip time. Meaning we can just update the current time and notify the user that some frames were missed and move on. This means there will be time gaps but for many event based models this is the correct behavior as defined by the system.

Proposal

1) Allow for a model to define if it can accept non-continuous time but I am not sure what to do about initialization in this case. 2) Add an additional time value into the doStep method that accepts the real time clock values so we can have continuous simulation time with time gapped real time. I do not like this because it is a breaking change.

[k-a-le13]

@chrbertsch & @pmai - do you have any recommendations here? What @rjoshc is proposing would require changes to the standard not just the guide?

Should this discussion be moved to the FMI standard repo instead?

[chrbertsch]

FMI-Design Meeting: Christian: regarding 1): what does not-continuous time mean? non-fixed timesteps are possible in CS Klaus: we have to distinguish clearly between wall-clock- and simulation time. The FMI standard only talks about simulation time. Typically you can only slow down your model to real time. Karl: users do all kind of effort to make models run fast enough for real time. Matthias: In realtime, wall clock and simulation time are the same Klaus: yes and no, you try to Khoa: we face problems during initiatialization Klaus: during initialization, time is not advanced Khoa: we will provide more context.

[k-a-le13]

Here is a diagram depicting our scenario with Hardware-In-the-Loop (HIL) and the need for real-time synchronization along with our proposal:

[chrbertsch]

Pierre: This seems to retrofit realtime capability to a simulator that is not aware of realtime Torsten/Klaus: Can you not use a separate variable to do that? Khoa: the importer would set a variable before the doStep Pierre: One could also use a time synchronization mechanism (e.g. PTP) inside the FMU. The problem with the variable is, that you would need probably more sync times. Klaus: the FMU would sync the simulation time to the real time itself. Khoa: if we would go for a variable, what about initialization? Pierre: The effort for initialization seems quite huge. Klaus: some system behind the FMU could contain a temperature, that have to be brought up. But why do you then have to agree on the start time in this case? Khoa: it would take some experimentation to find out how long the initialization takes. Pierre: the simulation master should take care of this, needs more intelligence.

[klausschuch]

Webmeeting 24.9.2024: agreement that this issue can be closed