Bild 1: Designstudie für eine mit E-Tools-HMI erstellte Bedienoberfläche: Das Startmenü erinnert an die Windows 8-Kacheln. Dank großer Buttons und farblicher Gruppierung zu Funktionsgruppen interagiert der User wie bei der Bedienung eines Tablet-PCs.

© Eckelmann

Der Wunsch nach immer größerer Individualität macht auch vor dem Maschinen- und Anlagenbau nicht halt. Dieser Trend wird häufig unter Begriffen wie „Personalisierung“ oder „Losgröße 1“ subsumiert. So wie man bei Autos heutzutage aus unzähligen Ausstattungsvarianten auswählen kann, erwarten auch Kunden von Maschinenbauern vermehrt perfekt auf sie zugeschnittene Lösungen. Wobei es nicht nur um eine besondere Optik oder Bedienphilosophie geht, sondern auch darum, dass sich die Bedienung optimal der jeweiligen Technologie und den spezifischen Eigenschaften der Maschine anpassen lässt. Denn die Bedienung ist ein essenzieller Bestandteil der Lösung, sie erst macht die Maschine komplett und entscheidet wesentlich mit über ihren Gebrauchswert. Hinzu kommt die Forderung nach Freiheit in der grafischen Umsetzung der Bedienoberfläche gemäß dem Corporate Design und hinsichtlich des Interaktions-Designs. Denn darüber lässt sich eine eigene Markenidentität aufbauen und diese mit einem positiven Nutzer­erlebnis verknüpfen. Aus der Unterhaltungselektronik ist dieser Effekt hinlänglich bekannt. Von dieser Strategie kann dank neuer Ansätze in der HMI-Programmierung auch der Maschinenbau profitieren. Nutznießer dieses Trends ist letztendlich immer der Anwender, denn die Bedienung von Maschinen wird dadurch komfortabler; vorausgesetzt allerdings, die grafische Bedienoberfläche ist gut durchdacht und erfüllt die praktischen Anforderungen, die in Anwendungsfällen genau definiert wurden (siehe Bild 1).

Anbieter von Automatisierungslösungen für CNC-Maschinen wie Eckelmann stellen sich auf die neuen An­forderungen an die Flexibilität der HMI-Programmierung ein, indem sie moderne Werkzeuge zur Erstellung solcher Bedienoberflächen entwickeln. Es geht hierbei allerdings um weit mehr als nur das „Look and Feel“, es geht um eine grundsätzlich neue Betrachtungsweise von User-Interfaces. Die eigent­liche Herausforderung ist nämlich, dass der Spagat zwischen der universellen Einsetzbarkeit einer CNC-Steuerung und den sehr unterschiedlichen individuellen Anforderungen einer konkreten Bedienapplikation gelingt. Damit dies glückt, ist die Architektur der Software-Basis von entscheidender Bedeutung. Die Wahl einer geeigneten Architektur wird jedoch dadurch erschwert, dass eine Vielzahl verschiedener Techno­logien, Frameworks und Software-Paradigmen existiert, die alle spezifische Vor- und Nachteile haben.

Im Fol­genden werden die Erfahrungen und Vorgehensweisen erörtert, die bei der Entwicklung des neuen Werkzeuges namens E-Tools HMI gesammelt wurden.

Jeder Applikation ein User-Interface

Eine Basis für CNC-Bedienoberflächen zu erstellen, konfrontiert die Software-Entwickler mit ganz besonderen Anforderungen:

• Es gibt keinen starren Bedienablauf.
• Es gibt keinen starren Funktionsumfang.
• Der Umfang der zu visualisierenden Daten ist hochgradig variabel.
• Es sind komplexe Bedien- und Anzeige-Elemente notwendig (Anzeige des gerade ausgeführten DIN-Programms, Restdauerberechnung).
• Kunden-Module sollen sich einfach einbinden lassen.
• Das Design aller Bedien- und Anzeige-Elemente muss einfach an Kundenwünsche anpassbar sein.

Um nicht von der Komplexität der Entwicklung und Pflege der verschiedenen Varianten der Bedienoberfläche verschlungen zu werden, sind neue Programmieransätze gefragt. Eine zentrale Herausforderung ist dabei, dass es möglich sein muss, einer bestehenden Bedienoberfläche mit einfachen Mitteln ein neues Look&Feel zu geben. Nicht zuletzt deshalb, weil ein zeitgemäßes Design und die Benutzerfreundlichkeit von Bedienoberflächen und Visualisierungen für Maschinenbauer als Verkaufsargument an Bedeutung gewinnen. Aber auch weil Screendesigns mehr als früher Moden unterworfen sind, so dass aktuell zeitgemäße Bedienoberflächen schnell „alt aussehen“. Gerade die starke Verbreitung von Tablet-PCs und Smartphones hat diese Entwicklung verschärft und zu einer hohen Erwartungshaltung an Bedien­oberflächen geführt: Transitionseffekte, Gestensteuerung, Multitouch und anspruchsvolle Optik sind nur einige Beispiele dafür.

Ein erneuertes Screendesign für eine bestehende Bedienoberfläche ist mit den meisten heutigen HMI-Tools allerdings nur mit äußerst großem Aufwand zu stemmen, weil Präsentation und Geschäftslogik nicht unabhängig vonei­nander sind.

Wesentlicher für den Maschinenbauer ist allerdings, dass er einer Bedienoberfläche Funktionen hinzufügen oder diese entfernen kann, ohne dass die Optik oder Bedienbarkeit darunter leidet. Denn nur mit dieser Flexibilität lässt sich ein HMI gestalten, das perfekt auf die Anforderungen der Maschine zugeschnitten ist.

Und um mit geringem Aufwand ein konsistentes HMI zu pflegen, ist die Möglichkeit unabdingbar, Funktionen, also Code, zu aktualisieren und diese Aktualisierung in alle bestehenden Oberflächen einfließen zu lassen, ohne jede Anwendung einzeln anpassen zu müssen.

Trennung von Anwendungsschichten

Die Lösung liegt in einer strikten Trennung von Funktionalität und Darstellung sowie der Nutzung moderner UI-Frameworks. So wird es auf der einen Seite möglich, die Darstellung zu ändern, ohne dass Code angepasst werden muss. Der Maschinenbauer kann somit die Bedienoberfläche auf seine Bedürfnisse zuschneiden, ohne dass er dafür Zugriff auf den Source-Code der Bedienoberfläche benötigt. Auf der anderen Seite ist es dem Automatisierungshersteller möglich, Code zu ändern, also beispielsweise Updates durchzuführen, ohne dass er jede individuelle Bedienoberfläche modifizieren muss.

Model-View-ViewModel

Das Model-View-ViewModel-Paradigma überwindet die Nachteile der klassischen (HMI-)Programmierung. MVVM setzt auf dem Model-View-Controller-Ansatz auf und unterteilt eine Software in das Model (das betrifft die Anbindung der CNC-Steuerung, die Bereitstellung von Funktionen wie Firmware-Downloads, die Anzeige von Werten), das ViewModel für die Geschäftslogik und die eigentliche Präsentation (View), also die Beschreibung des Bildschirmlayouts sowie der einzelnen UI-Elemente.

Bild 2: Das Prinzip des Model-View-ViewModel-Ansatzes

© Eckelmann

Dabei ist wichtig, dass die Bindung in eine Richtung als referenzielle Bindung erfolgt und in die andere Richtung als Nachrichtenbindung (siehe Bild 2). Diese zweigeteilte Art der Bindung sorgt dafür, dass das ViewModel die Views nicht kennen muss. Die Views können also ohne Rückwirkung auf das ViewModel ausgetauscht werden.

Am Beispiel der Anzeige der Vorschubgeschwindigkeit lässt sich dies leicht nachvollziehen. Das Model als eigentliche Datenzugriffsschicht sorgt dafür, dass die Vorschubgeschwindigkeit aus der Steuerung ausgelesen wird. Das ViewModel liest die Vorschubgeschwindigkeit über die entsprechenden Methoden zyklisch aus und verschickt bei einer Änderung eine Nachricht. Eine oder mehrere Views referenzieren das Model und empfangen so die Benachrichtigungen über die Änderung der Vorschubgeschwindigkeit und stellen diese Änderung grafisch dar, beispielsweise als Balkenanzeige oder numerisch.

Aussehen, Bedienphilosophie und Zusammenstellung von Bedienelementen lassen sich durch diese strikte Trennung und den standardisierten und einseitig referenzierten Datenaustausch vollkommen unabhängig voneinander ändern und austauschen. Das Programmierparadigma selber beschreibt allerdings nur die generelle Architektur. Nachdem das Programmierparadigma feststeht, gilt es, geeignete Frameworks für die grafische Darstellung und die Einbindung von Kundenfunktionen zu finden.

Windows Presentation Foundation

Als nächstes steht die Auswahl und Bewertung eines UI-Frameworks an. Dieses Framework sorgt für die Interaktion mit dem Bediener, also die grafische Darstellung und die Behandlung von Benutzereingaben. Am Markt gibt es eine Vielzahl von Frameworks, wie beispielsweise WinForms, Visual Component Library, Qt und Windows Presentation Foundation.

Eckelmann hat sich für das UI-Framework WPF (Windows Presentation Foundation) entschieden. Das Framework muss natürlich das MVVM-Programmierparadigma und die Trennung von Funktion und Darstellung unterstützen. Die stufenlose Skalierbarkeit durch Vektorgrafik spielt eine weitere wichtige Rolle bei der Auswahl. Der Automatisierungs-Lieferant weiß im Vorfeld nicht, mit welchen Displaygrößen ein Maschinenbauer seine Werkzeugmaschine ausrüsten möchte und muss deshalb eine Bedienoberfläche zur Verfügung stellen, die in verschiedenen Auflösungen läuft und unter den gegebenen Rahmenbedingungen den jeweils bestmöglichen Nutzen bietet.

Durch die stufenlose Skalierbarkeit sehen die User-Interfaces unabhängig von der Auflösung immer gut aus, da alle Elemente sich der jeweiligen Auflösung anpassen und in dieser erst gerendert werden. Treppeneffekte und verwaschene Bilder beim Zoomen und Verschwinden von Details und Beschriftungen beim Verkleinern: All diese bekannten Nachteile von Rastergrafiken gehören somit endgültig der Vergangenheit an.

Und schlussendlich nutzt WPF die Schnittstelle DirectX, über die vorhandene Grafikbeschleuniger automatisch eingebunden werden. Als angenehmer Nebeneffekt der Nutzung von DirectX werden nicht nur 2D-, sondern auch 3D-Grafiken nativ unterstützt. Dies ist ein weiterer großer Vorteil gegenüber anderen UI-Frameworks, die teilweise noch die mittlerweile veraltete GDI-Schnittstelle nutzen und damit die Möglichkeiten moderner Chipsätze mit Hardware-Beschleunigung brachliegen lassen.

Eine zunehmend wichtige Rolle spielt, neben den normalen Bedienelementen, Multimedia-Inhalte einbinden zu können. WPF bietet nativ die Möglichkeit, an beliebigen Stellen Medien einzubinden, wie beispielsweise Videos im WMV oder MPEG-Format oder Dokumente, etwa im XPS-Format. Am interessantesten ist dieses Feature sicher für die Online-Hilfe und die Unterstützung des Maschinenbedieners bei der Fehlerbehebung.

Durch die Trennung von Funktion und Darstellung lässt sich darüber hi­naus der automatische Unit-Test enorm vereinfachen. Da der automatische Test von Software zunehmend an Bedeutung gewinnt, ist dies ein nicht zu vernachlässigender Vorteil. Für den automatischen Test muss das HMI, das normalerweise Benutzereingaben verarbeitet, eine Anregung von außen bekommen. Ebenso müssen die Reaktionen, die der Benutzer normalerweise auf dem Bildschirm sieht, automatisch ausgewertet werden. Durch die Trennung von Funktion und Darstellung lässt sich die Funktion testen, indem statt der Darstellung ein Testframework angekoppelt wird, das automatisch die Vorgabewerte erzeugt und Reaktionen auswertet.

Um den Programmieraufwand trotz der vielen Bindungen zwischen den Views und dem ViewModel gering zu halten, sollte ein Composition-Framework verwendet werden. Hier fiel die Wahl auf Caliburn.Micro; andere Composition Frameworks sind Cinch, Prism oder CAB.

Technologiespezifische Anpassungen

Die Eckelmann-CNC unterstützt eine große Anzahl an Technologien, was bei der Entwicklung des HMI-Tools zu berücksichtigen war. Während Anwendungen wie Stabbearbeitungszentren und Handlingsysteme hauptsächlich eine Auftragsverwaltung und Anbindung an Leitsysteme benötigen, sind bei Technologien wie dem Brennschneiden und der Laserbearbeitung umfangreiche technologiespezifische Einstellungen nötig.

Bild 3: Über das Managed Extensibility Framework (MEF) lassen sich Erweiterungen zur Laufzeit quasi wie Plug-ins einbinden.

© Eckelmann

Aus diesem Grund wurden alle Funktionen über Interfaces untereinander verbunden. Erst zur Laufzeit erfolgt die Verknüpfung der benötigten Dienste über das Managed Extensibility Framework (MEF), ähnlich wie bei Plug-ins. Diese Erweiterungen können von verschiedenen Anwendungen eingebunden werden. Dabei bietet MEF nicht nur Funktionen zum Darbieten oder Einbinden von Funktionen, sondern beinhaltet auch Funktionen zum Lokalisieren und Laden von Erweiterungen. Damit ist MEF ideal darauf zugeschnitten, technologiespezifische Zusatzmodule in eine Bedienoberfläche einzubinden.

Die Geschäftslogik, die beispielsweise die Parametrierung einer Plasma-Stromquelle steuert, kann über MEF eingebunden werden, ohne dass der Sourcecode der ursprünglichen Bedienoberfläche vorliegen muss oder eine erneute Compilierung notwendig ist.

Auf dem gleichen Weg lassen sich daneben kundenspezifische Erweiterungen von Applikationsingenieuren oder vom Kunden selber einbinden, ohne dass der Sourcecode vorliegen oder zugänglich gemacht werden muss. Ebenso einfach können Aktualisierungen einzelner Komponenten eingespielt werden.

Ein weiteres Beispiel für eine Erweiterung ist die Live-Anzeige eines Kamerabildes, beispielsweise bei optischen Inspektionssystemen oder einer in die Werkzeugmaschine integrierten Bildverarbeitung zur Lage- oder Restmaterial-Erkennung.

Auch wenn ein Maschinenbauer seine Bedienoberfläche komplett selbst entwickeln möchte, kann er von dem E-Tools-HMI profitieren. Denn es be­inhaltet ein Maschinenmodell in C# als Bibliothek, die die komplette Kommunikation mit der Steuerung abwickelt und es erlaubt, sämtliche Funktionen vom Programm-Download bis zur Echtzeit-Statusanzeige zur Verfügung zu stellen. Neben dem Maschinenmodell steht ein Threading-Konzept zur Entkopplung von Logik und Präsentation zur Verfügung sowie Interface-Techniken und eine Basis zur einfachen Anbindung von Prozessdaten aus der CNC und der SPS.

Autoren: Dr. Marco Münchhof leitet die Systement­wicklung bei Eckelmann,
Thomas Traiser ist Leiter HMI-Software bei Eckelmann.