Wake events and heartbeat

[tguild]

In the data task force calls we have been discussing Harjot's Data Contract document.

https://docs.google.com/document/d/15chftyY4WMv4yQ3WlyVlHrG8BcWm-Tyws9-79eqDCgA/edit#

It raises a number of pertinent topics that can influence VSS, gen2 or perhaps be addressed by separate standards or guidelines.

One topic in particular was whether the gen2 service would have any wake event triggers or be available for periodic heartbeat checks when the vehicle's ignition is off.

Gunnar affirmed my understanding that very few things are permitted to be on when the ignition is off, primarily to conserve battery provided the business case for doing so is strong enough to warrant.

https://www.w3.org/2019/01/10-auto-minutes.html#item02 https://www.w3.org/2019/01/28-auto-minutes.html

Geotab's OBD2 device and another one I experiment with will remain on or power on briefly provided voltage is above a threshold (eg 12.2v) indicating charge is not depleted beyond what is needed to start the vehicle.

We touched on a few real world scenarios they currently cover for their various large mixed fleet customers such as being able to detect when a vehicle is towed or to be able to query location or state (eg fuel not being stolen/siphoned off) of a parked vehicle.

Being able to provide vehicles to commercial fleets that would require such capabilities in monitoring applications is a compelling business argument. Provided we agree this is something we should accommodate the possibility of in gen2, the question becomes how to handle which applications meet this criteria and detect whether any are installed so the service knows under what conditions to wake.

We are also working on policies in the task force which are meant primarily for GDPR compliance off boarding specific data elements and could help provide the mechanism for this need. There are other potential policies that can govern application behavior in the vehicle being discussed. Policy pertaining to an application can be included in a package manifest as it is installed, they would be reviewed and approved by OEM in their app marketplaces. It can be used to enforce what signals gen2 service provides that application as identified by token. It could also contain whether the application is allowed to run when the service wakes for heartbeat checks or which signal changes should trigger a wake event. Application could go through registration process on installation that examines the accompanying policy and makes sure vehicle is aware that an application wants to run when ignition is off under certain conditions and provided battery state makes it possible.

That is one idea on how to handle this, interested in others.

[PatrickCQ]

Low Energy: The distribution of implementations of services allows to place always implementations on low energy ECUs. If we want to equip our Gen2 to be capable of being used in low energy scenarios that would be something to have in mind.

[PatrickCQ]

Wake event triggers: Would that be part of the protocol? E.g. in networking wake up is done on OSI Layer Two. Our Gen2 is at home in OSI Layer 7.

[PatrickCQ]

Heartbeat: We could add the possibility for a client to ask for a heartbeat. But this is not as easy to combine with the REST idea. In my mind it would be something to inform the transport protocol that it will be used a lot (e.g. http keep alive).

[wzr1337]

I my opinion, heartbeat is against REST in general, as REST should allow you to close an reopen the connection whenever the consumer wants to fetch current state. Only this way, thing like multilayer an cachability are possible. Imagine the cache needing a heartbeat... Hmm...

Heartbeats would mean client and server hold a persistent connection, which typically means the hold each other's state information, which again is not RESTful

[tguild]

Heartbeat/wake approach is agreeably wrong when it comes to REST but then so is a server that is so restful, it is often asleep and unreachable.

This scenario is definitely an edge case, likely only permitted for limited few, due to power drain, sanctioned applications. How big do we think that edge may be to consider it? The example use cases were just a couple current real world ones for fleet owners. If the trend towards usage over individual vehicle ownership continues, this becomes an increasingly more important and influential sector. OEM might also want the flexibility of an environment they can run future applications on for themselves in addition to being fleet friendly.

Is this difficult and complicate implementations? Yes, absolutely especially knowing which ECU to wake and which signals can be cached. Some will certainly not have this capability, that might become a market differentiator at some point. Should we allow for the possibility and if so consider how to enable?

[tguild]

Lack of interest in supporting wake events in the group and expected reluctance from OEM without compelling business cases, so withdrawing