Automotive WG f2f in Paris - Day 1

Introduction

<inserted> scribenick: kaz

starting with Paul

Paul Boyes, Ted Guild, Shinjiro Urata, Tatsuhiko_Hirabayashi

Kaz_Ashimura, Qing_An

Volker_Fricke, Wonsuk_Lee

Soumya_Kanti_Datta, Peter_Winzell, Powell_Kinney, Rudi_Streif

Klaus_Birken from Genivi, Osamu_Nakamura

Hiro_Hayashi

Kevin_Gavigan

Service approach versus web runtime approach (Websocket approach vs current WebIDL)

Slides

rudi: there are various OSs/platforms, and no standard APIs

urata: made some slides on pros/cons of each approach

peter: IDL could be used for either approach

rudi: the question is where do you implement the API

paul: what level of API do we as the WG want to expose?

klaus: we have built a prototype implementation
... if we manage to specify protocol, we can define APIs on both the W3C side and the Genivi side
... protocol and serialized data should be separately defined

rudi: we focus on the upper layer interface

paul: would discuss what APIs would be used which interface using Kevin's architecture

urata: (shows his slides)

kaz: slides to be distributed later

urata: Pros and Cons
... Questions
... and Web and Automotive Hackathon in Tokyo
... [ Vehicle API (polyfill) structure
... KDDI/ACCESS implemented polyfill-based Vehicle API processor
... what is done by the polyfill
... manages queues for subscribe() API and get() API
... Data matching, JSON parsing and WebSocket I/F
... Data Broker translates OBD-II data into JSON
... another possibility is Data Broker directly handles get/subscribe APIs but it's not the case here
... call backs will be queued on the subscribe queue and the get queue

hira: Web Apps don't specify URLs (or IP addresses)?

urata: no

kevin: are you really subscribing the data?
... what's the purpose of having subscribe and get?

urata: depends on the property
... get for vehiclespeed
... and subscribe for engineSpeed

rudi: this is the model I was describing, we can define the WebIDL piece and leave the websocket server and databroker to the underlying auto manufacturer

wonsuk: how much data could be handled at the same time?

urata: there is no limitation

wonsuk: concerned since we have a lot of data properties

urata: the vehicle api polyfill keeps working

hira: you'll improve the mechanism. right?

urata: yes

wonsuk: why did you use this model?

urata: wanted to implement an actual prototype system asap

klaus: share the concern with wonsuk
... should avoid making the JS processor keep work
... the communication flow between the OBD2 side and the data broker side

urata: there is a set method within the spec
... using OBD2 dongle to communicate with the OBD2 network
... in this system, it's impossible to implement set method
... we focused on get/subscribe for this model

ted: websocket approach may be bi-directional
... you used OBD2 for this model, though
... Rudi's comment is that the green Data Broker part may be provided by OEMs

rudi: blue part should concentrate on the existing APIs
... and we could use websocket approach for the I/F between the orange part (vehicle api polyfill) and the green part (data broker)

kevin: the orange part is in charge of data transfer to the green part

paul: we have Adam Croft online (gotomeeting)
... can share the screen using Gotomeeting

kevin: another question is how to use websocket for multiple APIs

powell: could have 2 separate socket connections for get and subscribe

kaz: how many sockets did you use, Urata-san?

urata: one socket for both get and subscribe

<klausbirken> I understand there is a goto meeting for screen sharing, could someone share a URL, please?

ted: one of my reasons I like the websocket approach is that it could have access control granularity

<AdamC> Hi All - go to meeting https://global.gotomeeting.com/join/134321333

ted: developers could use both the vehicle apis and websocket depending on their need
... AGL does websocket approach
... agnostic from the presentation layer, e.g., Qt
... vehicle apis might be convenient for developers but websocket would provide another layer

rudi: I myself am neutral
... inside of the IVI system, there could be various presentation layers
... possible to have another web browser who talks with web servers outside the vehicle

<ted> scribenick: ted

kaz: you can connect for talking to the outside world as well in the vehicle api layer

rudi: you can still do websocket approach from a webidl and expose other lower level system (c++) apis that way
... speaking to platform specific apis would require browser vendors to implement and they might once platforms like genivi are more established

<Zakim> ted, you wanted to ask who would likely produce and maintain vehicle api layer

Browser extended to include the vehicle api processor polyfill

<kaz> ted: we may see one or more browser vendors implement for this market but there will likely be a time gap we would need to cover. we would need to get genivi or someone to implement browser extension. it would be easier to have a js only lib implementation as it can work in multiple runtimes

<inserted> scribenick: kaz

klaus: how do we handle smartphones attached a car? they are less likely to have webidl component but could do websocket

urata: you can use vehicle apis on the smartphone

<ted> volker describes the kid in the backseat "are we there yet?" use case :)

volker: might want to use bluetooth, etc., as well

hira: implemented this system on smartphones for taxis as well
... including bluetooth I/F

paul: Kevin also has his presentation

urata: coexistence of high-level I/F and low-level I/F would be possible
... [ Vehicle API (native) structure ]
... peter implements similar model

kaz: have you already implemented this native model?

urata: partially
... implemented get method but not subscribe yet
... [ Vehicle API Impl ]
... same things are done within both the polyfill version and the native version
... [ Vehicle API (native) structure; again ]
... [ Vehicle API Impl; again ]
... [ Pros Cons ]
... we had many opinions already

ph: can you do both the approaches?

urata: that's possible
... and one possible option

paul: want to have explicit discussion on this

urata: [ Web and automotive hackathon in Tokyo ]
... Japanese OEMs attended, Tier1 companies as well
... there were 11 teams

hira: please talk about the development environment

urata: created some emulation environment for the developers
... (shows some video)
... video image hosted on Youtube and vehicle data on the display using the vehicle api polyfill
... highways, mountain roads, etc.
... wanted to detect ABS information but couldn't handle that
... in this system we implemented 20 features or so
... [ diagram of AWS, YouTube, Synchronize, Vehicle API polyfills ]
... vehicle api polyfill requests data and AWS sends the data

hira: recorded data could be used for testing

ph: wondering if it's possible to make this more publicly to W3C so that more people can be aware of this work
... maybe other Members are interested in this work

urata: someone has to drive the car to collect data
... because of security reason, we've not published the URL yet

paul: this is the link to the AWS site

urata: right

klaus: what is important from the GENIVI viewpoint is clear mapping between the IDL and the implementation
... we could transform FrancaIDL to WebIDL
... automatically
... the key point is how to adapt to this

(Klaus leaving for another GENIVI session)

paul: Kevin also has his presentation

(we can come back to the Pros/Cons discussion later)

[ morning break ]

<ted> scribenick: ted

Kevin's architecture diagram

https://lists.w3.org/Archives/Public/public-automotive/2016Apr/att-0028/W3C_Automotive_API_Candidate_Architecture_KCG_v1_0.pdf

kevin: left hand side is vehicle modules - display, gps, cameras etc.. list is much more extensive and these are just examples
... along the bottom are CAN signals with their secure gateways
... glossing over the networking components as they can be bridged a number of different ways
... the top layer is the different types of clients that could consume the vehicle api, again not exhaustive
... web runtime is what we call a browser instance without an address bar but to run html5 apps available on the vehicle
... loaded from a local webserver and file store
... you can have a multiple of different information available to your apps
... if it wants to consume vehicle signals it would need to go through an application server, imagine a nodejs instance that can return json
... between the application server and vehicle interface we can attach security tokens. not everyone (app) should be able to get and set attributes
... in a typical vehicle there can be more than one CAN bus with different gateways
... client might also want to combine signals from off-board (internet) service
... those would go through a firewall to externals data services, portals etc
... getting traffic, weather and other information
... OEM may have a specific data provider, vehicle identifies itself via PKI
... all communication over TLS
... another potential client is where the user can have a browser and retrieve html, css, etc from the internet directly and we permit some access to local application server
... given the security concerns this is a less common scenario
... also may be Qt/C++ and headless(managed runtime) apps
... as we do not intend to expose a public IP address the cloud data provider will control what gets passed back to the vehicle
... off vehicle clients can be a browser - follow vehicle activity
... or external applications and services

paul: why have separate web server and application server?

kevin: they are performing separate roles
... they don't have to be separate

soumya: it seems you are using a number of web standards/technologies already
... if there is some time from WoT perspective we have a presentation that would be worth sharing

paul: hopefully yes

<Soumya> thanks Ted

kevin: in terms of security if we stay with http web service base, are there issues with hijacking websockets or other concerns
... there are scenarios where you may want to expose off vehicle advanced access like to emergeny responders who want to disable airbags after crash so they do not engage as they are helping people

[kevin describes token passing]

kevin: you will want various off vehicle information about driver, preferences for seat position, music stations etc
... people will want this to be able to follow them across vehicles and will likely have different subscriptions (content and service) they will want to use
... number of reasons you will want to identify the driver and it is rather complex since they may not be the owner and you want to protect driver information, clear it from vehicle
... user can be registered with oem portal which stores their information, they identify themselves with a sso auth and retrieve that information

soumya: do you have guidelines for how we access the CAN bus?
... I have a basic demo for transferring basic data from the vehicle to the cloud

kevin: it won't be the same even from the same vehicle manufacturer across different models

soumya: there any standards for that?

paul: you can buy some tools that try to synthesis the varied signals more consistently

rudi: there are common denominators and been some attempts to expose more consistently

paul: you referring to the bosch project? it helps you decode the various signals, i haven't used it though

rudi: no, I'll look for the name of it

<rstreif> http://openxcplatform.com/

kevin: it is a big piece of work
... an oem cannot just expose signals

<Zakim> kaz, you wanted to confirm "Off vehicle clients" could be include smartphones of the driver within the car

kaz: I was wondering if your off vehicle client could include the driver's phone?

paul: yes

kaz: they would be firewalled from the vehicle

kevin: yes

kaz: including bluetooth connections and the phone can then combine with internet information

kevin: off vehicle can be any one of a number of things, including other vehicles or anything connected to the internet

Bart van Leeuwen http://netage.nl/en/ - useful contact for emergency service interests and use cases - he is an emergency responder and software engineer involved in w3c

ted: i would recommend oem portal does poll & pull of updates instead of push as is generally more secure. i think a portable user profile that span different manufacturers is more useful for the consumer, handle borrowing or renting cars, mixed corporate fleets etc.

kevin: @@external and profile

powell: you need to be concerned during the http handshake but once wss socket is established it should be safe

<Paul> Vehicle Spy - http://www.intrepidcs.com/VehicleSpy/index.html Vector - http://vector.com/vi_can_solutions_en.html Busmaster - https://rbei-etas.github.io/busmaster/ OpenXC - http://openxcplatform.com/

[JLR video]

wonsuk: can you elaborate on the type of application is your 'web runtime'?

kevin: it is a browser but supresses address bar and can only run selected apps from a homepage
... it will be a managed environment

wonsuk: will you be creating apps for the phone as well that resembles an application and not a browser?

kevin: yes, we have some already from JLR
... there is code in the downloaded app to act as an authorized external device that can be used as an touchscreen for the head unit

wonsuk: do you presently have a web runtime in your vehicles?

kevin: we have a supplier that provides a web runtime

paul: you see this model used elsewhere like checkin kiosks at the airport

wonsuk: role of web runtime is to provide a more secure environment potentially with access to additional privileged apis
... you mentioned security tokens to access different modules
... will an app need to use different tokens to access different modules?

kevin: you don't have to but will want to if that is being shared with different [external] services

soumya: @@2

wonsuk: have you looked at FIDO?

kevin: there are a number of interesting mechanisms, more on the way, for increasing security including hardware models
... it is an evolving area
... some things, like entertainment, are not as critical
... but anything coming from off vehicle is a possible attack vector

<Soumya> Ted - my question was on provisioning the security keys

[attempt to get a understanding of webidl, websocket or both]

rudi describes the francaidl (genivi) would be used by the websocket server to communicate to the underlying vehicle and there is a clear benefit to web app developer to have the higher level api

[in the case of genivi as more francaidl that want to be exposed, they would only need to follow the coupling in websockets layer]

how we might want to do the REST https://github.com/OAI/OpenAPI-Specification

different developer audiences (lower level C++ automotive and web developer) but it would be worth seeing if franca generated js is viable as the higher level js api

Three Levels of Interfaces

RESOLUTION: 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

<kaz> [ Lunch ]

<inserted> scribenick: kaz

Electric vehicle (Volker Fricke)

Slides

volker: [ Agenda ]
... EU Green Vehicles Project
... Project IBM Research an Energy Producer EKZ
... EU Green Vehicle Project "NeMo"
... Requirements for EV In-Vehicle Data Access
... [ The "Green eMotion" Project
... [ What are the end-user's requirements about electromobility services? ]
... charge EV anywhere; only one bill; finding charging points from any station provider; intelligent and smart at any station provider; park&ride
... [ The Green eMotion Project Consortium ]
... industries, utilities, EV manufacturers, Municipalities, Research Institutes
... [ Who are the stakeholders around electromobility? ]
... EVSE, Utility, EVSP, IT Provider - End User
... [ Operating EVs with many stakeholders is becoming very complex, costly and impractical
... quite complicated data flow
... [ Green eMotion Building Blocks ]
... Municipalities/Government: Policies, Legislation, Standards
... EVSP: EVSP Backend
... MP Provider: Clearing House, EVSE Search, Marketplace
... OEM/Fleet Operator: EVMS
... APIs between MP Provider and OEM
... [ Mass market adoption of EVs is enabled by a B2B Marketplace that will interconnect all stakeholders... ]
... [ Motivation for EV Smart Charging ]
... nice to get charge plan loaded automaticall into my EV
... [ Pilot architecture for ubiquitous smart=charging of EVs - 2014-2015 ]
... information automatically downloaded into the car
... prototype implementation
... [ European Union Call for Green Vehicle GV8 extends IBM contribution from EU Project "Green eMotion" towards transport and smart grid integration and services ]
... interaction with ICT platform
... [ IBM has demonstrated "Open Marketplace" ICT solution which allows new innovative business services... ]
... [ Information and Communication Technology (ICT) plays ... ]
... [ Source: NeMo Proposal, chapter 1, figure 2 ]
... this project is about to start
... lasts for 3 years
... [ Nemo environment interconnect all stakeholders ICT systems... ]
... only one marketplace
... also network of e-mobility
... [ Initial Draft of EV Data Requirements for In-Vehicle Data Access ]
... Table of "Draft by Robert Sharpe & Volker Fricke"
... Table of "C-ITS EU Platform Workgroup..."
... this is our first input
... data needed for EVs
... don't see OEMs want to have standard framework for EVs
... so would propose Web-layer framework
... will send the PDF to the group

paul: questions?

wonsuk: did you see the W3C Vehicle Data spec?

volker: quickly skimmed

wonsuk: already some overlaps
... we need to add requirements from this work to the Vehicle Data

paul: there was some background discussion as well

wonsuk: we should create a new GitHub issue for this topic

peter: there was already some issue, wasn't it?

paul: something, but we should add another issue for EVs

volker: yellow part of the table on the right side is partly available
... Daimlar, VW, BMW who participate in C-ITS

ted: can we talk with C-ITS guys?

<ted> (get review of spec addition of ev attributes)

volker: we had this initial idea from some of the vendors
... not mandated

wonsuk: there are some mismatching between this work and our vehicle data

<ted> Missing electric vehicle functionality

paul: suggests you and Robert work on that

volker: it's not a standardization body but a EU working group
... on the ISO level, we have Web service I/F
... mandated by European Commission, so European car manufactures have to do

paul: can you send information on tesla api standards, Robert?
... you could post the information

robert: of course
... will send it
... the other thing is
... any motivation...

(lost connection?)

paul: he created a group, and send a link

<paul> https://docs.google.com/spreadsheets/d/1pwe06DD6XD8oIjp6XxOGkOqDHMR0y96CNMOvf-EcTCQ/edit#gid=1209696266

hira: question
... sometimes EVs act as a power supply
... but don't see that feature in the list here
... switching time/voltage, etc.
... were your taking about that point within C-ITS?

volker: no
... so far manufacturers think about just storing electricity and use it for vehicle itself
... Mitsubishi Motors is interested in using electricity for other purposes

ted: safely reuse the electricity?

volker: yes
... feeding electric power to the home
... we IBM have some project on energy management
... use EVs as electric power buffer
... only Mitsubishi provides that capability

hira: Toyota may also

ted: I have seen Prius where I live as a generator when there is a power outage from storms

paul: looking at the Google spreadsheet above

Robert: there are commercial entities
... this is a remote API

kevin: promote competition
... there are a number benefits

<paul> https://www.linkedin.com/groups/8469823

volker: some proposal :)

paul: if we have a standard, would be beneficial to reduce the cost

robert: have to talk within the company

volker: this kind of position paper would be useful to convince OEMs

kevin: JLR is very keen on opensource

volker: this work is done to convince OEMs

kevin: OEMs take care of user information

kaz: wanted to suggest we talk with JP OEMs and ask them for opinions on EV features

robert: It is probably better to set standard then let manufcaturers follow

W3C Web of Things (Soumya)

Slides

soumya: working on discovery, etc., for Web of Things topic
... would present to highlight what is the role of W3C in the WoT space
... also how WoT could be useful for the automotive industry
... [ Internet of Things - Landscape ]
... various industries
... [ IoT Challenges ]
... everybody has to implement their platform
... wide range of technologies
... vertical domains
... uniform data representation and processing
... [ Web of Things ]
... open markups
... [ Web of Things - Motivation ]
... WoT concept is becoming more popular
... web standards to interconnect devices
... open, flexible, scalable and interoperable
... [ Problem to be addressed ]
... Fragmentation in IoT platforms and technologies
... High cost of integration into an existing solution
... Barriers for semantic interoperability
... [ How to Solve ]
... many ways to solve the issues
... open standards for Web-based abstraction layer
... [ WoT - Clean Separation of Concerns ]
... application developer (WoT focus): Application, Things
... platform developer (IoT focus): Transfer, Transport, Network
... [ W3C WoT Interest Group ]
... workshop in Berlin (June 2014)
... launched IG in 2015
... 4 technical TFs and Communication TF
... WG charter is under preparation
... [ W3C WoT Interest Group (cont.) ]
... Strong emphasis on practical implementation - Plugfest
... interoperability and understanding
... compiled document on current practices

-> http://w3c.github.io/wot/current-practices/wot-practices.html current practice doc

scribe: [ Thing Description and Metadata ]
... what kind of data do you serve?
... how can I access the data?
... [ Thing Description Overview ]
... the Thing Description TF working on three objectives
... 1. minimal vocabulary
... 2. extension for domain-specific context
... 3. resource description
... current working odel: semantic metadata, resources, communication, @@@
... [ Scripting APIs and Binding to Protocols ]
... discussing the guideline for the possible scripting APIs
... [ Scripting APIs for WoT ]
... possible model
... WoT Client API: discover things, access things, considering Thing Description
... [ Resource Discovery ]
... discover Things and their Metadata
... 6 mechanisms: search around ME, search on a network, search in a directory, search across peers, search for metadata, search using semantics
... [ Provisioning ]
... includes several aspects
... [ Security, Privacy and Resilience ]
... also work on security, privacy and resilience
... [ Communications and collaboration ]
... reaching out to industry alliances and SDOs
... [ Deliverables ]
... Current practices: http://w3c.github.io/wot/current-practices/wot-practices.html
... Architecture: w3c.github.io/wot/architecture/wot-architecture.html
... Use Cases and Requirements: http://w3c.github.io/wot/wot-ucr.html
... Survey of current tech landscape: https://w3c.github.io/wot/landscape.html
... will send the slides to the group
... tomorrow I'll have another presentation on Eurecom's automotive work and demo video

hira: what is the scope/definition of WoT?
... Web browser for IoT?

soumya: Web standards for IoT
... so many physical things
... they can communicate with each other and expose capability using the Web standards

hira: many companies/organizations have developed protocols for IoT
... wondering about the relationship between W3C and those orgs

soumya: a lot participation from the industry
... e.g., Fujitsu and Panasonic
... this is the list of participants
... (shows "Members of the Web of Things Interest Group")

hira: discrimination on the role of other SDOs

soumya: we can put WoT on the top of their own approaches

What WoT is like

kaz: Soumya explained WoT as the background for his talk on "Web of Things for Connected Vehicles" tomorrow

(discussion on the agenda)

paul: can show you what we do

peter: have some codes

paul: maybe Urata-san as well

<ted> scribenick: ted

<kaz> [ afternoon break ]

<Soumya> * soumya thanks kaz for his explanation on WoT

<PowellKinney> https://github.com/pkinney/w3cag-simple-server

Vinli's implementation (Powell)

<PowellKinney> Caveat: just threw this together this morning, so may not be the prettiest, most idiomatic implementation

powell: quick prototype based on this morning session
... here is a server with a data backend. vinli has a socket server
... this is pure js using jquery in nodejs
... start off with storage, open port, wait for connection, examine message type - get/set/subscribe
... on subscribe we set a listener to the store. when it is updated we send back the json
... looking at whether to sub/unsub by path
... finally when the client disconnects there is a garbage collection
... the local data store is just a big hash
... vinli has some similarities in its model
... i have a dummy account that does routing information
... on the screen you can see the data being streamed
... that is the data being fed
... bottom half you see the web methods (request log)
... in this front end mockup you can subscribe or get, see the data coming through, unsubscribe after
... websockets are easy to work with, what makes it complicated is hoops to go through
... we are going to have to look at path based subscription, having multiple apps requesting overlapping and different data
... having as many different examples of this as possible
... i want to turn this into a mocha script so we can validate
... feel free to play with it, there is a docker container if you want to run it that way
... now showing the frontend side code
... there is a bit of awkwardness and would be nice to have a higher level api (as discussed this morning)
... at some point in time i expect a value back

peter: what do you mean when you subscribe to vehicle.door?
... does that return the json for the door or changes to door data?

powell: you may want to subscribe to everything available from the front right door
... and see all individual messages underneath, open, lock, close messages
... you will get the same messages if you subscribe higher up in the tree
... rabbitmq has a good model and pattern
... when we get some kind of model i would like to have some sort of drop down and work on the visualization
... ask for the model available and traverse it

paul: what is the protocol on websockets here?

powell: this is just a strawman and needs to be spelled out, heartbeats and handoff are taken care of for us

INRIX/OpenCar implementation

paul: i can show our (opencar/inrix) system
... it follows w3c dataset

[scrolling through attributes for an actively changing one]

paul: this is from a mazda3

wonsuk: that websocket also?

paul: yes
... the json is very similar to what you just showed

Vehicle Signal Specification (VSS)

Slides

magnus: we need to be able to share the vehicle state with off-vehicle entities
... there is no standards that fully fit the bill, w3c's is close
... one format does not suit all
... vss is standardizing signals information under genivi banner
... we are keeping it simple and evolving quickly, lightweight mailing list and pull request process to add new signals data
... we hope to be the feed data signals to w3c and other organizations
... signals is standard tree structure, branches and signals

[sample body.mirrors.left.heated...]

magnus: we are currently scrubbing internal documents to make available
... volvo (at least) is interested in the same thing
... branches have descriptions. signal is an attribute with unit, type, min, max
... if a subsignal is updated the entire branch gets sent
... yaml does not have an include directive but #comments work
... we can include the same subspec for door for example. you can have door or upstream the entire body
... if the door vspec is later added we can regenerate and updated files will have it
... even if you have proprietary signal information you can include that vehicle specific information easily

[sample has anti-gravity and teleportation as example :) ]

magnus: if someone is using an electric vehicle and they want to standardize their model we can accept as a pull request

ted: we had that earlier (possible ev contributions) today from volker and robert

magnus: it is one line of code to generate the json, francaIDL, markdown documentation and we are open to new target generations
... parser is open, again submit a pull request
... pull requests prompt mailing list thread discussion. if no objection and backwards compatible a new version is released

[demo]

magnus: i took the latest version, run make on the yaml files and here is the json produced
... we still need to agree on how to name doors, presently using 0 based index

ted: when you gave some of us a tour before i thought you mentioned overriding index labels eg door 0 to front left

magnus: yes, you can do so in your proprietary vspec
... you can weigh your values

kaz: so you can override branches?

magnus: yes, supported but not implemented

kaz: i say this because we were looking at a picture of Veyron earlier

magnus: yes, different number of cylinders
... this is just a naming scheme

<kaz> fyi: https://en.wikipedia.org/wiki/Bugatti_Veyron

[we need to stop talking about cars none of us can afford :) ]

[unless they want us to help with testing...]

powell: no access layers?

magnus: no, this is on vehicle
... question is can this be mapped (or integrated) into w3c standard and wrapped with an api

powell: what about signal frequency?

magnus: yes but implementation specific, frequency varies by signal and bus

[i think i heard top practical signal speed of 10ms - can someone confirm?]

paul: we have a big flat table of these things, you build a profile of what you want
... you name the signals you want
... a debate here is flat vs hierarchical?
... what happens when an attribute falls into multiple branches?

powell: aliasing?

magnus: yes
... that is going to be a lovely argument and different oem will have different structures
... we are going to put out an initial proposal and not going to be religious about it
... are you proposing aliases or?

paul: just asking

magnus: your speed signal example belongs under transmission imho

powell: you might just get speed not wheel speed and not know where it came from

magnus: it can even be gps derived

paul: maybe you are sending data offboard for product development and want all three different speeds
... an app developer just wants one value

magnus: in that case it probably will be in three branches and you want to decide which you want or we present a generic one
... i don't have answers but you are asking the right questions :)

powell: you will want to know which you can read, write or if you cannot read it that it exists

paul: when you subscribe to a value and get a string or id, the upper level api will likely pass the full string but you may want to map to an id
... that would be useful for many

magnus: we want a library that injests this spec, can traverse the tree and let you know what is actually available on the vehicle to subscribe to

[that would be extremely useful to app developers]

powell: whatever is published right now is what we assuming

<Zakim> kaz, you wanted to ask if signal freq depends on the class/type of vehicle

paul: you'll need to know a bit about what you are looking for
... JLR (Paul Wheller) and others did an exercise where they looked at earlier data spec and what they could expose

magnus: we are not sure yet how apps in the head unit will use this data
... it is not going to be a dump of signals but i want a low barrier for being able to share them

paul: you would hope for hmi you can expect these common set of signals

powell: can we have a baseline?

ted: no unfortunately, eg in some cases oem do not have licensing rights to some ecu signals to give to hmi

paul time check and ota on agenda

magnus: next step is to integrate from existing w3c vehicle spec

kaz: we might want to have a spreadsheet with two columns, 1 for VSS another for W3C Data spec like the following.

VSS vs. W3C Data Spec

joonhyung: it would be nice if genivi and w3c developers were using the same

paul: that is a possibility but would impact whoever has started implementing

shinjiro: we knew we were using an early spec

paul: precision and floating points in js might be an issue
... you cannot control precision at the source

magnus: you may also want an average and lower frequency

ted: interest in ditching data spec instead of mapping, adopting vss adding ev and work on ipr concerns (nil?) between orgs and w3c snapshotting or doing external references to snapshots. this is genivi specific and a very open submission process but concerned people may come to w3c with proposals/objections - will want to avoid forking/conflict resolution

magnus: feel free to fork

ted hopes we don't need to but yeah that was what we thought might be the outcome

paul: we had pushback earlier. i would argue with them heavily on differences to eg tree structure

ted: people who show up late have less of an argument

paul: plus you have an override mechanism
... i can see arguments from auto side on diagnostics

magnus: there will be some that will want it changed to suit their existing architectures
... we might get people coming out of the woodwork with their counter proposals

paul: almost a good problem to have

magnus: we are trying to abstract this as much as possible

shinjiro: i am concerned about the timeline/roadmap
... we are suppose to be shipping this rather soon...

ted: no problem
... actually we have rechartering on agneda for tomorrow

shinjiro: we will need two reference implementations for lower and higher level apis?

ted: we will likely split the specs and can move separately

shinjiro: also test suite

kaz: yeah. two test suites should be also generated separately

RVI API

jerry: for creating vheicles we have vin as identifier

PUT /vehicles/:vin/...

<kaz> GENIVI SOTA project

jerry: component path returns list of all the components that are on that vehicle
... and how you get the underlying part number
... same thing with [software] package
... packages are distinguished by name and version
... includes vendor and description
... version is major.minor
... to associate a package as installed you use PUT
... you can PUT many packages on the system
... where that is interesting is with GET /filters which takes a unique name and expression
... expression is string with regex, AND or OR logic...

[see link to filter syntax within the doc]

jerry: you can do a POST /validate/[filter]
... GET /resolve/:name/:version is useful for knowing what is currently installed and need to be updated
... POST /updates
... resolve comes up with vins that will be affected

paul: this is the sota server side, this is a web server api
... what is the core api?

jerry: for the oem to provision the vehicle and initiate upgrades

rudi: rvi doesn't know the vehicle IP address
... sota runs on top of rvi

<paul> http://pdxostc.github.io/rvi_sota_server

[sota client is on the vehicle, sota server is backend]

<kaz> SOTA Architecture

<paul> http://pdxostc.github.io/rvi_sota_server/dev/architecture.html

volker: are these packages signed?

rudi: another piece of infrastructure handles package management and checks keys etc

wonsuk: can you describe the usual process? the vehicle sota client checks with the server need to update

jerry: i have been going through the admin and oem interfaces
... rvi is json rpc not rest

rudi: sota server is run by oem and initiates a software update campaign
... what happens next is the campaign goes out to resolver to know which vehicles it applies to
... legacy parts management system figures out the components (ecu) dependencies
... there is a mix of hardware and software dependencies
... server figures all this out, comes up with list of vehicles affected
... the core server schedules the campaign telling the client (vehicle) the package is available not sending the actual package
... client acks it receives update notification, potentially alerting the owner that there are pending software updates. there may be policies about when the notices and updates take place, eg not while going 100mph on the hiway
... user can accept or decline some types of updates, security and critical ones may not even be sent to the user but required by policy
... client will tell server when it it ready for the software update
... chunking it up and sending over rvi (logical protocol) which does address resolution
... rvi on the client side lets the server know where it is (how it is available to connect)
... this is different than debian or rpm packages, squashfs and can carry out various different types of operations
... it doesn't just update the packages on the head unit itself but can relay onto the vehicle network to underlying ecu

paul: where do we think this should go within w3c?

rudi: that is a good question
... not sure how this conversation initially started

paul: john cain from arynga reached out to us probably based on this work
... what i am trying to ascertain is how we fit in. you already did all the work and this makes sense

rudi: agree, this is like amazon trying to standardize their ec2 cloud services

paul: if there are multiple implementations and you want to get people involved

volker: this is also a topic for iot

jerry: what we would like to do is approach different oem to adopt this for their fleet management

paul: the left side presumably (sota server in diagram)

jerry: exactly so genivi based client systems

wonsuk: who would maintain the packages

rudi: oems (or designated operator)
... the package is a squashfs image that contains the manifest and installable components

ted: @@on genivi+rvi vs eg qnx.

rudi: yes, it might want to wait based on quality of carrier signal to wait until a better wifi upstream is available

paul: this is a great starting point and makes it easy for us to get our heads around it
... we have one implementation, if someone else is likely to implement then we have a recommended candidate
... the big challenge is who that other person will be

rudi: standardization has great benefits for certain economies of scale and that is clear with vehicle signals
... it is more limited (focused) in this case

paul: you (volker) bring up a good point that this is useful for iot as well
... soumya... we're talking to you and kaz...

rudi: OMA and Samsung

paul: and we are talking with Samsung tomorrow who is in w3c

rudi explains some of the other non-ota use cases of rvi like sending an unlock door signal to a given vehicle vin with certificates and tokens to proove it is allowed to unlock xyz

ted: will this be the only way to do updates including to the ivi os?

rudi: you can handle os updates with debian/rpm

paul: this resembles iot/wot provisioning and updating?

soumya: i'm listening
... maybe the server side yes

paul: client can be any piece

volker: is the device management work taking place at OMA relevant?

rudi: we are looking at that, vehicle is not a single thing and it does not fit that well
... those that see cars as a smartphone on wheels oversimplifies and doesn't understand how it is a complex distributed computing system

paul: joel hoffman approached us (paul, philipp, ted) about how to make oma more relevant in automotive
... there seems to be a very urgent timeline for rvi

rudi: yes, we want to have wider adoption of rvi
... it handles 3 macro use cases ota, big data and vehicle interaction and status information from external devices (smartphone and other)

paul: to me those use cases could fall into the BG
... like ted said unless there are additional parties interested (outside of genivi) we will just slow you down
... also you may want to talk with WoT folks more on the discovery and provisioning

rudi: agree standards alone don't work and you need implementations to proove their work
... people look at the specification and wonder if they have to implement it all themselves or if there is something tangible they can use

ted: all three of your macro use cases and waiting for better (alternate) connectivity are pertinent to WoT as well
... without requiring you to wait or refactor it might be something they want to examine and then find what to generalize at a more abstract layer

paul: the BG is designed to explore potential work so this is in scope

wonsuk: i think there is clear we want to pursue this further
... i will investigate more

qing_an: we can set up a different task force like media tuner
... i need to check internally what alibaba is doing

wonsuk will reach out to samsung

Soumya you and Kaz will check if WoT people want to look at this too