...
6.5.1 Overview and objective of project...
6.5.2 API's defined
6.5 W3C VSS Standardization
A result from the RVI project is being developed within W3C regarding consistent naming of vehicle endpoints that could abstract the OEM specific software from third party applications remotely or locally accessing them, as illustrated below:
Initially, VSS is supported by open source projects under development in Jaguar Land-Rover's OSTC in Portland, OR and quickly being accepted by others including some telematics system suppliers.
6.6 OCF IoTivity
...
6.6.1 Overview and purpose of project
...
Optimizing personal mobility , is no longer with 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 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.
- Home Energy Management
- Security System Interaction
- Vehicle Location
- Smart Home device status
- Vehicle Control from Smart Device
- Smart Device Control from Vehicle
- Smart Mobility service integration
The Project will be driven is led 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.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 many different protocols. RVI separates the vehicle data representation from the transport. The "Vehicle Signal Specification" is a straightforward 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 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.
...
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, permits 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 defines 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, permits 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 a simple way to combine IoT devices and vehicle states to implement new services that leverages leverage the capabilities of these devices.
...
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 structure, was already available in the context of the iotivity 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 the 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 regarding 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 the 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 just 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 entirely 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 information is never sent over to 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 Source code is published under
under https://github.com/GENIVI/meta-genivi-ocf-demo/tree/master
and 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.2 API's defined
Please focus on expected overall penetration of OSS work in IoT market
...
6.7.1 Overview and objective of project...
6.7.2 API's defined
7.0 Analysis and recommendations to achieve interoperability
This paper tells a story about the desire for both automotive and consumer electronics to find improved way to interact and provide the compelling experience to buyers of cars and "things" that will motivate them to invest their money in new models that work together better. Gone are the days of expecting customers to buy every component of a system as all one brand as many did when buying a stereo system for their home in the 70s.
A matched set of your phone, tablet, PC, car, home lighting, thermostat, and security system is highly unlikely. Consumers are already struggling with the subtleties of Android and Apple devices with different interactions based on closed architecture. Automakers are resisting the entry of these private consumer models into their products, yet are happy to adapt cross-device standards as shown by Toyota and Ford supporting SD-Link. An independent ecosystem of software developers is a bold trend in automotive. The pace of acquisition and respect for startups by car companies continues to increase. Open source projects such as the GENIVI IVI baseline, Linux Foundation AGL Unified Code Base, as well as the RVI and IoTivity projects provide evidence that open platforms in automotive are changing the car development process dramatically.
The need for IoT standards is clearly needed. While these standards emerge, both industries need to learn from past efforts. There is some overlap between GotAPI, accepted in communications space, and OCF's IoTivity, which is not yet proven but could become a standard from the device makers. Similarly, OMA DM has an extensive implementation portfolio with communications providers and overlaps some with GENIVI's RVI implementation while that project promises to incorporate OMA DM to include carrier support of LTE.
W3C has the responsibility to further the work of VSS, regardless of the other projects and there appears to be no competition for this automotive specification, and the W3C Automotive Working Group needs to increase emphasis on this aspect of the RVI related work they are undertaking currently.
In all cases these projects require more automaker support to succeed. The demonstration efforts by OCF and GENIVI are helpful, and also deserve more interaction between OMA, W3C, OCF to architect as a fully documented standard. SAE must be a part of this group effort. SAE has strong alignment with the auto suppliers and OEMs. This heritage recently surged by substantial industry excitement around Automated Driving Systems (ADS). No longer referred to as autonomous driving per SAE J3016 SEP2016, these ADS modules will not be functional as separate units but will need significant external information from other "things" both inside and outside the car to achieve higher levels of driving automation (Level 5).
Rather than constrain the need for standard interfaces, APIs and data formats to convenience features (operating your garage door) a clear standard will find its way into many interactive systems. Safety related priorities must also align with the work of consortia focused on automotive production development.
Unquestionably, security is a key factor and methodologies under development for protecting and securing private and safety critical information should be the topic of study for another paper in this series. interoperability (JOEL H)
8. References (Temporary)
- http://www.volkswagenag.com/content/vwcorp/info_center/en/news/2016/07/connected_car.html
- http://fortune.com/2016/07/13/jaguar-land-rover-autonomous-cars-britain/
...