Automotive WG

Spec Status

<inserted> Github issues

Adam: we have gone into the various issues including the language configuration one
... to be able to distinguish preferences
... the remaining open issues include refactoring api

Paul: I believe we came close to a consensus on that one

Qing_An: we discussed the language issue and reached consensus on refactoring

Dave: we were ok with where they stood but sought input from other working groups

Paul: Philippe Le Hegaret responded in-line on that issue

-> https://github.com/w3c/automotive/issues/37 Refactor API Signatures

Kaz: we can ask various groups in person at TPAC

Ted: I recall you (Paul) asked the TAG for their input and that Daniel Applequist acknowledged it but forget the details
... they are meeting this week and I will inquire if this is on their agenda and if we should expect a response

Paul: Daniel asked for a summary of what we were looking for and although we intended to do so at the face to face we did not
... Philippe had a few points in his response
... (to editors on the call) can you help identify what we want further focus

<kaz> Refactor API signatures issue (#37)

Dave: it was a pretty long discussion thread with some back and forth but it is fairly clear

Paul: I'll get back to the TAG

Kaz: we discussed using some GeoLocation API in LBS and would be good to get feedback on that as well during TPAC
... we can create breakout sessions on Wednesday

Kevin: part of the problem is we have not settled on a consistent sense of zone yet
... a 3x3x3 cube makes the most sense
... zone left would represent 9 cubes in that plane
... it would cover uses like camera on right front bumper (bottom - 1 cube)

Ted: I agree on 3x3x3 as the most logical. Some OEM don't deal with top/bottom (zenith/nadir) for specific items and that is fine, API would give null values if queried for them

Greg: blind spot monitoring needs to follow the object being tracked
... as such it needs to be consistent

Kevin: you may not care about vertical dimension in that scenario
... there are times you would want to just say front or back (and skip left/right)

Ted: in such a case asking for front right or front left should give the same value

Shinjiro: you may also have a camera facing outward and another inward within the same zone
... 3x3x3 is a simple and good concept but there can be exceptional cases that will need more
... we can come up with specifying name for direction the camera/sensor is collecting data from

Kevin: an extra attribute could help for orientation
... such as external or internal (facing)

Shinjiro: if we decide to put there more details, there will be also cases where it is not available
... the 3x3x3 zone system is good but do need flexibility for additional particulars
... such exceptions may need to come up with their own identifiers for the additional parameters
... i would provide a specific strings to describe that camera

Paul: in summary 3x3x3 is basically alright but we need to provide a mechanism for exceptions
... how to cover that will be the challenge. we need clearer use cases. at some point we need to define our world as finite and cover what is realistic
... it is not worth the effort to cover everything possible if it isn't useful

Greg: it sounds like we should move forward with 3x3x3

Paul: agree until we encounter the more complex

Ted: agree we need to be finite but perhaps provide some flexibility, additional optional data points or how the api can be extended. We can also consult DAP WG as they may have some varying device capability discovery

<kaz> kaz: we have a basic requirement/restriction of concentrating on usual passenger cars (not buses or limos)

<kaz> Paul: right

Publishing Working Draft

<inserted> scribenick: kaz

ted: the published draft is getting out of date
... we can publish an updated draft automatically
... the master branch document on Github can be published automatically

<inserted> scribenick: ted

Adam: how would this work?

Ted: we can deem the master branch to be the one to publish automatically. Kevin was in favor, want to hear from other editors before we adopt

Adam: I am in favor of it

Use Cases

Greg: in a different venue/group I've been working on use cases as well
... it is nearly impossible to write an exhaustive set of use cases for something like security
... people will consider such a set complete when it is not
... somewhere we would need to include a disclaimer,

Paul: yes that it is just informative, that makes sense

Kevin: I agree

Hashimoto: I want to work on security requirements at TPAC based on the use cases collected
... I have shared six privacy items from forty or so use cases. We should do the same for security
... yes the use cases are not exhaustive and informative but can contribute to requirements

<j-hashimoto> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=0

Paul: that makes sense to me and segues to the next items - privacy and security update and f2f planning...

Hashimoto: we have produced privacy requirements
... I want to get opinions on privacy and security requirements from others in the group
... we should create a draft at or before TPAC
... also it would be good to be able to get input at Genivi

Paul: the Genivi AMM would be a good place to get feedback at with the various OEM and Tier 1s
... who plans on being at Genivi? I haven't seen many registrations yet

-> https://www.w3.org/2002/09/wbs/61259/20151023_BG_F2F_SEOUL/ BG registration for Genivi

Hashimoto: for Genivi AMM we should give introduction/overview on W3C

Paul: there is an opportunity to give a high level introduction to Genivi members, but we also will be conducting BG meeting on LBS, security etc
... the security group in Genivi is having similar discussions to ours
... there is Fabian from PSA and Jeremiah from Pelagicore (sp?) plus people from Visteon and Bosch. we should see about liaising with them
... we should try to get some of them to join us for the BG meeting

<peterW> Its Pelagicore

Paul: for the W3C intro it would be similar to one Adam A., Ted and I did
... who on this call will be attending Genivi?

Adam: Kevin and I will not be at Seoul but will be at Sapporo

Qing_An: unfortunately no

<j-hashimoto> junichi and hirabayashi-san will be attenging.

-> https://www.w3.org/2002/09/wbs/35125/TPAC2015/ TPAC registration

<kaz> [ will attend both Genivi and TPAC :) ]

<peterW> Looking to go to Sapporo

<peterW> not korea

[ted will be at both]

<inserted> Genivi registration

<inserted> BG registration

Hashimoto: I wonder how many OEM will attend the BG meeting

Paul: often the same cast of characters (PSA, JLR, we have had BMW)
... Hyundai sometimes comes to Genivi but has not been at a BG meeting in awhile, similar with VW
... as Ted said it would be good for people from this group to attend Genivi AMM tracks as well for liaising

Ted: we can ask eg Philippe Robin to communicate an invitation to join the BG meeting as observers to Genivi AMM participants in addition to doing so in our intro about W3C

Paul: I'll reach out to Philippe about trying to get more engagement

Kaz: Do we need to register for Genivi meeting itself?

-> https://www.eiseverywhere.com/ereg/newreg.php?eventid=134067&& Genivi AMM registration

Paul: they have Open Automotive which is open to the Public, the other sessions are closed to Members

<PaulBoyes> http://genivi.org/amm-2015-october