Automotive User Interfaces and Interactive Vehicular Applications

2.1 Modeling using Conventional GUI-
Builders
Bock [1] proposes that OEMs define suitable model types and
create the corresponding tools by means of Meta-CASE tools 2 .
His sample implementation is divided into separate views, each of
which is addressing a different expertise (layout, content, and
behavior). Graphical models based on Statecharts [11,12] are used
to describe the HMI behavior. A standard SWT/Swing GUI
builder is applied for modeling the layout of the GUI, which is
intended to be used by visual designers. In such tools the GUI is
composed of multiple views that consist of a hierarchical structure
of SWT- or Swing-widgets. Each instance of a widget in a view
can be individually configured by adapting its properties.
However, the look and feel of the widget types needs to be
programmed manually.
Choosing such a GUI-builder is not reasonable because these
graphic frameworks are not used in embedded target platforms.
They are designed for desktop applications and are not suitable for
building HMIs for consumer products. Another major drawback
of all conventional widget-based GUI builders is that each type of
widget needs to be programmed manually before it can be used
for modeling. When visual designers want to create new GUIs the
available widget set may not be sufficient for their
implementation. All additional widgets have to be created before
they can be used to build the GUI. This leads to delays and acts as
a break on the creative design process. A further drawback of this
approach is the fact that the widgets developed using SWT-
/Swing technology cannot be used in the target system but have to
be re-implemented using other technologies. This leads to
considerable additional specification and implementation effort
because the widgets constitute an essential part of the GUI’s look
and feel. Finally, since the same functionality is implemented
more than once it can no longer be assured that prototypes and the
final HMI show the same appearance and behavior.
2.2 Available Tools for HMI Modeling
There are several specialized tools available on the market for
creating HMI models and transforming them into executable
software for embedded systems [13], e.g., Elektrobit‘s Graphical
User Interface Designer Studio (GUIDE) [14,15], Presagis’ VAPS
XT [16,17,5], and Mecel’s Populus.
All these tools are designed for the model-driven development of
automotive HMIs. They are applied to formalize and detail drafts
of ergonomists, visual designers and other domain experts. The
tools make use of different specialized editors. Code generators
and runtime environments create prototypes and the final HMIsoftware
for the target system respectively.
In order for the editors to be easy to use without experience in
programming, they make use of graphical notations and the
WYSIWYG system. These tools however, are quite complex so in
practice are used exclusively by trained experts.
In these tools modeling the GUI is also based on widgets just as in
the GUI-builders for desktop applications. Therefore, all
necessary widgets need to be implemented before they can be
used to build the GUI. This is a major drawback, because it is
often the case that changes need to be made to the design of the
2 The term Meta is used for a class-instance relationship between
different models. Analogous to this, tools that serve to create
CASE-Tools for individual model types are often called Meta-
CASE-Tools.
GUI in late project phases due to influences from evaluation
feedback or new design trends. These changes may call for new
widgets to be made, which need to be precisely described by the
visual designers and then implemented by programmers. This
results in associated efforts for both. When those widgets are
available they are used to rebuild the draft of the designers as
exact as possible. This procedure delays the development process
because the same visual designs are implemented twice using
different technologies.
2.3 EDONA-HMI
The EDONA-project addresses the interoperability of the tools
applied in the development of automotive embedded systems
[18,19]. An integration platform was developed which allows
exchanging data or models between OEMs and suppliers. A
subproject of EDONA focuses on the model-driven development
of HMIs [9]. If the models exchanged between OEMs and
suppliers use formats tied to a certain tool, the suppliers are forced
to adapt their toolchains whenever the OEMs change their tool
[19]. Based on this observation, EDONA HMI proposes to make
use of a tool-independent exchange format. In the past multiple
such formats have been developed 3 . Most of them are specific
XML-based languages. However, because none of these have
become an industry standard tool support is not widely available.
EDONA HMI, however, recommends using the already
established image format SVG. In SVG an image is composed of
a tree of primitive graphic objects (scene graph). EDONA HMI
defines a specific SVG subset (profile) adapted to the need of
automotive HMIs. The profile also introduces particular
extensions that can be used to annotate attributes of elements in
the scene graph, such as the position or angle of an object. These
annotated attributes can then be connected to calculation rules
which modify them at runtime based on data coming from the
application 4 . The calculation rules are described using the
ESTEREL synchronous programming language. SVG files and
their calculation rules can be bundled into HMI components.
Similar to widgets, they serve as reusable building blocks
consisting of graphical appearance and behavior.
Even though using SVG files is advantageous as mentioned above
the format is not used as exchange format in industry. However,
the approach of going with a standard graphic format is wise
because it allows for seamless integration of the HMI modeling
tools and the tools which visual designers use. Designers can
create design drafts using standard software without having to use
a specific tool. These drafts can be used directly for the
implementation of the final HMI software instead of having to recreate
them using a particular widget set. Modern GUIs use
complex animations that are also defined by visual designers.
SVG files however cannot describe animations so this information
cannot be exchanged. Furthermore, the SVG format supports only
2D graphics and not 3D GUIs, which are foreseen to play a big
role in the next generations of automotive HMI [14,20,21].
The low familiarity of ESTEREL in industrial practice is also a
drawback of EDONA. Furthermore, the way ESTEREL is used in
is not sufficient for defining the complete behavior of the HMI.
For example, it cannot describe the dialogue flow including
3
Examples of such formats are OEMXML, VWXML, IML,
ICUC-XML, and Abstract HMI.
4
To create a virtual analogue gauge a SVG image is required. The
needle’s angle attribute is then annotated and linked to a rule
that calculates the angle based on an input signal.