Default values for org.fmi_standard.fmi_ls_xcp.EnableXcpOn[Tcp| Udp]Ip configuration variables are not clear for an importer.

[adriantirea]

The sentences “If not present” causes me problems if I would be an importer.

   org.fmi_standard.fmi_ls_xcp.EnableXcpOnTcpIp
        Description:         "Determines whether the TCP instance of the XCP service provided
                              by the FMU shall be started."
        Type:                Boolean
        Example Start Value: "true"
        Requirement Type:    Should be supplied, if the FMU provides an XCP service using TCP
        If not present:      Defaults to true, i.e. if the XCP slave supports TCP it will be started.

   org.fmi_standard.fmi_ls_xcp.EnableXcpOnUdpIp
        Description:         "Determines whether the UDP instance of the XCP service provided
                              by the FMU shall be started."
        Type:                Boolean
        Example Start Value: "false"
        Requirement Type:    Should be supplied, if the FMU provides an XCP service using UDP
        If not present:      Defaults to true, i.e. if the XCP slave supports UDP it will be started.

How should an importer know if TCP or UDP service will be started when EnableXcpOn[Tcp|Udp]Ip is not present? The fmi-ls-xcp does not say it. Possible answers:

1. If there is at least other TCP variable published in the modelDescription.xml, then deduce TCP is available. The same for UDP.
2. The importer should look in the a2l file and see if there is any TCP and UDP information. Possible solutions:
3. Use one of the above possible answers.
4. Mandate that if TCP is supported, the modelDeschiption.xml shall contain org.fmi_standard.fmi_ls_xcp.EnableXcpOnTcpIp. The same for UDP.

An exporter has no problem. The exporter can play safe and make the situation clear by supplying the TCP variables if the FMU supports TCP and the UDP variables if the FMU supports UDP.

If the FMU supports both TCP and UDP, but not at the same time. How can the importer know which one will be started if both variables are not present?

[pmai]

None of the variables or other information mandated by the layered standard are supposed to supercede the A2L information, unless specifically noted otherwise (e.g. the port if the relevant variables are present and are changeable).

So an implementation shall never rely on the presence/absence or values of any variables to detect TCP or UDP support, as that is fully determined in the A2L file. None of the variables have to be present (for a reason, BTW, consider manual retrofit of FMI-LS-XCP support), yet everything will work as designed as the supported XCP protocols are defined in the A2L, together with all other relevant information.

The variables in question are only there to selectively disable XCP server startup, not to indicate potential support for a protocol.

[pmai]

If the FMU supports both TCP and UDP, but not at the same time. How can the importer know which one will be started if both variables are not present?

Both of them will have to be started by the FMU at startup if the variables are not present; whether the FMU can handle simultaneous connections is up to the FMU, and it will have to handle that at runtime (e.g. by erroring out on secondary connection attempts), just as it has to today...

[adriantirea]

Thank you for the explanation.

The current fmi-ls-xcp mindset is that usually the UDP and TCP services are offered and are on. If one protocol is not offered by the FMU, the FMU must announce the incapability in the modelDescription.xml by declaring the org.fmi_standard.fmi_ls_xcp.EnableXcpOnTcpIp as constant output with value false.

The mindset I came to the subject is that the XCP services are usually not on and user chooses what to enable.

[pmai]

Just so that are no misunderstandings: The current fmi-ls-xcp mindset should be that the A2L file decides whether XCP is offered at all (rather than direct memory access), and which protocols. Since an FMU does not have to offer any additional variables at all, that can be the sole thing that an importer can rely on - which is also good, as that is the canonical place to find such information absent any FMI-related info at all.

So the FMU does not have to announce anything, as the A2L file already anounces everything. What the FMU can offer beyond what pure A2L allows is selectively enabling services at startup, and/or changing of ports, etc. For all of this the added variables play their role, however they are not to be considered as superceding the A2L information, unless specifically indicated otherwise. I.e. if the FMU offers org.fmi_standard.fmi_ls_xcp.EnableXcpOnTcpIp, but has no XCP section in the A2L, it would still not support XCP (and e.g. having the variable as anything other than a constant false would be likely misleading).