W3C home > Mailing lists > Public > public-automotive@w3.org > July 2016

[portland-f2f] minutes - Day 1 - 26 July 2016

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 27 Jul 2016 16:18:31 +0900
Message-ID: <CAJ8iq9XQmfvMWZMEXCVC7UVwMoR611ePCrQ=OqbJsmmtZzPMvw@mail.gmail.com>
To: public-automotive <public-automotive@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 24 October 2017 18:52:51 UTC