VISS and "Vehicle Last Seen"/"Vehicle Present"

[erikbosch]

One possible deployment of VISS is that an App that wants to communicate with a vehicle but is not allowed to communicate directly with the vehicle. I.e. it rather communicates with a "digital twin" in an OEM data center, which in turn communicates with the vehicle. This could simplify access management but also allows the App to fetch cached vehicle information (e.g. location, fuel/battery status) even when the vehicle has no connectivity or is in "sleep" mode.

In such setup, it might be interesting for the App to know if the vehicle actually is present/reachable, so commands can be sent to it, or if just "old" cached values are available. I can see a few ways how to achieve this, and they must in some way be managed by the cloud server, as the vehicle (server) itself cannot explicitly inform the server that it has lost connection to the cloud server. One alternative could be to have specific VSS signals that are populated/managed by the cloud server (and not the vehicle), like Vehicle.IsConnectivityAvailable (bool) and Vehicle.LastSeen (string with timestamp). Another alternative could be that the information in some way could be available as VISS server metadata, similar to server capabilities. There are of-course work-arounds, an App could just try to do a set and see if it works, and it could try to deduce when vehicle was last seen by checking e.g. timestamps on data that typically are updated frequently.

Have this need been discussed?

[petervolvowinz]

I think that it was briefly discussed when applying MQTT as the transport. If I recall correctly MQTT have mechanisms that lets clients now when connectivity is lost, caching... so it was never discussed to actually introduce "virtual" cloud vehicle signals into a specification of vehicle signals. I can see the convenience from the client point of view though.

[UlfBj]

This was discussed in the WG, the view was that the idea of having the cloud server save the timestamp of the latest received message from the vehicle could do it. If this "signal" was to be represented as a VSS signal, it would be unique in that it would be created in the cloud, and not (explicitly) in the vehicle. A solution to it was not seen as likely to be visible in the VISSv2 spec.