- From: Streif, Rudolf <rstreif@jaguarlandrover.com>
- Date: Wed, 27 Jul 2016 08:41:27 -0700
- To: Kazuyuki Ashimura <ashimura@w3.org>
- Cc: public-automotive <public-automotive@w3.org>
- Message-ID: <CANpGCGKXg6nLYsqUHD1e2+u2t5-zAgAx-ojpWu5kWN=h1X3ahw@mail.gmail.com>
Thank you, Kaz. Much appreciated. Rudi On Wed, Jul 27, 2016 at 12:18 AM, Kazuyuki Ashimura <ashimura@w3.org> wrote: > available at: > https://www.w3.org/2016/07/26-auto-minutes.html > > also as text below. > > Thanks, > > Kazuyuki > > --- > [1]W3C > > [1] http://www.w3.org/ > > - DRAFT - > > Automotive WG F2F Meeting in Portland - Day 1 > > 26 Jul 2016 > > [2]Agenda > > [2] > https://www.w3.org/auto/wg/wiki/Main_Page#July_26-28.2C_2016_in_Portland.2C_OR > > See also: [3]IRC log > > [3] http://www.w3.org/2016/07/26-auto-irc > > Attendees > > Present > Rudolf_Streif(JLR), Kevin_Gavigan(JLR), > Adam_Crofts(JLR), Wonsuk_Lee(ETRI), > Peter_Hauser(CarFit;_observer), Magnus_Feuer(JLR), > Peter_Winzell(Mitsubushi), Paul_Boyes(INRIX), > Junichi_Hashimoto(KDDI), Shinjiro_Urata(ACCESS), > Tatsuhiko_Hirabayashi(KDDI), Kaz_Ashimura(W3C), > Ted_Guild(W3C), Jeremiah_Foster(Pelagicore;_remote), > Song_Li(Newsky_Security), Powell_Kinney(Vinli), > Joonhyung_Kim(LG, Electronics) > > Regrets > Chair > Rudi, Peter, Paul > > Scribe > ted, kaz > > Contents > > * [4]Topics > 1. [5]Introductions and Agenda review > 2. [6]Status on Vehicle Information Service Specification > 3. [7]OSTC Tour > 4. [8]JavaScript API > 5. [9]Carfit > 6. [10]Security&Privacy update > * [11]Summary of Action Items > * [12]Summary of Resolutions > __________________________________________________________ > > <ted> scribenick: ted > > Rudi: welcome to JLR OSTC > ... housekeeping items: wifi, facilities > ... some background on our OSTC, started renting space > initially, built OSTC1 in 2014 which we'll see later this week > ... last year we started building this facility, OSTC2 which > houses designers and our incubators > ... Matt Jones came up with the slogan that we are striving to > be the best software company that happens to sell cars > ... we open source our architecture to help other companies and > enable third parties to be able to work with us better > ... we want people to be able to download and install our > environment on their computing platform to be able to develop > towards it > ... our open source and standards is behind our participation > in various consortium such as Genivi where Matt is president > and W3C > ... JLR is the largest UK automanufacturer > > Introductions and Agenda review > > Rudolf_Streif(JLR) Kevin_Gavigan(JLR) Adam_Crofts(JLR) > Wonsuk_Lee(ETRI) Peter_Hauser(CarFit) Magnus_Feuer(JLR) > Peter_Winzell(Mitsubushi) Paul_Boyes(INRIX) > Junichi_Hashimoto(KDDI) Shinjiro_Urata(ACCESS) > Tatsuhiko_Hirabayashi(KDDI) Kaz Ashimura(W3C) Ted_Guild(W3C) > > [agenda review from wiki] > > Status on Vehicle Information Service Specification > > -> > [13]https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service > _Specification Vehicle Information Service Specification > > [13] > https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification > > Kevin: the diagram is over simplified as there are other > possible routes > ... client can be software running on vehicle, agent will send > data to off vehicle services > ... agents can query signals same as clients > ... we are providing an overview of what we know can work > > Rudi: the idea would be to implement so the security layers > apply to the different actors > > Paul: I know we plan on discussing Iotivity OMA tomorrow. have > people looked at their security model in detail? > > Rudi: I have looked at the OMA model and do not recall any > details on security > ... there is some detail on the data model from VSS > ... as we looked at the current draft W3C data spec we saw it > as too static > ... any time you wanted to extend it you would need to go > through the standards process again > ... you need a path to a signal through the API and want to be > able to maintain data definition and API separately > ... the idea of VSS is to use a simple and extensible language > ... straight forward tooling and editing > ... we hope to have a minimum signal set that most if not all > OEM will implement and expose in addition vehicle specific > signals > > [example declarations from wiki] > > Rudi: these definitions can be maintained in separate files and > combined with #include > ... get and set methods need to provide the path of the signal > they want > ... there is signal * wildcarding to get eg signals from all > doors > > Kevin: there has been some discussion on whether it is better > to use localhost or a different host name - maintained by > /etc/hosts file > > Adam: we want ids for client connections > > Kevin: subscription id facilitates management of sockets > ... a concern is multiple connections being used by the same > client application, setting signals on one connection and race > condition querying on another > > Peter: I had not had time to fully compare the previous data > spec and VSS but have spent time to implement a test signal > system > > -> > [14]https://github.com/PeterWinzell/vehicle-carsignal-examples > Peter Winzell's vehicle signal examples > > [14] https://github.com/PeterWinzell/vehicle-carsignal-examples > > Rudi: we should discuss procedures for adopting VSS, whether it > should reside in W3C repo or ok to reference it etc > > Kevin: the tree model of VSS can allow one to provide vehicle > objects similar to DOM (VOM) > ... we need nodes to have unique ids in the tree whether they > be numeric indexes or UUIDs > ... we want to be able to allow for jquery type searches on > either id or eg all cameras > > Peter: so that is a suggested extension? > > Kevin: correct > > Peter: sounds like a good idea > > Rudi: server would be able to load VSS and create a queryable > VOM > > Kevin: you could subscribe to vehicle.body and get back a body > object with all the related json > > Hira: I understand the merit of VSS tree structure. what is the > top of the tree, vehicle? > > Rudi: yes > > Hira: there will be some redundance > > Rudi: Magnus will tell us more when we get to VSS > ... we want to make a model that is easily understood so a > developer can find and navigate to the data signals they need > > Adam: we looked at current data spec and readability > ... how do you define a control - you might not want to have it > under chassis > > Kevin: there is static data that never changes like the vehicle > weight and dynamic or configuration data > > Magnus: we wanted to keep VSS specific to signals data and stay > clear of configuration data > ... however there is clearly a need for that > > Paul: can you clarify what you mean by configuration data? > > Magnus: static data like mileage rating, weight > > [Magnus presentation on VSS] > > Magnus: vehicles can have private branches that are specific to > them > ... if we see commonly repeated private branches they should be > candidates to include in the main branch > > Paul: I would think as an app developer you would want a > similar if not the same interface > > Magnus: if there is a need from W3C side that can influence the > argument at Genivi > ... private branch approach has two top level branches > ... there are ambiguities in the current spec > ... example with seats is you do not know by index which the > steering wheel is at as that varies based on location model UK > vs US for instance > ... aliases can help here so you can define 1 as driver's seat > > Adam: I see this as much larger than configuration data > > Paul: what happens to get that static data is implementation > specific and behind the scenes > > Magnus: correct but they will be in their own specific/private > VSS files > > Paul: are there any other standards that do this level of > semantics we can leverage? > > Magnus: I'm sure there have been other efforts > > Rudi: Magnus will make adjustments to Global parameters and > Peter H will define Chasis branch > > PeterH: how detailed should I go on eg steering attributes? > > Rudi: keep it simple for starters > ... bear in mind we will have proprietary/vehicle specific > attributes that will be added as private branches > > Magnus: we need to get the basics and structure right > > Kaz: how to handle airbags? it's related to how to handle zones > as well. > > Magnus: that will be under cabin, they can be active or > deployed > > Kevin: what about telematics control units? > > Magnus: we want to leave out network specific information > > <kaz> (discussion on how to handle zones for airbags, cameras, > etc.) > > <kaz> [ morning break ] > > [break] > > PeterH: can you explain more about zones? > > Kevin: we started off two dimensional and latter switched to > three dimensional and found 3x3x3 (rubic cube) could handle > many but not all situations > > (earlier example was you may have 5 cameras in the front, two > with different angles in eg front left corner) > > Kevin: we can have x,y,z coordinates or index and aliases as > Magnus suggested > > Adam: we used ISO8855 x, y, z positive integer coordinates > ... in earlier data spec > > Rudi: we should action Magnus to use same ISO8855 in VSS > > action Magnus to add ISO8855 in VSS > > <trackbot> Created ACTION-18 - Add iso8855 in vss [on Magnus > Feuer - due 2016-08-02]. > > <inserted> scribenick: kaz > > -> [15]https://github.com/GENIVI/vehicle_signal_specification > GENIVI Vehicle Signal Spec > > [15] https://github.com/GENIVI/vehicle_signal_specification > > -> > [16]https://github.com/GENIVI/vehicle_signal_specification/blob > /develop/spec/Body/ExteriorLights.vspec ExteriorLights.vspec > > [16] > https://github.com/GENIVI/vehicle_signal_specification/blob/develop/spec/Body/ExteriorLights.vspec > > (discussion on consistency of name convention) > > -> > [17]https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service > _Specification Back to the W3C repo > > [17] > https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification > > (review "VSS Description" section) > > (discussion on "Branch Entry") > > rudi: "aggregate" element is optional and the default value is > "true" > > (discussion on "Aggregation Inclusion") > > rudi: "aggregation inclusion" is not a right wording... > ... changes to "Global Inclusion" > ... flag to identify read/write? > > kevin: some data might be more cautious > > rudi: implementers might restrict the permission > ... update the "Signal Entry" section with "mode: r" for > "chassis.transmisison.speed" to make clear that implementers > may restrict the permission > ... also update the "Enumerated Signal Entry" > ... with "mode: r" > > kaz: maybe it would be better to have another column of > "possible values" in addition to "default value" > > rudi: updates the table with the possible values > ... "r = read, w = write, rw = read and write" > [18]discussion > > [18] https://www.w3.org/auto-f2f/photos/26/DSC_0126.JPG > > [ lunch ] > > OSTC Tour > > JavaScript API > > -> > rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html > Vehicle Information Access API > > -> > [19]http://lists.w3.org/Archives/Public/public-automotive/2016J > ul/0019.html Wonsuk's message > > [19] > http://lists.w3.org/Archives/Public/public-automotive/2016Jul/0019.html > > paul: should align with the service spec > > rudi: what is exposed in the current spec? > > paul: there are access api spec and data spec > > -> rawgit.com/w3c/automotive/master/vehicle_data/data_spec.html > data spec > > paul: we've been doing webidl > ... also some implementations on thelibrary > > ted: who is implementing? > > paul: KDDI/ACCESS > > peter: others as well > > rudi: who is investing? > > kevin: Web clients would benefit with WebIDL? > > ted: nice to have high-level wrapper > ... but maintenance issue > > hira: we've implemented JS API based on ACCESS's platform > > paul: maintain separately as is? > > kevin: benefit to Web browser vendors > > paul: that's why created a wiki to see that > > urata: making the two specs aligned is good > ... simple APIs are useful for Web developers > ... vehicle signal spec has tree structure > > paul: would present? > > urata: yes > ... vehicle information service spec > ... "Signal Addressing" section > ... simple "get" API > > hira: should be able to map with each other > > ted: you have to update the mapping > ... people have to implement both the service spec and JS API > spec > > hira: most Web developers are familiar with the current JS API > ... they're not really familiar with the VSS spec > > hashi: information service spec specifies local server > ... W3C doesn't specify that > > paul: previously we had Data spec > ... now we're changing that > ... how to tie then with each other? > ... spent long time for the current data spec > ... VSS is trying to do more than we did > > peter: possible for the data to glow > ... don't see any issues to have high-level APIs > > powell: we can keep the WebIDL API > ... and work on the service interface > > ted: once the service API is done we can do the mapping between > the service API and the JS API > > paul: like the idea of VSS > ... agree with what Ted says > ... could have JS library for the client > ... maybe we could decouple them > ... VSS has more broad target > > kevin: websocket interface would be sufficient for us > > urata: one thing I'm worrying about is the roadmap > ... by the end of this year > > <ted> [webidl api in its current form could be mapped to > services api and vss with a wrapper library. webidl api has > provisions for being extensible and that may be how it gets at > new signals data that gets added to vss] > > urata: if we change our plan drastically, the schedule would > change much > > <ted> [service api is a prerequisite and needs to be done > first] > > urata: if we change our direction, not sure about what to do > ... need strong reason if we change our plan drastically > > paul: this is a flexible architecture > ... how your clients work with it > ... what the client would look like > > peter: the industry doesn't want the old spec... > > ted: we're losing interest in the WebIDL approach > ... would make sense to have predefined set > > <ted> [we are finding more parties interested in the > service/socket approach who are doing similar and had dismissed > our idl approach] > > kevin: what sort of conclusion? > > rudi: the WebIDL specs are still drafts > > paul: what should we do for the new charter? > > ted: we're going through the new charter now > > paul: who would implement the service interface? > ... maybe four from this group? > ... who would implement the current WebIDL spec? > ... my company would not... > > rudi: interested in WebSocket service approach + VSS > > kevin: JLR would interested in websocket service approach with > VSS > ... not really webidl > > wonsuk: also interested in websocket approach > ... but JS API could be implemented by polyfill and in that > case it's websocket in the end > > paul: do we need JS library? > > wonsuk: we don't want to maintain the webidl spec > ... but we want to provide js library for Web application > developers > ... to define APIs for them > ... if people are interested they can provide JS library > > kevin: opensource community might want to have JS library > ... it wouldn't give any harm > > paul: are we formalizing our approach? > > kevin: both are logically compatible > > paul: I'm not against > ... we need two implementations for getting CR > ... webidl spec is a client spec > ... do we want to specify that? > > <inserted> scribenick: ted > > kaz: WoT IG is facing a similar problem. they are sending a > questionnaire to stake holders to see what they want > ... perhaps we should do the same > > <kaz> [20]WoT Implementations list > > [20] https://www.w3.org/WoT/IG/wiki/Implementations > > <kaz> [ afternoon break ] > > Carfit > > [21]http://car.fit > > [21] http://car.fit/ > > PeterH: there are many issues not properly monitored by owners > (tires, brakes etc) that are also lacking sufficient sensors > ... we are trying to be a go between between service and owners > ... drawing from personal fitness devices came up with carfit > ... our device sits on top of the steering wheel and monitors > vibrations > ... we see this as a real compliment to odb2 monitoring > ... we are starting to run pilots of the product out in the > field and starting to look for possible partnerships > ... we're looking at things outside of the engine > > Ted: what sort of things can you detect - wheel imbalances, > brakes stuttering when applied? > > PeterH: yes but we are getting a range of interesting data. we > can tell if there are burrs on rotors > ... we are able to discover common issues by class, > manufacturer and combine our sensor data with known problem > sets > ... getting information from a genivi+w3c environment adds to > diagnostic capabilities > > Rudi: lots of variables such as tire manufacturer to take into > account > > Kevin: you are really able to tell that much from vibrations on > the steering column > > PeterH: yes, a new car should be pretty smooth and vibration > free a good zero starting off point > ... we collect lots of data, some of which will become > interesting or valuable later > > Ted: seeing this as an aftermarket solution, you working with > OEMs to get your devices embedded? > > PeterH: yes but aftermarket is huge with millions of vehicles > on the road that require hundreds of billions of dollars in > service revenue > > Kaz: can you account for driver behavior variation? > > PeterH: yes and also we can get into things like detecting when > a given driver's behavior changes - distracted or tired > > Shinjiro: is everything done on the device? > > PeterH: yes and combining with phone capabilities and products > like Vin.li's > ... we would like to be able to send a tire out of balance > notification to head unit for example > > Security&Privacy update > > Song: security is about controlling access to data and privacy > policies about who that information can be shared with > > <kaz> [22]Security&Privacy considerations section in the > Vehicle Service Spec > > [22] > https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations > > Paul: laws vary by country, for instance in Germany people need > to opt in explicitly for sharing specific information to a > third party > > Kevin: we do not want to try to keep pace with various > legislation, only define the mechanisms > > Rudi: I agree. we will enable accessing that data but it will > be up to the individual OEM to follow laws for where vehicles > are > > Paul: yes but you need to know the use cases more to be able to > define those mechanisms > > Kevin: the mechanism can be generic, identifying which > information it is proposing to which external service > > Paul: can you give example on how that would work? > > Rudi: we went through this with RVI. if a given application > wants to access certain services it needs a signed certificate > and a means to verify it > > Powell: @@p > > Kevin: the model here is there are separate security authority > providers that can verify a token and entity is valid > > Powell: we need a web socket that has a secure handshake and > then able to exchange tokens > ... is a token for a specific app? > > Kevin: it could be > > Song: everything is based on same origin policy > > Kevin: I am not sure we need to solve the application > distribution problem > > Powell: correct, we can just say you need a token > > Rudi: token is signed by OEM and when the token is verified, > specific information that can be shared with the application a > UI can prompt user to opt in > ... subsequent times the app is run the IVI system will know it > went through the verification and opt in > > Ted: you can send a subscribe to top of the tree with your > token and get back all the data elements you are entitled to > > Kevin: yes and a scenario is you might have a privileged > application like ADAS that is allowed full access > > [whiteboard exercise led by Powell going over client server > token interactions, verification] > [23]Powell's picture > > [23] https://www.w3.org/auto-f2f/photos/26/DSC_0129.JPG > > [ Day 1 adjourned ] > > Summary of Action Items > > Summary of Resolutions > > [End of minutes] > __________________________________________________________ > > > Minutes formatted by David Booth's [24]scribe.perl version > 1.147 ([25]CVS log) > $Date: 2016/07/27 07:08:01 $ > > [24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > [25] http://dev.w3.org/cvsweb/2002/scribe/ > > -- *Rudolf J Streif* System Architect - Open Source Initiative Open Source Technology Centre *M:* +1.619.631.5383 *Email:* rstreif@jaguarlandrover.com UK: G/26/2 G02 Building 523, Engineering Centre, Gaydon, Warwick, CV35 ORR US: 1419 NW 14th Ave, Portland, OR 97209 jaguar.com | landrover.com ------------------- Business Details: Jaguar Land Rover Limited Registered Office: Abbey Road, Whitley, Coventry CV3 4LF Registered in England No: 1672070 This e-mail and any attachments contain confidential information for a specific individual and purpose. The information is private and privileged and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please e-mail us immediately. We apologise for any inconvenience caused but you are hereby notified that any disclosure, copying or distribution or the taking of any action in reliance on the information contained herein is strictly prohibited. This e-mail does not constitute an order for goods or services unless accompanied by an official purchase order.
Received on Wednesday, 27 July 2016 15:42:01 UTC