- From: Streif, Rudolf <rstreif@jaguarlandrover.com>
- Date: Fri, 20 May 2016 10:20:54 -0700
- To: Kazuyuki Ashimura <ashimura@w3.org>
- Cc: public-automotive <public-automotive@w3.org>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>, Magnus Feuer <mfeuer1@jaguarlandrover.com>
- Message-ID: <CANpGCGJsFkU4maY9bcqh1FBaXT_-41gP52JGmx=jrf+KFfEvPw@mail.gmail.com>
Colleagues: Thank you, Kaz. On Fri, May 20, 2016 at 2:54 AM, Kazuyuki Ashimura <ashimura@w3.org> wrote: > Hi Automotive WG/BG guys, > > Today there was a call of the WoT IG on OCF's IoTivity as follows, > and during that call there was some discussion about a possible > demonstration for automotive use cases during TPAC 2016 in Lisbon. > > Unfortunately, I was not aware of the meeting otherwise I would have liked to attend it. > And I got an action item from the meting to ask the Automotive WG/BG > about our interest in this demonstration opportunity. > > I think that would definitely be a good think to do. Sanjeev and his team have demoed an integration of IoTivity with RVI which he presented about during our f2f in Paris [1]. I would like to draw the attention to slide 18: [image: Inline image 1] The architecture shows the OCF Gateway integration with GENIVI's RVI on the cloud side. This successful implementation and demonstration prompted me to suggest to use OCF/IoTivity also on the vehicle platform as outlined in this slide that I presented last week at the Future Connected Car conference in Santa Clara: [image: Inline image 2] IoTivity gateway could fulfill the role of the REST server as IoTivity essentially is REST based using CRUD. On the vehicle platform there would be a 1:1 relationship between the IoTivity gateway and the vehicle meaning that only resources exposed by that particular vehicle platform could be used. In the cloud there would be a 1:n relationship as many vehicles are addressable. Discovery and routing in this case is handled by RVI that provides all the necessary mechanisms for it. RVI also provides the security with certificates for authentication and authorization. The Vehicle Signal Specification (VSS) [2] provides the standardization of the signals and the data structures. We just published the first iteration that contains about 180 signals that are derived from JLR's CAN database. It is essentially the real thing, we just generalized them to make them pretty much applicable to any OEM and vehicle. We expect to grow this specification to probably around 500 signals over the next couple of weeks. So essentially, this would present a tremendous opportunity for anyone wanting to develop applications for it. The opportunity would be twofold: - Apps for the in-vehicle platform - Apps and web-based services for the cloud The great thing, imho, is that in-vehicle platform apps and cloud would be using the exact same APIs. I really think that is a huge advantage for the entire industry. I do, of course, realize that this is somewhat GENIVI-centric, in particular the use of RVI. While RVI is a GENIVI component and part of the GENIVI Development Platform, companies not wanting to use RVI as a transport could simply replace it with something else. It would not matter to application developers as the northbound APIs would remain the same. > I think it would be a great opportunity for us as well to join the WoT > IG's PlugFest demonstration which will be collaborative run with IRTF > and OCF this time (if possible). > > What do you think? > > I think that is great idea and certainly one more reason for the hackathon I proposed for our next f2f meeting end of July in Portland. > Maybe we can talk about this during the next WG/BG call. > > Definitely. :rjs
Attachments
- image/png attachment: image.png
- image/png attachment: 02-image.png
- application/pdf attachment: genivi-ocf-20160427-160428193732.pdf
Received on Friday, 20 May 2016 17:21:45 UTC