Embedded Grafik Visualisieren ohne programmieren

Die Anforderungen und Wünsche an die Qualität und Features industrieller Mensch-Maschine-Schnittstellen steigen ständig. Hier setzten Vorbilder aus der Unterhaltungselektronik Maßstäbe. mit der Umsetzung dieser Grafikanforderungen sind Maschinenprogrammierer jedoch in der Regel überfordert.

Smartphones haben unser Bedienverhalten grundlegend geändert. Das wirkt sich zunehmend auch auf andere Bereiche aus. Ansprechende, animierte Objekte sind inzwischen auch für Embedded-Anwendungen zunehmend von Interesse. Dazu werden unter anderem aufwendige Grafiken mit Farbverläufen, Schattenwürfen, 3-D-Darstellung, animierte Objekte für bewegte Darstellungen von Prozesszuständen oder Touch-Funktionen benötigt. Programmierer von Maschinenprozessen sind mit der Umsetzung dieser Grafikanforderungen in der Regel überfordert.

Angenommen, es sei eine neue Maschine zu entwickeln und im Rahmen dessen ist auch eine Bedienung beziehungsweise Visualisierung zu realisieren. Nach intensiver Analyse der zu erledigenden Aufgaben und der zur Verfügung stehenden Lösungen, werden sich folgende Kernpunkte herauskristallisieren:

  • Datenbehandlung: Primär ist zu klären, welche Daten visualisiert werden müssen und wie der Zugriff auf diese Daten erfolgt. Für die spätere Anzeige müssen die Wertebereiche, Grenzwerte und Datentypen ermittelt beziehungsweise festgelegt werden. Nicht zuletzt wollen diese Daten auch noch verwaltet und organisiert werden. 
  • Darstellung: Für die Darstellung wird ein Anzeigemedium ausgewählt. Dies kann eine lokale Grafik, ein PC mit Windows oder ein Webbrowser sein. Entsprechend der Möglichkeiten des gewählten Ausgabemediums müssen die Bildschirmmasken aufgebaut werden. 
  • Interaktionen: In vielen Fällen ist eine Interaktion mit dem Bediener erforderlich. Die Ereignisse, die vom Bediener ausgelöst werden, müssen also weitergereicht oder behandelt werden. 

Die Abarbeitung dieser Aufgaben erfolgt meistens in einem individuellen Programm, das unter Zuhilfenahme einer Hochsprache erstellt wird. Hierfür stehen gemeinhin hohe Investitionskosten an: hochqualifizierte Programmierer, Zeit etc.

Bei genauer Betrachtung der Aufgaben des Visualisierungsprogramms ist festzustellen, dass für viele Visualisierungs- und Bedienaufgaben sehr ähnliche Voraussetzungen anzutreffen sind und auch ähnliche logische Abläufe realisiert werden müssen. Warum also nicht diese Aufgaben durch ein Modell beschreiben und dieses Modell in einem allgemeinen Visualisierungsprogramm abbilden? Die individuellen Unterschiede der Visualisierungsaufgaben lassen sich in einer Konfigurationsdatei erfassen und von einem Visualisierungsprogramm zur Laufzeit interpretieren.
Das Abbilden der Aufgaben in einem Modell erfordert einige Voraussetzungen:

  • Die Visualisierungslogik muss autark lauffähig und entkoppelt von der Ablauflogik der Maschine sein (Bild 1). 
  • Die Visualisierungslogik muss automatisch generiert werden können. 
  • Interaktionen mit der Ablauflogik der Maschine erfolgen ausschließlich über eine Datenrepräsentanz im Datenmodell. 
  • Es muss eine Möglichkeit geschaffen werden, die es erlaubt, individuelle Anzeige- und Bedienobjekte zu entwerfen und diese zu dynamisieren, ohne expliziten Programmcode einer Hochsprache zu verwenden. 

Ablauflogik von der Hardware trennen

Um Visualisierungsaufgaben von der Ablauflogik und der Hardware einer Maschine sauber zu trennen, sind die Daten zu abstrahieren. Dies erfolgt in einer Zwischenschicht (Middleware), die alle für die Visualisierung und Bedienung der Maschine benötigten Größen verwaltet und zur Verfügung stellt. Mit Hilfe der Abstraktionsschicht können auch verschiedene Standards eingebunden und unterstützt werden, zum Beispiel »OPC UA«, »Gamma«, lokale Datenmodelle, Soft-SPS usw.

In der Middleware werden in hierarchisch organisierten Strukturen Variablen angelegt. Jede Variable lässt sich über ihren Namen adressieren. Eine Variable repräsentiert unter anderem einen Wert (physikalischer Wert, Zustand, Text etc.), einen Zeitstempel, optional Grenzwerte für Skalierungen und den Datentyp. Für Interaktionen mit der Ablauflogik der Maschine besteht die Möglichkeit, Variablen für bidirektionale Verwendung zu definieren. Diese Variablen lassen sich durch eine Benutzereingabe ändern. Dadurch kann die Ablauflogik auf Ereignisse reagieren.

Das eigentliche Herz der Visualisierung ist das Visualisierungsmodell (Bild 2). Im Modell sind alle Regeln, die für Visualisierungen nötig sind, festgelegt. Das Regelwerk des Modells ist als Programmlogik im Visualisierungsprogramm komplett abgebildet. Das Visualisierungsprogramm lädt nach dem Start aus einer Konfigurationsdatei sein individuelles Regelwerk. Somit weiß das Programm, welche Variablenwerte wann und wo angezeigt werden sollen. Es werden die in der Konfiguration spezifizierten Bildschirmmasken geöffnet, die zugehörigen Variablen ermittelt und deren Werte zur Weitergabe an Anzeigeobjekte aufbereitet. Die Variablenwerte erfahren eine Transformation vom ursprünglichen Wertebereich in den Wertebereich des Anzeigeobjektes.

Zu den Aufgaben des Visualisierungsprogramms zählt auch das Handling von Benutzereingaben. Sobald der Benutzer ein Ereignis auslöst, wird die Reaktion darauf in der Konfiguration gesucht. Mögliche Aktionen könnten sein: Manipulieren einer Variablen, Ändern eines Objektes, Umschalten der Landessprache, Öffnen oder Schließen von Bildschirmmasken usw.

Der HMI-Editor ist ein Werkzeug, mit dem sich Bildschirmmasken und das zugehörige Regelwerk für die Visualisierung erstellen lassen. Solche Masken setzen sich aus Standardobjekten und in letzter Zeit immer häufiger aus kundenspezifischen Objekten zusammen. Mit dem HMI-Editor wählt der Entwickler Objekte aus und platziert sie in einer Bildschirmmaske. Nach dem Platzieren kann er die Eigenschaften der Objekte einstellen. Zu diesen Eigenschaften zählen unter anderem Verknüpfungen mit Variablen und Reaktionen auf Benutzereingaben. Der HMI-Editor ist auch bei der Erzeugung und Verwaltung von hierarchischen Variablenstrukturen, wie sie in der Middleware verwendet werden, behilflich. Es lassen sich sowohl Variablenstrukturen importieren als auch neue Variablen erzeugen.

Die größte Herausforderung zur Umsetzung des Konzeptes ist die Unterstützung von individuellen, dynamisierbaren Objekten. Immer öfter verlangen Kunden Objekte, die in Funktion und Aussehen genau ihren Vorgaben entsprechen. Üblicherweise entwerfen Designer die Objekte, Programmierer erstellen die nötige Software für die Dynamik. Diese Vorgehensweise ist sehr zweitaufwendig und damit kostenintensiv. Eine Lösung dieser Problematik sind Objekte, welche die Logik in Form einer eingebetteten Interpretersprache beinhalten, die zur Laufzeit interpretiert wird.

Aus diesem Grund wurde eine erweiterte Beschreibungssprache für Vektorobjekte entwickelt. Diese Sprache ist im Objekteditor von XiSys, der wie ein Zeichenwerkzeug verwendet werden kann, vollständig abgebildet. Somit ist ein Designer in der Lage, die Dynamisierungslogik schon während der Entwurfsphase im Objekt selbst zu hinterlegen.

Dynamisieren ohne Hochsprache

Eine weitere wichtige Eigenschaft ist die Sprachunabhängigkeit der Objekte. Daher müssen die Objekte zu jedem Zeitpunkt ihre textbasierten Einträge selbstständig durch Einträge einer anderen Sprache austauschen können. Dies lässt sich durch das Einführen von nachträglichen Verweisen auf Textobjekte in einer Ressource bewerkstelligen. So kann einem Objekt durch den HMI-Editor ein individueller Texteintrag nachträglich zugewiesen werden. Mit diesen Verweisen lässt sich auch die Sprachumschaltung »on the fly« jederzeit durchführen.

Wie erfolgt die Dynamisierung von Objekten ohne Hochsprache? Dynamisiert wird durch Ändern des Wertes eines sogenannten Animationseintrages. Animationseinträge sind Vektoren, die mit einem ASCII-Namen adressiert werden. In Animationseinträgen werden Wertebereiche für die interne Skalierung und externe Repräsentation festgelegt. Außerdem kann zwischen verschiedenen Verhaltensmustern ausgewählt werden (z.B. Animation via Maus, Touch, Software etc.). Beschreibende Vektoren legen geometrische Eigenschaften fest, wie den Ort oder den Rotationswinkel. Zusätzlich bestimmen sie auch optische Eigenschaften wie Farben, Schatten, Transparenz und ähnliche. Alle Eigenschaften lassen sich durch Referenzieren auf einen Animationseintrag manipulieren. Folglich werden durch Ändern des Wertes eines Animationseintrages alle Eigenschaften von Vektoren, die sich auf diesen Eintrag beziehen, gleichzeitig geändert. Das Animieren eines Objektes wird durch Softwarebefehle aus einem Programm, die Verknüpfung mit einer Variablen oder durch eine Benutzereingabe via Maus oder Touch angestoßen.

Damit werden Visualisierungsaufgaben durch ein Modell beschrieben und in einem Visualisierungsprogramm abgebildet. Wiederkehrende Programmierarbeiten in einer Hochsprache entfallen. Der HMI-Editor übernimmt als Maskengenerator und Verknüpfungswerkzeug die gestalterischen Aufgaben und erzeugt das Regelwerk für das Visualisierungsprogramm. Die neue Programmiersprache für dynamisierbare Objekte in Verbindung mit dem Objekteditor ermöglicht es dem Grafikdesigner, Objekte zu entwickeln und selbstständig mit Leben zu erfüllen. Somit entfallen alle Programmierarbeiten zu Gunsten von Konfigurationsarbeiten. Diese neue Methode – Visualisieren ohne zu Programmieren – hat das Potenzial, 80% bis 90% des Entwicklungsaufwandes für traditionelle Embedded-Grafiksysteme einzusparen.

Über den Autor:

Klaus Gerstendörfer ist Geschäftsführer von XiSys Software.