arndtjonasson
commented
9 years ago The Link/Port/Ecu tables should of course be used for this, and today they are not used at all. (Whether real tables or kept in the XML file.)
Open arndtjonasson opened 9 years ago
arndtjonasson
commented
9 years ago The Link/Port/Ecu tables should of course be used for this, and today they are not used at all. (Whether real tables or kept in the XML file.)
arndtjonasson
commented
9 years ago See also #26.
When a car gets an app, checks should be made that they are compatible; i.e., that the ports the car has fit what the app wants, and that they are in the right place. We don't have a global description of port functions, but at least the read/write status of a port can be checked.
Whether a car (or rather, vehicleConfig) is compatible with an app can be checked already in the GUI, so that only apps are presented for installation that can actually be installed.
When associating a vehicle with a vehicleConfig, no checks can be made, since the server doesn't know anything about the vehicle hardware, but when talking to the car, a check might be made.
The car should check the compatibility when an installation comes, but can't communicate any problems in any other way than being silent, with the present protocol.
The simulator creates cars by reading in the same kind of vehicle config files as have been uploaded to the server, so with the proper protocol, an appropriate match could be made.
How the physical car is configured I don't know at this moment.
When/if it's possible to have several plugins in one app, they could be checked for compatibility.
In any case, a new app on a car should be checked so it doesn't use ports that an already installed app uses - warn if that's the case. Exactly what happens if they try to write to the same port or read is probably dependent on the hardware or at least the properties of autosar/the CAN bus.