See also: IRC log
<scribe> scribenick: ted
<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
<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: 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]