07:09:49 RRSAgent has joined #auto 07:09:49 logging to http://www.w3.org/2016/04/28-auto-irc 07:09:51 Zakim has joined #auto 07:10:07 Meeting: Automotive WG f2f in Paris - Day 1 07:10:13 topic: Introduction 07:10:17 starting with Paul 07:11:22 Paul Boyes, Ted Guild, Shinjiro Urata, Tatsuhiko_Hirabayashi 07:12:03 Kaz_Ashimura, Qing_An 07:12:36 hira has joined #auto 07:13:03 Volker_Fricke, Wonsuk_Lee 07:14:45 Soumya_Kanti_Datta, Peter_Winzell, Powell_Kinney, Rudi_Streif 07:15:49 Klaus from Genivi, Osamu_Nakamura 07:16:07 Hiro_Hayashi 07:16:37 Kevin_Gavigan 07:17:02 Agenda: https://www.w3.org/auto/wg/wiki/Main_Page#April_26-29.2C_2016_in_Paris 07:19:04 s/Klaus/Klaus_Birken/ 07:19:25 topic: Service approach versus web runtime approach (Websocket approach vs current WebIDL) 07:20:48 rudi: there are various OSs/platforms, and no standard APIs 07:21:19 urata: made some slides on pros/cons of each approach 07:21:29 q+ Shinjiro 07:21:32 q+ 07:22:12 peter: IDL could be used for either approach 07:25:52 q- 07:26:08 Paul has joined #auto 07:30:25 q+ 07:33:05 q- 07:34:10 q+ 07:34:27 Soumya has joined #auto 07:34:27 PowellKinney has joined #auto 07:34:33 KevG has joined #auto 07:34:38 peters has joined #auto 07:34:58 peters has left #auto 07:35:07 klausbirken has joined #auto 07:35:13 peters has joined #auto 07:35:15 q+ 07:35:49 kaz has joined #auto 07:35:58 q+ 07:36:07 rudi: (missed the comments; disconnected for a while...) 07:36:30 wonsuk: how much data could be handled at the same time? 07:36:40 urata: there is no limitation 07:36:58 q? 07:37:28 wonsuk: concerned since we have a lot of data properties 07:38:24 urata: the vehicle api polyfill keeps working 07:38:28 s/(missed the comments; disconnected for a while...)/this is the model I was describing, we can define the WebIDL piece and leave the websocket server and databroker to the underlying auto manufacturer/ 07:38:50 hira: you'll improve the mechanism. right? 07:38:53 urata: yes 07:39:01 wonsuk: why did you use this model? 07:39:18 urata: wanted to implement an actual prototype system asap 07:39:28 klaus: share the concern with wonsuk 07:39:52 ... should avoid making the JS processor keep work 07:40:25 ... the communication flow between the OBD2 side and the data broker side 07:40:41 urata: there is a set method within the spec 07:41:02 ... using OBD2 dongle to communicate with the OBD2 network 07:41:24 ... in this system, it's impossible to implement set method 07:41:34 ... we focused on get/subscribe for this model 07:41:45 ted: websocket approach may be bi-directional 07:41:47 AdamC has joined #auto 07:41:59 ... you used OBD2 for this model, though 07:42:30 ... Rudi's comment is that the green Data Broker part may be provided by OEMs 07:42:56 rudi: blue part should concentrate on the existing APIs 07:43:38 ... and we could use websocket approach for the I/F between the orange part (vehicle api polyfill) and the green part (data broker) 07:44:12 kevin: the orange part is in charge of data transfer to the green part 07:44:47 paul: we have Adam Croft online (gotomeeting) 07:45:01 ... can share the screen using Gotomeeting 07:45:08 rstreif has joined #auto 07:45:15 urata_access has joined #auto 07:45:46 kevin: another question is how to use websocket for multiple APIs 07:45:58 q+ 07:46:08 powell: could have 2 separate socket connections for get and subscribe 07:46:30 kaz: how many sockets did you use, Urata-san? 07:46:40 urata: one socket for both get and subscribe 07:47:24 I understand there is a goto meeting for screen sharing, could someone share a URL, please? 07:47:40 ted: one of my reasons I like the websocket approach is that it could have smaller granularity 07:48:00 Hi All - go to meeting https://global.gotomeeting.com/join/134321333 07:48:22 ... developers could use both the vehicle apis and websocket depending on their need 07:48:34 ... AGL does websocket approach 07:48:45 ... agnostic from the presentation layer, e.g., Qt 07:49:11 ... vehicle apis might be convenient for developers but websocket would provide another layer 07:49:45 rudi: I myself am neutral 07:50:13 ... inside of the IVI system, there could be various presentation layers 07:51:06 ... possible to have another web browser who talks with web servers outside the vehicle 07:51:26 q+ 07:51:40 q- 07:52:29 scribenick: ted 07:52:54 kaz: you can connect for talking to the outside world as well in the vehicle api layer 07:54:09 rudi: you can still do websocket approach from a webidl and expose other lower level system (c++) apis that way 07:55:31 q+ to ask who would likely produce and maintain vehicle api layer 07:57:54 rudi: speaking to platform specific apis would require browser vendors to implement and they might once platforms like genivi are more established 07:58:36 ted, you wanted to ask who would likely produce and maintain vehicle api layer 08:00:21 picture on the flipchart about a browser extended to include the vehicle api processor polyfill 08:00:27 ack t 08:00:38 ted: @@@ 08:00:56 klaus: how do we handle smartphones attached a car? 08:01:36 urata: you can use vehicle apis on the smartphone 08:01:55 klaus describes the kid in the backseat "are we there yet?" use case :) 08:02:08 klaus: might want to use bluetooth, etc., as well 08:02:26 hira: implemented this system on smartphones for taxis as well 08:02:41 ... including bluetooth I/F 08:03:00 i/how do/scribenick: kaz/ 08:03:27 s/klaus: might/volker: might/ 08:03:38 peter: /me ah 08:03:47 s|peter: /me ah|| 08:04:05 s/@@@/we may see one or more browser vendors implement for this market but there will likely be a time gap we would need to cover. we would need to get genivi or someone to implement browser extension. it would be easier to have a js only lib implementation as it can work in multiple runtimes/ 08:04:28 paul: Kevin also has his presentation 08:04:42 s/klaus describes the/volker describes the/ 08:05:08 urata: coexistence of high-level I/F and low-level I/F would be possible 08:05:23 ... [ Vehicle API (native) structure ] 08:05:26 s/attached a car?/attached a car? they are less likely to have webidl component but could do websocket/ 08:05:38 ... peter implements similar model 08:06:13 peters has joined #auto 08:06:56 kaz: have you already implemented this native model? 08:06:58 urata: partially 08:07:14 ... implemented get method but not subscribe yet 08:07:22 s/smaller granularity/access control granularity/ 08:07:55 ... [ Vehicle API Impl ] 08:08:32 ... same things are done within both the polyfill version and the native version 08:08:43 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html ted 08:09:51 ... [ Vehicle API (native) structure; again ] 08:09:59 ... [ Vehicle API Impl; again ] 08:10:04 ... [ Pros Cons ] 08:10:15 ... we had many opinions already 08:11:06 ph: can you do both the approaches? 08:11:11 urata: that's possible 08:11:20 ... and one possible option 08:11:53 rrsagent, make log public 08:11:54 rrsagent, draft minutes 08:11:54 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 08:12:30 paul: want to have explicit discussion on this 08:12:52 urata: [ Web and automotive hackathon in Tokyo ] 08:13:39 ... Japanese OEMs attended, Tier1 companies as well 08:14:23 ... there were 11 teams 08:14:52 hira: please talk about the development environment 08:16:56 urata: created some emulation environment for the devleopers 08:17:03 s/devleopers/developers/ 08:17:29 urata: (shows some video) 08:18:25 ... video image hosted on Youtube and vehicle data on the display using the vehicle api polyfill 08:19:01 ... highways, mountain roads, etc. 08:19:34 ... wanted to detect ABS information but couldn't handle that 08:20:22 ... in this system we implemented 20 features or so 08:20:25 PeterW has joined #auto 08:20:57 ... [ diagram of AWS, YouTube, Synchronize, Vehicle API polyfills ] 08:21:36 ... vehicle api polyfill requests data and AWS sends the data 08:22:07 hira: recorded data could be used for testing 08:22:44 ph: wondering if it's possible to make this more publicly to W3C so that more people can be aware of this work 08:23:04 ... maybe other Members are interested in this work 08:23:22 urata: someone has to drive the car to get data 08:23:27 q+ 08:23:28 s/get/collect/ 08:23:52 ... because of security reason, we've not published the URL yet 08:24:22 paul: this is the link to the AWS site 08:24:31 urata: right 08:24:40 q? 08:24:42 ack k 08:25:19 klaus: what is important from the GENIVI viewpoint is clear mapping between the IDL and the implementation 08:25:37 ... we could transform FrancaIDL to WebIDL 08:25:54 ... automatically 08:26:10 ... the key point is how to adapt to this 08:26:23 (Klaus leaving for another GENIVI session) 08:27:15 paul: Kevin also has his presentation 08:27:25 (we can come back to the Pros/Cons discussion later) 08:30:45 [ morning break ] 08:30:51 rrsagent, draft minutes 08:30:51 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 08:31:12 i/starting with Paul/scribenick: kaz/ 08:31:14 rrsagent, draft minutes 08:31:14 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 08:31:42 Chair: Paul 08:44:08 rstreif has joined #auto 08:47:32 rrsagent, draft minutes 08:47:32 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 08:47:52 scribenick: ted 08:48:27 Kevin's architecture diagram 08:49:04 [will ask for pdf to list] 08:49:32 kevin: left hand side is vehicle modules - display, gps, cameras etc.. list is much more extensive and these are just examples 08:49:50 … along the bottom are CAN signals with their secure gateways 08:50:27 … glossing over the networking components as they can be bridged a number of different ways 08:50:58 … the top layer is the different types of clients that could consume the vehicle api, again not exhaustive 08:51:36 … web runtime is what we call a browser instance without an address bar but to run html5 apps available on the vehicle 08:51:46 … loaded from a local webserver and file store 08:53:16 … you can have a multiple of different information available to your apps 08:53:54 … if it wants to consume vehicle signals it would need to go through an application server, imagine a nodejs instance that can return json 08:54:52 … between the application server and vehicle interface we can attach security tokens. not everyone (app) should be able to get and set attributes 08:55:20 q+ 08:55:24 … in a typical vehicle there can be more than one CAN bus with different gateways 08:56:25 … client might also want to combine signals from off-board (internet) service 08:56:43 … those would go through a firewall to externals data services, portals etc 08:56:54 … getting traffic, weather and other information 08:57:37 … OEM may have a specific data provider, vehicle identifies itself via PKI 08:57:56 … all communication over TLS 08:58:41 i/this is the model I was/@@@missing text should be copied from Kaz's local note here@@@/ 08:58:44 rrsagent, draft minutes 08:58:44 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 09:00:21 … another potential client is where the user can have a browser and retrieve html, css, etc from the internet directly and we permit some access to local application server 09:01:09 … given the security concerns this is a less common scenario 09:02:34 … also may be Qt/C++ and headless apps 09:03:55 … as we do not intend to expose a public IP address the cloud data provider will control what gets passed back to the vehicle 09:04:35 q+ 09:04:46 q- 09:04:59 … off vehicle clients can be a browser - follow vehicle activity 09:05:11 … or external applications and services 09:05:20 q+ to confirm "Off vehicle clients" could be include smartphones of the driver within the car 09:05:22 q+ 09:05:54 s/headless/headless(managed runtime)/ 09:06:11 paul: why have separate web server and application server? 09:06:21 kevin: they are performing separate roles 09:06:30 … they don't have to be separate 09:07:14 soumya: it seems you are using a number of web standards/technologies already 09:07:35 … if there is some time from WoT perspective we have a presentation that would be worth sharing 09:07:46 paul: hopefully yes 09:07:54 thanks Ted 09:08:22 kevin: in terms of security if we stay with http web service base, are there issues with hijacking websockets or other concerns 09:11:06 … there are scenarios where you may want to expose off vehicle advanced access like to emergeny responders who want to disable airbags after crash so they do not engage as they are helping people 09:13:11 klausbirken has joined #auto 09:14:01 [kevin describes token passing] 09:14:45 kevin: you will want various off vehicle information about driver, preferences for seat position, music stations etc 09:15:25 … people will want this to be able to follow them across vehicles and will likely have different subscriptions (content and service) they will want to use 09:16:04 … number of reasons you will want to identify the driver and it is rather complex since they may not be the owner and you want to protect driver information, clear it from vehicle 09:17:20 … user can be registered with oem portal which stores their information, they identify themselves with a sso auth and retrieve that information 09:17:50 q? 09:18:58 soumya: do you have guidelines for how we access the CAN bus? 09:19:20 … I have a basic demo for transferring basic data from the vehicle to the cloud 09:19:41 kevin: it won't be the same even from the same vehicle manufacturer across different models 09:19:56 soumya: there any standards for that? 09:20:22 paul: you can buy some tools that try to synthesis the varied signals more consistently 09:22:26 rudi: there are common denominators and been some attempts to expose more consistently 09:22:46 paul: you referring to the bosch project? it helps you decode the various signals, i haven't used it though 09:22:53 rudi: no, I'll look for the name of it 09:23:27 http://openxcplatform.com/ 09:23:33 kevin: it is a big piece of work 09:23:56 … an oem cannot just expose signals 09:24:22 kaz, you wanted to confirm "Off vehicle clients" could be include smartphones of the driver within the car 09:24:39 peterW has joined #auto 09:24:53 kaz: I was wondering if your off vehicle client could include the driver's phone? 09:24:56 paul: yes 09:25:14 q+ 09:25:15 kaz: they would be firewalled from the vehicle 09:25:26 kevin: yes 09:26:08 kaz: including bluetooth connections and the phone can then combine with internet information 09:26:35 kevin: off vehicle can be any one of a number of things, including other vehicles or anything connected to the internet 09:32:29 q? 09:32:33 q+ peter 09:33:39 ack p 09:33:54 Bart van Leeuwen http://netage.nl/en/ - useful contact for emergency service interests and use cases - he is an emergency responder and software engineer involved in w3c 09:34:25 ted: @@push/pull+poll oem portal for user profile -can it be more platform agnostic, across manufacturers? 09:34:48 kevin: @@external and profile 09:34:59 powell: @@socket 09:36:27 s/@@socket/you need to be concerned during the http handshake but once wss socket is established it should be safe/ 09:36:27 Vehicle Spy - http://www.intrepidcs.com/VehicleSpy/index.html Vector - http://vector.com/vi_can_solutions_en.html Busmaster - https://rbei-etas.github.io/busmaster/ OpenXC - http://openxcplatform.com/ 09:37:16 PowellKinney has joined #auto 09:37:19 [JLR video] 09:38:09 wonsuk: can you elaborate on the type of application is your 'web runtime'? 09:38:29 kevin: it is a browser but supresses address bar and can only run selected apps from a homepage 09:38:45 … it will be a managed environment 09:39:55 wonsuk: will you be creating apps for the phone as well that resembles an application and not a browser? 09:40:07 kevin: yes, we have some already from JLR 09:40:54 … there is code in the downloaded app to act as an authorized external device that can be used as an touchscreen for the head unit 09:41:24 wonsuk: do you presently have a web runtime in your vehicles? 09:41:36 kevin: we have a supplier that provides a web runtime 09:45:30 paul: you see this model used elsewhere like checkin kiosks at the airport 09:47:19 wonsuk: role of web runtime is to provide a more secure environment potentially with access to additional privileged apis 09:47:59 … you mentioned security tokens to access different modules 09:48:21 … will an app need to use different tokens to access different modules? 09:48:41 kevin: you don't have to but will want to if that is being shared with different [external] services 09:48:52 soumya: @@2 09:49:48 wonsuk: have you looked at FIDO? 09:50:18 kevin: there are a number of interesting mechanisms, more on the way, for increasing security including hardware models 09:50:42 … it is an evolving area 09:50:52 … some things, like entertainment, are not as critical 09:51:18 … but anything coming from off vehicle is a possible attack vector 09:52:34 Ted - my question was on provisioning the security keys 09:52:51 rstreif has joined #auto 10:00:27 [attempt to get a understanding of webidl, websocket or both] 10:01:21 rudi describes the francaidl (genivi) would be used by the websocket server to communicate to the underlying vehicle and there is a clear benefit to web app developer to have the higher level api 10:10:28 [in the case of genivi as more francaidl that want to be exposed, they would only need to follow the coupling in websockets layer] 10:12:03 how we might want to do the REST https://github.com/OAI/OpenAPI-Specification 10:14:51 different developer audiences (lower level C++ automotive and web developer) but it would be worth seeing if franca generated js is viable as the higher level js api 10:40:15 rrsagent, draft minutes 10:40:15 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 10:40:19 [ Lunch ] 10:40:21 rrsagent, draft minutes 10:40:21 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 11:47:57 QingAn has joined #auto 11:51:19 rstreif has joined #auto 11:52:16 hira has joined #auto 11:52:22 urata_access has joined #auto 11:52:30 kaz has joined #auto 11:53:30 present+ Kaz_Ashimura(W3C), Qing_An(Alibaba), Volker_Fricke(IBM), Wonsuk_Lee(ETRI), Osamu_Nakamura(W3C), Soumya_Kanti_Datta(Eurecom), Peter_Winzell(Mitsubishi_Electric), Powell_Kinney(Vinli), Rudi_Streif(JLR) 11:53:33 present+ Kevin_Gavigan(JLR), Paul_Boyes(Inrix), Ted Guild(W3C), Shinjiro Urata(ACCESS), Tatsuhiko_Hirabayashi(KDDI), Klaus_Birken(ITEMIS), Hiro_Hayashi(Sony), Jade_Moon(Intel), Dave_Francis(Inrix), Philipp_Hoschka(W3C) 11:53:36 rrsagent, draft minutes 11:53:36 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 11:53:52 topic: Electric vehicle (Volker Fricke) 11:53:58 wonsuk has joined #auto 11:55:37 volker: [ Agenda ] 11:55:53 ... EU Green Vehicles Project 11:56:05 ... Project IBM Research an Energy Producer EKZ 11:56:19 ... EU Green Vehicle Project "NeMo" 11:56:40 ... Requirements for EV In-Vehicle Data Access 11:56:56 ... [ The "Green eMotion" Project 11:57:47 ... [ What are the end-user's requirements about electromobility services? ] 11:59:44 ... charge EV anywhere; only one bill; finding charging points from any station provider; intelligent and smart at any station provider; park&ride 11:59:57 ... [ The Green eMotion Project Consortium ] 12:00:36 ... industries, utilities, EV manufacturers, Municipalities, Research Institutes 12:00:48 ... [ Who are the stakeholders around electromobility? ] 12:02:08 ... EVSE, Utility, EVSP, IT Provider - End User 12:02:39 ... [ Operating EVs with many stakeholders is becoming very complex, costly and impractical 12:02:58 ... quite complicated data flow 12:03:16 ... [ Green eMotion Building Blocks ] 12:03:39 ... Municipalities/Government: Policies, Legislation, Standards 12:03:47 ... EVSP: EVSP Backend 12:04:09 ... MP Provider: Clearing House, EVSE Search, Marketplace 12:04:18 ... OEM/Fleet Operator 12:04:30 s/Operator/Operator: EVMS/ 12:04:46 ... APIs between MP Provider and OEM 12:05:27 ... [ Mass market adoption of EVs is enabled by a B2B Marketplace that will interconnect all stakeholders... ] 12:05:56 ... [ Motivation for EV Smart Charging ] 12:07:13 ... nice to get charge plan loaded automaticall into my EV 12:07:31 ... [ Pilot architecture for ubiquitous smart=charging of EVs - 2014-2015 12:07:36 s/2015/2015 ] 12:07:41 rrsagent, draft minutes 12:07:41 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 12:07:58 ... information automatically downloaded into the car 12:09:10 ... prototype implementation 12:09:58 ... [ European Union Call for Green Vehicle GV8 extends IBM contribution from EU Project "Green eMotion" towards transport and smart grid integration and services 12:10:06 ... interaction with ICT platform 12:10:12 s/services/services ] 12:10:38 ... [ IBM has demonstrated "Open Marketplace" ICT solution which allows new innovative business services... ] 12:10:52 ... [ Information and Communication Technology (ICT) plays ... ] 12:10:59 paul has joined #auto 12:11:10 ... [ Source: NeMo Proposal, chapter 1, figure 2 ] 12:11:39 ... this project is about to start 12:11:49 ... lasts for 3 years 12:12:05 ... [ Nemo environment interconnect all stakeholders ICT systems... ] 12:12:14 ... only one marketplace 12:12:25 ... also network of e-mobility 12:13:03 ... [ Initial Draft of EV Data Requrements for In-Vehicle Data Access ] 12:13:10 s/Requrements/Requirements/ 12:13:46 ... Table of "Draft by Robert Sharpe & Volker Fricke" 12:14:08 ... Table of "C-ITS EU Platform Workgroup..." 12:14:15 ... this is our first input 12:14:22 ... data needed for EVs 12:15:27 ... don't see OEMs want to have standard framework for EVs 12:15:40 ... so would propose Web-layer framework 12:16:12 ... will send the PDF to the group 12:16:15 paul: questions? 12:16:32 wonsuk: did you see the W3C Vehicle Data spec? 12:16:41 volker: quickly skimmed 12:16:50 wonsuk: already some overlaps 12:17:07 ... we need to add requirements from this work to the Vehicle Data 12:17:20 paul: there was some background discussion as well 12:17:29 q+ 12:17:51 wonsuk: we should create a new GitHub issue for this topic 12:18:08 peter: there was already some issue, wasn't it? 12:18:33 paul: something, but we should add another issue for EVs 12:19:08 volker: yellow part of the table on the right side is already available 12:19:30 s/already/partly/ 12:20:32 ... Daimlar, VW, BMW 12:20:56 ted: can we talk with C-ITS guys? 12:21:09 s/BMW/BMW who participate in C-ITS 12:21:21 (get review of spec addition of ev attributes) 12:22:27 volker: we had this initial idea from some of the vendors 12:22:31 ... not mandated 12:23:30 Soumya has joined #auto 12:24:00 wonsuk: there are some mismatching between this work and our vehicle data 12:24:15 -> https://github.com/w3c/automotive/issues/79 Missing electric vehicle functionality 12:24:23 paul: suggests you and Robert work on that 12:24:55 volker: it's not a standardization body but a EU working group 12:25:25 ... on the ISO level, we have Web service I/F 12:26:21 ... mandated by European Commission, so European car manufactures have to do 12:27:20 paul: can you send information on tests, Robert? 12:27:48 s/on tests/on tesla api standards/ 12:28:12 ... you could post the information 12:28:18 robert: of course 12:28:30 PowellKinney has joined #auto 12:28:33 ... will send it 12:28:38 ... the other thing is 12:28:47 ... any motivation... 12:28:54 (lost connection?) 12:29:19 paul: he created a group, and send a link 12:30:01 q? 12:30:20 https://docs.google.com/spreadsheets/d/1pwe06DD6XD8oIjp6XxOGkOqDHMR0y96CNMOvf-EcTCQ/edit#gid=1209696266 12:30:33 hira: question 12:30:52 ... sometimes EVs act as a power supply 12:31:07 ... but don't see that feature in the list here 12:31:17 ... switching time/voltage, etc. 12:31:32 ... were your taking about that point within C-ITS? 12:31:34 volker: no 12:32:20 ... so far manufacturers think about just storing electricity and use it for vehicle itself 12:32:40 ... Mitsubishi Motors is interested in using electricity for other purposes 12:32:53 ted: safely reuse the electricity? 12:33:01 volker: yes 12:33:09 ... feeding electric power to the home 12:33:39 ... we IBM have some project on energy management 12:33:56 ... use EVs as electric power buffer 12:34:15 ... only Mitsubishi provides that capability 12:34:23 hira: Toyota may also 12:34:25 q? 12:34:40 ted: Prius as power generator 12:34:59 paul: looking at the Google spreadsheet above 12:35:24 s/Prius as power generator/I have seen Prius where I live as a generator when there is a power outage from storms/ 12:35:44 Robert: there are commercial entities 12:35:56 ... this is a remote API 12:36:21 kevin: promote competition 12:36:35 ... there are a number benefits 12:36:44 https://www.linkedin.com/groups/8469823 12:37:26 volker: some proposal :) 12:38:02 paul: if we have a standard, would be beneficial to reduce the cost 12:38:50 robert: have to talk within the company 12:39:35 volker: this kind of position paper would be useful to convince OEMs 12:40:56 kevin: JLR is very keen on opensource 12:42:14 volker: this work is done to convince OEMs 12:43:41 kevin: OEMs take care of user information 12:44:00 q? 12:44:41 kaz: wanted to suggest we talk with JP OEMs and ask them for opinions on EV features 12:44:42 ack k 12:45:53 robert: It is probably better to set standard then let manufcaturers follow 12:46:02 rrsagent, draft minutes 12:46:02 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 12:46:54 topic: W3C Web of THings (Soumya) 12:47:17 soumya: working on discovery, etc., for Web of Things topic 12:47:25 s/THings/Things/ 12:47:43 ... would present to highlight what is the role of W3C in the WoT space 12:47:55 ... also how WoT could be useful for the automotive industry 12:48:09 ... [ Internet of Things - Landscape ] 12:48:19 ... various industries 12:48:48 ... [ IoT Challenges ] 12:49:01 ... everybody has to implement their platform 12:49:20 ... wide range of technologies 12:49:38 ... vertical domains 12:50:04 ... uniform data representation and processing 12:50:10 ... [ Web of Things ] 12:50:47 ... open markups 12:50:56 ... [ Web of Things - Motivation ] 12:51:09 ... WoT concept is becoming more popular 12:51:32 ... web standards to interconnect devices 12:51:57 ... open, flexible, scalable and interoperable 12:52:13 ... [ Problem to be addressed ] 12:52:30 ... Fragmentation in IoT platforms and technologies 12:52:42 ... High cost of integration into an existing solution 12:52:54 ... Barriers for semantic interoperability 12:53:02 ... [ How to Solve ] 12:53:08 ... many ways to solve the issues 12:53:20 ... open standards for Web-based abstraction layer 12:53:45 ... [ WoT - Clean Separation of Concerns ] 12:54:11 ... application developer (WoT focus): Application, Things 12:54:29 ... platform developer (IoT focus): Transfer, Transport, Network 12:54:58 ... [ W3C WoT Interest Group ] 12:55:10 ... workshop in Berlin (June 2014) 12:55:22 ... launched IG in 2015 12:55:44 ... 4 technical TFs and Communication TF 12:55:57 ... WG charter is under preparation 12:56:10 ... [ W3C WoT Interest Group (cont.) ] 12:56:48 ... Strong emphasis on practical implementation - Plugfest 12:56:57 ... interoperability and understanding 12:57:06 ... compiled document on current practices 12:57:27 -> http://w3c.github.io/wot/current-practices/wot-practices.html current practice doc 12:57:40 ... [ Thing Description and Metadata ] 12:57:54 ... what kind of data do you serve? 12:58:09 ... how can I access the data? 12:58:23 ... [ Thing Description Overview ] 12:58:38 ... the Thing Description TF working on three objectives 12:58:49 ... 1. minimal vocabulary 12:59:07 ... 2. extension for domain-specific context 12:59:31 ... 3. resource description 13:00:01 ... current working odel: semantic metadata, resources, communication, @@@ 13:00:10 ... [ Scripting APIs and Binding to Protocols ] 13:00:32 ... discussing the guideline for the possible scripting APIs 13:00:59 ... [ Scripting APIs for WoT ] 13:01:06 ... possible model 13:01:48 ... WoT Client API: discover things, access things, considering Thing Description 13:01:54 ... [ Resource Discovery ] 13:02:09 ... discover Things and their Metadata 13:02:55 ... 6 mechanisms: search around ME, search on a network, search in a directory, search across peers, search for metadata, search using semantics 13:03:58 ... [ Projisioning ] 13:04:08 s/Projisioning/Provisioning/ 13:04:20 ... includes several aspects 13:04:30 ... [ Security, Privacy and Resilience ] 13:04:43 ... also work on security, privacy and resilience 13:04:58 ... [ Communications and collaboration ] 13:05:08 ... reaching out to industry alliances and SDOs 13:05:32 ... [ Deliverables ] 13:05:37 ... Current practices: http://w3c.github.io/wot/current-practices/wot-practices.html 13:05:50 ... Architecture: w3c.github.io/wot/architecture/wot-architecture.html 13:06:04 ... Use Cases and Requirements: http://w3c.github.io/wot/wot-ucr.html 13:06:27 ... Survey of current tech landscape: https://w3c.github.io/wot/landscape.html 13:06:39 ... will send the slides to the group 13:07:04 ... tomorrow I'll have another presentation on Eurecom's automotive work and demo video 13:07:17 hira: what is the scope/definition of WoT? 13:07:38 ... Web browser for IoT? 13:07:52 soumya: Web standards for IoT 13:08:06 ... so many physical things 13:08:37 ... they can communicate with each other and expose capability using the Web standards 13:09:04 hira: many companies/organizations have developed protocols for IoT 13:09:14 PowellKinney has joined #auto 13:09:18 ... wondering about the relationship between W3C and those orgs 13:09:29 soumya: a lot participation from the industry 13:09:39 ... e.g., Fujitsu and Panasonic 13:09:53 ... this is the list of participants 13:10:09 ... (shows "Members of the Web of Things Interest Group") 13:10:32 hira: discrimination on the role of other SDOs 13:11:00 soumya: we can put WoT on the top of their own approaches 13:11:24 q+ 13:22:43 ack k 13:22:57 what WoT is like 13:23:33 kaz: Soumya explained WoT as the background for his talk on "Web of Things for Connected Vehicles" tomorrow 13:24:10 (some discussion on the agenda) 13:24:59 s/some // 13:26:18 paul: can show you what we do 13:26:32 peter: have some codes 13:26:37 paul: maybe Urata-san as well 13:27:43 scribenick: ted 13:28:35 [ afternoon break ] 13:28:39 rrsagent, draft minutes 13:28:39 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 13:28:55 * soumya thanks kaz for his explanation on WoT 13:35:30 https://github.com/pkinney/w3cag-simple-server 13:36:12 Caveat: just threw this together this morning, so may not be the prettiest, most idiomatic implementation 13:42:54 s|[will ask for pdf to list]|https://lists.w3.org/Archives/Public/public-automotive/2016Apr/att-0028/W3C_Automotive_API_Candidate_Architecture_KCG_v1_0.pdf| 13:43:07 powell: quick prototype based on this morning session 13:43:24 … here is a server with a data backend. vinli has a socket server 13:43:39 KevG has joined #auto 13:43:47 wonsuk has joined #auto 13:44:24 … this is pure js using jquery in nodejs 13:44:49 … start off with storage, open port, wait for connection, examine message type - get/set/subscribe 13:45:10 … on subscribe we set a listener to the store. when it is updated we send back the json 13:45:30 … looking at whether to sub/unsub by path 13:45:55 … finally when the client disconnects there is a garbage collection 13:46:10 … the local data store is just a big hash 13:46:39 … vinli has some similarities in its model 13:47:07 … i have a dummy account that does routing information 13:47:17 … on the screen you can see the data being streamed 13:47:29 … that is the data being fed 13:47:48 … bottom half you see the web methods (request log) 13:48:33 … in this front end mockup you can subscribe or get, see the data coming through, unsubscribe after 13:49:09 … websockets are easy to work with, what makes it complicated is hoops to go through 13:49:37 … we are going to have to look at path based subscription, having multiple apps requesting overlapping and different data 13:49:56 … having as many different examples of this as possible 13:50:12 … i want to turn this into a mocha script so we can validate 13:50:43 … feel free to play with it, there is a docker container if you want to run it that way 13:51:27 … now showing the frontend side code 13:51:47 … there is a bit of awkwardness and would be nice to have a higher level api (as discussed this morning) 13:51:49 rrsagent, draft minutes 13:51:49 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 13:52:36 … at some point in time i expect a value back 13:52:57 peter: what do you mean when you subscribe to vehicle.door? 13:53:25 … does that return the json for the door or changes to door data? 13:53:52 powell: you may want to subscribe to everything available from the front right door 13:54:08 i/Electric vehicle (Volker/scribenick: kaz/ 13:54:10 rrsagent, draft minutes 13:54:10 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 13:54:12 … and see all individual messages underneath, open, lock, close messages 13:54:48 … you will get the same messages if you subscribe higher up in the tree 13:55:16 … rabbitmq has a good model and pattern 13:55:18 i/Caveat:/topic: Vinli's implementation (Powell)/ 13:55:20 rrsagent, draft minutes 13:55:20 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 13:55:47 … when we get some kind of model i would like to have some sort of drop down and work on the visualization 13:55:55 … ask for the model available and traverse it 13:56:37 paul: what is the protocol on websockets here? 13:57:07 powell: this is just a strawman and needs to be spelled out, heartbeats and handoff are taken care of for us 13:57:55 paul: i can show our (opencar/inrix) system 13:58:08 … it follows w3c dataset 13:58:09 yingying has joined #auto 13:58:23 [scrolling through attributes for an actively changing one] 13:58:37 paul: this is from a mazda3 13:59:27 wonsuk: that websocket also? 13:59:29 paul: yes 13:59:38 … the json is very similar to what you just showed 14:00:02 present+ Joonhyung_Kim(LGE), Magnus_Feuer(JLR), Jerry_Trieu(Advanced_Telematic_Systems), Arthur_Taylor(Advanced_Telematic_Systems) 14:00:36 i/can show our/topic: INRIX/OpenCar implementation/ 14:00:38 rrsagent, draft minutes 14:00:38 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 14:01:42 Topic: Vehicle Signal Specification (VSS) 14:03:45 magnus: we need to be able to share the vehicle state with off-vehicle entities 14:04:02 … there is no standards that fully fit the bill, w3c's is close 14:04:14 … one format does not suit all 14:04:30 … vss is standardizing signals information under genivi banner 14:05:10 … we are keeping it simple and evolving quickly, lightweight mailing list and pull request process to add new signals data 14:05:29 … we hope to be the feed data signals to w3c and other organizations 14:05:43 … signals is standard tree structure, branches and signals 14:05:57 [sample body.mirrors.left.heated...] 14:06:12 magnus: we are currently scrubbing internal documents to make available 14:06:23 … volvo (at least) is interested in the same thing 14:06:54 … branches have descriptions. signal is an attribute with unit, type, min, max 14:07:14 … if a subsignal is updated the entire branch gets sent 14:07:53 … yaml does not have an include directive but #comments work 14:08:27 … we can include the same subspec for door for example. you can have door or upstream the entire body 14:09:16 … if the door vspec is later added we can regenerate and updated files will have it 14:09:37 … even if you have proprietary signal information you can include that vehicle specific information easily 14:09:53 [sample has anti-gravity and teleportation as example :) ] 14:10:47 magnus: if someone is using an electric vehicle and they want to standardize their model we can accept as a pull request 14:11:30 ted: we had that earlier (possible ev contributions) today from volker and robert 14:12:12 magnus: it is one line of code to generate the json, francaIDL, markdown documentation and we are open to new target generations 14:12:25 … parser is open, again submit a pull request 14:13:10 … pull requests prompt mailing list thread discussion. if no objection and backwards compatible a new version is released 14:13:15 [demo] 14:13:37 magnus: i took the latest version, run make on the yaml files and here is the json produced 14:14:15 … we still need to agree on how to name doors, presently using 0 based index 14:14:56 ted: earlier i thought you mentioned overriding index labels eg door 0 to front left 14:15:23 magnus: yes, you can do so in your proprietary vspec 14:15:49 s/earlier i thought/when you gave some of us a tour before i thought/ 14:16:06 magnus: you can weigh your values 14:16:37 kaz: so you can override branches? 14:16:47 magnus: yes, supported but not implemented 14:17:13 kaz: i say this because we were looking at a picture of @@v earlier 14:17:26 magnus: yes, different number of cylinders 14:17:48 … this is just a naming scheme 14:17:51 s/@@v/Veyron/ 14:18:40 fyi: https://en.wikipedia.org/wiki/Bugatti_Veyron 14:19:15 [we need to stop talking about cars none of us can afford :) ] 14:19:28 [unless they want us to help with testing...] 14:19:45 powell: no access layers? 14:19:53 magnus: no, this is on vehicle 14:20:24 … question is can this be mapped (or integrated) into w3c standard and wrapped with an api 14:20:41 powell: what about signal frequency? 14:21:11 magnus: yes but implementation specific, frequency varies by signal and bus 14:22:09 [i think i heard top practical signal speed of 10ms - can someone confirm?] 14:22:38 paul: we have a big flat table of these things, you build a profile of what you want 14:22:54 … you name the signals you want 14:22:55 q? 14:23:10 … a debate here is flat vs hierarchical? 14:23:22 q+ to ask if signal freq depends on the class/type of vehicle 14:23:30 … what happens when an attribute falls into multiple branches? 14:23:36 powell: aliasing? 14:23:53 magnus: yes 14:24:24 … that is going to be a lovely argument and different oem will have different structures 14:24:25 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html ted 14:24:45 … we are going to put out an initial proposal and not going to be religious about it 14:25:03 … are you proposing aliases or? 14:25:08 paul: just asking 14:25:25 magnus: your signal example belongs under transmission imho 14:25:49 powell: you might just get speed not wheel speed and not know where it came from 14:25:58 magnus: it can even be gps derived 14:26:28 s/your signal example/your speed signal example/ 14:26:52 paul: maybe you are sending data offboard for product development and want all three different speeds 14:27:00 … an app developer just wants one value 14:27:46 magnus: in that case it probably will be in three branches and you want to decide which you want or we present a generic one 14:27:56 … i don't have answers but you are asking the right questions :) 14:28:34 powell: you will want to know which you can read, write or if you cannot read it that it exists 14:29:41 paul: when you subscribe to a value and get a string or id, the upper level api will likely pass the full string but you may want to map to an id 14:29:52 … that would be useful for many 14:30:38 magnus: we want a library that injests this spec, can traverse the tree and let you know what is actually available on the vehicle to subscribe to 14:30:56 [that would be extremely useful to app developers] 14:31:36 powell: whatever is published right now is what we assuming 14:31:38 q+ 14:31:51 ack k 14:31:51 kaz, you wanted to ask if signal freq depends on the class/type of vehicle 14:32:37 paul: you'll need to know a bit about what you are looking for 14:33:08 q+ kaz 14:33:10 q- later 14:34:07 paul: JLR (Paul Wheller) and others did an exercise where they looked at earlier data spec and what they could expose 14:34:41 magnus: we are not sure yet how apps in the head unit will use this data 14:35:05 … it is not going to be a dump of signals but i want a low barrier for being able to share them 14:35:30 paul: you would hope for hmi you can expect these common set of signals 14:35:57 powell: can we have a baseline? 14:36:21 ted: no unfortunately, eg in some cases oem do not have licensing rights to some ecu signals to give to hmi 14:37:11 paul time check and ota on agenda 14:37:57 magnus: next step is to integrate from existing w3c vehicle spec 14:40:25 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html ted 14:41:18 kaz: @@on mapping 14:43:03 joonhyung: it would be nice if genivi and w3c developers were using the same 14:43:19 paul: that is a possibility but would impact whoever has started implementing 14:43:43 rrsagent, draft mintues 14:43:43 I'm logging. I don't understand 'draft mintues', kaz. Try /msg RRSAgent help 14:44:04 shinjiro: we knew we were using an early spec 14:44:29 s/@@on mapping/we might want to have a spreadsheet with two columns, 1 for VSS another for W3C Data spec: 14:45:05 paul: precision and floating points in js might be an issue 14:45:27 … you cannot control precision at the source 14:45:50 rrsagent, draft minutes 14:45:50 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 14:45:58 s|rrsagent, draft mintues|| 14:46:00 rrsagent, draft minutes 14:46:00 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 14:46:34 magnus: you may also want an average and lower frequency 14:47:05 ted: interest in ditching data spec instead of mapping, adopting vss adding ev and work on ipr concerns (nil?) between orgs and w3c snapshotting or doing external references to snapshots. this is genivi specific and a very open submission process but concerned people may come to w3c with proposals/objections - will want to avoid forking/conflict resolution 14:49:06 magnus: feel free to fork 14:49:31 ted hopes we don't need to but yeah that was what we thought might be the outcome 14:50:23 paul: we had pushback earlier. i would argue with them heavily on differences to eg tree structure 14:50:43 ted: people who show up late have less of an argument 14:51:04 paul: plus you have an override mechanism 14:51:45 … i can see arguments from auto side on diagnostics 14:52:05 magnus: there will be some that will want it changed to suit their existing architectures 14:52:31 … we might get people coming out of the woodwork with their counter proposals 14:52:37 paul: almost a good problem to have 14:53:00 magnus: we are trying to abstract this as much as possible 14:53:08 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html ted 14:53:43 shinjiro: i am concerned about the timeline/roadmap 14:53:56 … we are suppose to be shipping this rather soon... 14:54:01 ted: no problem 14:54:09 … actually we have rechartering on agneda for tomorrow 14:54:20 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html ted 14:54:30 q+ 14:54:54 shinjiro: we will need two reference implementations for lower and higher level specs 14:55:03 s/level specs/level apis? 14:55:06 s/level specs/level apis/ 14:55:22 ted: we will likely split the specs and can move separately 14:55:27 q- 14:55:32 shinjiro: also test suite 14:55:43 kaz: yeah 14:56:32 s/yeah/yeah. two test suites should be also generated separately/ 14:59:19 Topic: RVI API 15:00:06 jerry: for creating vheicles we have vin as identifier 15:00:41 PowellKinney has joined #auto 15:00:41 PUT /vehicles/:vin/... 15:01:10 -> http://pdxostc.github.io/rvi_sota_server/dev/api.html GENIVI SOTA project 15:01:28 jerry: component path returns list of all the components that are on that vehicle 15:01:38 … and how you get the underlying part number 15:01:48 … same thing with package 15:02:28 s/package/[software] package/ 15:02:51 … packages are distinguished by name and version 15:03:03 … includes vendor and description 15:03:16 … version is major.minor 15:03:53 … to associate a package as installed you use PUT 15:04:07 … you can PUT many packages on the system 15:04:46 … where that is interesting is with GET /filters which takes a unique name and expression 15:05:25 … expression is string with regex, AND or OR logic... 15:05:40 [see link to filter syntax within the doc] 15:06:13 jerry: you can do a POST /validate/[filter] 15:06:40 … GET /resolve/:name/:version is useful for knowing what is currently installed and need to be updated 15:07:51 rrsagent, draft minutes 15:07:51 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html kaz 15:07:59 … POST /updates 15:08:27 … resolve comes up with vins that will be affected 15:08:42 paul: this is the sota server side, this is a web server api 15:09:01 … what is the core api? 15:09:23 jerry: for the oem to provision the vehicle and initiate upgrades 15:10:25 rudi: rvi doesn't know the vehicle IP address 15:10:35 … sota runs on top of rvi 15:10:52 http://pdxostc.github.io/rvi_sota_server 15:11:20 [sota client is on the vehicle, sota server is backend] 15:11:24 -> http://pdxostc.github.io/rvi_sota_server/dev/architecture.html SOTA Architecture 15:11:29 http://pdxostc.github.io/rvi_sota_server/dev/architecture.html 15:11:41 volker: are these packages signed? 15:11:50 q+ 15:11:52 rudi: another piece of infrastructure handles package management and checks keys etc 15:14:30 wonsuk: can you describe the usual process? the vehicle sota client checks with the server need to update 15:14:59 jerry: i have been going through the admin and oem interfaces 15:15:15 … rvi is json rpc not rest 15:15:59 rudi: sota server is run by oem and initiates a software update campaign 15:16:21 … what happens next is the campaign goes out to resolver to know which vehicles it applies to 15:16:40 … legacy parts management system figures out the components (ecu) dependencies 15:16:49 … there is a mix of hardware and software dependencies 15:17:24 … server figures all this out, comes up with list of vehicles affected 15:17:58 … the core server schedules the campaign telling the client (vehicle) the package is available not sending the actual package 15:18:43 … client acks it receives update notification, potentially alerting the owner that there are pending software updates. there may be policies about when the notices and updates take place, eg not while going 100mph on the hiway 15:19:10 … user can accept or decline some types of updates, security and critical ones may not even be sent to the user but required by policy 15:19:28 … client will tell server when it it ready for the software update 15:20:05 … chunking it up and sending over rvi (logical protocol) which does address resolution 15:20:29 … rvi on the client side lets the server know where it is (how it is available to connect) 15:21:02 … this is different than debian or rpm packages, squashfs and can carry out various different types of operations 15:21:40 … it doesn't just update the packages on the head unit itself but can relay onto the vehicle network to underlying ecu 15:22:02 paul: where do we think this should go within w3c? 15:22:14 rudi: that is a good question 15:22:27 … not sure how this conversation initially started 15:22:42 paul: john cain from arynga reached out to us probably based on this work 15:23:13 … what i am trying to ascertain is how we fit in. you already did all the work and this makes sense 15:23:45 rudi: agree, this is like amazon trying to standardize their ec2 cloud services 15:24:35 paul: if there are multiple implementations and you want to get people involved 15:24:48 volker: this is also a topic for iot 15:25:09 jerry: what we would like to do is approach different oem to adopt this for their fleet management 15:25:28 paul: the left side presumably (sota server in diagram) 15:26:06 jerry: exactly so genivi based client systems 15:26:15 wonsuk: who would maintain the packages 15:26:24 rudi: oems (or designated operator) 15:27:01 … the package is a squashfs image that contains the manifest and installable components 15:30:12 ted@@on genivi+rvi vs eg qnx. 15:31:06 rudi: yes, it might want to wait based on quality of carrier signal to wait until a better wifi upstream is available 15:32:07 paul: this is a great starting point and makes it easy for us to get our heads around it 15:32:26 … we have one implementation, if someone else is likely to implement then we have a recommended candidate 15:32:34 … the big challenge is who that other person will be 15:32:53 rudi: standardization has great benefits for certain economies of scale and that is clear with vehicle signals 15:33:07 … it is more limited (focused) in this case 15:33:28 paul: you (volker) bring up a good point that this is useful for iot as well 15:33:52 … soumya... we're talking to you and kaz... 15:35:27 rudi: OMA and Samsung 15:35:41 paul: and we are talking with Samsung tomorrow who is in w3c 15:37:06 rudi explains some of the other non-ota use cases of rvi like sending an unlock door signal to a given vehicle vin with certificates and tokens to proove it is allowed to unlock xyz 15:40:18 ted: will this be the only way to do updates including to the ivi os? 15:40:23 rudi: you can handle os updates with debian/rpm 15:40:51 paul: this resembles iot/wot provisioning and updating? 15:41:00 soumya: i'm listening 15:41:13 … maybe the server side yes 15:41:22 paul: client can be any piece 15:42:53 QingAn has joined #auto 15:43:36 volker: is the device management work taking place at OMA relevant? 15:43:56 rudi: we are looking at that, vehicle is not a single thing and it does not fit that well 15:44:32 … those that see cars as a smartphone on wheels oversimplifies and doesn't understand how it is a complex distributed computing system 15:44:37 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html ted 15:45:55 paul: joel hoffman approached us (paul, philipp, ted) about how to make oma more relevant in automotive 15:46:11 QingAn_ has joined #auto 15:46:16 … there seems to be a very urgent timeline for rvi 15:46:33 rudi: yes, we want to have wider adoption of rvi 15:47:11 … it handles 3 macro use cases ota, big data and vehicle interaction and status information from external devices (smartphone and other) 15:47:21 paul: to me those use cases could fall into the BG 15:47:55 … like ted said unless there are additional parties interested (outside of genivi) we will just slow you down 15:48:57 … also you may want to talk with WoT folks more on the discovery and provisioning 15:50:27 rudi: agree standards alone don't work and you need implementations to proove their work 15:50:54 … people look at the specification and wonder if they have to implement it all themselves or if there is something tangible they can use 15:54:06 ted: all three of your macro use cases and waiting for better (alternate) connectivity are pertinent to WoT as well 15:54:44 … without requiring you to wait or refactor it might be something they want to examine and then find what to generalize at a more abstract layer 15:55:14 paul: the BG is designed to explore potential work so this is in scope 15:55:25 wonsuk: i think there is clear we want to pursue this further 15:56:41 … i will investigate more 15:57:52 qing an: we can set up a different task force like media tuner 15:58:31 … i need to check internally what alibaba is doing 15:59:06 wonsuk will reach out to samsung 16:00:06 Soumya you and Kaz will check if WoT people want to look at this too 16:00:39 I have made the request to generate http://www.w3.org/2016/04/28-auto-minutes.html ted 17:25:13 Zakim has left #auto