...
| Reference | Details |
|---|---|
\[GotAPI\] | Generic Open Terminal API Framework (GotAPI), Candidate Version 1.1 – 15 Dec 2015, Open Mobile Alliance, http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/generic-open-terminal-api-framework-1-1 |
| \[DWAPI\] | Device WebAPI-PCH, Candidate Version 1.0 – 19 Apr 2016, Open Mobile Alliance, http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-device-webapi-v1-0 |
3. Terminology and Conventions
3.1 Conventions
| \[OCF\] | The Open Connectivity Foundation (http://openconnectivity.org) |
| \[IoTivity\] | The open source implementation of the OCF speciications (http://iotivity.org) |
| \[RVI\] | Remote Vehicle Interaction open source project (https://github.com/GENIVI/rvi_core) |
| \[VSS\] | Vehicle Signal Specifications (https://github.com/GENIVI/vehicle_signal_specification) |
3. Terminology and Conventions
3.1 Conventions
This is an This is an informative document, which is not intended to provide testable requirements to implementations.
...
| Abbreviation | Meaning | ||
|---|---|---|---|
| DWAPI | Device WebAPI | ||
| GotAPI | Generic Open Terminal API | ||
OMA | Open Mobile Alliance | ||
| OCF | Open Connectivity Foundation | ||
| RVI | Remote Vehicle Interaction | ||
| VSS | Vehicle Signal Specification |
4. Introduction
We live in an increasingly automated world with complex interactions between the inventions we depend on as well as those we simply enjoy using. The interactions between these devices depend largely on the standardization efforts of the internet. However, to achieve interoperability and full automotive between complex collections of machines such as cars, cities and homes deeper levels of agreed standards are needed. In the office setting, this has largely been resolved thanks to the widespread implementation of mostly the same software of all companies, such as Microsoft Windows and Microsoft Office. These products represent an implementation of a closed architectural design that works with itself smoothly. Apple has a similar approach where design, testing, and support all comes from a single source. However, even in this environment issues have appeared when one company uses one product and another company uses the other.
...
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.7 Multiple Deployment Models
The OCF-Vehicle translator is a software component that can be placed in
- Cloud
- Home Gateway
- Vehicle IVI unit
...
. 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.
The OCF-Vehicle translator is a software component that can be placed in
- Cloud
- Home Gateway
- Vehicle IVI unit
Depending on the desired end user experience and deployment configuration, the translator enables seamless service oriented access between IoT devices, web services (apps) as well as vehicle controls.
6.6.9 Next Steps
OCF has a vision to connect the next 25 billion things
- Automakers want simple interconnection with smart devices.
- Developers want apps to work across car brands and ecosystems.
- End users want secure connectivity and services across devices.
6.6.8 Related Links
https://www.youtube.com/watch?v=351m-GrRSNE
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/
The complete blog is presented here.
https://blogs.s-osg.org/osg-ocf-automotive-fortnight/
6.6.9 Next Steps
Over the next few months, Genivi and OCF will be working together with the W3C Automotive Working Group, to develop OCF data models for representing vehicle states which can be used by OCF-Vehicle translator implementations that can be used by IVI systems, web service integrators or home gateway developers to build products and services that help bring to market, the connected vehicle – IoT crossover scenarios to life.
6.6.2 API's defined
Please focus on overall expected penetration of OSS work in IoT market
...