Friday, June 28, 2019

Modularization: Reduce complexity with multiple models

Andreas Betz

Relaxed were the days when an HMI in the automobile world was small and its functionality easy to comprehend. Nowadays more and more functionality becomes a part of the HMI and this applies not just to the infotainment stack but also to instrument clusters and head up displays.

In addition to the ever-growing basic functions, the IoT and the need to be as up to date as possible make it necessary to be prepared for fast and easy updates done over the air by the end customer.

In the last years this development lead to the creation of huge monolithic HMI projects.

We from the EB GUIDE development team want to counter this trend with our modular HMI development approach.

The past

In previous versions of EB GUIDE, modelers were creating monolithic HMI models containing every functionality that was expected from the user into one big project.

Although this approach works for smaller projects, for full graphical cluster instruments and infotainment systems, it can overcomplicate the development especially when multiple teams or companies are working together on one HMI.

The biggest disadvantage is that everything is always involved. This means even for small changes, the model as a whole has to be changed.

With the increasing size of such a model the “natural entropy” of it also grows. If you ever encountered a situation where no team member could remember why a certain template is there or some states are existing that are not reachable, then you know what I mean.

The effort for maintaining the whole model is increasing – no matter how much discipline you try to keep.

And then of course the potential to manipulate things accidentally that are not related to the detail you are working on at the moment.

The above picture shows how such a monolithic HMI model would be executed in EB GUIDE GTF.

The EB GUIDE GTF core is running the HMI model related parts, where the state machines define the basic behavior.

These state machines can be matched to different scenes and displays or be part of a combined scene as dynamic state machines – e.g. for showing warnings or menus on top of other content.

Nonetheless also this monolith is described using one self-contained binary description containing the whole EB GUIDE model.

Exchanging or updating only a part of it is not easily possible.

This makes a collaboration between several teams or even companies working on the same project less efficient and cumbersome.

The present

With the latest version of EB GUIDE we provide the possibility to divide the functionality, users expect in an automotive HMI, into several smaller projects.

Each of these smaller projects can then focus on one functionality which can easily be maintained, developed and tested.

This means that a modeler only works on a small dedicated model – e.g. the status bar – with a defined interface to the rest of the system and does not have to care about the other parts of the HMI.

These smaller models can then be run by EB GUIDE GTF and connected to each other to collaborate in an integrated HMI.

To support this, EB GUIDE GTF provides several options:

  • running these models in the same process
  • running each model in a different process, partition of the same device or a different device
  • any combination of the above


The synchronization of these models is done on the data layer automatically by EB GUIDE GTF.

This means updates to datapool properties and events that are known by several models will automatically be shared and synched.

If EB GUIDE GTF instances are connected via IPC, then our IPC services will synchronize the data layers of all participating EB GUIDE GTF instances.

This brings not only the possibility to reduce the responsibility of one model to a comprehensible and maintainable level, but also reduces the overhead of collaboration in cross-team projects.

Another advantage is the dynamic lifecycle of such a model. In case you need to update only a part of the HMI, you just shut down that particular part, exchange it and start it anew. And all this happens on-the-fly.


The future

In the upcoming releases of EB GUIDE we will further simplify the management of multiple models especially for the modeler.

By defining explicit interfaces of an EB GUIDE project a modeler will get the possibility to export and import this definition. Using this mechanism, the interaction between the models can be explicitly specified.

This will especially improve the collaboration between modelers and teams working together to create an outstanding HMI experience.

Start modeling now!

As always, the following resources have been updated and are now available:

Download the Community edition of EB GUIDE.

Read through our updated Release Notes.

Download updated user documentation.

Access updated tutorials here.

Download updated feature demo, examples and custom widgets.

Sign up for one of our EB GUIDE trainings now.