This is a draft of the report being created by the OMAuto Incubator Group at OMA. Feel free to edit this report if you have something of value to contribute.
If you want to add or edit 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 source format, for future updates. Once finished editing, save the image as a PNG with filename per the caption of the image 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 image and select close.
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 operators 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 needs to 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
- Work 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
| Reference | Details |
|---|
\[RefName\] | Title, Document Number, Publisher, URL |
| | |
| | |
| | |
3. Terminology and Conventions
3.1 Conventions
This is an informative document, which is not intended to provide testable requirements to implementations.
3.2 Definitions
3.3 Abbreviations
| Abbreviation | Meaning |
|---|
OMA | Open Mobile Alliance |
| | |
4. Introduction
4.1 Observed Problem
- Problem statement 1
- There are a series of initiatives in the automotive industry that will touch the mobile environment
- There is work going on in the mobile/IoT industry that will need to interoperate with automobiles
- It is important for all not to waste resources by “reinventing the wheel”
- Use good protocols that already exist and are deployed
- There are a number of one-to-one company level programs underway, there is NOT a conversation happening at the industry-to-industry level to insure standards-based interoperability and reduce fragmentation of protocols across automotive interacting with IoT and mobile services
- The overall needs of the automotive industry are not being translated into mobile/IoT industry developments – harmonization of requirements and solutions between the mobile and the automobile environments. What are the problems the automotive industry are trying to solve?
- Problem statement 2
- The auto industry wants to ensure openness and mobile device interoperability in relation to the automotive telematics systems
- Automakers run the risk of becoming a “dumb device” with no control over user data
- Operators and automakers could be forced to the sidelines where consumer touch, data collection and ownership are no longer future revenue sources
- Existing automotive approach of proprietary implementations is no longer working
- SDL - Smart Device Link, an open source implementation of Ford’s AppLink (Ford Sync) software libraries enabling smartphone integration across all radio levels and brands of devices (Apple, Android, Windows, etc.)
- RVI - Remote Vehicle Interaction, an open source project by JLR Research Centre in Portland, OR. Enables universal connectivity to the vehicle bus transparently across LTE, Wi-Fi, Bluetooth, 3G, NFC and future networking technologies by embedding a standard software module in the vehicle head unit.
- SOTA - Software Over The Air (included in RVI above) through the entire vehicle (ASIL grade Safety and Security)
4.2 Hot Projects in Open Automotive
- SDL - Smart Device Link, an open source implementation of Ford’s AppLink (Ford Sync) software libraries enabling smartphone integration across all radio levels and brands of devices (Apple, Android, Windows, etc.)
- RVI - Remote Vehicle Interaction, an open source project by JLR Research Centre in Portland, OR. Enables universal connectivity to the vehicle bus transparently across LTE, Wi-Fi, Bluetooth, 3G, NFC and future networking technologies by embedding a standard software module in the vehicle head unit.
- SOTA - Software Over The Air (included in RVI above) through the entire vehicle (ASIL grade Safety and Security)
5. Automotive Opportunity
5.1 DM
5.2 Device APIs in Automotive
The goal is to have to user can access and share information with anyone, anywhere. The problem today is Mobile apps, self-contained (lock off their data) from the wider internet. User information is effectively walled off from the rest of the Internet - they keep you in their world.
- Devices web APIs: open the gates to the content from external that enable web developers to interact with a particular platform. Enable third parties apps developer to take data from different sources (e.g. external devices) and leverage its data in new and interesting ways
- GotAPIs/Device APIs is a well-designed framework that expose data to third parties in a consistent way by providing for registration, discovery, access, security, authentication, etc. for apps and ext. devices.
- Without GotAPIs, we would have to implement these methods for each device independently
5.2.1 OMA Enablers: Example of possible work for Automotive
We need to find the synergy between what is happening in Mobile application (e.g. driver safety, etc.), IoT, etc. with the evolving technology in the car environment. OMA device APIs: Web-based application, for example, an application in the car that have access to the car information and external sensors, driver vital signs (including your heartbeat, breathing rate, temperature, and blood pressure, etc).
- RVI example: Mobile Keyless Entry, download app to smartphone and use it to unlock the vehicle.
- Also the application can discover external sensors, example, road sensors, outside air quality sensors, etc.
Overview: Various External Devices Work with GotAPI and Applications
(Web app case)
GotAPI Architecture
5.1.1 Example of RVI and OMA Devices APIs
The RVI will have two roles with respect to GotAPI server. These are: Plug-in and App Client. We think these two roles will support both 3rd party Web Applications in the car that have access to external devices and car data through its internal device APIs. In the second role, RVI as defined will support external devices by interacting with GotAPI server (Device API).
From implementation point of view, if you support one, you can support the second.
In use Case A, we are leveraging the existing work done in OMA (GotAPI V1.1 and DWAPI*) that is championed by NTT DoCoMo, KDDI, etc.
Use case A
Any 3rd party Web developers can access the RVI data and external device data through GotAPI/Device API. Ex: Auto Driving Lessons Coach.
3rd party App in this use case does not need to implement RVI.
Use Case A
Use Case B
External devices supplying data to RVI. Ex: RVI exposing access to home lighting system.
