modelica / fmi-ls-xcp

Specification of the FMI Layered Standard for XCP
https://modelica.github.io/fmi-ls-xcp/main/
Other
13 stars 7 forks source link

Enable multiple XCP servers in one FMU #63

Open chrbertsch opened 3 weeks ago

chrbertsch commented 3 weeks ago

e.g. in nested FMUs, see https://github.com/modelica/fmi-standard/issues/1953#issuecomment-2160949513

@pmai will analyze this, to be discussed in FMI design meeting June 18th

bmenne-dspace commented 3 weeks ago

@pmai, @andreas-junghanns and @chrbertsch: I did not take part in the discussion (so I don't know all the arguments that were on the table), but take https://github.com/modelica/fmi-ls-xcp/issues/19 also into account for analysis. As far as I know multiple slave instances are a XCPplus feature and we already discussed that within https://github.com/modelica/fmi-ls-xcp/issues/19.

What I can also say: Several FMUs in combination work technically excellently on the basis of the fmi-ls-xcp on dSPACE side (we tested it like @andreas-junghanns did).

chrbertsch commented 2 weeks ago

@pmai, @andreas-junghanns and @chrbertsch: I did not take part in the discussion (so I don't know all the arguments that were on the table), but take #19 also into account for analysis. As far as I know multiple slave instances are a XCPplus feature and we already discussed that within #19.

What I can also say: Several FMUs in combination work technically excellently on the basis of the fmi-ls-xcp on dSPACE side (we tested it like @andreas-junghanns did).

@bmenne-dspace : this is not about the simulation of multiple FMUs with XCP support, but about one FMU that contains several XCP servers. A use case is the creation of a nested FMU out of several FMUs that have XCP support.

What are the realization possibilities?

chrbertsch commented 2 weeks ago

FMI Design Webmeeting:

Pierre: not all slaves can listen to the same port. We need some way of grouping for grouping. I suggest to have more information in the manifest, instead of adding annotations in the modelDescription.xml (see comment https://github.com/modelica/fmi-ls-xcp/pull/69#issuecomment-2176025206) Options have to be discussed (using identifiers, or relative URIs) ... This solves the issue of not hard coding variable names, and for multiple XCP servers and possibly for direct memory access. I have not looked at "xcp+" yet ...

Andreas: Could we take the current version and add this later in a non-contradicting way?

Pierre: In principle yes, defining a default, ... but this would cement the variable names hard-coded .. and most implementations would probably support only the default case ...

Andreas: how urgent is this?

Pierre: I see usage, because our tool is used to combine multiple FMUs

Nikolai Fast : we would run into this problem, too. It could be nested FMUs

Pierre: or FMUs that contains different parts of implementation code ...

Torsten S: I like this approach better than the annotations ... This approach also solves the issue of hard-coded variable names.

Benedikt: There might be another problem ... "XCP+" use case via one combined channel. you can communicate via differen ports. E.g. combine UDP and ....

Pierre: we have to clarify whether the a2l is for direct memory access or for xcp support. Putting more information in the manifest is in general beneficial

Benedikt: do you have in your use case multiple a2l files?

Pierre: yes ...

Matthias: What about the schedule?

Pierre: Goal would be to have a baseline proposal in the FMI Design Meeting in next week or in a dedicated meeting. We have to rewrite parts of the documentation ... Could someone look into "xcp+". Generally I do not think this proposal changes much of the "mechanics" of this LS.

Benedikt : Patrick already collected information on "xcp+"

Poll:

1) Shall we go on with this proposal (putting the information in the manifest file) ? (Which solves both problems: hard coded variables, multiple XCP servers) Andreas, Benedikt, Jan, Markus, Matthias, Nikolai, Timo, Tim, Pierre, Torsten B., Torsten S, Christian

2) Shall we release LS-XCP as is?

3) Abstain: Daniel, Johannes, Kahramon, Kaska, Khoa, Peter