Automotive User Interfaces and Interactive Vehicular Applications

system (runtime skinning) by either the (secondary-) vendor or the
customer (personalization).
There are different ways to apply a skin depending on when it will
be applied as well as who is the one who will be applying the
skin. These are discussed below:
5.3.1 Reconfiguring and changing resource files
The simplest way to perform skinning is to exchange the resources
of the existing software such as images, fonts and configuration
files. In this approach the source code of the HMI is not changed
(Figure 5). The skin is applied by copying the contained resource
files to a designated location in the file system, possibly
overwriting the previous ones. Such a process can be easily
automated.
Figure 5: Reconfiguring and changing resource files
This approach is used by desktop-applications such as the
Windows Media Player or the Winamp Player. It is also used by
certain mobile phone manufacturers. This type of skinning can be
done even after the deployment of the base software, because it
does not require recompiling the software. Such skins have a
simple structure and don’t require a lot of knowledge about the
functional principles of the base software. Therefore, they can be
created by customers, too.
However, this approach requires that all skinnable elements exist
in the HMI already. They also have to be implemented in such a
way that all skin-specific information is read from external
resources. This can lead to additional implementation efforts in
the base software. As reading and evaluating resources happens at
runtime, performance drawbacks can be expected compared to a
conventional implementation. Therefore, this approach is typically
limited to images and fonts.
5.3.2 HMIs interpreted at runtime
Some frameworks interpret HMI-models at runtime [10]. In such
a case, skinning can either modify the interpreted models or the
interpreter. If the rules that control the interpretation are
modifiable [1,8,5], skinning can also be done by adapting these
rules (Figure 6).
Modifying the interpreter rules allows for a simple handling of
skins since there is no need to maintain different interpreter
software or modified versions of the large HMI-models.
Skinning by modifying the interpreter or its rules leads to a
different rendering of the original HMI models. It also alters the
rendering of all other compatible HMI-models. Therefore, it can
be used to achieve a specific look-and-feel for HMI-models
unknown at development time, e.g., HMIs of dynamic services
[8]. However, this technique requires expert knowledge and
therefore cannot be done by customers.
Figure 6: HMIs interpreted at runtime
In the case that a more specific adaptation is to be made, it is more
reasonable to modify the interpreted HMI models directly instead
of modifying the interpreter or its rules that affects the entire
HMI. Initial models should not be changed since they are to be
used in different vehicles, so skin-specific information can also be
provided in a separate skin-model, which will override its
counterparts from the HMI base model.
Maximum flexibility can be achieved when the interpreter, its
rules, as well as the HMI-models are all adapted within the
skinning process.
5.3.3 Automatically generated HMIs
Adapting the initial HMI-models or providing skin-specific
information in additional models can also be done if they are not
interpreted at runtime but are used to generate code. Just like
modifying the interpreter or its rule set, such a code generator and
its generation rules can also be adapted (Figure 7).
Figure 7: Automatically generated HMIs
Taking the skin-specific information into account during code
generation, this approach reduces the number of decisions that
have to be made at runtime. This allows for high runtime
performance which in turn can reduce hardware costs. Such
savings are especially significant when skinning is applied in
order to use the same infotainment system for several brands and
models. On the other hand extensive software has to be generated
and compiled for each variant which leads to long turnaround
times.
5.3.4 Exchanging the HMI-software
The previous chapter described how skinning can be implemented
by modifying the code generator and the models it works on. As a
result a different HMI-software is generated for each variant. The
corresponding adaptations of the code can also be done manually
if no model-driven development methods are applied