15:38:28 RRSAgent has joined #auto 15:38:28 logging to http://www.w3.org/2016/07/26-auto-irc 16:21:09 scribenick: ted 16:21:29 Rudi: welcome to JLR OSTC 16:22:31 … housekeeping items: wifi, facilities 16:22:52 Agenda: https://www.w3.org/auto/wg/wiki/Main_Page#July_26-28.2C_2016_in_Portland.2C_OR 16:24:43 … some background on our OSTC, started renting space initially, built OSTC1 in 2014 which we'll see later this week 16:25:15 … last year we started building this facility, OSTC2 which houses designers and our incubators 16:25:52 … Matt Jones came up with the slogan that we are striving to be the best software company that happens to sell cars 16:26:42 … we open source our architecture to help other companies and enable third parties to be able to work with us better 16:27:23 … we want people to be able to download and install our environment on their computing platform to be able to develop towards it 16:28:13 … our open source and standards is behind our participation in various consortium such as Genivi where Matt is president and W3C 16:29:27 … JLR is the largest UK automanufacturer 16:29:36 Topic: Introductions and Agenda review 16:30:20 @@Attendees from signup sheet 16:32:35 AdamC has joined #auto 16:34:10 wonsuk has joined #auto 16:38:40 s/@@Attendees from signup sheet/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)/ 16:38:52 [agenda review from wiki] 16:39:39 KevG has joined #auto 16:42:07 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) 16:51:34 Present+ Jeremiah_Foster(Pelagicore) 16:54:20 Topic: Status on Vehicle Information Service Specification 16:54:20 16:54:20 16:54:28 -> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification Vehicle Information Service Specification 16:54:28 16:54:35 s/Pelagicore/Pelagicore;_remote/ 16:55:13 urata_access has joined #auto 16:55:14 Kevin: the diagram is over simplified as there are other possible routes 16:57:31 … client can be software running on vehicle, agent will send data to off vehicle services 16:58:55 … agents can query signals same as clients 17:01:05 … we are providing an overview of what we know can work 17:01:57 Rudi: the idea would be to implement so the security layers apply to the different actors 17:03:14 Paul: I know we plan on discussing Iotivity OMA tomorrow. have people looked at their security model in detail? 17:03:31 Rudi: I have looked at the OMA model and do not recall any details on security 17:03:57 junichi has joined #auto 17:04:01 … there is some detail on the data model from VSS 17:04:36 … as we looked at the current draft W3C data spec we saw it as too static 17:04:57 … any time you wanted to extend it you would need to go through the standards process again 17:05:25 … you need a path to a signal through the API and want to be able to maintain data definition and API separately 17:05:54 … the idea of VSS is to use a simple and extensible language 17:06:06 … straight forward tooling and editing 17:07:44 … we hope to have a minimum signal set that most if not all OEM will implement and expose in addition vehicle specific signals 17:07:59 present+ Song_Li(Newsky_Security) 17:09:24 [example declarations from wiki] 17:10:22 Rudi: these definitions can be maintained in separate files and combined with #include 17:11:53 … get and set methods need to provide the path of the signal they want 17:12:04 … there is signal wildcarding to get eg signals from all doors 17:12:18 s/wild/* wild/ 17:13:25 Kevin: there has been some discussion on whether it is better to use localhost or a different host name - maintained by /etc/hosts file 17:16:04 Adam: we want ids for client connections 17:17:04 Kevin: subscription id facilitates management of sockets 17:17:51 … a concern is multiple connections being used by the same client application, setting signals on one connection and race condition querying on another 17:18:07 hira has joined #auto 17:19:57 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 17:20:35 -> https://github.com/PeterWinzell/vehicle-carsignal-examples Peter Winzell's vehicle signal examples 17:22:06 Rudi: we should discuss procedures for adopting VSS, whether it should reside in W3C repo or ok to reference it etc 17:23:03 present+ Powell_Kinney(Vinli) 17:23:12 Kevin: the tree model of VSS can allow one to provide vehicle objects similar to DOM (VOM) 17:24:08 … we need nodes to have unique ids in the tree whether they be numeric indexes or UUIDs 17:24:37 … we want to be able to allow for jquery type searches on either id or eg all cameras 17:24:54 Peter: so that is a suggested extension? 17:25:13 Kevin: correct 17:25:24 Peter: sounds like a good idea 17:25:52 Rudi: server would be able to load VSS and create a queryable VOM 17:27:08 Kevin: you could subscribe to vehicle.body and get back a body object with all the related json 17:27:52 Hira: I understand the merit of VSS tree structure. what is the top of the tree, vehicle? 17:27:55 Rudi: yes 17:28:45 Hira: there will be some redundance 17:29:05 Rudi: Magnus will tell us more when we get to VSS 17:29:25 … we want to make a model that is easily understood so a developer can find and navigate to the data signals they need 17:30:06 Adam: we looked at current data spec and readability 17:31:08 … how do you define a control - you might not want to have it under chassis 17:32:17 Kevin: there is static data that never changes like the vehicle weight and dynamic or configuration data 17:32:37 Magnus: we wanted to keep VSS specific to signals data and stay clear of configuration data 17:32:46 … however there is clearly a need for that 17:33:20 Paul: can you clarify what you mean by configuration data? 17:33:40 Magnus: static data like mileage rating, weight 17:34:38 [Magnus presentation on VSS] 17:35:08 Magnus: vehicles can have private branches that are specific to them 17:35:34 … if we see commonly repeated private branches they should be candidates to include in the main branch 17:35:58 Paul: I would think as an app developer you would want a similar if not the same interface 17:36:32 Magnus: if there is a need from W3C side that can influence the argument at Genivi 17:37:54 … private branch approach has two top level branches 17:37:55 wonsuk has joined #auto 17:38:33 … there are ambiguities in the current spec 17:40:27 … 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 17:40:43 … aliases can help here so you can define 1 as driver's seat 17:42:45 Adam: I see this as much larger than configuration data 17:53:54 Paul: what happens to get that static data is implementation specific and behind the scenes 17:54:34 Magnus: correct but they will be in their own specific/private VSS files 18:00:35 Paul: are there any other standards that do this level of semantics we can leverage? 18:00:48 Magnus: I'm sure there have been other efforts 18:26:58 urata_access has joined #auto 18:27:00 Rudi: Magnus will make adjustments to Global parameters and Peter H will define Chasis branch 18:27:29 PeterH: how detailed should I go on eg steering attributes? 18:27:44 Rudi: keep it simple for starters 18:28:19 … bear in mind we will have proprietary/vehicle specific attributes that will be added as private branches 18:28:56 Magnus: we need to get the basics and structure right 18:29:07 Kaz: how to handle airbags? 18:29:38 Magnus: that will be under cabin, they can be active or deployed 18:30:15 Kevin: what about telematics control units? 18:30:25 Magnus: we want to leave out network specific information 18:30:46 s/airbags?/airbags? it's related to how to handle zones as well./ 18:41:23 (discussion on how to handle zones for airbags, cameras, etc.) 18:50:03 [ morning break ] 18:50:08 rrsagent, make log public 18:50:14 rrsagent, draft minutes 18:50:14 I have made the request to generate http://www.w3.org/2016/07/26-auto-minutes.html kaz 18:50:45 Chair: Rudi, Peter, Paul 18:50:47 rrsagent, draft minutes 18:50:47 I have made the request to generate http://www.w3.org/2016/07/26-auto-minutes.html kaz 18:51:11 Meeting: Automotive WG F2F Meeting in Portland - Day 1 18:51:12 rrsagent, draft minutes 18:51:12 I have made the request to generate http://www.w3.org/2016/07/26-auto-minutes.html kaz 19:07:27 [break] 19:07:51 PeterH: can you explain more about zones? 19:08:40 Kevin: we started off two dimensional and latter switched to three dimensional and found 3x3x3 (rubic cube) could handle many but not all situations 19:09:10 (earlier example was you may have 5 cameras in the front, two with different angles in eg front left corner) 19:10:08 Kevin: we can have x,y,z coordinates or index and aliases as Magnus suggested 19:11:01 Adam: we used ISO8855 x, y, z positive integer coordinates 19:11:17 … in earlier data spec 19:12:30 Rudi: we should action Magnus to use same ISO8855 in VSS 19:13:08 action Magnus to add ISO8855 in VSS 19:13:08 Created ACTION-18 - Add iso8855 in vss [on Magnus Gunnarsson - due 2016-08-02]. 19:16:49 wonsuk has joined #auto 19:17:06 s/Gunnarsson/Feuer/ 19:18:54 -> https://github.com/GENIVI/vehicle_signal_specification GENIVI Vehicle Signal Spec 19:19:49 -> https://github.com/GENIVI/vehicle_signal_specification/blob/develop/spec/Body/ExteriorLights.vspec ExteriorLights.vspec 19:24:05 (discussion on consistency of name convention) 19:29:23 -> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification Back to the W3C repo 19:35:24 (review "VSS Description" section) 19:36:37 (discussion on "Branch Entry") 19:37:11 rudi: aggregate element is optional and the default value is "true" 19:37:27 s/aggregate/"aggregate"/ 19:38:04 (discussion on "Aggregation Inclusion") 19:38:20 rudi: "aggregation inclusion" is not a right wording... 19:38:39 ... changes to "Global Inclusion" 19:42:29 ... flag to identify read/write? 19:44:50 kevin: some data might be more cautious 19:45:23 rudi: implementers might restrict the permission 19:50:16 ... update the wiki with "mode: r" for "chassis.transmisison.speed" to make clear that implementers may restrict the permission 19:51:10 s/update the wiki/update the "Signal Entry" section/ 19:51:24 ... also update the "Enumerated Signal Entry" 19:51:54 ... with "mode: r" 19:53:47 kaz: maybe it would be better to have another column of "possible values" in addition to "default value" 19:54:11 rudi: updates the table with the possible values 19:54:40 ... "r = read, w = write, rw = read and write" 19:55:31 i/GENIVI Vehicle Signal Spec/scribenick: kaz/ 19:56:27 [ lunch ] 19:56:32 rrsagent, draft minutes 19:56:32 I have made the request to generate http://www.w3.org/2016/07/26-auto-minutes.html kaz 20:53:24 ahaller2 has joined #auto 21:00:30 junichi-hashimoto has joined #auto 21:29:15 topic: OSTC Tour 21:29:25 topic: JavaScript API 21:30:37 -> rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html Vehicle Information Access API 21:30:49 junichi-hashimoto has joined #auto 21:30:56 peterw has joined #auto 21:31:05 Paul has joined #auto 21:33:55 -> http://lists.w3.org/Archives/Public/public-automotive/2016Jul/0019.html Wonsuk's message 21:34:16 paul: should align with the service spec 21:36:33 rudi: what is exposed in the current spec? 21:37:34 paul: there are access api spec and data spec 21:39:21 -> rawgit.com/w3c/automotive/master/vehicle_data/data_spec.html data spec 21:41:09 wonsuk has joined #auto 21:43:30 paul: we've been doing webidl 21:43:43 ... also some implementations on th library 21:43:48 s/th /the/ 21:44:08 ted: who is implementing? 21:44:16 paul: KDDI/ACCESS 21:44:24 peter: others as well 21:45:00 q+ 21:45:41 rudi: who is investing? 21:46:42 kevin: Web clients would benefit with WebIDL? 21:47:32 ted: nice to have high-level wrapper 21:47:46 ... but maintenance issue 21:49:03 q- 21:49:39 hira: we've implemented JS API based on ACCESS's platform 21:50:14 paul: maintain separately as is? 21:51:03 kevin: benefit to Web browser vendors 21:51:23 paul: that's why created a wiki to see that 21:51:48 urata: making the two specs aligned is good 21:52:17 ... simple APIs are useful for Web developers 21:52:46 ... vehicle signal spec has tree structure 21:53:55 paul: would present? 21:53:55 urata: yes 21:54:13 ... vehicle information service spec 21:54:22 ... "Signal Addressing" section 21:55:14 ... simple "get" API 21:55:29 hira: should be able to map with each other 21:56:29 ted: you have to update the mapping 21:57:35 ... people have to implement both the service spec and JS API spec 21:58:25 hira: most Web developers are familiar with the current JS API 21:58:42 ... they're not really familiar with the VSS spec 21:59:13 hashi: information service spec specifies local server 21:59:31 ... W3C doesn't specify that 22:01:35 paul: previously we had Data spec 22:01:43 ... now we're changing that 22:02:19 ... how to tie then with each other? 22:03:26 ... spent long time for the current data spec 22:03:38 ... VSS is trying to do more than we did 22:04:08 peter: possible for the data to glow 22:04:19 ... don't see any issues to have high-level APIs 22:05:09 powell: we can keep the WebIDL API 22:05:21 ... and work on the service interface 22:05:55 ted: once the service API is done we can do the mapping between the service API and the JS API 22:06:58 paul: like the idea of VSS 22:07:08 ... agree with what Ted says 22:07:25 ... could have JS library for the client 22:07:54 ... maybe we could decouple them 22:08:34 paul: VSS has more broad target 22:09:40 kevin: websocket interface would be sufficient for us 22:09:55 urata: one thing I'm worrying about is the roadmap 22:09:58 ... by the end of this year 22:10:11 [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] 22:10:15 ... if we change our plan drastically, the schedule would change much 22:10:29 [service api is a prerequisite and needs to be done first] 22:11:10 ... if we change our direction, not sure about what to do 22:11:29 ... need strong reason if we change our plan 22:11:37 s/plan/plan drastically/ 22:12:04 paul: this is a flexible architecture 22:12:30 ... how your clients work with it 22:13:01 ... what the client would look like 22:13:37 peter: the industry doesn't want the old spec... 22:13:58 ted: we're losing interest in the WebIDL approach 22:14:57 ... would make sense to have predefined set 22:16:25 [we are finding more parties interested in the service/socket approach who are doing similar and had dismissed our idl approach] 22:17:23 kevin: what sort of conclusion? 22:17:44 rudi: the WebIDL specs are still drafts 22:18:32 paul: what should we do for the new charter? 22:18:42 ted: we're going through the new charter now 22:20:14 paul: who would implement the service interface? 22:20:21 ... maybe four from this group? 22:21:07 ... who would implement the current WebIDL spec? 22:21:18 ... my company would not... 22:22:38 rudi: interested in WebSocket service approach + VSS 22:23:35 kevin: JLR would interested in websocket service approach with VSS 22:24:00 ... not really webidl 22:24:19 wonsuk: also interested in websocket approach 22:24:56 ... but JS API could be implemented by polyfill and in that case it's websocket in the end 22:25:26 paul: do we need JS library? 22:25:46 wonsuk: we don't want to maintain the webidl spec 22:25:57 ... but we want to provide js library for dvelopers 22:26:15 ... to define APIs for them 22:26:43 s/dvelopers/Web application developers/ 22:27:04 ... if people are interested they can provide JS library 22:27:57 kevin: opensource community might want to have JS library 22:28:25 ... it wouldn't give any harm 22:29:25 paul: are we formalizing our approach? 22:29:48 kevin: both are logically compatible 22:30:10 paul: I'm not against 22:30:17 jkim has joined #auto 22:30:24 ... we need two implementations for getting CR 22:32:27 ... webidl spec is a client spec 22:32:35 ... do we want to specify that? 22:43:52 ahaller2 has joined #auto 22:48:14 wonsuk has joined #auto 22:48:50 kaz: WoT IG is facing a similar problem. they are sending a questionnaire to stake holders to see what they want 22:48:56 … perhaps we should do the same 22:51:06 i/WoT IG/scribenick: ted/ 22:53:08 -> https://www.w3.org/WoT/IG/wiki/Implementations WoT Implementations list 22:54:56 [ afternoon break ] 23:04:09 ahaller2 has joined #auto 23:05:20 Karen has joined #auto 23:13:54 junichi-hashimoto has joined #auto 23:16:15 jkim has joined #auto 23:16:54 jkim has joined #auto 23:17:27 Topic: Carfit 23:17:33 http://car.fit 23:18:23 PeterH: there are many issues not properly monitored by owners (tires, brakes etc) that are also lacking sufficient sensors 23:18:41 … we are trying to be a go between between service and owners 23:19:29 … drawing from personal fitness devices came up with carfit 23:19:44 … our device sits on top of the steering wheel and monitors vibrations 23:20:07 … we see this as a real compliment to odb2 monitoring 23:20:43 … we are starting to run pilots of the product out in the field and starting to look for possible partnerships 23:21:24 … we're looking at things outside of the engine 23:22:27 Ted: what sort of things can you detect - wheel imbalances, brakes stuttering when applied? 23:23:01 PeterH: yes but we are getting a range of interesting data. we can tell if there are burrs on rotors 23:24:10 … we are able to discover common issues by class, manufacturer and combine our sensor data with known problem sets 23:24:36 … getting information from a genivi+w3c environment adds to diagnostic capabilities 23:25:05 Rudi: lots of variables such as tire manufacturer to take into account 23:26:08 Kevin: you are really able to tell that much from vibrations on the steering column 23:26:23 jkim_ has joined #auto 23:26:35 PeterH: yes, a new car should be pretty smooth and vibration free a good zero starting off point 23:28:03 … we collect lots of data, some of which will become interesting or valuable later 23:30:10 Ted: seeing this as an aftermarket solution, you working with OEMs to get your devices embedded? 23:30:55 PeterH: yes but aftermarket is huge with millions of vehicles on the road that require hundreds of billions of dollars in service revenue 23:31:28 Kaz: can you account for driver behavior variation? 23:32:03 PeterH: yes and also we can get into things like detecting when a given driver's behavior changes - distracted or tired 23:32:35 Shinjiro: is everything done on the device? 23:33:18 PeterH: yes and combining with phone capabilities and products like Vin.li's 23:33:42 … we would like to be able to send a tire out of balance notification to head unit for example 23:34:48 I have made the request to generate http://www.w3.org/2016/07/26-auto-minutes.html ted 23:41:48 topic: Security&Privacy update 23:42:20 present+ Joonhyung_Kim(LG Electronics) 23:43:03 Song: security is about controlling access to data and privacy policies about who that information can be shared with 23:43:09 -> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#Security_and_Privacy_Considerations Security&Privacy considerations section in the Vehicle Service Spec 23:44:22 Paul: laws vary by country, for instance in Germany people need to opt in explicitly for sharing specific information to a third party 23:44:24 ahaller2 has joined #auto 23:44:45 Kevin: we do not want to try to keep pace with various legislation, only define the mechanisms 23:45:37 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 23:46:02 Paul: yes but you need to know the use cases more to be able to define those mechanisms 23:46:34 Kevin: the mechanism can be generic, identifying which information it is proposing to which external service 23:47:17 Paul: can you give example on how that would work? 23:48:20 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 23:48:57 Powell: @@p 23:50:32 Kevin: the model here is there are separate security authority providers that can verify a token and entity is valid 23:51:51 Powell: we need a web socket that has a secure handshake and then able to exchange tokens 23:52:16 … is a token for a specific app? 23:52:20 Kevin: it could be 23:55:46 urata_access has joined #auto