...

2.     References 

3.     Terminology and Conventions

...

3.3     Abbreviations

4.     Introduction

...

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, or running in connected devices. 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, and the Web Device API (WDAPI) enabler based upon GotAPI. 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.

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

...

• 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
• Such Auto system apps or user smartphone 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 or in connected devices:, e.g.

• the Auto system can offer vehicle information/services to apps running in an Auto Web runtime environment, or running in connected devices
• the Auto system can offer interfaces (e.g. bluetooth, WiFi, ...) through which apps in GotAPI-enabled devices (e.g. smartphones) can access vehicle information/services

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

...

• 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.1 Overview and objective of project...

6.1.2 API's defined

6.2 OMA GotAPI

...

and DWAPI

This section introduces the OMA 

...

6.2.1 Overview and objective of project...

The Generic Open Terminal API Framework (GotAPI) v1.1 enabler, and the GotAPI-based Device WebAPI (DWAPI) v1.0 \[DWAPI\] enabler.. (editing in progress) 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

Image Added

6.3 LWM2M (AMIT S / PADHU)

6.3.1 Overview and objective of project...

...