VSS sensor read-only or read-write?

[UlfBj]

The document on the link contains my attempt to answer the question that was discussed on the CVII meeting yesterday.

https://docs.google.com/presentation/d/13VSCF5nuLpUCZZaGJkgBVNAXldgtsA191SbjsfG5FcU/edit?usp=sharing

[tguild]

VISS+VSS is an abstraction layer. The WG has envisioned multiple ways it could be used:

• service and application residing in-vehicle
• service in-vehicle and application in the cloud
• service in the cloud with an already off-boarded data store in the cloud

For the latter there is a pronounced physical disconnect from the underlying data source, whether it was from a sensor, actuator or a static value is irrelevant.

An implementation could choose to use the set method as a means to update the state store (data cache) VISS uses for some or all signal. This makes perfect sense not only when the data store is in the cloud but could be used as part of a security design consideration where critical control signals (brakes, steering, acceleration) should be given extra consideration and compartmentalized, on a different network or using a different means to relay data to VISS than used for other signals. A gateway could be a client to VISS and set the value from anti-lock brake sensor for example.

As where and how VISS will be used and implementations will vary, we should focus on VISS' behavior when a set is not permitted or illogical. We already have various error responses that seem applicable.

[erikbosch]

When discussing this we should also consider actuators, like seat position. We have said in both VSS and VISS meeting that setting an actuator means setting the wanted value, while reading it means reading the actual value. That could possibly work with scenario 1 in the google document (when TCU gets a set request, it just forward it to ECU1), but not with scenario 2, as TCU must separate between "wanted" value and "actual" value.

[SebastianSchildt]

We documented our system level view in kuksa.val when using a VSS data model and VISS in vehicle. See it here https://github.com/eclipse/kuksa.val/blob/master/doc/system-architecture.md

The main takeaway is, that in such a scenario you would not want to implement two protocols, one for reading one for writing. That may not need to be VISS, but on the other hand, since VISS aims to supports much more use cases (with the filtering, history, complex security etc.), it would be a pity if at this particular point it forbids something, which from my point of view is a sensible use case.

Using a VISS (subset) instead of inventing our own REST or GRPC protocol would makes sense from an ecosystem perspective kind of way, so developers who encounter some full fledged VISS thing in the cloud would still see a similar thing in-vehicle, and of course in time tooling and libraries can be shared instead of solving the same problems multiple times.

[erikbosch]

Is it possibly so that we would benefit from having 3 methods like:

• read - to read actual value - relevant for all types (attribute/sensor/actuator)
• request - to set wanted value - relevant only for actuators
• publish - to publish current value - relevant for all types (attribute/sensor/actuator)

... where the later two methods could basically have the same syntax/parameters. That could at least be a solution to separate between writing wanted value and and writing actual value for actuators. An alternative approach for VSS would be to change the meaning of actuators so they only are concerned with the current wanted/requested/ordered value, so that you need a second signal if you also want to to know the current status.

Update 2022-01-25:

I thought a bit more about the difference between setting "wanted value" (for actuators) and publishing "actual value". When you set a wanted value the time of the request will likely not matter that much, but when you publish a value the "capture time" of the value (as described in https://raw.githack.com/w3c/automotive/gh-pages/spec/VISSv2_Core.html#read) might matter more. So do we need a possibility to include a time stamp when we call the "publish" method? If not, the "capture time" will reflect when the TCU VSS-server got the value rather than when the original sensor captured it. Another thought for "publishing" concerns the need to publish multiple observations in a single operation. At least for frequently updated signals and/or if connectivity is not always available there might be a need for "ECU1" to publish a large set of signals. I.e. a possibility to send a "publish request" with multiple data similar to the response in https://raw.githack.com/w3c/automotive/gh-pages/spec/VISSv2_Transport.html#wss-search-read

[UlfBj]

@erikbosch I appreciate your creative thinking about adding a publish method. However, I think your very sound reasoning shows that it adds considerably to the protocol. This should be weighed against the added value it brings. And here I want to challenge the scenario 2. In-vehicle inter-ECU communication typically occurs over buses like CAN, and Flexray that are not really suited for the protocols VISSv2 support. Ethernet buses, that would handle it better, are still not so widespread, I believe. We should try to ask OEMs for their view on this so that we do not add something that will not become used.

I added a scenario 3 to the PPT which I believe would be likely if the inter-ECU communication goes over CAN or Flexray.

[UlfBj]

After discussion in the WG, and soliciting of OEM feedback, where only a negative view to the idea of extending the interface with a publish method was received, it was decided not to go along with this extension. On a related question on whether the current normative language saying that sensor signals MUST be read-only, it was decided that a PR changing this should be created, and including a short reasoning on why it should be read-write. When created, this latter discussion can then be continued there, and this issue can be closed.

[UlfBj]

Argument for read-write of sensor added to CORE.

[UlfBj]

Argument for read-write of sensor added to CORE.