Automotive User Interfaces and Interactive Vehicular Applications

Figure 1: Example for the derivation process of a specific
infotainment system variant
1. Infotainment systems come with a range of different feature
sets. For example, one system may be available with or
without navigation functionality. There are more optional
features available such as CD-changer, iPod- or cell phone
connector, telematics-module, etc. In order for each of these
options to function, a particular software service as well as a
user interface is needed in the infotainment system. Various
software variants with different ranges of functionality are
required that can be composed by taking components from the
product-line-wide base of common assets (Core-Assets) 2 [4].
This process can be automated using certain tools. Variantspecific
configurations are used to determine which core
assets are to be combined and how they are tailored for each
specific variant.
2. Infotainment systems with the same feature set are offered in
different car models and brands. However, these features may
need to be presented individually. In this case, skinning can
be applied to modify the base software. Several of these
skinning processes can be executed one after another
(cascading skinning). This can be useful when skinning is
applied for different purposes; such as a generic brandspecific
design followed by a model-specific design (Figure
1). Splitting up the skinning in such a way reduces the
complexity of each step. Furthermore, the intermediate results
after the brand-specific skinning can be reused for the creation
of the HMI of each of the brand’s models. This can allow for
abbreviating the derivation process when the software of
multiple models of this brand is to be created at once [6].
It is possible to present the infotainment system’s base
functions in different visual styles to the user, and allow him
to choose those styles while operating the system. In
infotainment systems to come the user might select different
design profiles such as sport, eco or classic [12]. A simpler
example that can be found today is the day- and the nightmode.
The mode changes the display’s colors and brightness,
to avoid visual distraction and improve readability. Such a
product feature can require having more than one skinned
HMI in the same system.
3. Special edition vehicles or variants with different body shapes
based on a single car model can use the same skinned base
software. The necessary changes for each derivative require
only minor adoptions to the HMI, which can be achieved by
2 The core assets alone do not form a product. A product is built
by a combination of core assets and more elements.
simple reconfigurations if they are adequately considered in
advance.
4. Infotainment systems are built for cars that are marketed
globally. In order to provide products that fit the customer’s
needs in each country, the infotainment system’s software
needs to be adapted. Besides technical adoptions in the baseplatform
this calls for culture-specific changes of the HMI.
This includes the translation of all texts (in the GUI and the
voice dialog system), the use of different units and date
formats as well as the replacement of icons, images and colors
[3,13].
When localizing an HMI, the changes in the number and
structure of the interaction components should be kept to a
minimum in order to keep the variant diversity manageable.
Hence, localization is providing country-specific content for
the interaction components defined while skinning. However,
some skinning-specific conditions have to be considered, e.g.,
the font and the available display space for the rendered text
in the actual skin need to be known in order to avoid violating
the bounds when translating GUI texts [6]. Therefore, each
translation only has to be created for a specific skin and makes
up an essential part of it (Figure 2).
Figure 2: Configuration items required for the derivation of a
specific variant with two different skins, and multiple
translations for each skin
3. DELIMITATION
Contrary to the procedure described above for product line
engineering (PLE), skinning uses the existing software of a
specific product as a starting point and modifies the parts that are
visible to the user (see Figure 3). Changing the base function
available to the HMI goes beyond the scope of skinning. Thus,
skinning can be seen as a special case of conventional PLE, which
offers less variability and applies specific methods in the
derivation process.
Figure 3: Comparison between PLE and Skinning