MeeGo wiki - User contributions [en]

In-vehicle/Roadmap/Vehicle Network API

2011-07-13T08:08:03Z

Jsbach86: /* SDK Architecture */

== IVI Architecture for embedding CAN Network ==
=== Main Purpose ===
Accessing vehicle network to obtain vehicle data and to control certain vehicle functionalities is the essential feature of IVI system.

=== Possible Use Cases ===
* Smart Drive-Thu : Franchised restaurants can provide App, which finds nearby restaurant and helps to select menu and place order. It may set the destination of navigation to it automatically, and report the order and expected arrival time to the restaurants.
* Pay-As-You-Drive : Insurance companies can provide App, which reports the driver’s driving habits with his consent. The data can be used to discount insurance fee.
* Smart Routing Navigation : A driver can download the premium navigation App. It may provide server-based routing, which can perform complicated computation by using many conditions such as statistical data, current traffic status and traffic demands when the car will pass by the road. The reliable data can be collected by cars which use the navigation App.
* The more data we open to the public, the more convenient applications can be developed. It’s the key to make so-called ‘Smart Car’.

=== Overview of the plan ===
We plan to make the standardized interface using D-Bus and Qt IVI package
* '''D-Bus''' need to be standardized for realizing security framework for user application. MeeGo is using the security mechanism based on D-Bus.
* '''Qt IVI package''' will provide convenience to App developers by Qt characteristics such as ‘signal slot mechanism’ and ‘cross-platform’.

== Candidate Architecture ==
=== Architecture Proposal ===

[[File:MeeGoIVI_Arch1.jpg|MeeGo IVI Architectures according to two popular system configurations]]

CAN is being used widely for IVI. The diagrams above are two popular system configurations. Because of the real-time requirements about CAN communication, Configuration #1 is more preferred even though it costs more.

There're a few commercial CAN stacks. It's not only CAN chipset driver, but it also includes more functions such as filtering and parsing messages. Since each OEMs uses its own CAN messages, CAN stack is OEM-specific part and seems not easy to be standardized.

'''CAN Adapter''' communicates with CAN stack and delivers it on the specific D-Bus. It translates OEM specific messages to standardized D-Bus objects. It’s a just mapping or simple conversion, thus it’ll not be so difficult if we define D-Bus standard well-aligned with the existing OEM messages.

In the case of configuration #1, SPI or UART is used for communication between Host CPU and MICOM. In normal, OEMs use their own protocol for this communication. In the case of configuration #2, CAN Adapter and stack will be merged into one process.
This approach allows OEM not to change many critical parts such as their own CAN messages or hardware configuration to adopt MeeGo. The only thing they have to do is delivering its own vehicle data on the D-Bus as standardized format.

'''Qt IVI''' is a package of libraries related to IVI. Car-System is a library to provide user application to access vehicle functionality via Qt style APIs. Although user application can access D-Bus directly, the library can help lightened the load of D-Bus coding. Furthermore, it provides convenience of Qt such as ‘signal slot mechanism’ and ‘cross-platform’.

=== Another Possible Structure for after market IVI ===
[[File:MeeGoIVI_Arch2.jpg|MeeGo IVI can be used when using OBD dongle for accessing vehicle network]]

It’s for the After-Market IVI system. In this case, IVI system can access vehicle data via OBD dongle.
Usually, OBD dongle provides vehicle data via wireless such as Bluetooth.
In this case, CAN Adapter should have a functionality to communicate with OBD Dongle. It may use the existing BT stack to BT communication and add functions on the BT profile level.

=== Consideration for interoperability with GENIVI ===
[[File:MeeGoIVI_Arch3.jpg|Consideration for interoperability with GENIVI]]

GENIVI plans to standardize the infrastructure to interconnect 'Host CPU' and 'MICOM' including CAN communication in the configuration #1.
That either D-Bus or Qt IVI or both could be implemented on top of this infrastructure.
We need to keep working closely with GENIVI to align with it.

== SDK Architecture ==
[[File:MeeGoIVI_Arch_SDK.jpg|To help App. Developer working without real CAN network]]

Open platform should consider the development environment for public developers when designing its architecture. Especially, accessing vehicle network is difficult part for developers because it’s hard to test it without expensive simulation equipment.
Thus, convenient simulation environment is important to encourage developers to develop various IVI Apps.

The suggested architecture can satisfy this requirement by providing '''CAN Adapter Emulator''' and '''Car Emulator'''.
User can send and receive vehicle data by using Car Emulator. It doesn’t need to use real CAN type message. The purpose of SDK is to provide convenience to App Developer not CAN Adapter developer. An App developer is interested in whether his App can work as he intended or not when a certain vehicle data comes.
Even so, the CAN Adapter developer can refer CAN Adapter Emulator code to make a real one.

CAN Adapter Emulator and Car Emulator use TCP/IP. It can make Car Emulator work both in the same PC and in another PC without changing code.
The first one is the usual App development environment for single developer. The second one using additional laptop can help to test or demonstrate an entire IVI system without connecting to the real vehicle. The third one is for developer who works on Non-Linux OS. Since Qt provides cross-platform environment, it’s also possible model on the assumption that we makes windows or Mac version of Qt IVI package.

In-vehicle/Roadmap/Vehicle Network API

2011-07-13T07:22:51Z

Jsbach86:

== IVI Architecture for embedding CAN Network ==
=== Main Purpose ===
Accessing vehicle network to obtain vehicle data and to control certain vehicle functionalities is the essential feature of IVI system.

=== Possible Use Cases ===
* Smart Drive-Thu : Franchised restaurants can provide App, which finds nearby restaurant and helps to select menu and place order. It may set the destination of navigation to it automatically, and report the order and expected arrival time to the restaurants.
* Pay-As-You-Drive : Insurance companies can provide App, which reports the driver’s driving habits with his consent. The data can be used to discount insurance fee.
* Smart Routing Navigation : A driver can download the premium navigation App. It may provide server-based routing, which can perform complicated computation by using many conditions such as statistical data, current traffic status and traffic demands when the car will pass by the road. The reliable data can be collected by cars which use the navigation App.
* The more data we open to the public, the more convenient applications can be developed. It’s the key to make so-called ‘Smart Car’.

=== Overview of the plan ===
We plan to make the standardized interface using D-Bus and Qt IVI package
* '''D-Bus''' need to be standardized for realizing security framework for user application. MeeGo is using the security mechanism based on D-Bus.
* '''Qt IVI package''' will provide convenience to App developers by Qt characteristics such as ‘signal slot mechanism’ and ‘cross-platform’.

== Candidate Architecture ==
=== Architecture Proposal ===

[[File:MeeGoIVI_Arch1.jpg|MeeGo IVI Architectures according to two popular system configurations]]

CAN is being used widely for IVI. The diagrams above are two popular system configurations. Because of the real-time requirements about CAN communication, Configuration #1 is more preferred even though it costs more.

There're a few commercial CAN stacks. It's not only CAN chipset driver, but it also includes more functions such as filtering and parsing messages. Since each OEMs uses its own CAN messages, CAN stack is OEM-specific part and seems not easy to be standardized.

'''CAN Adapter''' communicates with CAN stack and delivers it on the specific D-Bus. It translates OEM specific messages to standardized D-Bus objects. It’s a just mapping or simple conversion, thus it’ll not be so difficult if we define D-Bus standard well-aligned with the existing OEM messages.

In the case of configuration #1, SPI or UART is used for communication between Host CPU and MICOM. In normal, OEMs use their own protocol for this communication. In the case of configuration #2, CAN Adapter and stack will be merged into one process.
This approach allows OEM not to change many critical parts such as their own CAN messages or hardware configuration to adopt MeeGo. The only thing they have to do is delivering its own vehicle data on the D-Bus as standardized format.

'''Qt IVI''' is a package of libraries related to IVI. Car-System is a library to provide user application to access vehicle functionality via Qt style APIs. Although user application can access D-Bus directly, the library can help lightened the load of D-Bus coding. Furthermore, it provides convenience of Qt such as ‘signal slot mechanism’ and ‘cross-platform’.

=== Another Possible Structure for after market IVI ===
[[File:MeeGoIVI_Arch2.jpg|MeeGo IVI can be used when using OBD dongle for accessing vehicle network]]

It’s for the After-Market IVI system. In this case, IVI system can access vehicle data via OBD dongle.
Usually, OBD dongle provides vehicle data via wireless such as Bluetooth.
In this case, CAN Adapter should have a functionality to communicate with OBD Dongle. It may use the existing BT stack to BT communication and add functions on the BT profile level.

=== Consideration for interoperability with GENIVI ===
[[File:MeeGoIVI_Arch3.jpg|Consideration for interoperability with GENIVI]]

GENIVI plans to standardize the infrastructure to interconnect 'Host CPU' and 'MICOM' including CAN communication in the configuration #1.
That either D-Bus or Qt IVI or both could be implemented on top of this infrastructure.
We need to keep working closely with GENIVI to align with it.

== SDK Architecture ==
[[File:MeeGoIVI_Arch_SDK.jpg|To help App. Developer working without real CAN network]]

Open platform should consider the development environment for public developers when designing its architecture. Especially, accessing vehicle network is difficult part for developers because it’s hard to test it without expensive simulation equipment.
Thus, convenient simulation environment is important to encourage developers to develop various IVI Apps.

The suggested architecture can satisfy this requirement by providing '''CAN Adapter Emulator''' and '''Car Emulator'''.
User can send and receive vehicle data by using Car Emulator. It doesn’t need to use real CAN type message. The purpose of SDK is to provide convenience to App Developer not CAN Adapter developer. An App developer is interested in whether his App can work as he intended or not when a certain vehicle data comes.
Even so, the CAN Adapter developer can refer CAN Adapter Emulator code to make a real one.

Can Adapter Emulator and Car Emulator use TCP/IP. It can make Car Emulator work both in the same PC and in another PC without changing code.
The first one is the usual App development environment for single developer. The second one using additional laptop can help to test or demonstrate an entire IVI system without connecting to the real vehicle. The third one is for developer who works on Non-Linux OS. Since Qt provides cross-platform environment, it’s also possible model on the assumption that we makes windows or Mac version of Qt IVI package.

File:MeeGoIVI Arch SDK.jpg

2011-07-13T07:07:37Z

Jsbach86: MeeGo IVI SDK Architecture

MeeGo IVI SDK Architecture

File:MeeGoIVI Arch3.jpg

2011-07-13T07:07:00Z

Jsbach86: Consideration for interoperability with GENIVI

Consideration for interoperability with GENIVI

File:MeeGoIVI Arch2.jpg

2011-07-13T07:06:32Z

Jsbach86: Another Possible Architecture for after market IVI

Another Possible Architecture for after market IVI

File:MeeGoIVI Arch1.jpg

2011-07-13T07:05:15Z

Jsbach86: MeeGo IVI Architecture according to two popular system configurations

MeeGo IVI Architecture according to two popular system configurations

In-vehicle/Roadmap/Vehicle Network API

2011-07-13T06:34:10Z

Jsbach86: Created page with "== IVI Architecture for embedding CAN Network == === Why we’re going to do this? === Accessing vehicle network to obtain vehicle data and to control certain vehicle functionali..."

== IVI Architecture for embedding CAN Network ==
=== Why we’re going to do this? ===
Accessing vehicle network to obtain vehicle data and to control certain vehicle functionalities is the essential feature of IVI system.

=== Possible Use Cases ===
* Smart Drive-Thu : Franchised restaurants can provide App, which finds nearby restaurant and helps to select menu and place order. It may set the destination of navigation to it automatically, and report the order and expected arrival time to the restaurants.
* Pay-As-You-Drive : Insurance companies can provide App, which reports the driver’s driving habits with his consent. The data can be used to discount insurance fee.
* Smart Routing Navigation : A driver can download the premium navigation App. It may provide server-based routing, which can perform complicated computation by using many conditions such as statistical data, current traffic status and traffic demands when the car will pass by the road. The reliable data can be collected by cars which use the navigation App.
* The more data we open to the public, the more convenient applications can be developed. It’s the key to make so-called ‘Smart Car’.

=== How to enable applications to access vehicle network? ===
We plan to make the standardized interface using D-Bus and Qt IVI package
* '''D-Bus''' need to be standardized for realizing security framework for user application. MeeGo is using the security mechanism based on D-Bus.
* '''Qt IVI package''' will provide convenience to App developers by Qt characteristics such as ‘signal slot mechanism’ and ‘cross-platform’.

== Candidate Architecture ==

CAN is being used widely for IVI. The diagrams above are two popular system configurations. Because of the real-time requirements about CAN communication, Configuration #1 is more preferred even though it costs more.

There're a few commercial CAN stacks. It's not only CAN chipset driver, but it also includes more functions such as filtering and parsing messages. Since each OEMs uses its own CAN messages, CAN stack is OEM-specific part and seems not easy to be standardized.

'''CAN Adapter''' communicates with CAN stack and delivers it on the specific D-Bus. It translates OEM specific messages to standardized D-Bus objects. It’s a just mapping or simple conversion, thus it’ll not be so difficult if we define D-Bus standard well-aligned with the existing OEM messages.

In the case of configuration #1, SPI or UART is used for communication between Host CPU and MICOM. In normal, OEMs use their own protocol for this communication. In the case of configuration #2, CAN Adapter and stack will be merged into one process.
This approach allows OEM not to change many critical parts such as their own CAN messages or hardware configuration to adopt MeeGo. The only thing they have to do is delivering its own vehicle data on the D-Bus as standardized format.

'''Qt IVI''' is a package of libraries related to IVI. Car-System is a library to provide user application to access vehicle functionality via Qt style APIs. Although user application can access D-Bus directly, the library can help lightened the load of D-Bus coding. Furthermore, it provides convenience of Qt such as ‘signal slot mechanism’ and ‘cross-platform’.

=== Another Possible Structure for after market IVI ===

It’s for the After-Market IVI system. In this case, IVI system can access vehicle data via OBD dongle.
Usually, OBD dongle provides vehicle data via wireless such as Bluetooth.
In this case, CAN Adapter should have a functionality to communicate with OBD Dongle. It may use the existing BT stack to BT communication and add functions on the BT profile level.

=== Consideration for interoperability with GENIVI ===

GENIVI plans to standardize the infrastructure to interconnect 'Host CPU' and 'MICOM' including CAN communication in the configuration #1.
That either D-Bus or Qt IVI or both could be implemented on top of this infrastructure.
We need to keep working closely with GENIVI to align with it.

== SDK Architecture ==

Open platform should consider the development environment for public developers when designing its architecture. Especially, accessing vehicle network is difficult part for developers because it’s hard to test it without expensive simulation equipment.
Thus, convenient simulation environment is important to encourage developers to develop various IVI Apps.

The suggested architecture can satisfy this requirement by providing '''CAN Adapter Emulator''' and '''Car Emulator'''.
User can send and receive vehicle data by using Car Emulator. It doesn’t need to use real CAN type message. The purpose of SDK is to provide convenience to App Developer not CAN Adapter developer. An App developer is interested in whether his App can work as he intended or not when a certain vehicle data comes.
Even so, the CAN Adapter developer can refer CAN Adapter Emulator code to make a real one.

Can Adapter Emulator and Car Emulator use TCP/IP. It can make Car Emulator work both in the same PC and in another PC without changing code.
The first one is the usual App development environment for single developer. The second one using additional laptop can help to test or demonstrate an entire IVI system without connecting to the real vehicle. The third one is for developer who works on Non-Linux OS. Since Qt provides cross-platform environment, it’s also possible model on the assumption that we makes windows or Mac version of Qt IVI package.

In-vehicle/Roadmap

2011-07-13T06:20:41Z

Jsbach86: /* High-level Roadmap */

== High-level Roadmap ==

The big picture:
* [[In-vehicle/Roadmap/FeatureScope|Feature Scope]]
* [[In-vehicle/Roadmap/SystemArchitecture|System Architecture]]

Details on Roadmap items:
* [[In-vehicle/Roadmap/AutomotiveNetworking|Automotive Networking]]
* [[In-vehicle/Roadmap/AudioManagement|Audio management]]
* [[In-vehicle/Roadmap/UX|User Experience]]
* [[In-vehicle/Roadmap/API|API]]
* [[In-vehicle/Roadmap/Vehicle Network API|Vehicle Network API]]
* App Store Demonstration
* CE Device connectivity
* [[In-vehicle/Roadmap/Navigation|Navigation]]
* Auto UX
* BSP/ARM-support

To help the discussion of the road map content, there is a separate overview of the [[In-vehicle/Roadmap/FeatureScope|potential feature scope]] for In-Vehicle Infotainment.

== Feature list from Bugzilla ==
Feature suggestions and planning is tracked in the MeeGo bugzilla system.

[https://bugs.meego.com/enter_bug.cgi?product=MeeGo%20IVI%20Features Submit new MeeGo IVI feature suggestions]

New feature suggestions need design and development resources to be committed before they become "ACCEPTED".

[https://bugs.meego.com/report.cgi?x_axis_field=bug_status&y_axis_field=version&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&rep_platform=Automotive&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Current status of features suggested or planned for MeeGo IVI]

== MeeGo 1.2 Target Features ==
The MeeGo 1.2 development milestones are:
* November 1, 2010 MeeGo 1.2 merge window open
* January 20, 2011 MeeGo 1.2 Feature freeze (Alpha finish, Beta start)
* March 20, 2011 MeeGo 1.2 Release Candidate start
* April 29, 2011 MeeGo 1.2 Release branch created
* May 19, 2011 MeeGo 1.2.0 Final Release

The new features planned for the MeeGo IVI 1.2 release are:
* Terminal Mode from Nokia [https://bugs.meego.com/show_bug.cgi?id=8704 Feature 8704]
* Integration of EMGD graphics [https://bugs.meego.com/show_bug.cgi?id=6863 Feature 6863] [http://bugs.meego.com/show_bug.cgi?id=8815 Feature 8815]
* Integration of TopCliff/Crown Bay drivers [https://bugs.meego.com/show_bug.cgi?id=6862 Feature 6862]
* Integration of Crossville ML7213/OKI IVI IOH drivers [https://bugs.meego.com/show_bug.cgi?id=12050 Feature 12050]
* Updating IVI Home screen with new layout for the task launch menus and porting from QT to QML.
* Updating sample apps (browser, contacts, video player, photo player, music player, settings) from MeeGo Touch Framework based (MTF) to QML based.

[[Category:IVI]]

In-vehicle/Roadmap/API

2011-07-05T09:20:45Z

Jsbach86: /* Car-Systems */

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

[[File:MeeGo-IVI-Stack.png|800px|MeeGo IVI Stack]]

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.

=== Car-Systems ===

[[Category:IVI]]

{| x:str border=1 cellpadding=0 cellspacing=0
| rowspan=2 | Group
| rowspan=2 | Function
| colspan=2 | Parameter
| rowspan=2 | Operation
|-
| Type
| Contents
|-
| rowspan=5 | Application 
Interoperability
| Supported Features
| Integer
| Bit setting per each APIs
| Get
|-
| Car Manufacturer
| String
| 　
| Get
|-
| WMI
| String
| World Manufacturer Identifier as defined by SAE. 3 characters.　
| Get
|-
| Car Model Name
| String
| 　
| Get
|-
| VIN
| String
| Vehicle Identification Number as defined by ISO 3779. 17 characters.　
| Get
|-
| rowspan=5 | Car Information
| Car Type
| Enum
| Sedan, Coupe, Cabriole, Roadster, SUV, Truck
| Get
|-
| Door Type
| Compound
| # of doors in first row, second row, third row
| Get
|-
| Engine Type
| Enum
| Gasoline, Diesel, Hybrid, Electric
| Get
|-
| Transmission Gear Type
| Enum
| Auto/Manual
| Get
|-
| Wheel Information
| Compound
| Radius of Wheel, Wheel Track (for GPS Dead Reckoning)
| Get
|-
| rowspan=16 | Running Status
| Vehicle Power Mode
| Enum
| Off / Acc / Run / Ignition
| Get / Noti
|-
| Speedometer
| Integer
| km/h or mph
| Get / Noti
|-
| Engine Speed
| Integer
| rpm
| Get / Noti
|-
| Trip meter
| Integer
| km or mile
| Get / Noti
|-
| Transmission Gear Status
| Enum
| 0=N,1,2,3,4,5,6,7,8,9,10, 64=R, 128=Auto
| Get / Noti
|-
| Cruise Control Status
| Compound
| Activate/Deactivate, Speed
| Get / Noti
|-
| Wheel Brake
| Boolean
| Idle, Engaged, Malfunction
| Get / Noti
|-
| Lights Status
| Compound
| On / Off per each light (Head, Turn Right, Turn Left, Brake, Fog, Hazard Signal, Parking)
| Get / Noti
|-
| Interior Lights Status
| Compound
| On / Off per each light (Driver, Passenger, Center)
| Get / Noti
|-
| Horn
| Boolean
| On / Off
| Get / Noti
|-
| Chime
| Boolean
| On / Off
| Get / Noti
|-
| Fuel
| Integer
| Remaining % (Remaining, Total Capacity in liter or gallon)
| Get / Noti
|-
| Engine Oil
| Compound
| Remaining %, Temperature
| Get / Noti
|-
| Engine Coolant
| Compound
| Level, Temperature, Pressure
| Get / Noti
|-
| Steering Wheel Angle
| Integer
| (for GPS Dead Reckoning)
| Get / Noti
|-
| Wheel Tick Sensor
| Compound
| Left Wheel Rotation Counter, Right Wheel Rotation Counter (for GPS Dead Reckoning)
| Get
|-
| rowspan=6 | Maintenance
| Odometer
| Integer
| km/h or mph
| Get / Noti
|-
| Transmission Oil
| Integer
| Remaining %
| Get / Noti
|-
| Brake Fluid
| Integer
| Remaining %
| Get / Noti
|-
| Washer Fluid
| Integer
| Remaining %
| Get / Noti
|-
| Battery Status
| Compound
| Voltage, Current
| Get / Noti
|-
| Tire Pressure
| Compound
| PSI or Status (Normal, Low) per each tire (front left, front right, rear left, rear right)
| Get / Noti
|-
| rowspan=10 | Personalization
| Key ID (Driver ID)
| Enum
| 　
| Get
|-
| Language
| Enum
| English, Spanish, French, …
| Get / Set
|-
| Measurement System
| Boolean
| Km (litter), mile (gallon)
| Get / Set
|-
| Mirror
| Compound
| 2byte(Tilt, Pan) position per each mirror (driver side, passenger side, inside mirror)
| Get / Set
|-
| Steering Wheel Position
| Compound
| Level per each part (slide, tilt)
| Get / Set
|-
| Driving Mode
| Enum
| Comfort, Auto, Sport, Eco, Manual
| Get / Set
|-
| Driver Seat Position
| Compound
| Level per each part (recline seatback, slide, cushion height, headrest, back cushion, side cushion)
| Get / Set
|-
| Passenger Seat Position
| Compound
| Level per each part (recline seatback, slide, cushion height, headrest, back cushion, side cushion)
| Get / Set
|-
| Dashboard Illumination
| Enum
| % of Illumination ( 0 : Darkest, 100 : Brightest)
| Get / Set
|-
| Generated Car Sound Mode
| Enum
| Normal, Quiet, Sportive
| Get / Set
|-
| rowspan=10 | Driving Safety
| Antilock Braking System
| Enum
| Available (Equipped), Idle, Engaged
| Get / Noti
|-
| Traction Control System
| Enum
| Available (Equipped), On/Off
| Get / Noti
|-
| Vehicle Top Speed Limit
| Integer
| km/h or mph (0 means no limitation)
| Get / Set
|-
| Airbag Status
| Compound
| Activate/Deactivate/Deployment per each airbag (driver, passenger, side)
| Get / Noti
|-
| Door Open Status
| Compound
| Open/Ajar/Close per each door (driver, passenger, rear left, rear right, trunk, fuel filler cap, hood)
| Get / Noti
|-
| Door Lock Status
| Compound
| Lock/Unlock per each door (driver, passenger, rear left, rear right)
| Get / Noti / Set
|-
| Occupants Status
| Compound
| Type (Adults/Child/Vacant) per each seat (driver, passenger, rear left, rear right)
| Get / Noti
|-
| Seat Belt
| Compound
| Fasten or not per each seat (driver, passenger, rear left, rear right)
| Get / Noti
|-
| Window Lock
| Compound
| Lock/Unlock per each window (driver, passenger, rear left, rear right)
| Get / Noti / Set
|-
| Obstacle Distance
| Compound
| Sensor Status (available or not), Distance per each sensor (Position #)
| Get / Noti
|-
| rowspan=3 | Parking
| Security Alert
| Enum
| Available (Equipped), Idle, Activated, Alarm Detected
| Get / Noti
|-
| Parking Brake
| Boolean
| On / Off
| Get / Noti
|-
| Parking Lights
| Boolean
| On / Off
| Get / Noti / Set
|-
| rowspan=16 | Climate 
/ Environment
| Interior Temperature
| Integer
| 0.1 degrees of Celsius
| Get / Noti
|-
| Exterior Temperature
| Integer
| 0.1 degrees of Celsius
| Get / Noti
|-
| Exterior Brightness
| Integer
| lux
| Get / Noti
|-
| Rain Sensor
| Enum
| Level of rain intensity ( 0 : No Rain ~ 10 : Heaviest Rain)
| Get / Noti
|-
| Windshield Wiper
| Enum
| Level of speed ( 0 : Off, 1 : Slowest, 5 : Fastest, 10 : Auto)
| Get / Noti / Set
|-
| HVAC Fan
| Compound
| Airflow Direction (Front Panel, Floor Duct, Front+Floor, Defroster+Floor), Level of Fan Speed (0~7), Target Temperature (1 degrees of Celsius)
| Get / Noti / Set
|-
| Air-Conditioning
| Boolean
| On / Off
| Get / Noti / Set
|-
| Air-Recirculation
| Boolean
| On / Off
| Get / Noti / Set
|-
| Heater
| Boolean
| On / Off
| Get / Noti / Set
|-
| Defrost
| Compound
| On / Off per each position (Windshield, Rear Window, Side Mirrors)
| Get / Noti / Set
|-
| Steering Wheel Heater
| Boolean
| On / Off
| Get / Noti / Set
|-
| Seat Heater
| Boolean
| On / Off
| Get / Noti / Set
|-
| Seat Cooler
| Boolean
| On / Off
| Get / Noti / Set
|-
| Window
| Compound
| % of openness per each window (driver, passenger, rear left, rear right)
| Get / Noti
|-
| Sunroof
| Compound
| % of openness ( 0 : Closed, 100 : Fully Opened), % of tilt ( 0 : Closed, 100 : Maximum Tilted )
| Get / Noti / Set
|-
| Convertible roof
| Boolean
| On / Off
| Get / Noti / Set
|-
| rowspan=7 | Electric Vehicle
| Hybrid Power Status
| Enum
| Idle, Battery Mode, Engine Mode, Hybrid Mode
| Get / Noti
|-
| Charging Status
| Boolen
| On / Off
| Get / Noti / Set
|-
| Battery Voltage
| Compound
| Voltage ( 0.1 volt ), Level of charge (0~100%)
| Get / Noti
|-
| Battery Charge Cord
| Boolen
| Not Connected / Connected
| Get / Noti
|-
| Target Charge Level
| Integer
| Level of charge capacity (0~100%)
| Get / Noti
|-
| Est. time to full charge
| Integer
| Number of minutes remaining
| Get / Noti
|-
| Est. time to target charge
| Integer
| Number of minutes remaining
| Get / Noti
|}

=== Navigation ===
[[Category:Navigation]]

{| x:str border=1 cellpadding=0 cellspacing=0
| rowspan=2 | Group
| rowspan=2 | Function
| colspan=2 | Parameter
| rowspan=2 | Operation
|-
| Type
| Contents
|-
|-
| rowspan=16 | Maps / Navigation
| Navigation Status
| Enum
| Idle, Guiding, Off-Route, ...
| Get
|-
| Destination
| ?
| Place Element (address, coordinates, viewport)
| Get / Set
|-
| ClearDestination
| none
| Clear current destination / Stop navigation routing
| Set
|-
| Routing Options
| Composition
| Shortest/Fastest, Free/Don't care, Highway/Don't care, ...
| Get / Set
|-
| Get Route
| Composition
| ?
| Get
|-
| POI
| Composition
| List of: <Place Element, Landmark>
| Get / Set
|-
| Latest Destination
| Composition
| Place Element (address, coordinates, viewport)
| Get
|-
| Stored Locations
| Composition
| Place Element List (address, coordinates, viewport)
| Get / Set
|-
| Pitch
| Integer
| 2D/3D representation (pitch): '0' - 2D Bird;s eye view; '15' - 3D view 15 degrees
| Get / Set
|-
| Zoom
| Integer
| zooming (IN / OUT / auto-zoom): '2' - zoom in with factor 2; '-2' zoom out with factor -2; factor: > 1 and < -1
| Get / Set
|-
| Panning
| Integer
| panning (NORTH / SOUTH / EAST / WEST / and combination of these 4 eg. NORTH-WEST)
| Set
|-
| Orientation
| Boolean
| orientation / northing (ON - map oriented north / OFF - map oriented in travelling direction)
| Get / Set
|-
| FollowGPS
| Boolean
| follow gps signal ( ON - map cursor follows gps signal / OFF - map cursor does not follow gps signal / timeout - number of updates to wait before cursor follows gps signal on map; useful for panning)
| Get / Set
|-
| Layout
| Composition
| day / night / detailed - POIs / plain simple
| Get / Set
|-
| SetUnits
| Enum
| Metric / Imperial / ...
| Get / Set
|-
| MapCenter
| Composition
| Center the map ( Place Element (address, coordinates, viewport) )
| Get / Set
|}

=== Multimedia ===
Basically, IVI shares Qt Mobility functions.
This section is for IVI exclusive functionality about Multimedia

=== Communication ===
Basically, IVI shares Qt Mobility functions.
This section is for IVI exclusive functionality about Communication

In-vehicle/Roadmap/API

2011-06-27T10:17:08Z

Jsbach86:

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

[[File:MeeGo-IVI-Stack.png|800px|MeeGo IVI Stack]]

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.

=== Car-Systems ===

[[Category:IVI]]

{| x:str border=1 cellpadding=0 cellspacing=0
| rowspan=2 | Group
| rowspan=2 | Function
| colspan=2 | Parameter
| rowspan=2 | Operation
|-
| Type
| Contents
|-
| rowspan=3 | Application 
Interoperability
| Supported Features
| Integer
| Bit setting per each APIs
| Get
|-
| Car Manufacturer
| String
| 　
| Get
|-
| Car Model Name
| String
| 　
| Get
|-
| rowspan=5 | Car Information
| Car Type
| Enum
| Sedan, Coupe, Cabriole, Roadster, SUV, Truck
| Get
|-
| Door Type
| Composition
| # of doors in first row, second row, third row
| Get
|-
| Engine Type
| Enum
| Gasoline, Diesel, Hybrid, Electric
| Get
|-
| Transmission Gear Type
| Enum
| Auto/Manual
| Get
|-
| Wheel Information
| Composition
| Radius of Wheel, Wheel Track (for GPS Dead Reckoning)
| Get
|-
| rowspan=16 | Running Status
| Vehicle Power Mode
| Enum
| Off / Acc / Run / Ignition
| Get / Noti
|-
| Speedometer
| Integer
| km/h or mph
| Get / Noti
|-
| Engine Speed
| Integer
| rpm
| Get / Noti
|-
| Trip meter
| Integer
| km or mile
| Get / Noti
|-
| Transmission Gear Status
| Enum
| 0=N,1,2,3,4,5,6,7,8,9,10, 64=R, 128=Auto
| Get / Noti
|-
| Cruise Control Status
| Composition
| Activate/Deactivate, Speed
| Get / Noti
|-
| Wheel Brake
| Boolean
| Idle, Engaged, Malfunction
| Get / Noti
|-
| Lights Status
| Composition
| On / Off per each light (Head, Turn Right, Turn Left, Brake, Fog, Hazard Signal, Parking)
| Get / Noti
|-
| Interior Lights Status
| Composition
| On / Off per each light (Driver, Passenger, Center)
| Get / Noti
|-
| Horn
| Boolean
| On / Off
| Get / Noti
|-
| Chime
| Boolean
| On / Off
| Get / Noti
|-
| Fuel
| Integer
| Remaining % (Remaining, Total Capacity in liter or gallon)
| Get / Noti
|-
| Engine Oil
| Composition
| Remaining %, Temperature
| Get / Noti
|-
| Engine Coolant
| Composition
| Level, Temperature, Pressure
| Get / Noti
|-
| Steering Wheel Angle
| Integer
| (for GPS Dead Reckoning)
| Get / Noti
|-
| Wheel Tick Sensor
| Composition
| Left Wheel Rotation Counter, Right Wheel Rotation Counter (for GPS Dead Reckoning)
| Get
|-
| rowspan=6 | Maintenance
| Odometer
| Integer
| km/h or mph
| Get / Noti
|-
| Transmission Oil
| Integer
| Remaining %
| Get / Noti
|-
| Brake Fluid
| Integer
| Remaining %
| Get / Noti
|-
| Washer Fluid
| Integer
| Remaining %
| Get / Noti
|-
| Battery Status
| Composition
| Voltage, Current
| Get / Noti
|-
| Tire Pressure
| Composition
| PSI or Status (Normal, Low) per each tire (front left, front right, rear left, rear right)
| Get / Noti
|-
| rowspan=10 | Personalization
| Key ID (Driver ID)
| Enum
| 　
| Get / Set
|-
| Language
| Enum
| English, Spanish, French, …
| Get / Set
|-
| Measurement System
| Boolean
| Km (litter), mile (gallon)
| Get / Set
|-
| Mirror
| Composition
| 2byte(Tilt, Pan) position per each mirror (driver side, passenger side, inside mirror)
| Get / Set
|-
| Steering Wheel Position
| Composition
| Level per each part (slide, tilt)
| Get / Set
|-
| Driving Mode
| Enum
| Comfort, Auto, Sport, Eco, Manual
| Get / Set
|-
| Driver Seat Position
| Composition
| Level per each part (recline seatback, slide, cushion height, headrest, back cushion, side cushion)
| Get / Set
|-
| Passenger Seat Position
| Composition
| Level per each part (recline seatback, slide, cushion height, headrest, back cushion, side cushion)
| Get / Set
|-
| Dashboard Illumination
| Enum
| % of Illumination ( 0 : Darkest, 100 : Brightest)
| Get / Set
|-
| Generated Car Sound Mode
| Enum
| Normal, Quiet, Sportive
| Get / Set
|-
| rowspan=10 | Driving Safety
| Antilock Braking System
| Enum
| Available (Equipped), Idle, Engaged
| Get / Noti
|-
| Transaction Control System
| Enum
| Available (Equipped), On/Off
| Get / Noti
|-
| Vehicle Top Speed Limit
| Integer
| km/h or mph (0 means no limitation)
| Get / Set
|-
| Airbag Status
| Composition
| Activate/Deactivate/Deployment per each airbag (driver, passenger, side)
| Get / Noti
|-
| Door Open Status
| Composition
| Open/Ajar/Close per each door (driver, passenger, rear left, rear right, trunk, fuel filler cap, hood)
| Get / Noti
|-
| Door Lock Status
| Composition
| Lock/Unlock per each door (driver, passenger, rear left, rear right)
| Get / Noti / Set
|-
| Occupants Status
| Composition
| Type (Adults/Child/Vacant) per each seat (driver, passenger, rear left, rear right)
| Get / Noti
|-
| Seat Belt
| Composition
| Fasten or not per each seat (driver, passenger, rear left, rear right)
| Get / Noti
|-
| Window Lock
| Composition
| Lock/Unlock per each window (driver, passenger, rear left, rear right)
| Get / Noti / Set
|-
| Obstacle Distance
| Composition
| Sensor Status (available or not), Distance per each sensor (Position #)
| Get / Noti
|-
| rowspan=3 | Parking
| Security Alert
| Enum
| Available (Equipped), Idle, Activated, Alarm Detected
| Get / Noti
|-
| Parking Brake
| Boolean
| On / Off
| Get / Noti
|-
| Parking Lights
| Boolean
| On / Off
| Get / Noti / Set
|-
| rowspan=16 | Climate 
/ Environment
| Interior Temperature
| Integer
| 0.1 degrees of Celsius
| Get / Noti
|-
| Exterior Temperature
| Integer
| 0.1 degrees of Celsius
| Get / Noti
|-
| Exterior Brightness
| Integer
| lux
| Get / Noti
|-
| Rain Sensor
| Enum
| Level of rain intensity ( 0 : No Rain ~ 10 : Heaviest Rain)
| Get / Noti
|-
| Windshield Wiper
| Enum
| Level of speed ( 0 : Off, 1 : Slowest, 5 : Fastest, 10 : Auto)
| Get / Noti / Set
|-
| HVAC Fan
| Composition
| Airflow Direction (Front Panel, Floor Duct, Front+Floor, Defroster+Floor), Level of Fan Speed (0~7), Target Temperature (1 degrees of Celsius)
| Get / Noti / Set
|-
| Air-Conditioning
| Boolean
| On / Off
| Get / Noti / Set
|-
| Air-Recirculation
| Boolean
| On / Off
| Get / Noti / Set
|-
| Heater
| Boolean
| On / Off
| Get / Noti / Set
|-
| Defrost
| Composition
| On / Off per each position (Windshield, Rear Window, Side Mirrors)
| Get / Noti / Set
|-
| Steering Wheel Heater
| Boolean
| On / Off
| Get / Noti / Set
|-
| Seat Heater
| Boolean
| On / Off
| Get / Noti / Set
|-
| Seat Cooler
| Boolean
| On / Off
| Get / Noti / Set
|-
| Window
| Composition
| % of openness per each window (driver, passenger, rear left, rear right)
| Get / Noti
|-
| Sunroof
| Composition
| % of openness ( 0 : Closed, 100 : Fully Opened), % of tilt ( 0 : Closed, 100 : Maximum Tilted )
| Get / Noti / Set
|-
| Convertible roof
| Boolean
| On / Off
| Get / Noti / Set
|-
| rowspan=7 | Electric Vehicle
| Hybrid Power Status
| Enum
| Idle, Battery Mode, Engine Mode, Hybrid Mode
| Get / Noti
|-
| Charging Status
| Boolen
| On / Off
| Get / Noti / Set
|-
| Battery Voltage
| Composition
| Voltage ( 0.1 volt ), Level of charge (0~100%)
| Get / Noti
|-
| Battery Charge Cord
| Boolen
| Not Connected / Connected
| Get / Noti
|-
| Target Charge Level
| Integer
| Level of charge capacity (0~100%)
| Get / Noti
|-
| Est. time to full charge
| Integer
| Number of minutes remaining
| Get / Noti
|-
| Est. time to target charge
| Integer
| Number of minutes remaining
| Get / Noti
|}

=== Navigation ===
[[Category:Navigation]]

{| x:str border=1 cellpadding=0 cellspacing=0
| rowspan=2 | Group
| rowspan=2 | Function
| colspan=2 | Parameter
| rowspan=2 | Operation
|-
| Type
| Contents
|-
|-
| rowspan=9 | Maps / Navigation
| Navigation Status
| Enum
| Idle, Guiding, Off-Route, ...
| Get
|-
| Destination
| ?
| ?
| Get / Set
|-
| Routing Options
| Composition
| Shortest/Fastest, Free/Don't care, Highway/Don't care, ...
| Get / Set
|-
| Get Route
| Composition
| ?
| Get
|-
| POI
| Composition
| ?
| Get / Set
|-
| Latest Destination
| Composition
| ?
| Get
|-
| Stored Locations
| Composition
| ?
| Get / Set
|-
| Pitch
| Integer
| 2D/3D representation (pitch)
| Get / Set
|-
| Zoom
| Integer
| zooming (IN / OUT / auto-zoom)
| Get / Set
|}

=== Multimedia ===
Basically, IVI shares Qt Mobility functions.
This section is for IVI exclusive functionality about Multimedia

=== Communication ===
Basically, IVI shares Qt Mobility functions.
This section is for IVI exclusive functionality about Communication

In-vehicle/Roadmap/API

2011-06-23T08:56:06Z

Jsbach86: /* API Functional Groups and Functions */

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

[[File:MeeGo-IVI-Stack.png|800px|MeeGo IVI Stack]]

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.

[[Category:IVI]]

{| x:str border=1 cellpadding=0 cellspacing=0
| rowspan=2 | Group
| rowspan=2 | Function
| colspan=2 | Parameter
| rowspan=2 | Operation
|-
| Type
| Contents
|-
| rowspan=3 | Application 
Interoperability
| Supported Features
| Integer
| Bit setting per each APIs
| Get
|-
| Car Manufacturer
| String
| 　
| Get
|-
| Car Model Name
| String
| 　
| Get
|-
| rowspan=5 | Car Information
| Car Type
| Enum
| Sedan, Coupe, Cabriole, Roadster, SUV, Truck
| Get
|-
| Door Type
| Composition
| # of doors in first row, second row, third row
| Get
|-
| Engine Type
| Enum
| Gasoline, Diesel, Hybrid, Electric
| Get
|-
| Transmission Gear Type
| Enum
| Auto/Manual
| Get
|-
| Wheel Information
| Composition
| Radius of Wheel, Wheel Track (for GPS Dead Reckoning)
| Get
|-
| rowspan=17 | Running Status
| Vehicle Power Mode
| Enum
| Off / Acc / Run / Ignition
| Get / Noti
|-
| Speedometer
| Integer
| km/h or mph
| Get / Noti
|-
| Engine Speed
| Integer
| rpm
| Get / Noti
|-
| Trip meter
| Integer
| km or mile
| Get / Noti
|-
| Transmission Gear Status
| Enum
| 0=N,1,2,3,4,5,6,7,8,9,10, 64=R, 128=Auto
| Get / Noti
|-
| Cruise Control Status
| Composition
| Activate/Deactivate, Speed
| Get / Noti
|-
| Wheel Brake
| Boolean
| Idle, Engaged, Malfunction
| Get / Noti
|-
| Lights Status
| Composition
| On / Off per each light (Head, Turn Right, Turn Left, Brake, Fog, Hazard Signal, Parking)
| Get / Noti
|-
| Interior Lights Status
| Composition
| On / Off per each light (Driver, Passenger, Center)
| Get / Noti
|-
| Horn
| Boolean
| On / Off
| Get / Noti
|-
| Chime
| Boolean
| On / Off
| Get / Noti
|-
| Engine Coolant
| Composition
| Level, Temperature, Pressure
| Get / Noti
|-
| Compass Status
| Enum
| N, S, W, E, NE, NW, SE, SW
| Get / Noti
|-
| Steering Wheel Angle
| Integer
| (for GPS Dead Reckoning)
| Get / Noti
|-
| Wheel Tick Sensor
| Composition
| Left Wheel Rotation Counter, Right Wheel Rotation Counter (for GPS Dead Reckoning)
| Get
|-
| GPS Data - Date, Time
| Composition
| Date, Time
| Get
|-
| GPS Data - Position
| Composition
| Latitude, Longitude
| Get
|-
| rowspan=8 | Maintenance
| Odometer
| Integer
| km/h or mph
| Get / Noti
|-
| Fuel
| Integer
| Remaining % (Remaining, Total Capacity in liter or gallon)
| Get / Noti
|-
| Engine Oil
| Integer
| Remaining %
| Get / Noti
|-
| Transmission Oil
| Integer
| Remaining %
| Get / Noti
|-
| Brake Fluid
| Integer
| Remaining %
| Get / Noti
|-
| Washer Fluid
| Integer
| Remaining %
| Get / Noti
|-
| Battery Status
| Composition
| Voltage, Current
| Get / Noti
|-
| Tire Pressure
| Composition
| PSI or Status (Normal, Low) per each tire (front left, front right, rear left, rear right)
| Get / Noti
|-
| rowspan=8 | Personalization
| Key ID (Driver ID)
| Enum
| 　
| Get / Set
|-
| Language
| Enum
| English, Spanish, French, …
| Get / Set
|-
| Measurement System
| Boolean
| Km (litter), mile (gallon)
| Get / Set
|-
| Mirror
| Composition
| 2byte(Tilt, Pan) position per each mirror (driver side, passenger side, inside mirror)
| Get / Set
|-
| Steering Wheel Position
| Composition
| Level per each part (slide, tilt)
| Get / Set
|-
| Driver Seat Position
| Composition
| Level per each part (recline seatback, slide, cushion height, headrest, back cushion, side cushion)
| Get / Set
|-
| Passenger Seat Position
| Composition
| Level per each part (recline seatback, slide, cushion height, headrest, back cushion, side cushion)
| Get / Set
|-
| Dashboard Illumination
| Enum
| % of Illumination ( 0 : Darkest, 100 : Brightest)
| Get / Set
|-
| rowspan=10 | Driving Safety
| Antilock Braking System
| Enum
| Available (Equipped), Idle, Engaged
| Get / Noti
|-
| Transaction Control System
| Enum
| Available (Equipped), On/Off
| Get / Noti
|-
| Vehicle Top Speed Limit
| Integer
| km/h or mph (0 means no limitation)
| Get / Set
|-
| Airbag Status
| Composition
| Activate/Deactivate/Deployment per each airbag (driver, passenger, side)
| Get / Noti
|-
| Door Open Status
| Composition
| Open/Ajar/Close per each door (driver, passenger, rear left, rear right, trunk, fuel filler cap, hood)
| Get / Noti
|-
| Door Lock Status
| Composition
| Lock/Unlock per each door (driver, passenger, rear left, rear right)
| Get / Noti / Set
|-
| Occupants Status
| Composition
| Type (Adults/Child/Vacant) per each seat (driver, passenger, rear left, rear right)
| Get / Noti
|-
| Seat Belt
| Composition
| Fasten or not per each seat (driver, passenger, rear left, rear right)
| Get / Noti
|-
| Window Lock
| Composition
| Lock/Unlock per each window (driver, passenger, rear left, rear right)
| Get / Noti / Set
|-
| Obstacle Distance
| Composition
| Sensor Status (available or not), Distance per each sensor (Position #)
| Get / Noti
|-
| rowspan=3 | Parking
| Security Alert
| Enum
| Available (Equipped), Idle, Activated, Alarm Detected
| Get / Noti
|-
| Parking Brake
| Boolean
| On / Off
| Get / Noti
|-
| Parking Lights
| Boolean
| On / Off
| Get / Noti / Set
|-
| rowspan=16 | Climate 
/ Environment
| Interior Temperature
| Integer
| 0.1 degrees of Celsius
| Get / Noti
|-
| Exterior Temperature
| Integer
| 0.1 degrees of Celsius
| Get / Noti
|-
| Exterior Brightness
| Integer
| lux
| Get / Noti
|-
| Rain Sensor
| Enum
| Level of rain intensity ( 0 : No Rain ~ 10 : Heaviest Rain)
| Get / Noti
|-
| Windshield Wiper
| Enum
| Level of speed ( 0 : Off, 1 : Slowest, 5 : Fastest, 10 : Auto)
| Get / Noti / Set
|-
| HVAC Fan
| Composition
| Airflow Direction (Front Panel, Floor Duct, Front+Floor, Defroster+Floor), Level of Fan Speed (0~7), Target Temperature (1 degrees of Celsius)
| Get / Noti / Set
|-
| Air-Conditioning
| Boolean
| On / Off
| Get / Noti / Set
|-
| Air-Recirculation
| Boolean
| On / Off
| Get / Noti / Set
|-
| Heater
| Boolean
| On / Off
| Get / Noti / Set
|-
| Defrost
| Composition
| On / Off per each position (Windshield, Rear Window, Side Mirrors)
| Get / Noti / Set
|-
| Steering Wheel Heater
| Boolean
| On / Off
| Get / Noti / Set
|-
| Seat Heater
| Boolean
| On / Off
| Get / Noti / Set
|-
| Seat Cooler
| Boolean
| On / Off
| Get / Noti / Set
|-
| Window
| Composition
| % of openness per each window (driver, passenger, rear left, rear right)
| Get / Noti
|-
| Sunroof
| Composition
| % of openness ( 0 : Closed, 100 : Fully Opened), % of tilt ( 0 : Closed, 100 : Maximum Tilted )
| Get / Noti / Set
|-
| Convertible roof
| Boolean
| On / Off
| Get / Noti / Set
|-
| rowspan=7 | Electric Vehicle
| Hybrid Power Status
| Enum
| Idle, Battery Mode, Engine Mode, Hybrid Mode
| Get / Noti
|-
| Charging Status
| Boolen
| On / Off
| Get / Noti / Set
|-
| Battery Voltage
| Composition
| Voltage ( 0.1 volt ), Level of charge (0~100%)
| Get / Noti
|-
| Battery Charge Cord
| Boolen
| Not Connected / Connected
| Get / Noti
|-
| Target Charge Level
| Integer
| Level of charge capacity (0~100%)
| Get / Noti
|-
| Est. time to full charge
| Integer
| Number of minutes remaining
| Get / Noti
|-
| Est. time to target charge
| Integer
| Number of minutes remaining
| Get / Noti
|}