Automotive WG f2f Meeting in Paris - Day 2

<inserted> scribenick: kaz

Summary of yesterday's meeting

paul: we'll do both the WebIDL-based API and the Websocket-based API
... work with Genivi for VSS to align with the W3C Vehicle API
... FrancaIDL is used for system level API by Genivi

Three Levels of Interfaces

Navigation Web API (Philippe Colliot)

paul: Qing An and Wonsuk will join the Genivi liaison call

philippe: [ Quick status (since last AMM) ]
... Franca IDL for Web API generation
... no resource for WebIDL so far
... started to develop HTML/JS/Node.js-based POC
... Telco twice a month with W3C guys
... [ Reminder: FSA architecture today ]
... replace QML-based HMI to HTML5
... [ Purpose of the Oroof Of Concept ]
... [ Proof Of Concept: 3 solutions ]
... (shows demo on VM-ware (Ubuntu 14.04))
... Stub, Single client -> Multi-client based on sockets
... [ HMI migration to HTML: nodejs based approach ]
... nodejs server-JS-HTML5 HMI
... [ Several implementations for one interface ]
... FrancaIDL - DBus XML - Javascript - V8 code to DBus proxy

paul: did you show the architecture slide?

philippe: [ HMI migration to HTML: nodejs based approach ]

paul: using nodejs server to communicate underlying C++ platform
... similar to the architecture of Kevin

kevin: shows his architecture diagram

paul: application server here is nodejs server in Philippe's diagram
... you could go for Franca or JS
... socket server speaking REST for Web API
... we debated the JS library yesterday
... Wonsuk and Qing An are now co-Chairs for the BG
... also Peter and Rudi are co-Chairs for the WG

peter: you (=GENIVI) need to make decision how to handle WebIDL-based API

paul: we talked about our policy at the beginning of this meeting
... we can probably focus on similar type of security
... (looking at Kevin's architecture diagram)
... this is the pattern we've been talking
... for the I/F between app server and vehicle I/F module, Genivi uses Franca
... we use WebSocket or REST for the I/F between Browser and App Server

kevin: all the clients are meant to be located within a vehicle
... browser on the vehicle
... Native apps use Qt, etc.
... "Off vehicle clients" means the rest of the whole world

paul: would like to see stronger collaboration based on additional contribution by Qing An and Wonsuk

wonsuk: think JS APIs would require more time for implementations
... would see use cases and requirements by GENIVI using websocket
... try REST API first and then could extend the capability to JS API

paul: we have liaison meeting with GENIVI
...

qingan: already implementation using websocket?

philippe: shows [ Another example with WebIDL ]

paul: here there is WebIDL on the left side
... to me WebIDL is used for JS generation

rudi: strongly in favor to use WebIDL for Web browsers
... Franca may be used for GENIVI use cases

paul: so we separated the I/F levels
... we're still talking about service level API

(discussion on the approach for LBS API)

ted: ACCESS implemented JS library which talk the underlying platform using websocket
... using a pollyfill library

paul: think service layer is more important than WebIDL

philippe: this year we use FrancaIDL
... and generate other APIs based on that

paul: you can generate anything using Franca for system-level API
... server-level API will be websocket/REST
... web-level API is WebIDL

peter: for Chromium, we define WebIDL and then generate corresponding C++ codes

ted: WebIDL is used as a high-level I/F notation for C++
... you can use WebIDL for nodejs

(discussion using the diagram on the flipchart)

ted: Vehicle API is a high-level API to handle vehicle signals
... could handle LBS as well by that level of API as a starting point

wonsuk: still not clear

paul: high-level client spec (WebIDL), service spec, data spec (VSS), security

hira: what the "service spec" is like?

paul: websocket-based api

hira: my point is that we should define JSON format for the I/F between Browser and Server
... "service spec" would be too much

wonsuk: vehicle data spec handles what kind of data the vehicle should provide

Data and API

EU Platform Co-operative-ITS (C-ITS) Workgroup related to In-Vehicle Data Access (Volker)

<inserted> scribenick: ted

Slides

volker: it is about v2x
... in the connected car consortium they came up with various use cases for warning about traffic, hazards etc
... providing infrastructure for autonomous driving
... EU commission looking at what is needed for standardization, research, regulation etc
... scope of the platform is under the transport sector of EU commission
... first plenary meeting in november 2014
... they have had monthly wg meetins since november 2015

[list of partners/companies - 136 people in 11 wg - slide 7]

volker: multiple sectors involved

[oem, telco data, services, silicon]

volker: looking at cost level analysis, business case/deployment, legal issues, potential standardization
... ibm was appointed to participate on the business cases, privacy and security...
... the technical issues
... phased approach being defined
... there are 4 task forces
... yesterday i presented on ev part
... they are looking from the cloud api requiremnts, within the vehicle diagnostics and data
... location, speed and so on
... aggregate information being sent to the cloud
... based on frequency level and granularity of data needed
... they are looking at current ODB2 possibilities for getting this data and IVI going forward

[task force organization participants - slide 10]

[stakeholder orgs - slide 11]

[diagram on secure channels from vehicle to cloud and back end service providers. iso 20077 & 20078]

volker: this is for providing B2B data exchanges
... they are expecting the cloud api to be implemented within 6 years
... from Daimler presentation...
... recent acquisition of Here by German oem
... high level use cases as a result service calls, roadside assistance
... we see three different models for external access to vehicle data ExVe Extended Vehicle
... I have explained W3C activity to this group

hira: is there plan to use w3c api?

volker: no not yet. it was recognized but did not make it into the final report
... that particular wg was put on hold since they did not have a clear path on going forward
... the mailing list is still alive and can possibly start the dialog there

shinjiro: on daimler slide 5 is there a movement for the middle model?

[ivi and apps approach for external vehicle data exchange]

volker: the oem were more focused on other models

ted: more interest in building silos

volker: correct

rudi: this factors into all oem business

volker: apps are being developed by 3rd party developers on some platforms already like toyota

shinjiro: how is etsi involved?

volker: not really that started later
... we hope to promote this to various oem

hiro: toyota taking more of a sdl approach, are you seeing that more?

paul: sdl was given to genivi when ford open sourced it
... it is basically way for head unit to talk to phones

rudi: it is an alternate approach to eg carplay

paul: they are a number of variations of the same thing
... there is discussion of extending sdl with vehicle data in addition to being able to run apps from phones on ivi
... not sure it is that successful yet

<kaz> [ morning break ]

WoT

Slides

soumya: from iot perspective connected cars are a collection of things, sensors actuators
... from CAN it would be interesting to get at the various underlying sensor data
... you could determine weather conditions for instance from sensors
... from wot/iot we want some best practices for collecting uniform data
... oem have different sensors with data available at different frequencies
... wot is not looking at a single vertical (eg automotive) but bigger picture
... main focus for us is a data cycle
... seeking to get this off the vehicle and storage may be at different levels, roadside service infrastructure, cloud etc
... different data consumer needs should be factored in
... data collection, dissemination, consumption and configuration management

[slide 10 architecture diagram]

soumya: we have algorithms for processing and storing aggregate data

[slide 11 subsystems and elements]

soumya: we have not defined many privacy mechanisms yet but are thinking about acl administration and data consumers

[slide 14 prototyping scenario]

soumya: we were able to access a number of vehicle sensors and send to a roadside gateway
... from consumer side we can initiate discovery to query what is available and then access the data points of interest

[slide 15 hardware used for prototype]

[demonstration]

soumya: main conclusions:
... intersection of wot and vehicles
... want to integrate vehicles into wot
... describing prototyping experience, need to coordinate with auto wg

volker: are you looking at both pull and push for getting this information

soumya: we had a tiny web server in the car itself

kaz: it would be great to continue collaboration. I believe you could make great contribution to both the vehicle api side and the websocket api side

<kaz> ted: data coming off vehicles from your point of view will be either from apps on ivi or oem silos - problem will be sharing, privacy policies

OCF

Slides

sanjeev: we have open governance
... 170 members
... we are getting signficant momentum
... we have a RESTful framework, automotive is one of the sectors we are looking at
... I am tasked with looking at the different standards in this area
... we are looking at JLR/Genivi RVI in particular
... demo concept for us was from hmi in a land rover speaking ocf protocol to other devices
... all of our work is open and published
... we treat rvi as yet another service, had a simple json block describing it
... metadata,auth, capability list, tags
... we came up with a quick data format instead of looking at w3c or other models
... a capability is metadata block, headers, response and tags

[example capability json]

sanjeev: we can provide custome x-headers in addition
... authorization is simple, we went with oath2
... here is an interesting use case, brewing coffee based on weather forecast

[i hope it conforms to https://tools.ietf.org/html/rfc2324]

[Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)]

[demo]

sanjeev: we are using oic protocol instead of http

<Zakim> kaz, you wanted to ask if the initialization phase handles device discovery and to ask how to handle metadata (maybe using JSON-LD?) and to ask if Sanjeev is interested in joining

kaz asks question on initialization slide

sanjeev: application needs to do the discovery
... device doesn't know nor need to the specific apps but the desired high level service such as send alerts not which specific service

<ted> scribenick: kaz

kaz: another question is how the service description handles metadata
... a possibility is using JSON-LD

sanjeev: important point but IOTivity doesn't handle metadata at the moment
... would like to see JSON-LD

<kaz> [ Lunch ]

Wrap-up and Next Steps

paul: start to clarify tasks to do for each spec using a spreadsheet

Four Deliverables for Automotive WG/BG

kaz: Magnus from JLR should join the WG/BG

(discussion on what should be done for each deliverable)

Specs for Data and API

paul: copied the content from the spreadsheet to Word

kevin: mentions we should see the mapping between GENIVI's VSS (Vehicle Signal Spec) and W3C's Vehicle Data Spec

kaz: agree

Comparison between GENIVI's VSS and W3C's Vehicle Data

[ Link to Paul's Word document which summarizes the TF assignment should be added here. ]

urata: wondering how to deal with TF discussions

ted: can use the current BG/WG list with tags on the subject line

peter: wondering about the next f2f

ted: there will be TPAC 2016 in Lisbon

kaz: Sep. 19-23

<kaz> TPAC 2016 page

hira: when will be the next GENIVI AMM?

rudi: October

paul: there will TU-Auto in Detroit in June as well
... 15th GENIVI AMM will be held in SFO

<kaz> GENIVI event page

[ Meeting adjourned ]