...
6.6 OCF IoTivity (SANJEEV)
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:
...
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.
6.6.2 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.
...
| Role | Responsibilities | Expectations |
|---|---|---|
Service Provider | Hosts the web service Provides access via API and Apps | Extending service into the IoTivity IoT network. Minimal/No changes in existing workflows. More user engagement from multiple sources. |
| Customers | Consume Services & use IoT Devices Provide credentials for privacy and security | Zero/Minimal Setup overhead Ease of Use of Products & Services |
| Application Developers | Innovate and delight customers with New {Web services & IoT devices} Apps | Maximize Asset Reuse Simpler development New revenue streams |
| Auto makers & Tier 1 | Manufacture at Scale Compliance to standards (where applicable) | Increased user adoption Feature Differentiation |
...
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.
...
6.6.3 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.
6.6.4 How RVI models Vehicle Information as a Spec.
As explained in the section <<RVI Section>>, RVI seperates the vehicle service data representation from the transport. The "Vehicle Signal Specification" is a simple, flexible and scalable format to represent vehicle signals inside a vehicle using a simple tree like hierarchy. RVI Core stack handles the software infrastructure needed to discover other RVI endpoints and handling of end to end delivery of messages, i.e. the transport agnostic communications infrastructure.
6.6.5 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.
6.6.6 Demo Showcase Setup
The RVI-OCF Gateway basically handled all the service specific details.
Here’s how the bidirectional flow works.
...
6.6.7 Demo Showcase Setup
- 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
...