Herzlich Willkommen beim beam-Verlag in Marburg, dem Fachverlag für anspruchsvolle Elektronik-Literatur.


Wir freuen uns, Sie auf unserem ePaper-Kiosk begrüßen zu können.

Aufrufe
vor 5 Jahren

3-2014

  • Text
  • Electronic
  • Elektronik
  • Embedded
  • Software
  • Bressner
  • Electronics
PC & Industrie 3/2014 mit Einkaufsführer Embedded Systeme

Bedienen und

Bedienen und Visualisieren Embedded Grafik – Visualisieren ohne zu Programmieren Die Anforderungen und Wünsche an die Anzeigequalität und Bedienmöglichkeiten moderner Mensch- Maschine-Interfaces von Anlagen oder Geräten steigen ständig. Hier setzten Vorbilder aus der „Consumerwelt“, wie SmartPhones Maßstäbe. Ansprechende, animierte Objekte sind inzwischen auch für embedded Anwendungen zunehmend von Interesse. Dazu werden u.a. aufwendige Grafiken mit Farbverläufen, Schattenwürfen, 3D-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. Mit der modellorientierten Methode „Visualisieren ohne zu Programmieren“ gibt es einen neuen Ansatz, schneller und kostengünstiger ans Ziel zu gelangen. Durch das Abbilden der Visualisierungsaufgaben in einem Modell und dem daraus resultierenden Wegfall der Hochsprachenprogrammierung reduziert sich der Aufwand zum Erstellen einer Visualisierung auf das grafische Design von Objekten und Bildschirmmasken und deren Verknüpfung mit den zu visualisierenden Daten. Die Aufgabe Es soll eine neue Maschine entwickelt werden. Dazu zählt auch die Realisierung einer Bedienung bzw. Visualisierung. Nach intensiver Analyse der zu erledigenden Aufgaben und der zur Verfügung stehenden Autor: Klaus Gerstenhöfer, Geschäftsführer XiSys Software GmbH Bild 1: Entkoppelung der Visualisierung von der Maschinenlogik durch die Middleware Lösungen werden sich folgende Kernpunkte herauskristallisieren: 1) 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 bzw. festgelegt werden. Nicht zuletzt wollen diese Daten auch noch verwaltet und organisiert werden. 2) 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. 3) Interaktionen: In vielen Fällen ist eine Interaktion mit dem Bediener erforderlich. D.h. es müssen die Ereignisse, die vom Bediener ausgelöst werden, weitergereicht oder behandelt werden. Die Abarbeitung dieser Aufgaben erfolgt meistens in einem individuellem Programm, welches unter Zuhilfenahme einer Hochsprache erstellt wird. Hierfür stehen gemeinhin hohe Investitionskosten an: hochqualifizierte Programmier, Zeit, ... 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. Abbilden der Aufgaben in einem Modell Das Abbilden der Aufgaben in einem Modell erfordert einige Voraussetzungen: 1) Die Visualisierungslogik muss autark lauffähig und entkoppelt von der Ablauflogik der Maschine sein. 2) Die Visualisierungslogik muss automatisch generiert werden können. 3) Interaktionen mit der Ablauflogik der Maschine erfolgen ausschließlich über eine Datenrepräsentanz im Datenmodell. 4) 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. Um Visualisierungsaufgaben von der Ablauflogik und der Hardware einer Maschine sauber zu trennen, ist eine Abstrahierung der Daten zwingend notwendig (Bild 1). Das Abstrahieren 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, wie z.B. OPC UA, Gamma, lokale Datenmodelle, Soft-SPS usw. In der Middleware werden in hierarchisch organisierten Strukturen Variablen angelegt. Jede Variable kann über ihren Namen adressiert werden. Eine Variable repräsentiert unter anderem einen Wert (physikalischer Wert, Zustand, Text, ...), einen 38 PC & Industrie 3/2014

Bedienen und Visualisieren Bild 2: Das Visualisierungsmodell und seine Schnittstellen 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 können durch eine Benutzereingabe geändert werden. Dadurch kann die Ablauflogik zu Reaktionen auf Ereignisse veranlasst werden. Das Visualisierungsmodell Das eigentliche Herz der Visualisierung ist das Visualisierungsmodell. 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 es wann und wo angezeigen 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 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 Landes- sprache, Öffnen oder Schließen von Bildschirmmasken, usw. (Bild 2). Erstellen der Bildschirmmasken Der HMI-Editor ist ein Werkzeug, mit welchem Bildschirmmasken und das zugehörige Regelwerk für die Visualisierung erstellt werden. Bildschirmmasken werden aus Standardobjekten und in letzter Zeit immer häufiger aus kundenspezifischen Objekten aufgebaut. Mit dem HMI- Editor werden Objekte ausgewählt und in einer Bildschirmmaske platziert. Nach dem Platzieren können die Eigenschaften der Objekte eingestellt werden. 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 können Variablenstrukturen importiert, als auch neue Variablen erzeugt werden. Individuelle dynamisierbare Objekte 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 erfordert einen hohen Zeitaufwand mit damit verbundenen Kosten. 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. Eine weitere wichtige Eigenschaft ist die Sprachunabhängigkeit der Objekte. D.h. die Objekte müssen zu jedem Zeitpunkt in der Lage sein textbasierte Einträge selbständig durch Einträge einer anderen Sprache auszutauschen. Die Realisierung dieser Aufgabe erfolgt durch das Einführen von nachträglichen Verweisen auf Textobjekte in einer Ressource. 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. Dynamisierung von Objekten ohne Hochsprache Im Folgenden werden die Grundzüge der Dynamisierung von Objekten ohne Hochsprache beschrieben. Dynamisiert wird durch Ändern des Wertes eines sog. Animationseintrages. Letztere 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, ...). Beschreibende Vektoren legen geometrische Eigenschaften, wie den Ort oder den Rotationswinkel fest. Zusätzlich bestimmen sie auch optische Eigenschaften wie Farben, Schatten, Transparenz usw. Alle Eigenschaften können durch Referenzieren auf einen Animationseintrag manipuliert werden; d. h. durch Ändern des Wertes eines Animationseintrages werden alle Eigenschaften von Vektoren, die sich auf diesen Eintrag beziehen, gleichzeitig geändert. Das Animieren eines Objektes wird angestoßen durch Softwarebefehle aus einem Programm, die Verknüpfung mit einer Variablen oder durch eine Benutzereingabe via Maus oder Touch. Fazit Die Vorteile dieses neuen Ansatzes liegen auf der Hand. Visualisierungsaufgaben werden 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 selbstä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 - 90% des Entwicklungsaufwandes für traditionelle embedded Grafiksysteme einzusparen. • XiSys Software GmbH www.xisys.de PC & Industrie 3/2014 39

Fachzeitschriften

12-2019
12-2019
5-2019
4-2019
4-2019

hf-praxis

12-2019
11-2019
10-2019
9-2019
8-2019
7-2019
6-2019
5-2019
4-2019
3-2019
2-2019
1-2019
EF 2019-2020
Best_Of_2018
12-2018
11-2018
10-2018
9-2018
8-2018
7-2018
6-2018
5-2018
4-2018
3-2018
2-2018
1-2018
EF 2018/2019
12-2017
11-2017
10-2017
9-2017
8-2017
7-2017
6-2017
5-2017
4-2017
3-2017
2-2017
1-2017
EF 2017/2018
12-2016
11-2016
10-2016
9-2016
8-2016
7-2016
6-2016
5-2016
4-2016
3-2016
2-2016
1-2016
2016/2017
12-2015
11-2015
10-2015
9-2015
8-2015
7-2015
6-2015
5-2015
4-2015
3-2015
2-2015
1-2015
12-2014
11-2014
10-2014
9-2014
8-2014
7-2014
6-2014
5-2014
4-2014
2-2014
1-2014
12-2013
11-2013
10-2013
9-2013
8-2013
7-2013
6-2013
5-2013
4-2013
3-2013
2-2013
12-2012
11-2012
10-2012
9-2012
8-2012
7-2012
6-2012
4-2012
3-2012
2-2012
1-2012

PC & Industrie

EF 2020
12-2019
11-2019
10-2019
9-2019
1-2-2019
8-2019
7-2019
6-2019
5-2019
4-2019
3-2019
EF 2019
EF 2019
12-2018
11-2018
10-2018
9-2018
8-2018
7-2018
6-2018
5-2018
4-2018
3-2018
1-2-2018
EF 2018
EF 2018
12-2017
11-2017
10-2017
9-2017
8-2017
7-2017
6-2017
5-2017
4-2017
3-2017
1-2-2017
EF 2017
EF 2017
11-2016
10-2016
9-2016
8-2016
7-2016
6-2016
5-2016
4-2016
3-2016
2-2016
1-2016
EF 2016
EF 2016
12-2015
11-2015
10-2015
9-2015
8-2015
7-2015
6-2015
5-2015
4-2015
3-2015
2-2015
1-2015
EF 2015
EF 2015
11-2014
9-2014
8-2014
7-2014
6-2014
5-2014
4-2014
3-2014
2-2014
1-2014
EF 2014
12-2013
11-2013
10-2013
9-2013
8-2013
7-2013
6-2013
5-2013
4-2013
3-2013
2-2013
1-2013
12-2012
11-2012
10-2012
9-2012
8-2012
7-2012
6-2012
5-2012
4-2012
3-2012
2-2012
1-2012

meditronic-journal

4-2019
3-2019
2-2019
1-2019
5-2018
4-2018
3-2018
2-2018
1-2018
4-2017
3-2017
2-2017
1-2017
4-2016
3-2016
2-2016
1-2016
4-2015
3-2015
2-2015
1-2015
4-2014
3-2014
2-2014
1-2014
4-2013
3-2013
2-2013
1-2013
4-2012
3-2012
2-2012
1-2012

electronic fab

4-2019
3-2019
2-2019
1-2019
4-2018
3-2018
2-2018
1-2018
4-2017
3-2017
2-2017
1-2017
4-2016
3-2016
2-2016
1-2016
4-2015
3-2015
2-2015
1-2015
4-2014
3-2014
2-2014
1-2014
4-2013
3-2013
2-2013
1-2013
4-2012
3-2012
2-2012
1-2012

Haus und Elektronik

4-2019
3-2019
2-2019
1-2019
4-2018
3-2018
2-2018
1-2018
4-2017
3-2017
2-2017
1-2017
4-2016
3-2016
2-2016
1-2016
4-2015
3-2015
2-2015
1-2015
4-2014
3-2014
2-2014
1/2014
4-2013
3-2013
2-2013
1-2013
4-2012
3-2012
2-2012
1-2012

Mediadaten

2020 - deutsch
2020 - english
2020 - deutsch
2020 - english
2020 - deutsch
2020 - english
2020 - deutsch
2020 - english
2020 - deutsch
2020 - english
2019 deutsch
2019 english
2019 deutsch
2019 english
2019 deutsch
2019 english
2019 deutsch
2019 english
2019 deutsch
2019 english
© beam-Verlag Dipl.-Ing. Reinhard Birchel