...
Optimizing personal mobility, is no longer about the connected vehicle alone. To unlock these opportunities, OCF launched the Automotive Project in August 2016. For an automotive IoT ecosystem to flourish, the deployment 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. Service providers hosting the infrastructure expect minimal changes to the existing investments and expect new revenue streams by extending their services into the IoT network. Customers expect new services and experiences with zero setup overhead. Application developers are looking to leverage their existing assets and generate more user engagement. The The aim of the Project is to provide the technology, standards and collaboration needed to ensure secure interoperability between automotive and other verticals, starting with consumer electronics, smart home and healthcare. The initial use cases enabled by the project fall into the following broad categories.
...
The Project will be driven by members from Samsung, Honeywell, Cisco, SmartThings, ETRI, GRL and Tinnos. The project will also closely collaborate with other OCF working groups, leading automotive companies and alliances, open source projects and standards bodies. The OCF Automotive Project will define the data models. Additionally, the group will drive the certification requirements for compliant bridging implementations, which is essential for realizing valuable and commercially attractive use cases, to the automotive industry.
6.6.4 Initial Prototyping
OCF Automotive Project has been under
...
Samsung Open Source Group and Jaguar Land Rover Open Source Technology Center, followed an open collaboration model under the Genivi Alliance Incubator projects initiative to drive the OCF Automotive Project incubationincubation for the past six months. The incubation was carried out together with the Genivi Alliance under the Genivi Incubator projects initiative. The goals for this incubation involved realising realizing the aforementioned use cases using IoTivity open source project and the RVI open source implementation , developed under Genivi. One of the key objectives of this partnership was to use completely open source software and commodity off-the-shelf hardware, to realise the use cases (in bold).
6.6.5 Stakeholders : Roles, Responsibilities, and Expectations
6.6.3 How RVI models Vehicle Information as a Spec.
provided by Genivi.
The RVI or Remote Vehicle Interaction project provides a standardized means for communications between the vehicle and its remote services over a number of different protocols. RVI separates the vehicle As explained in the section <<RVI Section>>, RVI separates the vehicle service data representation from the transport. The "Vehicle Signal Specification" is a simple , and 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 an end 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.
...
5 Remote Vehicle Interaction Overview
The RVI or Remote Vehicle Interaction project provides a standardized means for communications between the vehicle and its remote services over a number of different protocols. RVI separates the vehicle data representation from the transport. The "Vehicle Signal Specification" is a simple and flexible format to represent vehicle signals using a tree-like hierarchy. RVI Core stack handles the software infrastructure needed to discover other RVI endpoints and handling 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.
RVI project also publishes the “VEHICLE SIGNAL SPECIFICATION” via github.
This repository specifies a set of vehicle signals that can be used in automotive applications to communicate the state of various vehicle systems. A standardized vehicle signal specification allows for an industry actor to use a common naming space for communicating vehicle state and, ultimately, allows the decoupling of the IVI stack from the underlying vehicle electrical architecture. The collection of signal specifications, or simply signals, is vendor independent. Vendor-specific extensions can be specified in a dedicated and uncontrolled branch of the signal specification tree.
This repository specifies a set of vehicle signals that can be used in automotive applications to communicate the state of various vehicle systems. A standardized vehicle signal specification allows for an industry actor to use a common naming space for communicating vehicle state and, ultimately, allows the decoupling of the IVI stack from the underlying vehicle electrical architecture. The collection of signal specifications, or simply signals, is vendor independent. Vendor-specific extensions can be specified in a dedicated and uncontrolled branch of the signal specification tree.
An open source RVI implementation combined with an open data format (VSS) to represent vehicle state, together provide the necessary software components that can provide secure connectivity to select functions of a vehicle, in a customizable manner. RVI enables simple way to combine IoT devices and vehicle states to implement new services that leverages the capabilities of these devices.
6.6.6 Developing the OCF-Vehicle Translator
A MEAN (Mongo-Express-Angular-Node) stack based gateway framework (WSI – Web Service Interface) for bringing multiple services and IoT devices together as part of a single programmable framework, was already available as part of the iotivity open source project. 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 depending on a desired deployment configuration. This approach provides the flexibility to choose the nexus of device-service integration at the hands of the developers.
Thinking about the connectivity to the vehicle as a service, with the help of RVI, helped us model the use cases in terms of discovering and invoking services provided by an RVI instance. This made the task of realizing the use cases to be simply a matter of service invocation rather than dealing with protocol or messaging details. This reduces the burden for app developers to a large extent.
The RVI service node hosted in the vehicle HMI running on GDP connects via the cloud to the home gateway. The RVI-OCF translator/gateway also runs an RVI node. RVI provides many means to access services and we decided to use websockets. The RVI-OCF translator/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 RVI-OCF translator/gateway.
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
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.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.
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 service 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?
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.
6.6.7 Message Flow
- 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.
6.6.8 Standardization Efforts
6.6.9 Related Links
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
...