Skip to content

Latest commit

 

History

History
106 lines (69 loc) · 3.16 KB

mmi-2-1_smart-car-configuration-management.md

File metadata and controls

106 lines (69 loc) · 3.16 KB

Title: Smart Car Configuration Management

Submitter(s):

Michael McCool

Reviewer(s):

Tracker Issue ID:

Category:

Accessibility

Class:

Status:

Target Users

<List all users that are involved in the use case, e.g. device manufacturer, gateway manufacturer, cloud provider>

Motivation:

User interface personalization is a task that most often needs to be repeated for all Devices a user wishes to interact with recurringly. With complex devices, this task can also be very time-consuming, which is problematic if the user regularly accesses similar, but not identical devices, as in the case of several cars rented over a month.

A standardized set of personal information and preferences that could be used to configure personalizable devices automatically would be very helpful for all these cases in which the interaction becomes a customary practice.

Expected Devices:

Personal mobile device running an application providing command mediation capabilities.

IoT-enabled smart car supporting remote sensing, actuation, and configuration functionality.

Expected Data:

Command and status information transferred between the personal mobile device application and the car's services and devices.

Profile data for user preferences.

Dependencies:

  • WoT Thing Description
  • WoT Discovery
  • Optional: WoT Scripting API in application on mobile personal device and possibly in IoT orchestration services in the car.

Description:

Basic in-car functionality is standardized to be managed by other devices. A user can control seat, radio or AC settings through a personalized multimodal interface shared by the car and her personal mobile device. User preferences are stored on the mobile Device (or in the cloud), and can be transferred across different car models handling a specific functionality (e.g. all cars with touchscreens should be able to adapt to a "high contrast" preference).

The car can make itself available as a complex modality component that wraps around all functionality and supported modalities, or as a collection of modality components such as touchscreen, speech recognition system, or audio player. In the latter case, certain user preferences may be shared with other environments.

For example, a user may opt to select the "high contrast" scheme at night on all of her displays, in the car or at home. A car that provides a set of modalities can be also adapted by the mobile device to compose an interface for its functionality, for example to manage playback of music tracks through the car's voice control system. Sensor data provided by the phone can be mixed with data recorded by the car's own sensors to profile user behavior which can be used as context in multimodal interaction.

Variants:

Additional portable devices may be brought into the car and also be incorporated into an application, for example, a GPS navigation system.

Gaps:

Data format describing user interface preferences.

Existing standards:

This use case is based on MMI UC 2.1.

Comments:

Does not include Requirements section from original MMI use case.