Re: minutes and actions from call on WoT & iotivity/OCF

Thanks a lot, Rudi!

Let's talk about this during the next call and ask the others as well
about their interest :)

It would be great if we could do some kind of demo during TPAC 2016
collaboratively with the WoT guys and the OCF guys.

Thanks,

Kazuyuki



On Sat, May 21, 2016 at 2:20 AM, Streif, Rudolf <rstreif@jaguarlandrover.com
> wrote:

> 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
>
>



-- 
Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo
Tel: +81 3 3516 2504