Automotive Working Group Teleconference

<scribe> scribenick: ted

April F2F

<kaz> f2f wiki

-> https://www.w3.org/2002/09/wbs/1/auto201604/ F2F registration

Paul: Peter from Mitsubishi wants to present on security wrt vehicle spec
... Volker from IBM wants to discuss Co-operative Intelligent Transport Systems (C-ITS)
... SOTA updates
... Code/Artifact generation
... Electric vehicle
... Media Tuning, although not sure who will present
... we don't have a venue set for Tuesday but sure we can do something ad-hoc and there will be plenty of room
... Hashimoto-san will you be there on the 26th?

Hashimoto: yes, I will be there then

Paul: some, like Peter, arrive in the afternoon on the 26th
... I will outline some possible times
... the move to services (websockets/rest) will be a significant topic
... I want to go in with a structured conversation so we can come out with a clear path on deliverables and timeline
... code generation stems from Philippe Colliot (PSA) Franca IDL work at Genivi

[discussion on EV folks Robert and Volker, know Volker is planning on attending and not sure Robert is]

Paul: as mentioned, I'm not sure we have anyone coming on Media Tuning

Ted: Kaz, has Ryan been attending recent TV controller API group?

Kaz: yes, collaboration has started and he has been attending calls. He is adding his use cases to their wiki

Paul: any concerns or agenda proposals for the F2F?

<kaz> GENIVI AMM agenda

Kaz: I am curious about the 27th, we have plans for the 26th, 28th and 29th. I see there is a report on W3C on the agend for the 27th, is there a plan there?

Paul: In the past it has been myself, Adam and Ted presenting on activity and W3C in general
... so there are two W3C related sessions, a breakout and general. They have been fairly well attended
... is Rudy attending?

Magnus: unfortunately no

Paul: Wonsuk will you be there?

Wonsuk: yes

Paul: and Peter will be there so we will have adequate chairs

[re Media Tuning - Ryan is not registered yet]

-> https://www.w3.org/2002/09/wbs/1/auto201604/ F2F registration

Kaz: we should discuss the GENIVI architecture and programming artifact during the GENIVI session on 27th, and bring the results back to our f2f meeting on 28th

Paul: we will go over the details of the changes to the spec on Thursday
... I am open to topics to include in presentation to Genivi

Vehicle Service Specification

<kaz> issue-81

Paul: I wanted to introduce Magnus, have him introduce the RVI motivated Vehicle Service Specification and combine with the related open Issue 81

-> https://github.com/PDXostc/vehicle_signal_specification Vehicle Service Specification

<Paul> https://lts.cms.here.com/static-cloud-content/Company_Site/2015_06/Vehicle_Sensor_Data_Cloud_Ingestion_Interface_Specification.pdf

Paul: this is maybe in line with Here's off vehicle ingestion interface

Magnus starts sharing screen to tour Vehicle Service Specification

Magnus: connected vehicles are going to happen and we will need to be able to interact securely with an API remote for unlocking doors etc
... how can we communicate with different components in the car, head unit and services in the cloud
... we need many more signals than what is presently in the W3C Vehicle API
... other things like radio station being listened to, windshield wipers on, rain sensor, how many pasengers, etc
... if we were to capture all the signals we should start with the couple thousand signals on the CAN bus
... we want to be flexible and rapidly extend to add signals quickly as they are proposed
... we need a convenient nomenclature to be able to quickly and succintly identify a component
... we specify all the signals and starting with using YAML
... we can assemble all these fragments through a pre-processor into Franca C++ JSON etc automatically for various consumers
... we started off with a tree based structure, a placeholder for the time being
... engine, body, mirrors, etc
... we took the typing from FrancaIDL
... we can have min/max. units of measurement will be in an external document
... example is door 0 but it could also be represented as right and left
... bunch of simple flat list entries (in YAML)
... simple description field to explain the signal
... another example chassis.transmission with enumerated values like reverse...
... when one component (long, lat, alt) on coordinates change we send the triple
... if we want to read in doors for example we have lock, window position, etc and doing so for each door with include directives
... this include approach makes it easy to build up the tree structure clearly
... plus is easier for collaborative editing since people are working on different files
... submit a pull request for a specific vsec file
... and can do continuous integration
... we do a simplistic make file invoking a python parser

[giving tour of a full structured json file]

Magnus: the JSON structure is easy for developers

[the expandable tree viewer you can see how you can have a condensed/collapsed view can be traversed]

Magnus: there are a few minor things that can be extended, usually for things like hanging a descriptor
... this is where issue 84 comes in
... how do we map to W3C spec

-> https://github.com/w3c/automotive/issues/84 issue-84

Paul: the main reason for using YAML is to be able to break this up in chunks

Magnus: yes

Paul: if I am an OEM and only want to produce a subset of new signals what do I do?

Magnus: you send an email, results in mud-wrestling on the list and after some agreement a pull request is sent to the developer branch
... we tag the master and merge
... cadence release
... there have already been question from the open interconnect asking if we can produce a RAML output
... I responded they are welcome to add to the python parser

Paul: let's say you have a mature robust spec but I only want to expose 50 of them on my vehicle

Magnus: we will talk to Tier 1s and say we are using release N of the spec and then provide a list of signals from that spec that will be made available
... an agreed subset (or entire spec if we're being ambitious)
... at the end of the day this is a naming convention and not more

Paul: we have a different structure for zones. doors for example have 0 based index

Magnus: it is possible to have multiple names for the same signal door.0 and alias door.left
... on a per vehicle make and model you can tie down what you wish to expose

Paul: what we have in the data spec directly translate, some naming differences

<kaz> Vehicle Data spec

Paul: it should be pretty reasonable to replicate those signals

Ted: @@@ on discovery and benefits of the broader approach

Magnus: we have some discussion on how to do exactly that, be able to do discovery

Powell: I just made a post on this issue shortly before the call
... I would like a low level and high level approach at accessing

Magnus: you can subscribe to various components even a node of a tree
... another thing apart from aliasing is whether you are receiving a signal or an acceptable default

Paul: in my experience you get undef, null etc on occasion

Powell: I don't see anything on availability

Magnus: you want to be able to use the spec to give an acceptable default

Wonsuk: current approach is familiar but the defining of id for each property is a little different
... we need to work on aligning these further, not sure how we can do that
... do you think it is possible to align this approach and W3C's spec

Magnus: W3C' spec is a good base line and want to make sure we integrate them
... the only incompatibility I have seen so far is zone
... we could branch and have a standalone branch. it can get messy

Wonsuk: In the W3C spec we need to align the end points of the existing data specification with VSS
... this will be confusing for developers

Paul: you are talking about 82 and 83 right?

Wonsuk: correct
... the description is different which adds to the confusion

Magnus: when I look at the name spaces in 82 and 83, these are things I would be willing to include in VSS
... what we can do is describe the vehicle with specific signals like length, width etc
... we can end up with a tree that is the official vehicle spec
... there should be a way to combine static attributes like weight and dynamic

Paul: what does the end point look like from our consumer perspective?
... Kevin sent me a proposed architecture, I'll encourage him to send it to the group
... what I guess I would like to see is a workshop where we do a mockup, I have signals I can send through CANalizer

Magnus: one effort is a generica CAN router that can go from CAN to DBUS
... at the end of the day is how a non-automotive entity developer can access this information

Paul asks Powell, Qing An and Urata-san if he will be attending the F2F

Powell: no but can attend remotely

Qing An: yes I'll be there

Urata: I will be too
... there are some very big differences between the Genivi and W3C data structures
... W3C's vehicle data is categorized differently and rather flat without tree structure
... flat structure can be more accepted by the majority
... one benefit of the W3C specification is how flat it is in nature

Magnus: when you add many (thousands) of signals a flatter view has its challenges
... we need several categories for just the HMI itself

Urata: how would a get/subscribe be used here?

Magnus: it depends if it is an internal component doing the subscribe or external
... if internal it would be via Franca
... if external we are going to use RVI and send JSON RPC command to and end point (URL) you want to deliver the data to

Urata: I can use a different API (Franca) within the vehicle

Magnus: correct, we will expose to external services differently (json etc) since we cannot persuade the world to move to Franca

<kaz> GENIVI Vehicle Web API presentation by Justin Park

[time check]

Paul: bring it! (thoughts on issues, ideas on implementation on github and to F2F)

Kaz summarizes the initial contributors to the specs; W3C vehicle specs (vehicle data + vehicle api) were generated based on the GENIVI Vehicle Web API discussion; we separately define the signal vocabulary within the vehicle data spec and should keep the clear separation between the data definition and the api definition, since the api definition could have various levels of interfaces (e.g., WebIDL, FrancaIDL and WebSocket)

Kaz: maybe we can improve the W3C data spec based on the Genivi's new vehicle signal spec

[ted de-queues and will follow up by email]