Closed t-sommer closed 5 months ago
I think if we are going to refactor the LS-XCP, due to also the missing ability to support more than one A2L file/XCP slave, then I think the better alternative would be to just name the variables in the manifest file of the ls-xcp, which, if we go down the route of not having fixed names, seems preferable, as it is more self-contained. It would also allow for grouping, so that we can have a wrapper element, which makes support for multiple A2L files and multiple XCP slaves simpler: e.g.:
<?xml version="1.0" encoding="UTF-8"?>
<fmiLayeredStandardManifest
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../schema/fmi3LayeredStandardXcpManifest.xsd"
xmlns:fmi-ls="http://fmi-standard.org/fmi-ls-manifest"
fmi-ls:fmi-ls-name="org.fmi-standard.fmi-ls-xcp"
fmi-ls:fmi-ls-version="1.0.0-rc.4"
fmi-ls:fmi-ls-description="Layered standard based on FMI 2.0 and FMI 3.0 for describing and implementing XCP support for FMUs, which can either provide an XCP service or allow direct memory access via A2L files.">
<access identifier="foo"
containsXcpService="true"
supportsDirectMemoryAccessViaA2L="true"
EnableXcpOnTcpIpVariable="top.EnableXcpOnTcpIp"
EnableXcpOnUdpIpVariable="top.EnableXcpOnUdpIp"
TcpListenIpAddressVariable="top.TcpListenIpAddress"
TcpListenPortNumberVariable="top.TcpListenPortNumber"
UdpListenIpAddressVariable="top.UdpListenIpAddress"
UdpListenPortNumberVariable="top.UdpListenPortNumber"/>
<access identifier="bar"
containsXcpService="true"
supportsDirectMemoryAccessViaA2L="false"
EnableXcpOnTcpIpVariable="org.fmi_standard.fmi_ls_xcp.EnableXcpOnTcpIp"
TcpListenPortNumberVariable="org.fmi_standard.fmi_ls_xcp.TcpListenPortNumber"/>
</fmiLayeredStandardManifest>
I've prepared a PR which sketches this approach out.
Pierre will close this in favour of #76
fixes #64