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,
- 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
...
We live in an increasingly automated world with complex interactions between the inventions we depend on, as well as those we merely enjoy using. The interactions (or interoperability) between these among devices depend largely on standardization efforts. However, to achieve interoperability between complex collections of machines such as cars, computers, appliances or even 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 common software across most 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 or department uses one product and another company or department uses the other.
One example can be seen when using contact information and calendar reminders. At one time each both Microsoft and Apple devised their own methods to store and share these small bits of information needed to synchronize between users in the enterprise. This allows people working in different countries and time zones to all see the dates in their own format and timezone, yet it is stored in a standard format for exchange. Enterprises Enterprise users with mostly Microsoft Office, but a few people using Apple Macs, left the minority users in the cold until a standard agreed upon format was defined, developed, tested and implemented in the otherwise closed systems. The data format and API for this is now called vCard and vCal. Through its implementation, the enterprise users have the choice of device, operating system, and application. Now that tablets, phones, and even Linux PCs have been added to the enterprise, all they need to do is implement the standard. The result was born as Thus BYOD or Bring Your Own Device , was enabled and is now an enterprise IT expectation along with the implications of incorporating personal preferences by users to maximize productivity.
Recently the open source software model (OSS) has caught momentum as a way for hundreds of different companies to participate in the development of software design and code creation. This model not only includes a licensing philosophy that tries to remove costly barriers to participation but encourages the use of a common base of code with each software provider adding their unique value and licensing only these differences. . Beginning in 2006 or so, automotive software development began to use this method to help manage the millions of lines of code needed to create a modern vehicle. The total number of cars heading to production is divided by at least ten automakers, often with hundreds of combinations of makes, model years and trim levels resulting in relatively small numbers of validation resources for each variation. This issue is driving car development and bugs to record levels, resulting in higher prices and costly recalls after the cars are on the road. Add in the concept of self-driving cars and safety automation features and the costs can be measured in both currency and lives. The collaborative model helps with this but still requires standardization to be useful.
...
- An Auto system app can monitor driver vital signs (heartbeat, breathing rate, temperature, blood pressure, etc)
- A user can download an RVI app providing Mobile Keyless Entry to their smartphone, and use it to unlock the vehicle
- Auto system apps can also discover other external sensors, e.g. road sensors, outside air quality sensors, etc
Through the two essential roles below, Auto systems (e.g. an RVI) that host a GotAPI-based API server can support a wide variety of use cases for apps running in the Auto system, e.g.
- the Auto system can offer vehicle information/services to apps running in an Auto Web runtime environment
- the Auto system can act as a GotAPI client in accessing information/services provided by connected devices
These use cases shown below:
Use Case A: Web apps (e.g. an Auto Driving Lessons Coach) can access the RVI data and external device data through GotAPI/Device API. GotAPI enables the Web app to access RVI information/services without needing to implement the RVI-specific interfaces:
Use Case A
Use Case B: An RVI can access external device information/services, e.g. exposing access to a home lighting system.
Use Case B
6. Automotive Industry API definition projects comparison
6.1 W3C Automotive Web API (Sanjeev-owner; Alan-editor)
...
- temperature, blood pressure, etc)
- A user can download an RVI app providing Mobile Keyless Entry to their smartphone, and use it to unlock the vehicle
- Auto system apps can also discover other external sensors, e.g. road sensors, outside air quality sensors, etc
Through the two essential roles below, Auto systems (e.g. an RVI) that host a GotAPI-based API server can support a wide variety of use cases for apps running in the Auto system, e.g.
- the Auto system can offer vehicle information/services to apps running in an Auto Web runtime environment
- the Auto system can act as a GotAPI client in accessing information/services provided by connected devices
These use cases shown below:
Use Case A: Web apps (e.g. an Auto Driving Lessons Coach) can access the RVI data and external device data through GotAPI/Device API. GotAPI enables the Web app to access RVI information/services without needing to implement the RVI-specific interfaces:
Use Case A
Use Case B: An RVI can access external device information/services, e.g. exposing access to a home lighting system.
Use Case B
6. Automotive Industry API definition projects comparison
6.1 W3C Automotive Web API (Sanjeev-owner; Alan-editor)
6.1.1 Overview and objective of project
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 consists of two parts:
- Vehicle Information Specification containing durable, unchanging access methods for obtaining vehicle information;
- Vehicle Data Specification to specify agreed upon standardized data elements as well as the method for extending data elements to OEM specific elements.
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.
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 :
- Authorize - Authorize a client to access the Vehicle API (TLS)
- GET - Gets the value of a parameter, like body.mirrors.left
- SET - Sets the value for a parameter
- Subscribe - Subscribe to status changes
- Unsubscribe
- 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.
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.
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.
6.1.2 API's defined
6.2 OMA GotAPI and DWAPI
...