Embedded-Bedienoberflächen effektiver Realisieren Modellbasiertes HMI-Design

Beim Realisieren von Bedienoberflächen von Embedded Systemen liegt der größte Aufwand oft in den für die Anwender nicht oder kaum sichtbaren Service-, Einstellungs- und Wartungsmenüs. Mit modellbasierten Methoden und dem Einsatz von geeigneten, domänenspezifischen Codegeneratoren lässt sich die Entwicklung dieser Funktionen deutlich effizienter gestalten.

Der sogenannte »Eisberg-Effekt« ist im Zusammenhang mit vielen Softwarepaketen bekannt: Wie beim Eisberg, von dem nur ein Bruchteil über der Wasseroberfläche liegt und somit sichtbar ist, nutzen durchschnittliche Anwender meist nur einen kleinen Teil der Funktionen eines mächtigen Programms. Auch auf die Disziplinen Schnittstellenentwicklung und GUI-Programmierung (Graphical User Interface) trifft der Eisberg-Effekt meist zu: 20% des Umfangs einer Entwicklung bedient der Anwender im normalen Betrieb, 80% verstecken sich in Service-, Einstellungs- und Wartungsmenüs (Bild 2). Dabei sind die 20% meist gut beschrieben, bis ins Kleinste vom Usability-Experten und Schnittstellenentwickler ausgearbeitet und vom Kunden bestmöglich spezifiziert.

Anders verhält es sich mit den übrigen 80%: Diese Teile sind ungeliebt, mühsam, unsichtbar und sowieso scheinbar selten genutzt. Aber genau hier liegt das Potenzial für eine weiterreichende »User Experience«:

  • Effizienter und effektiver Zugriff auf die Einstellungen und
  • stringente Umsetzung eines Usability-Konzepts zur dramatischen Reduzierung von Servicezeiten und Setup-Fehlern.

Hierfür bieten sich eine gut strukturierte Segmentierung des Bildschirms und eine objektorientierte Analyse zur Identifikation von Bedienungsprimitiva an. Die »U-Experten« von Ultratronik haben diesen Ansatz in einem Referenzprodukt umgesetzt. Mit dem »FoamMaster FM800« hat Franke Coffee Systems (FCS), ein führender Hersteller professioneller, vollautomatischer Kaffeemaschinen, einen benutzerfreundlichen Kaffeevollautomaten für den nach eigener Ansicht ultimativ individuellen, weil variantenreichen Genuss auf den Markt gebracht (Bild 1).

Entstanden ist dieses Projekt aus der Entscheidung des Unternehmens, die etablierte Produktserie »Spectra« um ein Premiummodell mit neuen Features zu erweitern.

Der Vollautomat unterstützt unter anderem zwei Sorten Bohnen, Kakao, Milchschäumer (kalt und warm) sowie bis zu drei Sirup-Zusätze. Für die Bedienung, aber auch die Inbetriebnahme, Kalibrierung und Wartung der FM800 setzten die Entwickler der Bedienoberfläche folgende verschiedene Bildschirminhalte (Screens) um: 

  • etwa 50 Screens im Bereich Kaffeebezug, 
  • etwa 150 Screens für die Kalibrierung und Inbetriebnahme durch Servicetechniker und 
  • etwa 150 Screens im Bereich Maschinenpflege und Einstellungen durch angelerntes Personal.

Insbesondere im Bereich der zirka 300 Servicescreens (Bild 3) ist es wichtig, eine Stringenz in der Bedienung und Zuverlässigkeit in der Funktion zu erreichen, auch um dem Lerneffekt des erfahrenen Anwenders gerecht zu werden. In diesem Projekt gelang es zum Beispiel, die Dauer der Inbetriebnahme durch den Monteur trotz deutlich mehr Parameter auf weniger als die Hälfte des ursprünglichen Zeitaufwands zu reduzieren.

Codegenerator beschleunigt die Entwicklung

Aber wie lässt sich diese Strategie effizient umsetzen? Im Gegensatz zu den 50 Screens im Bereich Kaffeebezug, die sich durch die vielen abzubildenden Anwendungsfälle (Use Cases) deutlich unterscheiden und deshalb »konventionell« und individuell mit einem Zeitaufwand von etwa drei Mannjahren in QML umgesetzt wurden, bot sich für die umfangreiche Serviceebene ein anderes, vom Aufwand her deutlich optimiertes Vorgehen an. Denn eine konstante Struktur der Aufteilung des Bildschirms und definierbare Bedienungsprimitiva sind die idealen Voraussetzungen für einen Codegenerator-Ansatz.

Bislang jedoch fanden in diesen Fällen entweder gar keine oder aber universelle Codegeneratoren Anwendung. Deren Nachteile sind bekannt: 

  • unverhältnismäßig große Codebasis, 
  • schlechte Performance-Ergebnisse, insbesondere im Embedded-Bereich, und 
  • schlechte Unterstützung von Tools wie QML (Qt Meta Language) oder Qt. 

Das bei den U-Experten verwendete Tool »Meta Genius« von Papa Lima ermöglicht hingegen, eine domänenspezifische Modellierungs- und Codegenerierungslösung zu erstellen, mit der sich diese Probleme vermeiden lassen. Das Grundkonzept unterscheidet sich bereits in der Zielrichtung der Modellierung, denn es wird nicht die Softwarelösung in dem Meta-Modell abgebildet, sondern eine strukturierte Erfassung der Anforderungen. Die Beschreibung der Oberflächen erfolgt daher in einer strukturierten Form, die im Wesentlichen die hierarchische Struktur des Menüs, aber auch die Variablen, Signale, Abhängigkeiten, Grenzwerte und vieles mehr umfasst. Diese formal strukturierten Anforderungen (Requirements) garantieren, dass alle Randbedingungen und Parameter vollständig erfasst sind, und erlauben andererseits, dass Kunden gegebenenfalls effektiv mitwirken können. Ähnlich wie bei einer Firmendatenbank ist der Programmierer für die Art und Struktur der Daten verantwortlich, der Anwender für das »Auffüllen« mit den spezifischen Werten und Daten.

Die Entwicklung und Anpassung des Generators basiert auf einer Anzahl von Transformationen von einem Zwischen-Meta-Modell zum nächsten bis hin zur finalen Erzeugung des Zielcodes. Dieser weist folgende Eigenschaften auf: 

  • Codegröße und Ablaufgeschwindigkeit wie manuell codiert, 
  • voll funktionsfähiger Code, 
  • keine leeren Funktionsstubs, 
  • die Ausgabe lässt sich direkt in das Komplettprojekt integrieren und so für jeden Teilbereich das optimale Vorgehen wählen, 
  • Unterstützung der gewünschten Zielcodierung, in diesem Falle C++, QML, Qt sowie Word-Dokumente (Pflichtenhefte, Dokumentation) und 
  • Wiederverwendung insbesondere von Backend-Transformationen. 

Softwareentwickler, die den Code normalerweise manuell programmiert hätten, nahmen die Anpassungen nach entsprechender Einarbeitung vor. Insgesamt wurde hierfür ein Mannjahr aufgewendet. Die in den Zwischen-Meta-Modellen abgebildeten Primitiva wurden auf der Basis eines ausgearbeiteten Interface-Designs konventionell entwickelt und in den Generator eingebunden.

Durch den domänenspezifischen Ansatz der Codegenerierung im Bereich von Service Menüs konnte Folgendes erreicht werden: 

  • Der Aufwand in der Umsetzung ließ sich in Summe von 15 Manntagen pro Screen auf einen Manntag pro Screen senken, insbesondere da Änderungen und Erweiterungen nicht zu maßgeblichem Programmieraufwand führten. 
  • Die geringe Fehlerreportrate (nur 5% aller Bugreports betrafen die Servicescreens) belegt die erwarteten positiven Nebeneffekte wie gute Testbarkeit, hohe Codequalität und zwangsläufige Übereinstimmung der Software mit dem Pflichtenheft. 

Bei zukünftigen Projekten wird die Erfassung von tabellarischen Anforderungen schon beim Kunden in Meta Genius erfolgen, um frühzeitig Konsistenz und Vollständigkeit bei zusätzlicher Effizienzsteigerung zu gewährleisten.

Über den Autor:

Ralf Nebel ist Consultant Technologie bei Ultratronik.