...
- Home Energy Management
- Security System Interaction
- Vehicle Location
- Smart Home device status
- Vehicle Control from Smart Device
- Smart Device Control from Vehicle
- Electric Vehicle Time-of-Use Charging
- Entertainment
- Third party application service integrations based on the above use cases
While most of these use cases solutions are realized through closed joint collaborative efforts between industry partners, there is in general a lack of open source alternatives which stifles innovation. Samsung Open Source Group and Jaguar Land Rover Open Source Technology Center, followed an open collaboration model under the Genivi Alliance Incubator projects initiative. Using One of the key objectives of this partnership was to use completely open source software and commodity off-the-shelf hardware, we were able to realize the use cases (in bold), with minimal resources and a short durationtime.
6.6.2
...
Stakeholders : Roles, Responsibilities and Expectations
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 limited roles and expectations.
...
| Role | Responsibilities | Expectations |
|---|---|---|
Service Provider (Cloud, Web, Network) | Hosts the service infrastructure backbone Enable authenticated access to the infra.Extending service into the IoT network. | Minimal/No changes in existing workflows.business models (non disruptive). Support exisiting legacy services.
Extending service into the IoT network.
More user engagement from multiple sources. |
| Customers | Consume Services & IoT Devices Provide credentials for privacy and security | Zero/Minimal Setup overhead Ease of Use of Products & Services Cost and Time savings with more personalization. New experiences in doing day to day activities. |
| 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 |
...
6.6.3
...
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.
...
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. RVI is capable of handling message delivery over Bluetooth, WiFi, LTE and SMS.
6.6.4 A Flexible Service Architecture for IoT
Within the IoTivity open source project we developed a MEAN (Mongo-Express-Angular-Node) stack based framework for bringing web services and IoT devices together to realize our use cases and to understand the issues while we attempt to integrate these domains. We defined an abstract service metadata model as a way for services to be represented within an IoT network and to move the execution of the business logic from the cloud to inside the IoT network or automobile respectively. Only the serive inThis 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.5 Vehicle Connectivity as a Service?
...
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.
6.6.8 Standardization Efforts
6.6.
...
9 Related Links
All of our source code is published under
...