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.
...
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
...
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 the 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 RVI promises to incorporate OMA DM to include carrier support of LTE. Intensifying these efforts will help align and reuse the work already done.
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. Today a small handful of engineers and technical leaders are working on these projects, and the W3C Automotive Working Group needs to increase emphasis on this aspect of the RVI related work they are undertaking currentlythis investment by suppliers must increase. Automaker endorsement and intention to build product will bring more experts to the table.
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 automotive and consumer 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.
Similar to the integration challenges experience in enterprise office systems, have been reduced by standard data formats and API's, such as vCard and vCal. Automotive leaders and communications leaders working together can deliver on the promise of open, safe, secure and smart cars that work with all your other smart "things".
8. References (Temporary)
...