Download current working formatted draft oma telecom and automotive 1-17[1].pdf

...

Table of Draft Inputs

Table of Contents

1.     Scope

1.1          OMAuto Goal

• Establish a venue for discussion between telecom and automotive at a technical and industry level to establish any network, any automobile connectivity.
• Adapt select current specifications to optimize for the needs of the Automotive market.
• Create a path for Auto industry to interface with the rest of IoT via standardized enablers.
• Bridge existing standards with standardization efforts in the Automotive sector.

Enable a path for automakers and Mobile Network Operators (MNOs) to encourage communications interoperability across automotive and wireless industries.

1.2          Deliverables

Medium = technical report with a set of agreed recommendations to drive future standardization work (25-50 pages)

• Get agreement across participating parties as to what work should be done and where (which SDO) it needs to be done.
• Examine landscape across mobile and automotive environment
• Identify areas of overlap across industry work groups (RVI, W3C, GSMA, 3GPP, OMA, Smart Device Link, Apple CarPlay and Android Auto, OCF, etc…)
• Produce use cases/examples including interaction between IoT and automobile
• Roadmap and proposed timeline of future work needed, for example
  • Security-related issues
  • Enabler creation or reuse to facilitate development of enhanced services
  • Collaborate with additional verticals (environmental, safety, healthcare)
• Deliverables publication to be public and available online
• Reference code-based projects already underway
• Clarify what should be standardized, open source vs. proprietary to encourage interoperability
• Other TBD

2.     References 

1. This is a draft of the report being created by the OMAuto Incubator Group at OMA. Feel free to edit this story if you have something of value to contribute.

If you want to add or delete an image on this page, download the file OMAuto Incubator Report Diagrams.Pptx PowerPoint deck and follow the instructions. If you don't have PowerPoint, follow these instructions:

• Images in source format other than Microsoft Office Graphic (Powerpoint) should be edited by other tools and uploaded to the wiki in the form of origin, for future updates. Once finished editing, save the image as a PNG with filename per the caption of the picture in the report.
• Edit the wiki page, and use the “Files” tool to upload the image. If you are updating an image with the same name, you don’t need to re-insert it, so deselect the checkbox on the picture and select close.

Table of Contents

Table of Contents

1.     Scope

1.1          OMAuto Goal

• Establish a venue for discussion between telecom and automotive at a technical and industry level to establish any network, any automobile connectivity.
• Adapt select current specifications to optimize for the needs of the Automotive market.
• Create a path for Auto industry to interface with the rest of IoT via standardized enablers.
• Bridge existing standards with standardization efforts in the Automotive sector.

Enable a path for automakers and Mobile Network Operators (MNOs) to encourage communications interoperability across automotive and wireless industries.

1.2          Deliverables

Medium = technical report with a set of agreed recommendations to drive future standardization work (25-50 pages)

• Get agreement across participating parties as to what work should be done and where (which SDO) it needs to be done.
• Examine landscape across mobile and automotive environment
• Identify areas of overlap across industry work groups (RVI, W3C, GSMA, 3GPP, OMA, Smart Device Link, Apple CarPlay and Android Auto, OCF, etc…)
• Produce use cases/examples including interaction between IoT and automobile
• Roadmap and proposed timeline of future work needed, for example
  • Security-related issues
  • Enabler creation or reuse to facilitate development of enhanced services
  • Collaborate with additional verticals (environmental, safety, healthcare)
• Deliverables publication to be public and available online
• Reference code-based projects already underway
• Clarify what should be standardized, open source vs. proprietary to encourage interoperability
• Other TBD

2.     References 

...

6.1.1 Overview and objective of project

The Automotive Working Group develops APIs to expose vehicle data and information from an W3C first explored the impact of the Open Web Platform on the automotive industry at the November 2012 Web and Automotive Workshop. Participants discussed how location-based services, enhanced safety, entertainment and integration of social networking will benefit drivers and passengers. Since then, the Business and Working Groups have kept the conversation around standardization and specifications, through regular meetings with stakeholders. The Automotive Working Group develops APIs to expose vehicle data and information from automotive network bus(es) (eg. MOST and CAN). The specification is broken into consists of two parts:

1. Vehicle Information Specification containing durable, unchanging access methods for obtaining vehicle information;
2. Vehicle Data Specification to specify agreed upon standardized data elements as well as the method for extending data elements to OEM specific elements.
   
   

Image RemovedImage Added

var vehicle = new WebSocket("wss://wwwivi", "wvvss1.0");

Authorize

GET

SET

Subscribe

Unsubscribe

getVSS - helps provide only a subset of the information.

   - can be controlled by vendor.

Request/Response mechanism over websockets

vehicle.send('{action' : 'subscribe', "path" :"body.mirrors.left", 'reqid' : "[some unique id] }");

Secure Web Socket

Connection Established

REQ : getVSS

RES : VSS File

REQ/RES : get/set/sub/unsub

onopen, onmessage, readyState

Demo

Prepare self-signed certificate

How does the client address IP based ns non-IP transports

The W3C Automotive Specifications follows a client server architecture. The W3C automotive compliant web clients "connect" to a W3C Vehicle Server using secure websocket connection (wss://). The Vehicle Signal Server abstracts the communications with the underlying automotive networks (like CAN, MOST etc), and presents a simple set of Web API for the clients. Beyond this, the interactions between client and server follow a Request/Response model.

Image Added

The "vehicle" object, represents an instance of the Vehicle Signal Server connection that can provide access to Vehicle Data through the W3C Information API. The supported methods are : 

1. Authorize  - Authorize a client to access the Vehicle API (TLS)
2. GET - Gets the value of a parameter, like body.mirrors.left
3. SET - Sets the value for a parameter
4. Subscribe - Subscribe to status changes
5. Unsubscribe
6. getVSS - get the JSON representation, to be used in GET/SET/SUBSCRIBE/UNSUBSCRIBE API.

The message format is JSON. Below is a simple flow diagram that explains the communication between W3C automotive clients and servers.

Image Added

The getVSS API provides a JSON payload that represents the vehicle information accessible to clients. The authorization mechanism helps implement role based access to vehicle data.

Given below is an example of how a web client would invoke a "Subscribe" request to the vehicle server.

Image Added

This example, registers the client to be notified about changes to "body.mirrors.left" by the vehicle server. The client can process the changes via Javascript callbacks.

The W3C Automotive Business Group recently met at the Genivi AMM in San Franciso and showed their demo implementation of the above API. With less than 100 lines of Javascript, developers can easily integrate Vehicle data into their apps and services. Here's a screenshot of the demo.

Image Added 

6.1.2 API's defined

6.2 OMA GotAPI and DWAPI

...