1. 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.

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

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

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          OMA Device APIs

Through OMA enablers focused on device APIs, we can enable automotive (Auto) 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 upon the Generic Open Terminal API (GotAPI) \[GotAPI\] enabler framework described in section 6.2.

5.2.1          Example Use Cases for OMA Device API use in the Auto Environment

OMA device APIs can enable synergy between app use cases in the Auto environment (e.g. driver safety, IoT, etc) and evolving Auto technologies. For example:

• 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 basic 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 are illustrated 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 (PAUL B / TED)

6.1.1 Overview and objective of project...

6.1.2 API's defined

6.2 OMA GotAPI and DWAPI

This section introduces the OMA Generic Open Terminal API Framework (GotAPI) v1.1 enabler, and the GotAPI-based Device WebAPI (DWAPI) v1.0 \[DWAPI\] enabler. At a high level, GotAPI leverages widely supported Web technologies to enable a GotAPI server host (e.g. the Auto system) to provide an easy-to-integrate framework for apps to register and authenticate, discover available API services, access those API services, and secure the data exchanged between apps and other devices/services accessed through the GotAPI server. Without GotAPI, apps typically would have be designed to support the specific methods through which other devices/services are accessed, e.g. a variety of APIs, protocols, and connection bearers.

DWAPI builds upon GotAPI in defining Web-based APIs used to access healthcare devices through IEEE-specified interfaces. Additional APIs such as for 3D printer access are in development at OMA.

Overview: Various External Devices Working with Apps Through GotAPI

GotAPI Architecture

GotAPI defines how apps and the GotAPI enabler components interact through the interfaces illustrated below:

• GotAPI-1: enables applications to make API requests and receive responses. This interface is generically specified by GotAPI, as GotAPI-based API specifications will define specific request/response transactions that can be utilized in host devices based upon the available interface technologies, payload protocols, and their applicable design patterns. These options include:
  • The interface technologies TLS 1.2, HTTP/1.1, HTTP/2, Server-Sent Events
  • The design patterns REST and JSON, such as JSON-RPC
  • A Temporary Server Feed (TSF) mechanism for binary data responses and triggering a different protocols
  • The initiation of the asynchronous messaging interface, GotAPI-5, to use WebSocket

• GotAPI-2: enables applications to obtain authorization for access to GotAPI-based APIs. This interface is fully specified by GotAPI, being a common (though optionally used) support function for all GotAPI-based APIs. GotAPI-2 supports bindings and request/response transactions that can be utilized in host devices based upon the available interface technologies. These options include the interface technologies TLS 1.2, HTTP/1.1, HTTP/2, and URI scheme handling. The GotAPI-2 interface is based upon the concepts of OAuth, though with different semantics as necessary for adaptation to the available interface technologies.

• GotAPI-3: enables the remote provisioning of API access authorizations through a policy management function, which may include one or more of:
  • OMA Device Management, using a Managed Object (MO) to be defined in a future version of the GotAPI enabler
  • An implementation-specific policy management service

• GotAPI-4: enables Extension Plug-Ins for external devices and internal enablers through which they communicate with the GotAPI Server. Note that host-device-internal enablers/applications may also be connected to GotAPI servers directly in implementation specific ways without using the GotAPI-4 interface and Extension Plug-Ins.

  The Extension Plug-Ins are independent applications. They are the mediators between the GotAPI Server, and external devices and internal enablers/applications. Typically, there are expected to be multiple Extension Plug-In applications installed on a device by the user or preinstalled on the device.

  The GotAPI-4 interface provides the following functions with respect to Extension Plug-Ins:

  1. Plug-In Discovery: GotAPI-4 Plug-In Discovery enables the GotAPI Server to discover the targeted Extension Plug-In which an application wants to access and communicate with.
  2. Service Discovery: GotAPI-4 Service Discovery enables the GotAPI Server to find all the services provided by an Extension Plug-In. In this context, the "service" means an external device or a function provided by an internal enabler through an Extension Plug-In. The Service Discovery provides not only the list of services but also the availability of each service at the time.
  3. Approval: GotAPI-4 Approval is the function to ensure security, especially to protect users’ data and privacy from unwanted exploits, so that the users can safely use the application with external devices and enablers that are connected via Extension Plug-Ins.
  4. Data Forwarding: GotAPI-4 Data Forwarding is the function that enables an application to communicate with the targeted Extension Plug-In through the GotAPI Server. Data Forwarding takes place after Plug-In Discovery (optional) and Approval processes have been successfully completed. GotAPI-4 Data Forwarding uses the “pass-through” mechanism, so that the application can access and communicate with the APIs that (i) are implemented in the Extension Plug-In and (ii) expose the features of the external devices or internal enablers.

• 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

6.3 LWM2M (AMIT S / PADHU)

LWM2M

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).

Key features

Some of the abilities which are helpful from connected car perspective from LWM2M are the following:

• Low data byte transmission with allowance for client to sleep (i.e., non-continuous communication)
• Suitable for constrained devices (hence reduced footprint for reduced CAPEX for car manufacturers)
• Several objects can be reported in one message using simple content types like TLV, JSON and single objects with simple text content type
• Ability to support a range of solutions through pre-defined objects (connected car objects/resources)
• Client (connected car) could send notifications to server based on defined trigger events e.g. periodic reporting, reporting upon change of value, reporting based on thresholds reached. This is key as it gets past the poll and/or notification model
• LWM2M by default works with 3GPP technologies hence easier integration with telecommunication operators

Core Interfaces

The core interfaces between the server and the client are categorized into:

• Bootstrap
• Client Registration
• Device management and service enablement
• Information Reporting

Features

OMA LWM2M is unique in that aspect, that it converges both management and application control functionality within one communication session allowing for efficient handling of IoT devices. Since OMA LWM2M protocol is based on IETF CoAP, the OMA LWM2M protocol allows different transport bindings (e.g., UDP, SMS) and is secured using IETF DTLS protocol.

The device management features defined by OMA for release 1.0 of LWM2M are:

• Access control on the specific contents that could be handled remotely by different entities
• Software / 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 in terms of communication characteristics over the air

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...

6.5.2 API's defined

6.6 OCF IoTivity (SANJEEV)

6.6.1 Overview and objective of project

The Open Connectivity Foundation (OCF), a global consortium of leading companies focused on creating a standard for interoperable devices and services was founded in 2014. The OCF approach has three key deliverables:

1. An Open Specification: Open Connectivity Foundation
2. An Open Source Implementation for OCF members: IoTivity
3. A membership driven certification program:  OCF certification

OCF's initial efforts to venture into the Connected Vehicle space involved analysis of the Connected Vehicle – Smart Home crossover use cases based on consumer interests and strategy reports. We also took a look at the contemporary demonstrations shown in trade shows. Based on the above, we consolidated the list of use cases, under the following broad categories.

1. Home Energy Management
2. Security System Interaction
3. Vehicle Location
4. Smart Home device status
5. Vehicle Control from Smart Device
6. Smart Device Control from Vehicle
7. Electric Vehicle Time-of-Use Charging
8. Entertainment
9. Third party application service integrations

While most of these solutions are realized through joint collaborative efforts between industry partners, there is in general a lack of open source alternatives which stifles innovation. Samsung Open Source Group and Jaguar Land Rover Open Source Technology Center, followed an open collaboration model under the Genivi Alliance Incubator projects initiative. One of the key objectives of this partnership was to use completely open source software and commodity off-the-shelf hardware, to realize the use cases (in bold), with minimal resources and time.

6.6.2 Stakeholders : Roles, Responsibilities and Expectations

We understood that, for an IoT ecosystem to flourish, the architecture should be flexible enough for the key stakeholders to bring in their value proposition and make it easy for consumption by the rest of the ecosystem. Early adopters stand to gain significantly in such an ecosystem play and this typically tends to create ecosystem mono/duo polies. From the beginning our goal was to identify the key stakeholders of the IoT ecosystem and provide an architecture that helps them integrate their existing solutions/software stacks, with as little friction as possible. We identified the following limited roles and expectations.

6.6.3 How RVI models Vehicle Information as a Spec.

As explained in the section <<RVI Section>>, RVI seperates the vehicle service data representation from the transport. The "Vehicle Signal Specification" is a simple, flexible and scalable format to represent vehicle signals inside a vehicle using a simple tree like hierarchy. RVI Core stack handles the software infrastructure needed to discover other RVI endpoints and handling of end to end delivery of messages, i.e. the transport agnostic communications infrastructure. RVI is capable of handling message delivery over Bluetooth, WiFi, LTE and SMS.

6.6.4 A Flexible Service Architecture for IoT

 Within the IoTivity open source project we developed a MEAN (Mongo-Express-Angular-Node) stack based framework for bringing web services and IoT devices together to realize our use cases and to understand the issues while we attempt to integrate these domains. We defined an abstract service metadata model  as a way for services to be represented within an IoT network and to move the execution of the business logic from the cloud to inside the IoT network or automobile respectively. Only the serive inThis approach helped us to represent ANY service in a consistent manner, thereby easing the handling of protocol, ownership, privacy, security and ease of use concerns.

6.6.5 Vehicle Connectivity as a Service? 

Thinking about the connectivity to the vehicle as a service helped us to model the use case in terms of discovering and invoking services provided by the vehicle. This made the task of realizing the use cases to be simply a matter of service invocation rather than dealing with protocol details and intricacies. These details are best handled by the software stack dictated by the automaker or Tier-1 service provider. It addresses the key issue of who owns this part of the stack, which is always a point of concern in commercial deployments.

 In this context, the RVI Expert Group within Genivi had an open source software in place for many important vehicle connectivity use cases which we could readily use for representing vehicle connectivity as a service within the WSI architecture. This extends the connectivity services hosted by the vehicle to be accessed by IoT devices inside the smart home. 

6.6.6 Demo Showcase Setup

 The RVI-OCF Gateway basically handled all the service specific details. 

6.6.7 Message Flow

1. The RVI service node hosted in the vehicle HMI running on GDP, connects via the cloud to the home gateway.
2. The WSI gateway also runs an RVI node (this is currently an implementation limitation which can be removed once native RVI libraries are implemented)
3. RVI provides many means to access services and we decided to use websockets.
4. The WSI gateway connects via websockets to the local RVI node which then talks to the remote RVI node.
5. Connection & remote RVI service discovery is handled purely by RVI and the WSI Gateway need not worry about the internals.

After connecting to the remote RVI node, the WSI Gateway simply translates between the service definitions provided by Remote RVI Service Node into corresponding OCF device control commands based on application developer logic. This mapping is totally independent of how the gateway functions and thus provides maximum flexibility to implement any rules or service logic you can come up with, depending on the scenario. In this case, the service was controlling the HVAC parameters of a vehicle. In future, we could extend the service to be whatever the situation demands. Another major benefit of this approach is that the IoT device data is never transmitted out of the home. Similarly, the vehicular data is never transmitted over the cloud. This provides a clear separation of the data across the domains, namely smart home and vehicle with a reduced security and privacy risk – while giving total control over the customer data to the existing services. In addition to the above demos and use cases, we also have made OCF stack called as IoTivity, as part of the GDP and AGL (Automotive Grade Linux), so that interested developers will now be able to implement use cases.

6.6.8 Standardization Efforts

6.6.9 Related Links

All of our source code is published under

 https://github.com/GENIVI/meta-genivi-ocf-demo/tree/master

 http://git.s-osg.org/ocf-automotive-sampleapps/

 A complete video demonstration of WSI at work is presented here.

 https://www.youtube.com/watch?v=351m-GrRSNE

 The complete blog is presented here.

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

6.6.2 API's defined

Please focus on overall expected penetration of OSS work in IoT market

6.7 OMA-DM and vehicle security (YAIR N)

6.7.1 Overview and objective of project...

6.7.2 API's defined

7. Analysis and recommendations to achieve interoperability (JOEL H)

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/