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

Bypass a part of an FMU #2011

Open
chrbertsch opened this issue Nov 20, 2024 · 4 comments
Open

Bypass a part of an FMU #2011

chrbertsch opened this issue Nov 20, 2024 · 4 comments

Comments

@chrbertsch
Copy link
Collaborator

(Issue created on behalf of @jeanmariequelin )
Objective is to be able to by-passed a part of a V-ECU Level 1 (100% applicative software) exported as FMU and replace this part by simulink model

Common to all use-cases

  • Simulation platform based on Simulink and using V-ECU as FMU
  • The algorithm of new SWC is developped using Simulink
  • Need to test in a short time (less than one hour) and in autonomy a new version of a Software Component of a V-ECU FMU. The user of simulation platform is not aware of the detailed content of the V-ECU, only know in advance the SWC she/he would like to modify.

Use-case 1

  • The V-ECU is developed internaly by OEM internal design teams but time to get a new V-ECU with updated content is seen too long

Use-case 2

  • The V-ECU is delivered by a Tier#1 as a ‘closed’ FMU and OEM internal design teams would like to test evolution of some SWC in full autonomy without needing to have the Tier#1 toolchain to rebuild a new FMU

Expected benefits

  • The user of FMU is autonomous to make a variant of one Software Component
  • The user doesn’t need to know how to rebuild a new V-ECU nor using specific licenses nor having access to the source codes
  • Protect the Intellectual Property of Tier#1 / OEM still allowing collaborative development

With a schema:

bypassed_fmu

@chrbertsch chrbertsch changed the title Bypass a part of a FMU Bypass a part of an FMU Dec 2, 2024
@nl78
Copy link

nl78 commented Dec 6, 2024

I would like to submit an additionnal use case that may be linked to this topic:

FMU needs a computation routine that depends on the environement. This routine may be called internally by the FMU several times during a Co-Simulation step.

Real life example: consider a FMU that computes the Vehicle Dynamic. It needs ground information at different locations (at least 4 for a car). This information usually depends on the environement (and simulation tool) and should be retrieved even between 2 co-simulation steps. For some models it is very difficult to put ground information as "classical input" of the fmu. In such situation, a callback function given by the environment may be very useful to retrieve ground information.

Is there a way to pass a callback (for computation routine) to an FMU ?

@andreas-junghanns
Copy link
Contributor

nl78:
If your simulation components are tightly coupled, consider Model Exchange.
If you are foced to use Co-Simulation, then you can look into fmi3IntermediateUpdateCallback, see https://fmi-standard.org/docs/3.0.2/#state-machine-co-simulation.

@nl78
Copy link

nl78 commented Dec 8, 2024

Andreas, yes I'm "forced" to use Co-Simulation. The callback I have in mind can be more seen as a "service" offered by environment than a "intermediate update".

In my specific example, "terrain picking" callback should be callable serveral times per FMU iteration (one or more time per wheel). Usage of fmi3IntermediateUpdateCallback can be considered but can lead to complicated implementation.

I shared this example here, because "callbacks" could be also used to overload some "SWC".

@chrbertsch
Copy link
Collaborator Author

@nl78 @jeanmariequelin : there has been a related proposal as an "FMI Change proposal" FCP-05 https://github.com/modelica/fmi-design/blob/master/FMI_ChangeProposals/FCP_005_Services/FCP_FMI_Services_draft20160706.pdf , which was not included in FMI 3.0 Could check and comment this?

One could also think about a realization in form of a layered standard instead of the in the core FMI 3.x standard

Another thought: could put the parts that your want to bypass in a separate DLL that is called from the FMU's main DLL? And then exchange it for another DLL with the same interface and the changed implementation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants