W3C home > Mailing lists > Public > public-automotive@w3.org > May 2016

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

From: Streif, Rudolf <rstreif@jaguarlandrover.com>
Date: Fri, 20 May 2016 10:20:54 -0700
Message-ID: <CANpGCGJsFkU4maY9bcqh1FBaXT_-41gP52JGmx=jrf+KFfEvPw@mail.gmail.com>
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>

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.


(image/png attachment: image.png)

(image/png attachment: 02-image.png)

Received on Friday, 20 May 2016 17:21:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 24 October 2017 18:52:50 UTC