Automotive User Interfaces and Interactive Vehicular Applications

The HMISL language for modeling HMI product lines
Simon Gerlach
HMI/Cluster, Switches
Volkswagen AG
PO Box 1148, D-38436 Wolfsburg, Germany
ABSTRACT
This paper introduces the HMISL language which serves to model
the behavioral logic of HMI product lines. HMISL models are
structured into separate modules that can be reused for creating
the software of different HMI variants by means of code
generation. The language is designed to be applied along with
different tools for GUI modeling available on the market.
Categories and Subject Descriptors
D.3.2 [Programming Languages]: Language Classifications –
specialized application languages, very high-level languages;
D.3.3 [Programming Languages]: Language Constructs and
Features; D.2.2 [Software Engineering]: Design Tools and
Techniques – user interfaces; D.2.13 [Software]: Reusable
Software – Domain Engineering; H.5.2 [Information Interfaces
and Presentation]: User Interfaces – Graphical user interfaces
(GUI); D.2.6 [Software Engineering]: Programming
Environments – Graphical environments;
Keywords
HMI, Automotive, DSL, model-driven software development,
domain-specific languages, HMISL, code generation
1. MODEL-DRIVEN HMI DEVELOPMENT
Model-driven software development promotes to automatically
generate software based on models that provide all necessary
information in a formal manner. There are models designed for
code generation of HMI software that come with different level of
abstraction and formalism. Most of them are focusing the
structural parts and in particular the layout of the GUI. The
dynamic behavior such as the dialogue flow is often modeled
using Statecharts [1].
Choosing behavior models with semiformal notations and higher
levels of abstraction can be beneficial in earlier project phases.
However, for the generation of the final HMI software such
abstract models are unsuitable. Because their level of detail is too
low and they lack expressiveness to provide the code generators
with all necessary information the generated code need to be
adapted or complemented manually. Furthermore, using pure
Statecharts is more complex than conventional programming
languages for modeling certain parts of the HMI behavior such as
algorithmic computations and string formatting. For this reason,
these parts of the HMI software are not developed in a modeldriven
way but are coded manually.
1.1 Drawbacks
Applying model-driven approaches together with traditional
software development for creating the HMI software gives rise to
several integration problems. Integrating the generated software
and the parts that were coded manually can call for designs with
Copyright held by author(s).
AutomotiveUI’11, November 29-December 2, 2011, Salzburg, Austria.
Adjunct Proceedings.
simon.gerlach@volkswagen.de
- 15 -
larger code size or lower runtime performance. It may be
necessary, for instance, to introduce additional interfaces or layers
in order to ensure the referential integrity of the overall software.
Because the usage of highly-specialized HMI modeling tools
requires different qualifications than conventional software
development different staff will be assigned to these jobs. Because
no vertical development is possible extensive communication
efforts is required during HMI implementation. In addition to that
bug fixing becomes a very complex task because generated code
and manually written code as well as models have to be taken into
account and it is necessary to understand how they interact.
1.2 Bridging conventional and model-driven
software development by hybrid models
The goal of this work is to overcome the aforementioned
problems of model-driven HMI development. In accordance with
the idea of Gröninger [2], the approach is based on combining
high-level concepts like state machines and a programming
language into a textual domain-specific modeling language (DSL)
called HMISL [3]. While we started with using LUA as the
embedded programming language we later changed to a
minimalistic Java dialect in order to take advantage of static
typing. The HMISL allows expressing the complete behavior of
the HMI in a single formal model. This enables vertical
development, semantically rich checks and full code generation of
the final HMI software. In contrast to other textual notations like
SCXML [4] we decided to use a formal notation that is not XMLbased.
This allowed achieving a smoother integration of the
programming language as well as a clearer and more compact
syntax because the one of the embedded programming language
did not need to be adapted to the restrictions of XML. For
instance, no double escaping of reserved characters is necessary
(Listing 1, Listing 2).
Listing 1 – Example Code in SCXML
state weather_main_page {
on EXIT then {
hasTarget = true;
if (CarDestLat==0 && CarDestLon==0) {
hasTarget = false;
}
}
on userinput(keycode) [keycode==">"] then
goto wetter_main_page2;
}
Listing 2 – Equivalent Code in HMISL