Co-Simulation FMU Support#4
Merged
Merged
Conversation
An Enum class is implemented in order to get the current type of the selected FMU. Depending on the FMU nature, a different integration is performed: if model exchange, then the default custom explicit integrator is used and, if co-simulation, the exported solver is called
still not trigger mode
dt measured starting from number of steps, buffer to limit drift
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
When Simscape is used in the model, the
ModelExchangeFMU type may cause unexpected behaviour. For this reason, some changes are made in order to make the agent able to automatically adapt to theCoSimulationFMU type as well.A standalone CoSimulation FMU can be obtained only if the model is configured to use a fixed-step solver. Variable-step solvers requires MATLAB RunTime
Changes
The changes are tested just on a Linux machine. Here's the outline of the changes:
CoSimulationorModelExchangefields in the .xml file, the corrisponding instantiation is performed;ModelExchangecase, otherwise the exported integrator that is embedded in the FMU is called;dtrequires to be fixed. In order to do that, the attributecanHandleVariableCommunicationStepSizeis checked and if a fixed step is used, then the agent loop runs at a fixed period. The period must be a multiple of the model solver's sample timeTrigger Integration With Fixed-Step
The execution of an FMU exported with a fixed-step solver requires time increments that are multiples of its sample time. To support asynchronous triggers from external agents, the trigger mode automatically manages time synchronization thanks to a dedicated accumulator variable (
t_buffer).When a trigger is received, the elapsed time is added to the t_buffer. The agent then computes the maximum number of discrete solver steps that can fit within the accumulated time. The FMU is stepped forward accordingly, and the remaining fractional time, that is insufficient to trigger a full solver step, is preserved inside the
t_buffer. This residual is carried over to the next cycle, ensuring no drift over the long term.Variable step dependency
The agent is able of detecting Variable-step CoSimulation FMUs, but they require the MATLAB Runtime to be present on the machine. This is because variable-step solvers rely on external shared libraries (such as
libmwsl_cosim_service_deploy.so). Without further machine configurations, it fails to instantiate due to that dependency.