<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

-> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification 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

-> https://github.com/PeterWinzell/vehicle-carsignal-examples Peter Winzell's vehicle signal 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

-> https://github.com/GENIVI/vehicle_signal_specification GENIVI Vehicle Signal Spec

-> https://github.com/GENIVI/vehicle_signal_specification/blob/develop/spec/Body/ExteriorLights.vspec ExteriorLights.vspec

(discussion on consistency of name convention)

-> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification Back to the W3C repo

(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"

[ lunch ]

OSTC Tour

JavaScript API

-> rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html Vehicle Information Access API

-> http://lists.w3.org/Archives/Public/public-automotive/2016Jul/0019.html Wonsuk's message

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> WoT Implementations list

<kaz> [ afternoon break ]

Carfit

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> Security&Privacy considerations section in the Vehicle Service Spec

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]

[ Day 1 adjourned ]