Enable multiple XCP servers in one FMU

[chrbertsch]

e.g. in nested FMUs, see modelica/fmi-guides#113

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

[bmenne-dspace]

@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).

[chrbertsch]

@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 modelica/fmi-standard#19 also into account for analysis. As far as I know multiple slave instances are a XCPplus feature and we already discussed that within modelica/fmi-standard#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?

• allow array variables for the XCP configuration variables
• add an additional identifier (e.g. "XCP1", "XCP2" ) as annotation for the configuration variables (that is unique for each XCP server), see the draft PR Have predefined simpleType Real, Integer, ... fmi-standard#69
• ...

[chrbertsch]

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 #69 (comment))
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