Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling triggered clocks (triggered time-events) #589

Open
masoud-najafi opened this issue Jul 1, 2019 · 0 comments

Comments

Projects
None yet
1 participant
@masoud-najafi
Copy link
Collaborator

commented Jul 1, 2019

Triggered clocks tick due to state, step, and time events.
In order to handle a triggered clock ticking due to a time-event in the FMU, the simulator retrieves the event-times by calling GetInterval() for a particular clock.
Then the simulator schedules the simulation and once the event time instant is reached, pushes the FMU into the event-mode.
In the event-mode, the FMU should distinguish the reason for which it is in the event-mode, which may be a step-event, a state-event, a discrete time event or a triggered clock.
In the current specification, the FMU needs to compare its internal clock times with the current simulation time. If they are identical the FMU returns the activated clocks via GetClock().
In order to avoid problem in the time comparison, very often an error tolerances is used by the FMU to check whether a time event has happened.

Note that, unlike inferred clocks where the simulator is allowed to perform a SetClock() to indicate to the FMU that an inferred clock has ticked, for triggered clocks, this is not possible.
The simulator is only allowed to invoke GetClock() to retrieve the ticked triggered clocks.

In order to avoid such numerical errors or using error tolerances in time event comparison, the simulator should be allowed to do SetClock() on triggered clocks too.
Since the simulator has the clock reference and the time of triggered clocks, it looks more natural that the simulator performs Setclock() for the triggered clock to inform the FMU about triggering of that clock.

Am I missing something? In any case, we would need a solution to get rid of time-event comparison inside the FMU to detect and tick a triggered clock.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.