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,

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 

...

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.

Interoperability standards in data formats and programming interfaces (APIs) in even more essential if non-automotive devices are attached to the "connected cars." Otherwise, consumers need to buy all their home appliances and electronic devices from the car dealer. This model ended with the "car phone" but continues in some way with the limited services available in closed telematics offers by each carmaker.

4.1          Observed Problem

...

5.1          Over-the-air updates

5.1.1 OMA DM (are all of Red Bend's contributions included?)

The OMA-DM protocol is deployed by leading Mobile Network Operators (MNOs) like AT&T, NTT DOCOMO, SoftBank, Sprint, T-Mobile US and Verizon Wireless. The MNOs use the OMA-DM protocol to manage mobile devices on their network. The following are some of the use cases MNOs have deployed:

...

In recent years, with the introduction of the connected car, the term “mobile device” is extended to include the “large mobile device” of the automotive industry. Many car OEMs select to use the OMA-DM protocol to manage the configuration and software of the cars they are building. This enables car manufacturers to capitalize on the full business potential of connected cars by enhancing driver experience with rapid deployment of value-added in-car services, and minimizing costs through improved efficiency and a reduction in recalls.

5.2          Device APIs (move all API info to this section - Elizabeth)

5.2.1 Overview (Alan to edit)

needs to be made generic - not OMA-centric Through OMA enablers focused on device APIs, we can enable Automotive systems to offer API services to apps running in app environments provided by the Auto system. Such API services can enable apps to access vehicle information/services or other connected devices. These OMA enabler APIs are based on the Generic Open Terminal API (GotAPI) \[GotAPI\] enabler framework described in section 6.2.

...

• 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

Image Removed

Use Case B: An RVI can access external device information/services, e.g. exposing access to a home lighting system. 

Use Case B

Image Removed

6. Automotive Industry API definition projects comparison

6.1 W3C Automotive Web API (Sanjeev-owner; Alan-editor)

...

• , 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

Image Added

Use Case B: An RVI can access external device information/services, e.g. exposing access to a home lighting system. 

Use Case B

Image Added

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:

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 Added

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

...

• GotAPI-5: The GotAPI-5 interface enables applications to listen to asynchronous messages from Extension-Plug-Ins via the GotAPI Server using WebSockets.

GotAPI Interfaces

Transport Protocols

6.3 LWM2M

...

6.3.1 Overview

The OMA LWM2M (Light Weight Machine To Machine) protocol provides the capability for applications to communicate and manage IoT devices. LWM2M is based on the IETF Constrained Application Protocol (CoAP) providing communication between a LWM2M Server and a LWM2M Client (where Client is located in a constrained IoT device).

...

• Access control on the specific contents that could be handled remotely by different entities
• Software and firmware Management for applications inside the Client
• Lock & Wipe of the device from misuse
• Connection management for choosing various radio methods by the Client
• Device Capability Management to identify the capabilities existing in the device
• Location of the device
• Connection Statistics concerning communication characteristics over the air

...

6.3.5 Object Registry

The object registry provides a unique way of identifying the necessary and relevant objects. The object registry is maintained by OMNA (Open Mobile Naming Authority). It includes categories for interleaving 3^rd party management objects and application objects into the OMNA system from vendors and other standards organizations (for, e.g., IPSO Alliance and oneM2M)

6.5 GENIVI Remote Vehicle Interaction (RUDI S to collaborate with Magnus/Magnus)

6.5.1 Overview and objective of project...

...

, e.g., IPSO Alliance and oneM2M)

6.5 W3C VSS Standardization

...

OCF has the vision to connect the next 25 billion things

• Automakers want simple interconnection with smart devices.
• Developers want apps to work across car brands and ecosystems.
• End users want secure connectivity and services across devices.

...

6.6.8 Related Links 

...

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 OMA-DM and vehicle security (YAIR N)

6.7.1 Overview and objective of project...

...

/blogs.s-osg.org/osg-ocf-automotive-fortnight/

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.

Image RemovedImage Added

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)

1. http://www.volkswagenag.com/content/vwcorp/info_center/en/news/2016/07/connected_car.html
2. http://fortune.com/2016/07/13/jaguar-land-rover-autonomous-cars-britain/

...