In-vehicle/Roadmap/API

Revision as of 10:35, 27 April 2011

Automotive API

To enable applications and software functionality specific to a vehicle context the MeeGo IVI software stack needs to implement an API that allows applications to access vehicle data and execute operations. The MeeGo IVI software stack essentially extends MeeGo Core and consequently the IVI APIs are extensions of the MeeGo Core APIs.

The API most likely will have multiple layers abstracting applications from the underlying specifics of the vehicle architecture. The latter will definitely differ from make to make and most likely within model lines of the same make and also between generations of the same model of a particular make.

The API layer provides vehicle data in a generalized form through methods such as getVehicleSpeed(), getFuelLevel(), getAverageFuelConsumption() etc. as well as executing function such as setRadioTuner(band, frequency), turnOnHeadlights(), lockDoor(doors), etc. An application can make use of these APIs directly.

Another layer of abstraction is the application framework layer that combines operations across multiple MeeGo APIs. An example could be a function providing range information based on the fuel level, the average consumption and the current vehicle position.

API Requirements

Functionality

The idea of the API is to treat vehicle data that can be retrieved and vehicle functions controlled through these APIs in an abstract manner. The implementation details of the API functionality e.g. where to get a particular piece of data from such as the fuel level or to execute a particular function e.g. closing a window are treated by underlying software layer and are transparent to the API. The developer using the API should not need to have any prior knowledge about the vehicle itself for instance what make and model it is.

Since not all vehicles will implement all of the APIs it is necessary that software using the API has methods to determine during runtime what APIs are actually implemented. The most straight-forward way is that an API returns a specific value when it is not implemented e.g. API_NOT_DEFINED. A calling software module would simply invoke the API and react accordingly if the API returns API_NOT_DEFINED. However, that may not be the most efficient way since dependent on what API functionality is available software modules may want to configure themselves differently. The most obvious case would be an application that changes its appearance in the UX according to the available functionality. Hence, it is desirable that the API implements reflection that allows querying its functionality during runtime. That can be achieved via API registration or other mechanisms.

If an API is implemented it must adhere to the API specification:

• Parameters are required to have the specified types and must accept values within the specified range.
• Return values must be of the specified type and only return values within the specified range.
• Only the specified exceptions (if exceptions are used at all by the API) must be thrown.

Security

Some APIs will require access control to restrict execution to calling software modules with the correct privileges. MeeGo IVI should rely on the security mechanisms provided by MeeGo and extend them where necessary.

API Functional Groups and Functions

This section list proposed APIs and places them into functional groups.