1. This is a draft of the report being created by the OMAuto Incubator Group at OMA. Feel free to edit this report if you have something of value to contribute.

If you want to add or edit an image on this page, download the file OMAuto Incubator Report Diagrams.pptx PowerPoint deck and follow the instructions. If you don't have PowerPoint, follow these instructions:

...

3.     Terminology and Conventions

...

These use cases are illustrated below.

Use Case A: Web apps (e.g. an Auto Driving Lessons Coach) can access the RVI data and external device data through GotAPI/Device API. GotAPI enables the Web app to access RVI information/services without needing to implement the RVI-specific interfaces:

Use Case A

Use Case B: An RVI can access external device information/services, e.g. exposing access to a home lighting system. 

...

6.6.1 Overview and objective of project...

The Open Connectivity Foundation (OCF), a global consortium of leading companies focused on creating a standard for interoperable devices and services was founded in 2014. The OCF approach has three key deliverables:

1. An Open Specification: Open Connectivity Foundation
2. An Open Source Implementation: IoTivity
3. A membership driven certification program:  OCF certification

We analyzed a wide variety of Connected Vehicle – Smart Home crossover use cases based on consumer interests and demonstrations shown in trade shows. We consolidated the list of use cases to the following broad categories.

1. Home Energy Management
2. Security System Interaction
3. Vehicle Location
4. Smart Home device status
5. Vehicle Control from Smart Device
6. Smart Device Control from Vehicle
7. Electric Vehicle Time-of-Use Charging
8. Entertainment
9. Third party application service integrations based on the above use cases

While most of these use cases are realized through closed collaborative efforts, Samsung Open Source Group and Jaguar Land Rover Open Source Technology Center, followed an open collaboration model under the Genivi Alliance Incubator projects initiative. We were able to realize the use cases in bold, with minimal resources and a short duration.

Key Stakeholders

We understood that, for an IoT ecosystem to flourish, the architecture should be flexible enough for the key stakeholders to bring in their value proposition and make it easy for consumption by the rest of the ecosystem.Early adopters stand to gain significantly in such an ecosystem play and this typically tends to create ecosystem mono/duo polies. From the beginning our goal was to identify the key stakeholders of the IoT ecosystem and provide an architecture that helps them integrate their existing solutions/software stacks, with as little friction as possible. We identified the following roles and expectations.

 All four stake holder concerns have to addressed in order create a thriving ecosystem. It is also important to note these roles overlap significantly and a single entity could be playing multiple stakeholder roles in an ecosystem.

 A Flexible Service Architecture for IoT

 The realization of the above use cases is enabled through an architecture called the “Web Service Interface (WSI)”.  With the WSI approach, we did not try to take data from IoT devices or the automobile into the cloud.  What we wanted to do was to provide a way for services and applications to be represented within the IoT network and to bring the execution of the rules from the cloud to inside the IoT network. This approach helped us to represent ANY service in a consistent manner thereby easing the handling of protocol, ownership, privacy, security and ease of use concerns.

Image Added

How RVI models Vehicle Information as a Spec.

 To be done.

Vehicle Connectivity as a Service?

Thinking about the connectivity to the vehicle as a service helped us to model the use case in terms of discovering and invoking services provided by the vehicle. This made the task of realizing the use cases to be simply a matter of service invocation rather than dealing with protocol details and intricacies. These details are best handled by the software stack dictated by the automaker or Tier-1 service provider. It addresses the key issue of who owns this part of the stack, which is always a point of concern in commercial deployments.

 In this context, the RVI Expert Group within Genivi had an open source software in place for many important vehicle connectivity use cases which we could readily use for representing vehicle connectivity as a service within the WSI architecture. This extends the connectivity services hosted by the vehicle to be accessed by IoT devices inside the smart home.

 Demo Showcase Setup

 The RVI-OCF Gateway basically handled all the service specific details.

Image Added

 Here’s how the bidirectional flow works.

 The RVI service node hosted in the vehicle HMI running on GDP, connects via the cloud to the home gateway.

The WSI gateway also runs an RVI node (this is currently an implementation limitation which can be removed once native RVI libraries are implemented)

 RVI provides many means to access services and we decided to use websockets.

 The WSI gateway connects via websockets to the local RVI node which then talks to the remote RVI node.

 Connection & remote RVI service discovery is handled purely by RVI and the WSI Gateway need not worry about the internals.

 After connecting to the remote RVI node, the WSI Gateway simply translates between the service definitions provided by Remote RVI Service Node into corresponding OCF device control commands based on application developer logic.

 This mapping is totally independent of how the gateway functions and thus provides maximum flexibility to implement any rules or service logic you can come up with, depending on the scenario.

 In this case, the service was controlling the HVAC parameters of a vehicle. In future, we could extend the service to be whatever the situation demands.

 Another major benefit of this approach is that the IoT device data is never transmitted out of the home. Similarly, the vehicular data is never transmitted over the cloud. This provides a clear separation of the data across the domains, namely smart home and vehicle with a reduced security and privacy risk – while giving total control over the customer data to the existing services. In addition to the above demos and use cases, we also have made OCF stack called as IoTivity, as part of the GDP and AGL (Automotive Grade Linux), so that interested developers will now be able to implement use cases.

All of our source code is published under

 https://github.com/GENIVI/meta-genivi-ocf-demo/tree/master

 http://git.s-osg.org/ocf-automotive-sampleapps/

 A complete video demonstration of WSI at work is presented here.

 https://www.youtube.com/watch?v=351m-GrRSNE

 The complete blog is presented here.

 https://blogs.s-osg.org/osg-ocf-automotive-fortnight/

6.6.2 API's defined

Please focus on overall expected penetration of OSS work in IoT market

6.7 OMA-DM and vehicle security (YAIR N)

6.7.1 Overview and objective of project...

6.7.2 API's defined

7. Analysis and recommendations to achieve interoperability (JOEL H)