See also: IRC log
-> https://www.w3.org/2017/01/23-auto-minutes.html Summary of Previous call
-> https://lists.w3.org/Archives/Public/public-autowebplatform/2017Jan/att-0019/VehicleAPI_UseCases_20170123_PB.pdf Patrick's use cases
PatrickL: we thought it would be
useful to have examples to see how the two approaches handle
use cases
... we discussed this week looking at assessing signals from
developer perspectice
<fulup> Hi everyone I'm Fulup Ar Foll from IoT.bzh calling for AGL(Automotive Grade Linux)/W3C syncup
Fulup: I am coming from a
technical point of view on what is taking place at AGL
... we feel implementing ViWi in AGL is pretty straight forward
although we have some security concerns that we would like to
address
Rudi: what the WG is producing is
a different model. what we are doing in these calls is trying
to find the next solution based on the various approaches
... some are implementing the current draft
Fulup: we implemented some of the
earlier work in Tizen, not worried about implementing a new
approach
... what I am more interested in is what would be the widest
adopted solution
... there is room for improvement
... No official AGL/W3C liaison program is yet in place, as a result I do not have the green light to represent AGL inside W3C.
<kaz> AGL AMM in Tokyo on Feb. 8-10
Ted: I believe Dan and I can work out those details
Paul: meanwhile what AGL is working on is publicly visible
Fulup: correct as will the code be behind our implementation
Paul: looking at what you have it is somewhat similar, it would be great to see us converge and have a solution implemented in AGL and Genivi
Fulup: we would like to see cross
platform adoption, AGL, Genivi and Tizen...
... we have both sockets and REST, we are finding sockets
potentially more useful
https://www.w3.org/TR/2016/WD-vehicle-information-service-20161020/
<AdamC> http://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html Latest Editor's draft of the Vehicle Information Service Specification
Paul: there are multiple things
at play here. the WG is strictly focused on this service
specification
... we also have AGL's model and ViWi submission from VW which
is in production use
... lastly from cloud perspective PSA+IBM has something that is
another
... we presently do not align fully but the approaches are
similar and we want to see if we can converge them
... if we adopt the same the chances of success are higher
Ted: what I understand of the AGL approach is that it is more similar than PSA+IBM. We're still reaching out to them. This is an opportunity to compare three very like architectures and figure out how to make them converge.
Fulup: we found web socket faster
than DBUS but we have other transport mechanisms being
considered
... the socket performance in the car and the cloud seems
better but we are fine with REST as well
Rudi: we chose web sockets for
the transport with pub and sub
... as far as the cloud is concerned I am not interested in
seeing a direct communication between it and a car
... perhaps better to go through OCF
Fulup: I agree on that. when we
talk about cloud we are looking to collect data from vehicles
and secure channels
... in some cases REST may make sense
... what is the vision on how to secure a subset of the
signals, e.g., geolocation? how will you restrict this
access
Rudi: that is part of the
specification definition but leaves the details up to the
individual implementers
... we figured there would be different models on the backend
by tier 1s and oems
Adam: you can have an app specific token that the implementation uses to enforce access rights
Kevin: only certain apps would be permitted to access sensitive data
<PatrickB> In the viwi case, you would be able to limit access on 3 levels: service, resource and even element properties, while the later is usually not very practical in real life ---- viwi of course spans multiple domains, so securing "signals" would rather be securing groups of them that you would find in separate resources
Fulup: understood. one thing we are looking in AGL is having an application describe what it wants to subscribe to and consume
<PatrickB> token based ofcourse
Fulup: if the API is standard but the metadata on what is being consumed by an application would be more difficult to run on multiple platforms
Kevin: we define get/set/subscribe and discovery. you can get back based on your specification the data permitted. what you get back is VSS tree
<kaz> GEINVI's Vehicle Signal Specification
<fulup> Deferring AGL architecture presentation should probably be delay by 2 weeks as next AGL/AMM in Tokyo will happen 8-10/feb.
fulup, that sounds good
PatrickL: we can try to do some side by side comparison
Paul: that sounds good
PatrickL: as an example if i need vin I would first do a search on the document for the API or click through and look at the whole tree from vss
[discussion of where to find in tree]
Paul: VSS is just the data definition, the call would be through the service spec
Adam: via web socket you would say get vehicle...vehicleid
PatrickL: in another example where i have the path available and want to subscribe and get notices every 100ms
Adam: you would send a subscribe with the path of the signal you want and a number of filters
<kaz> Latest Editor's Draft of the Vehicle Information Service Spec
PatrickL: I'll walk us through from ViWi side
[some were not able to follow presentation in WebEx, a written comparison in wiki, github or email would facilitate continuing conversation]
http://doodle.com/poll/4fwebn3qdu39hpsu#table
<PatrickB> For those who want to play around with viwi to experience it themselfs, I put my pet project on github, currently focussing on the server parts, functionality of service follows : https://github.com/wzr1337/viwiServer
0600JST, 1300PST, 2200CET, 2100GMT, 1600EST
for next Monday and possibly switch to alternating times