- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 27 Jul 2016 16:18:31 +0900
- To: public-automotive <public-automotive@w3.org>
- Message-ID: <CAJ8iq9XQmfvMWZMEXCVC7UVwMoR611ePCrQ=OqbJsmmtZzPMvw@mail.gmail.com>
available at:
https://www.w3.org/2016/07/26-auto-minutes.html
also as text below.
Thanks,
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Automotive WG F2F Meeting in Portland - Day 1
26 Jul 2016
[2]Agenda
[2]
https://www.w3.org/auto/wg/wiki/Main_Page#July_26-28.2C_2016_in_Portland.2C_OR
See also: [3]IRC log
[3] http://www.w3.org/2016/07/26-auto-irc
Attendees
Present
Rudolf_Streif(JLR), Kevin_Gavigan(JLR),
Adam_Crofts(JLR), Wonsuk_Lee(ETRI),
Peter_Hauser(CarFit;_observer), Magnus_Feuer(JLR),
Peter_Winzell(Mitsubushi), Paul_Boyes(INRIX),
Junichi_Hashimoto(KDDI), Shinjiro_Urata(ACCESS),
Tatsuhiko_Hirabayashi(KDDI), Kaz_Ashimura(W3C),
Ted_Guild(W3C), Jeremiah_Foster(Pelagicore;_remote),
Song_Li(Newsky_Security), Powell_Kinney(Vinli),
Joonhyung_Kim(LG, Electronics)
Regrets
Chair
Rudi, Peter, Paul
Scribe
ted, kaz
Contents
* [4]Topics
1. [5]Introductions and Agenda review
2. [6]Status on Vehicle Information Service Specification
3. [7]OSTC Tour
4. [8]JavaScript API
5. [9]Carfit
6. [10]Security&Privacy update
* [11]Summary of Action Items
* [12]Summary of Resolutions
__________________________________________________________
<ted> scribenick: ted
Rudi: welcome to JLR OSTC
... housekeeping items: wifi, facilities
... some background on our OSTC, started renting space
initially, built OSTC1 in 2014 which we'll see later this week
... last year we started building this facility, OSTC2 which
houses designers and our incubators
... Matt Jones came up with the slogan that we are striving to
be the best software company that happens to sell cars
... we open source our architecture to help other companies and
enable third parties to be able to work with us better
... we want people to be able to download and install our
environment on their computing platform to be able to develop
towards it
... our open source and standards is behind our participation
in various consortium such as Genivi where Matt is president
and W3C
... JLR is the largest UK automanufacturer
Introductions and Agenda review
Rudolf_Streif(JLR) Kevin_Gavigan(JLR) Adam_Crofts(JLR)
Wonsuk_Lee(ETRI) Peter_Hauser(CarFit) Magnus_Feuer(JLR)
Peter_Winzell(Mitsubushi) Paul_Boyes(INRIX)
Junichi_Hashimoto(KDDI) Shinjiro_Urata(ACCESS)
Tatsuhiko_Hirabayashi(KDDI) Kaz Ashimura(W3C) Ted_Guild(W3C)
[agenda review from wiki]
Status on Vehicle Information Service Specification
->
[13]https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service
_Specification Vehicle Information Service Specification
[13]
https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification
Kevin: the diagram is over simplified as there are other
possible routes
... client can be software running on vehicle, agent will send
data to off vehicle services
... agents can query signals same as clients
... we are providing an overview of what we know can work
Rudi: the idea would be to implement so the security layers
apply to the different actors
Paul: I know we plan on discussing Iotivity OMA tomorrow. have
people looked at their security model in detail?
Rudi: I have looked at the OMA model and do not recall any
details on security
... there is some detail on the data model from VSS
... as we looked at the current draft W3C data spec we saw it
as too static
... any time you wanted to extend it you would need to go
through the standards process again
... you need a path to a signal through the API and want to be
able to maintain data definition and API separately
... the idea of VSS is to use a simple and extensible language
... straight forward tooling and editing
... we hope to have a minimum signal set that most if not all
OEM will implement and expose in addition vehicle specific
signals
[example declarations from wiki]
Rudi: these definitions can be maintained in separate files and
combined with #include
... get and set methods need to provide the path of the signal
they want
... there is signal * wildcarding to get eg signals from all
doors
Kevin: there has been some discussion on whether it is better
to use localhost or a different host name - maintained by
/etc/hosts file
Adam: we want ids for client connections
Kevin: subscription id facilitates management of sockets
... a concern is multiple connections being used by the same
client application, setting signals on one connection and race
condition querying on another
Peter: I had not had time to fully compare the previous data
spec and VSS but have spent time to implement a test signal
system
->
[14]https://github.com/PeterWinzell/vehicle-carsignal-examples
Peter Winzell's vehicle signal examples
[14] https://github.com/PeterWinzell/vehicle-carsignal-examples
Rudi: we should discuss procedures for adopting VSS, whether it
should reside in W3C repo or ok to reference it etc
Kevin: the tree model of VSS can allow one to provide vehicle
objects similar to DOM (VOM)
... we need nodes to have unique ids in the tree whether they
be numeric indexes or UUIDs
... we want to be able to allow for jquery type searches on
either id or eg all cameras
Peter: so that is a suggested extension?
Kevin: correct
Peter: sounds like a good idea
Rudi: server would be able to load VSS and create a queryable
VOM
Kevin: you could subscribe to vehicle.body and get back a body
object with all the related json
Hira: I understand the merit of VSS tree structure. what is the
top of the tree, vehicle?
Rudi: yes
Hira: there will be some redundance
Rudi: Magnus will tell us more when we get to VSS
... we want to make a model that is easily understood so a
developer can find and navigate to the data signals they need
Adam: we looked at current data spec and readability
... how do you define a control - you might not want to have it
under chassis
Kevin: there is static data that never changes like the vehicle
weight and dynamic or configuration data
Magnus: we wanted to keep VSS specific to signals data and stay
clear of configuration data
... however there is clearly a need for that
Paul: can you clarify what you mean by configuration data?
Magnus: static data like mileage rating, weight
[Magnus presentation on VSS]
Magnus: vehicles can have private branches that are specific to
them
... if we see commonly repeated private branches they should be
candidates to include in the main branch
Paul: I would think as an app developer you would want a
similar if not the same interface
Magnus: if there is a need from W3C side that can influence the
argument at Genivi
... private branch approach has two top level branches
... there are ambiguities in the current spec
... example with seats is you do not know by index which the
steering wheel is at as that varies based on location model UK
vs US for instance
... aliases can help here so you can define 1 as driver's seat
Adam: I see this as much larger than configuration data
Paul: what happens to get that static data is implementation
specific and behind the scenes
Magnus: correct but they will be in their own specific/private
VSS files
Paul: are there any other standards that do this level of
semantics we can leverage?
Magnus: I'm sure there have been other efforts
Rudi: Magnus will make adjustments to Global parameters and
Peter H will define Chasis branch
PeterH: how detailed should I go on eg steering attributes?
Rudi: keep it simple for starters
... bear in mind we will have proprietary/vehicle specific
attributes that will be added as private branches
Magnus: we need to get the basics and structure right
Kaz: how to handle airbags? it's related to how to handle zones
as well.
Magnus: that will be under cabin, they can be active or
deployed
Kevin: what about telematics control units?
Magnus: we want to leave out network specific information
<kaz> (discussion on how to handle zones for airbags, cameras,
etc.)
<kaz> [ morning break ]
[break]
PeterH: can you explain more about zones?
Kevin: we started off two dimensional and latter switched to
three dimensional and found 3x3x3 (rubic cube) could handle
many but not all situations
(earlier example was you may have 5 cameras in the front, two
with different angles in eg front left corner)
Kevin: we can have x,y,z coordinates or index and aliases as
Magnus suggested
Adam: we used ISO8855 x, y, z positive integer coordinates
... in earlier data spec
Rudi: we should action Magnus to use same ISO8855 in VSS
action Magnus to add ISO8855 in VSS
<trackbot> Created ACTION-18 - Add iso8855 in vss [on Magnus
Feuer - due 2016-08-02].
<inserted> scribenick: kaz
-> [15]https://github.com/GENIVI/vehicle_signal_specification
GENIVI Vehicle Signal Spec
[15] https://github.com/GENIVI/vehicle_signal_specification
->
[16]https://github.com/GENIVI/vehicle_signal_specification/blob
/develop/spec/Body/ExteriorLights.vspec ExteriorLights.vspec
[16]
https://github.com/GENIVI/vehicle_signal_specification/blob/develop/spec/Body/ExteriorLights.vspec
(discussion on consistency of name convention)
->
[17]https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service
_Specification Back to the W3C repo
[17]
https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification
(review "VSS Description" section)
(discussion on "Branch Entry")
rudi: "aggregate" element is optional and the default value is
"true"
(discussion on "Aggregation Inclusion")
rudi: "aggregation inclusion" is not a right wording...
... changes to "Global Inclusion"
... flag to identify read/write?
kevin: some data might be more cautious
rudi: implementers might restrict the permission
... update the "Signal Entry" section with "mode: r" for
"chassis.transmisison.speed" to make clear that implementers
may restrict the permission
... also update the "Enumerated Signal Entry"
... with "mode: r"
kaz: maybe it would be better to have another column of
"possible values" in addition to "default value"
rudi: updates the table with the possible values
... "r = read, w = write, rw = read and write"
[18]discussion
[18] https://www.w3.org/auto-f2f/photos/26/DSC_0126.JPG
[ lunch ]
OSTC Tour
JavaScript API
->
rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html
Vehicle Information Access API
->
[19]http://lists.w3.org/Archives/Public/public-automotive/2016J
ul/0019.html Wonsuk's message
[19]
http://lists.w3.org/Archives/Public/public-automotive/2016Jul/0019.html
paul: should align with the service spec
rudi: what is exposed in the current spec?
paul: there are access api spec and data spec
-> rawgit.com/w3c/automotive/master/vehicle_data/data_spec.html
data spec
paul: we've been doing webidl
... also some implementations on thelibrary
ted: who is implementing?
paul: KDDI/ACCESS
peter: others as well
rudi: who is investing?
kevin: Web clients would benefit with WebIDL?
ted: nice to have high-level wrapper
... but maintenance issue
hira: we've implemented JS API based on ACCESS's platform
paul: maintain separately as is?
kevin: benefit to Web browser vendors
paul: that's why created a wiki to see that
urata: making the two specs aligned is good
... simple APIs are useful for Web developers
... vehicle signal spec has tree structure
paul: would present?
urata: yes
... vehicle information service spec
... "Signal Addressing" section
... simple "get" API
hira: should be able to map with each other
ted: you have to update the mapping
... people have to implement both the service spec and JS API
spec
hira: most Web developers are familiar with the current JS API
... they're not really familiar with the VSS spec
hashi: information service spec specifies local server
... W3C doesn't specify that
paul: previously we had Data spec
... now we're changing that
... how to tie then with each other?
... spent long time for the current data spec
... VSS is trying to do more than we did
peter: possible for the data to glow
... don't see any issues to have high-level APIs
powell: we can keep the WebIDL API
... and work on the service interface
ted: once the service API is done we can do the mapping between
the service API and the JS API
paul: like the idea of VSS
... agree with what Ted says
... could have JS library for the client
... maybe we could decouple them
... VSS has more broad target
kevin: websocket interface would be sufficient for us
urata: one thing I'm worrying about is the roadmap
... by the end of this year
<ted> [webidl api in its current form could be mapped to
services api and vss with a wrapper library. webidl api has
provisions for being extensible and that may be how it gets at
new signals data that gets added to vss]
urata: if we change our plan drastically, the schedule would
change much
<ted> [service api is a prerequisite and needs to be done
first]
urata: if we change our direction, not sure about what to do
... need strong reason if we change our plan drastically
paul: this is a flexible architecture
... how your clients work with it
... what the client would look like
peter: the industry doesn't want the old spec...
ted: we're losing interest in the WebIDL approach
... would make sense to have predefined set
<ted> [we are finding more parties interested in the
service/socket approach who are doing similar and had dismissed
our idl approach]
kevin: what sort of conclusion?
rudi: the WebIDL specs are still drafts
paul: what should we do for the new charter?
ted: we're going through the new charter now
paul: who would implement the service interface?
... maybe four from this group?
... who would implement the current WebIDL spec?
... my company would not...
rudi: interested in WebSocket service approach + VSS
kevin: JLR would interested in websocket service approach with
VSS
... not really webidl
wonsuk: also interested in websocket approach
... but JS API could be implemented by polyfill and in that
case it's websocket in the end
paul: do we need JS library?
wonsuk: we don't want to maintain the webidl spec
... but we want to provide js library for Web application
developers
... to define APIs for them
... if people are interested they can provide JS library
kevin: opensource community might want to have JS library
... it wouldn't give any harm
paul: are we formalizing our approach?
kevin: both are logically compatible
paul: I'm not against
... we need two implementations for getting CR
... webidl spec is a client spec
... do we want to specify that?
<inserted> scribenick: ted
kaz: WoT IG is facing a similar problem. they are sending a
questionnaire to stake holders to see what they want
... perhaps we should do the same
<kaz> [20]WoT Implementations list
[20] https://www.w3.org/WoT/IG/wiki/Implementations
<kaz> [ afternoon break ]
Carfit
[21]http://car.fit
[21] http://car.fit/
PeterH: there are many issues not properly monitored by owners
(tires, brakes etc) that are also lacking sufficient sensors
... we are trying to be a go between between service and owners
... drawing from personal fitness devices came up with carfit
... our device sits on top of the steering wheel and monitors
vibrations
... we see this as a real compliment to odb2 monitoring
... we are starting to run pilots of the product out in the
field and starting to look for possible partnerships
... we're looking at things outside of the engine
Ted: what sort of things can you detect - wheel imbalances,
brakes stuttering when applied?
PeterH: yes but we are getting a range of interesting data. we
can tell if there are burrs on rotors
... we are able to discover common issues by class,
manufacturer and combine our sensor data with known problem
sets
... getting information from a genivi+w3c environment adds to
diagnostic capabilities
Rudi: lots of variables such as tire manufacturer to take into
account
Kevin: you are really able to tell that much from vibrations on
the steering column
PeterH: yes, a new car should be pretty smooth and vibration
free a good zero starting off point
... we collect lots of data, some of which will become
interesting or valuable later
Ted: seeing this as an aftermarket solution, you working with
OEMs to get your devices embedded?
PeterH: yes but aftermarket is huge with millions of vehicles
on the road that require hundreds of billions of dollars in
service revenue
Kaz: can you account for driver behavior variation?
PeterH: yes and also we can get into things like detecting when
a given driver's behavior changes - distracted or tired
Shinjiro: is everything done on the device?
PeterH: yes and combining with phone capabilities and products
like Vin.li's
... we would like to be able to send a tire out of balance
notification to head unit for example
Security&Privacy update
Song: security is about controlling access to data and privacy
policies about who that information can be shared with
<kaz> [22]Security&Privacy considerations section in the
Vehicle Service Spec
[22]
https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations
Paul: laws vary by country, for instance in Germany people need
to opt in explicitly for sharing specific information to a
third party
Kevin: we do not want to try to keep pace with various
legislation, only define the mechanisms
Rudi: I agree. we will enable accessing that data but it will
be up to the individual OEM to follow laws for where vehicles
are
Paul: yes but you need to know the use cases more to be able to
define those mechanisms
Kevin: the mechanism can be generic, identifying which
information it is proposing to which external service
Paul: can you give example on how that would work?
Rudi: we went through this with RVI. if a given application
wants to access certain services it needs a signed certificate
and a means to verify it
Powell: @@p
Kevin: the model here is there are separate security authority
providers that can verify a token and entity is valid
Powell: we need a web socket that has a secure handshake and
then able to exchange tokens
... is a token for a specific app?
Kevin: it could be
Song: everything is based on same origin policy
Kevin: I am not sure we need to solve the application
distribution problem
Powell: correct, we can just say you need a token
Rudi: token is signed by OEM and when the token is verified,
specific information that can be shared with the application a
UI can prompt user to opt in
... subsequent times the app is run the IVI system will know it
went through the verification and opt in
Ted: you can send a subscribe to top of the tree with your
token and get back all the data elements you are entitled to
Kevin: yes and a scenario is you might have a privileged
application like ADAS that is allowed full access
[whiteboard exercise led by Powell going over client server
token interactions, verification]
[23]Powell's picture
[23] https://www.w3.org/auto-f2f/photos/26/DSC_0129.JPG
[ Day 1 adjourned ]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [24]scribe.perl version
1.147 ([25]CVS log)
$Date: 2016/07/27 07:08:01 $
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[25] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 27 July 2016 07:19:53 UTC