Entwicklung einer dezentralen, webbasierten ... - Lab4Inf

Fachbereich Elektrotechnik und Informatik
Entwicklung einer dezentralen, webbasierten
Prozessvisualisierung
Bachelorarbeit von
Simon Topmann
Betreuer:
Prof. Dr. rer. nat. Nikolaus Wulff
Dipl. Ing. (FH) Tobias Polonyi

1 EINFÜHRUNG...............................................................................................1
1.1 AUFGABENSTELLUNG.................................................................................1
1.2 AUFBAU DER ARBEIT..................................................................................1
1.3 UMFELD ....................................................................................................2
2 ANALYSE DER IST-SITUATION..................................................................3
2.1 ARCHITEKTUR DES GEGENWÄRTIGEN LEITSYSTEMS.....................................3
2.1.1 Bildserver, Bildclient und Serviceseiten ...........................................7
2.1.2 Schnittstelle zwischen Maschinensteuerung und Bildserver ...........8
2.1.3 Schnittstelle zwischen Leitrechner und Bedienterminal.................10
2.2 BEWERTUNG DES AKTUELLEN SYSTEMS....................................................10
3 KONZEPTION EINER NEUEN PROZESSVISUALISIERUNG ..................11
3.1 ORGANISATION DER BEDIENBILDER ..........................................................12
3.1.1 Kern der Visualisierungssoftware...................................................14
3.1.2 Definition eines Bedienbildes .........................................................14
3.1.3 Aufbau der Bedienelemente...........................................................16
3.2 FUNKTION DER VISUALISIERUNG...............................................................18
3.2.1 Initialisierung der Visualisierung.....................................................18
3.2.2 Erzeugung der Bedienseite aus der XML-Definition......................18
3.3 SCHNITTSTELLE VON DER STEUERUNG ZUR WEBOBERFLÄCHE ...................21
3.4 KOMMUNIKATIONSSYSTEME......................................................................23
3.4.1 CAN und andere Feldbussysteme .................................................23
3.4.2 TCP basierte Protokolle .................................................................24
3.4.3 UDP basierte Protokolle.................................................................25
3.4.4 UDP Mulitcast als Kommunikationsprotokoll .................................25
3.5 ÜBERTRAGUNGSPROTOKOLL....................................................................27
3.5.1 Funktion..........................................................................................27
3.5.2 Paketformate ..................................................................................29
3.5.3 Implementierung des Protokolls im Java-Applet............................31
3.5.4 Kommunikationsprotokoll in der Steuerung ...................................33
3.6 DATENSPEICHERUNG ...............................................................................36
4 IMPLEMENTIERUNG AM BEISPIEL EINES TESTSTANDES..................38
4.1 FUNKTION DES TESTSTANDS ....................................................................40
I

4.2 BEDIENOBERFLÄCHE................................................................................41
4.3 STEUERUNGSSOFTWARE..........................................................................44
4.3.1 Task MessTask ..............................................................................45
4.3.2 Task AchsTask...............................................................................46
4.3.3 Task ParamTask ............................................................................47
4.3.4 Task UdpTask ................................................................................48
4.3.5 Bibliothek UdpLib ...........................................................................48
4.3.6 Implementierung der Kommunikation ............................................50
4.3.7 Visualisierungsrechner...................................................................53
5 AUSBLICK ..................................................................................................50
6 ABBILDUNGSVERZEICHNIS ....................................................................55
7 TABELLENVERZEICHNIS .........................................................................56
8 QUELLENVERZEICHNIS ...........................................................................57
II

Sperrvermerk
Die vorliegende Bachelorarbeit „Entwicklung einer dezentralen, webbasierten
Prozessvisualisierung“ beinhaltet interne und vertrauliche Informationen der
Firma.
Die Weitergabe des Inhalts der Arbeit und eventuell beiliegender Zeichnungen
und Daten, im Gesamten oder in Teilen, ist grundsätzlich untersagt.
Es dürfen keinerlei Kopien oder Abschriften auch nicht in digitaler
Form gefertigt werden.
Ausnahmen bedürfen der schriftlichen Genehmigung der Firma:
WINDMÖLLER & HÖLSCHER KG
Münsterstr. 50, D-49525 Lengerich
Lengerich, den 23.08.2010 ___________________________
Simon Topmann
III

Erklärung
Ich versichere hiermit, dass ich die vorliegende Bachelorarbeit selbstständig
verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt
habe.
Lengerich, den 23.08.2010 ___________________________
Simon Topmann
IV

1 Einführung
Diese Arbeit beschäftigt sich mit der Konzeption einer graphischen Benutzeroberfläche
für Maschinen mit verteilten und vernetzten Steuerungssystemen auf
Basis von Webtechnologien.
1.1 Aufgabenstellung
Da der Industrieelektronikhersteller Bernecker & Rainer, im folgenden B&R genannt,
für seine Steuerungen einen Webserver zur Verfügung stellt, ist seitens
der Firma Windmöller & Hölscher der Wunsch entstanden, ein Konzept für eine
Visualisierung zu entwickeln, die ganz oder teilweise auf Webtechnologien basiert.
1.2 Aufbau der Arbeit
Zunächst wird allgemein die Architektur einer komplexen, vernetzten Maschinensteuerung
dargestellt. Anschließend folgt eine Beschreibung des aktuell bei
der Fa. Windmöller & Hölscher eingesetzten Visualisierungssystems und eine
Zusammenfassung der Probleme des Systems. In den darauf folgenden Kapiteln
wird ein Konzept für eine, auf Webtechnologien basierende, Maschinenvisualisierung
ausgearbeitet. Im Anschluss wird ein Kommunikationsprotokoll zwischen
der Maschinensteuerung und der Webanwendung entwickelt. Der letzte
Abschnitt der Arbeit beschreibt eine beispielhafte Implementierung der zuvor
entwickelten Konzepte anhand eines Teststandes. Abschließend folgt ein Ausblick
auf weitere Verbesserungs- und Entwicklungsmöglichkeiten.
Webbrowser im Visualisierungsterminal
Kommunikationsplugin
Prozessdaten
über UDP
Kommunikationsbibliothek
Bedienbilder
über HTTP
Webserver (B&R)
Steuerungssoftware
Abb. 1: Struktur der Prozessvisualisierung
1

1.3 Umfeld
Diese Arbeit wurde bei der Firma Windmöller & Hölscher in Lengerich, Westf.
angefertigt. Das Maschinenbauunternehmen fertigt und vertreibt Druckmaschinen,
Verpackungsmaschinen sowie Anlagen zur Kunststofffolienherstellung.
Eine moderne Druckmaschine ist eine komplexe technische Anlage, an der
es eine Vielzahl von Teilprozessen zu automatisieren gilt:
• Abwicklung einer Materialbahn
• Bedrucken der Bahn
• Trocknung
• Aufwicklung
• …
Um diese Aufgaben zu erfüllen, wird eine Vielzahl von Steuerungsgeräten
eingesetzt. Damit der Maschinenbediener eine einheitliche Benutzerschnittstelle
zur Kontrolle des Prozesses zur Verfügung hat, wird eine computerbasierte Visualisierung
eingesetzt.
Abb. 2: Abbildung einer Flexodruckmaschine
2

2 Analyse der Ist-Situation
2.1 Architektur des gegenwärtigen Leitsystems
Moderne Produktionsanlagen erfordern zur Beherrschung ihrer immer komplexer
werdenden Vorgänge ein entsprechend umfangreiches Steuerungssystem,
das eine komplexe Mensch-Maschine-Schnittstelle (HMI – Human Machine Interface)
zur Handhabung benötigt. Bei einfacheren Anlagen reichte noch eine
Ansammlung aus Leuchtmeldern, Schaltern und Anzeigeinstrumenten aus. Moderne
Anlagen hingegen können nicht mehr mit derartigen Mitteln beherrscht
werden. Aus diesem Grund werden in der heutigen Zeit vermehrt Benutzerschnittstellen
wie Touchscreens und andere computerbasierte Bedienterminals
verwendet.
Der Verbund aus der eigentlichen Maschinensteuerung, der Benutzerschnittstelle
und der Anbindung an weitere unternehmensinterne Systeme wird
auch als Leitsystem bezeichnet. Durch die steigende Komplexität werden diese
Leitsysteme üblicherweise in fünf bzw. vier Prozessführungsebenen aufgeteilt
[1].
5 – Ebenen-Modell 4 – Ebenen-Modell
Unternehmensführung
Betriebsführung
Anlagenführung
Unternehmensführung
Betriebsführung
Prozessführung
Maschinenführung
Feldebene
Feldebene
Abb. 3: Ebenenmodelle der Prozessführung
In der Praxis ist zwischen der Anlagenführungsebene und der Maschinenführungsebene
oft keine klare Trennung möglich, wodurch das 5-Ebenen-
Modell auf ein 4-Ebenen-Modell reduziert werden kann [1]. Bei diesem werden
die Anlagenführungsebene und die Maschinenführungsebene zu einer neuen
Ebene, der Prozessführungsebene, zusammengefasst. Ein Bedienterminal
3

kann beispielsweise direkt mit Sensoren und Aktoren in der Feldebene kommunizieren.
Damit dient das Terminal zum einen der Visualisierung, zum anderen
erfüllt es auch steuerungstechnische Aufgaben, womit es sowohl der Anlagenführungsebene
als auch der Maschinenführungsebene zugeordnet werden
kann.
Die Unternehmensführungsebene beinhaltet die langfristige Produktionsplanung,
die Auftragsakquise und die Verwaltung des Unternehmens. In der
Betriebsführungsebene wird die detailliertere Betriebsplanung durchgeführt, wie
z.B. die Kapazitätsplanung der Produktionsanlagen, die Qualitätssicherung sowie
die Terminüberwachung und Planung. Die bisher beschriebenen Ebenen
umfassen hauptsächlich betriebswirtschaftliche und verwalterische Aufgabenstellungen.
Die Ebenen, die sich darunter befinden, sind den technischen Bereichen
zuzuordnen.
Die Anlagenführungsebene umfasst die Betrachtung der technischen Anlage
als Ganzes. Als Kernaufgaben gelten hier die Prozessüberwachung, Fehlerdiagnose,
Störungsbeseitigung und Prozessoptimierung. Für die Kontrolle des
technischen Prozesses ist die Maschinenführungsebene verantwortlich. Sie
beinhaltet Aufgaben wie Messen, Steuern, Überwachen und Regeln. Auch in
dieser Ebene finden sich Elemente der Benutzerschnittstelle wieder, die für den
regulären Betrieb seltener benötigt werden und deshalb nicht in die eigentliche
Bedienung integriert sind. Unterhalb der Maschinenführungsebene befindet sich
die Feldebene. Sie beinhaltet die Sensoren, Aktoren etc.
Die Anforderungen an die Steuerung von komplexen Prozessen erfordern
dezentrale Systemarchitekturen, in denen eine Vielzahl von Steuerungskomponenten
den Prozess gemeinsam kontrollieren. Diese Verteilung von „Steuerungskompetenzen“
erfordert eine effiziente und zuverlässige Vernetzung der
einzelnen Teilsysteme. Um den Anforderungen des zu steuernden Systems
gerecht zu werden, müssen die Netzwerke strenge Anforderungen an die Sicherheit
und den Determinismus der Datenübertragung erfüllen [2]. Dazu werden
spezielle Bussysteme wie der CAN 1 -Bus oder Profibus 2 eingesetzt. Mit dem
Ziel, die Kosten der Systeme zu reduzieren und um gut verfügbare und erprobte
Komponenten verwenden zu können, kann in Zukunft vermehrt auf Bussysteme
zurückgegriffen werden, die auf Standardsystemen wie Ethernet basieren.
1
2
Controller Area Network, Feldbussystem aus der Automobilindustrie
Profibus, Standardisierter Feldbus auf Basis von RS485 oder Lichtwellenleitern
4

Dies gilt nicht nur für die Vernetzungskomponenten, sondern auch für die
weitere Steuerungshardware. Zur Visualisierung der Prozessdaten werden sehr
häufig Computer eingesetzt, die auf weit verbreiteter PC-Hardware basieren.
Die Nutzung von Standardhardware setzt sich in der Vernetzung der Visualisierungskomponenten
fort, da hier ebenfalls auf Techniken wie Ethernet zurückgegriffen
wird. Diese Entwicklung lässt sich auch an dem Prozessleitsystem der
Firma Windmöller & Hölscher erkennen.
Auf unterster Ebene, der Feldebene, wird eine breite Auswahl an Komponenten
von vielen verschiedenen Herstellern verwendet. Zur Vernetzung der
speicherprogrammierbaren Steuerungen mit Feldgeräten wie Frequenzumrichter
3 und diversen Sensoren wird neben der Stichverdrahtung für digitale und
analoge Signale unter Anderem auch der Powerlink 4 -Bus verwendet. Die übergeordnete
Kommunikation zwischen den Steuerungen läuft für zeitkritische Daten
über einen CAN-Bus. Zur Übertragung von großen Datenmengen oder unkritischen
Informationen wird ein gewöhnliches TCP/IP-Netzwerk verwendet.
Durch diese Aufteilung ist die Vernetzung der Steuerungen doppelt ausgeführt.
Neben den Steuerungen ist auch der Leitrechner in beide Netzwerke eingebunden.
Die Bedienterminals, die an verschiedenen Stellen in der Anlage verbaut
sind, werden ebenfalls über dasselbe TCP/IP-Netzwerk angebunden.
Terminal 1 Terminal 2
Leitrechner
SPS 1 SPS 2 SPS 3
TCP/IP
CAN, TCP/IP
CAN, Powerlink
Frequenzumrichter
…
Abb. 4: Netzwerkarchitektur des aktuellen Leitsystems
3
4
Steuergerät zum Lage- und Drehzahlgeregelten Betrieb von elektrische Antriebsmaschinen
Ethernetbasierter, echtzeitfähiger Feldbus
5

Die Entwicklung der Prozessvisualisierung bewegt sich nach Langmann [3] immer
mehr in die Richtung von webbasierten Technologien. Das bietet große
Vorteile, da vorhandene und erprobte Programme und Techniken eingesetzt
werden können. Die Darstellung der Prozessvisualisierung als Webseite bietet
die Möglichkeit als Anzeigegerät einen einfachen, handelsüblichen PC mit einem
Internet-Browser zu verwenden. Ein weiterer Vorteil der Webtechnologien
ist die Nutzbarkeit der Visualisierung in großer Entfernung zur Anlage, z.B. über
das Internet, wodurch unter anderem die Fernwartbarkeit wesentlich verbessert
wird [3].
Nachteilig an der Verwendung von Webtechnologien ist, dass es auf dem
Gebiet der Prozessvisualisierung noch keine Standardlösungen gibt. So stellt
jede Visualisierung auf dieser Basis eine, auf die jeweilige Anwendung optimierte,
Sonderlösung dar. Des Weiteren bereitet auch die durchgängig gleiche Darstellung
der Bedienbilder in verschiedenen Webbrowsern Probleme. Webbrowser
sind auf die Anzeige von Webseiten zugeschnitten, die sich grundlegend
vom Aufbau einer Prozessvisualisierung unterscheiden.
6

2.1.1 Bildserver, Bildclient und Serviceseiten
Die eigentliche Visualisierungssoftware der Firma Windmöller und Hölscher ist
in einen Bildserver und einen Bildclient gegliedert. Der Bildserver läuft auf dem
Maschinenleitrechner und stellt für die einzelnen Visualisierungsterminals über
TCP/IP Daten zur Verfügung. Zusätzlich zum Bildserver befinden sich auf dem
Leitrechner eine Reihe weiterer Programme, die ergänzende Aufgaben der Maschinensteuerung,
wie die Erzeugung von Alarmmeldungen und die Verwaltung
des Druckzylinderlagers übernehmen.
Der Bildclient läuft auf den einzelnen Visualisierungsterminals und stellt die
Daten, die er vom Bildserver erhält, graphisch am Bildschirm dar. Zudem leitet
er Benutzereingaben über das Netzwerk zurück an den Bildserver, der dann für
die weitere Verarbeitung im System sorgt.
Da in den einzelnen Steuerungen eine Vielzahl von Einstellungen und Parametern
vorhanden sind, wird neben der eigentlichen Prozessvisualisierung
noch eine Reihe von Visual Basic Programmen genutzt. Die sogenannten Serviceapplikationen
5 stellen zusätzliche Bedienbilder zur Parametrierung bereit.
Diese Programme sind mit den Steuerungen ausschließlich über PVI verbunden.
Sie werden, im Gegensatz zur Visualisierung, zusammen mit der Steuerungssoftware
gepflegt, da eine starke Abhängigkeit zwischen den Serviceapplikationen
und der Steuerungssoftware besteht.
PVI steht für „Process Variable Inspection“ und ist ein, vom Steuerungshersteller
B&R bereitgestelltes Protokoll, welches anderen Programmen über das
UDP-Protokoll den Zugriff auf steuerungsinterne Variablen und Speicherbereiche
erlaubt. Durch diesen Mechanismus greifen die Serviceapplikationen auf
einen Speicherbereich in den jeweiligen Steuerungen zu, in dem die einzelnen
Parameter abgelegt sind. Da PVI nur den Speicherzugriff ermöglicht, werden für
die weitere Ablaufsteuerung, z.B. schreiben der Parameter in den Flash-
Speicher der Steuerung, zusätzliche übergelagerte Protokolle benötigt. Diese
bestehen meist aus dem Setzen einer Variable in der Steuerung durch die Serviceapplikation
und dem zurücksetzen aus der Steuerungssoftware heraus. Bei
der Verwendung der PVI-Funktionalität entsteht auf der Steuerung keine zu-
5
Bezeichnung bei Windmöller & Hölscher
7

sätzliche Komplexität in der Software, da dieser Dienst vom Betriebssystem der
Steuerung zur Verfügung gestellt wird.
Die Serviceapplikationen sind nicht in die eigentliche Prozessvisualisierung
eingegliedert, da sie sich deutlich häufiger ändern als die Visualisierung selbst
und so der Pflegeaufwand für die Visualisierung unverhältnismäßig steigen
würde. Durch diese Trennung kann die Serviceapplikation relativ leicht mit der
Steuerungssoftware ausgeliefert werden und es wird kein Update der gesamten
Visualisierung am Maschinenstandort notwendig.
2.1.2 Schnittstelle zwischen Maschinensteuerung und Bildserver
Die Steuerungen kommunizieren mit dem Bildserver über den CAN-Bus und
über PVI. Wie zuvor erwähnt wird der CAN-Bus für zeitkritische Daten genutzt.
Bei der Kommunikation über den CAN-Bus wird ein CAN Application Layer Protocol
genutzt, welches auf dem CAN-Protokoll nach ISO99-1, ISO99-2 und
ISO99-3 basiert. In diesem Protokoll werden Kommunikationsobjekte 6 definiert,
die zwischen den Steuerungen ausgetauscht werden. Das Senden und die
Verarbeitung der Daten erfolgt dabei ereignisgesteuert. Jedes Objekt wird von
genau einer Steuerung gesendet und von beliebig vielen empfangen. Innerhalb
der Steuerungssoftware wird dieses Arbeitsprinzip über Ereignisvariablen 7 abgebildet.
Diese Variablen werden abhängig vom Objekttyp von der Applikationssoftware
auf einen Wert gesetzt, der z.B. das Senden auf dem CAN-Bus auslöst.
Wurde eine CAN-Nachricht empfangen, wird diese Eventvariable vom
CAN-Treiber der Steuerung auf einen festgelegten Wert gesetzt, um die Applikationssoftware
über eine Aktualisierung dieser Prozessvariable in Kenntnis zu
setzen.
6
7
In der Spezifikation als Communication Object, auch COB, bezeichnet.
Variable, die beim Eintreten eines Ereignisses auf einen bestimmten Wert gesetzt wird um
die Applikationssoftware über das Eintreten des Ereignisses zu informieren.
8

Steuerung 1 Steuerung 2
Applikation
CAN
CAN
Applikation
zyklisch
Eventflag setzen
zyklisch
Eventflag
rücksetzen
Daten senden
Eventflag setzen
zyklisch
Daten lesen
Eventflag
rücksetzen
Abb. 5: Kommunikationsmodell im CAN-Bus
In der darüber liegenden Abstraktionsschicht werden die einzelnen, über
den Bus synchronisierten, rechnerlokalen Variablen als globale Prozessvariablen
betrachtet, die auf allen Steuerungen/Rechnern zu jedem Zeitpunkt, unter
Berücksichtigung der Totzeiten durch die Übertragung, denselben Inhalt haben.
Über diese gemeinsamen Prozessvariablen werden Sollwerte, Zustände etc.
zwischen den Steuerungen und zur Visualisierung kommuniziert. Es entsteht
eine Art gemeinsamer „Speicher“ aller angeschlossenen Komponenten.
Beispiel:
Gibt der Maschinenführer an einem Visualisierungsterminal eine neue Sollgeschwindigkeit
für die Anlage ein, so wird diese Eingabe vom Bildclient an den
Bildserver gesendet. Dieser verteilt sie dann weiter über das CAN-Bussystem.
Die entsprechenden Steuerungen erhalten den neuen Sollwert über ihre CAN-
Schnittstelle und die Applikationssoftware wird über ein gesetztes Eventflag
über die Änderung informiert. Durch die Änderung des Eventflags wird dann in
der Applikation der Sollwert überprüft und die Anlage entsprechend dem Sollwert
beschleunigt oder verzögert.
9

2.1.3 Schnittstelle zwischen Leitrechner und Bedienterminal
Auf dem eigentlichen Anzeigegerät, dem Bedienterminal, läuft eine spezielle
Software zur Anzeige der Bedienbilder. Diese stellt die Bedienseiten am Bildschirm
dar und erlaubt dem Bediener die Interaktion mit der Maschine.
Die eigentliche Definition der Bedienbilder befindet sich im Quellcode des
Bildservers. Dieser enthält eine Klassenhierarchie, die die einzelnen Bedienbilder
abbildet. Im Konstruktor der Klassen wird von Hand eine Liste mit Bedienelementen
für das jeweilige Bedienbild erstellt. Bei der Anzeige eines Bildes an
einem Bedienterminal wird diese Liste mittels einer TCP-Verbindung an das
Terminal gesendet und angezeigt. Die Software des Bedienterminals sendet
Benutzereingaben an den Bildserver zurück. Eingaben an den Bedienterminals
werden zentral auf dem Leitrechner verarbeitet. Durch diese zentrale Datenverarbeitung
ist der Zustand der Bedienbilder an allen Bedienterminals konsistent
und die parallele Nutzung mehrerer Bedienstellen bereitet keine Probleme, da
im Bildserver nur eine Instanz jeder Bedienbildklasse existiert.
2.2 Bewertung des aktuellen Systems
Die Visualisierung stellt ein nach außen geschlossenes System dar. Bei häufig
vorkommenden Erweiterungen der Funktionalität ist daher jeweils eine neue
Version notwendig. Dies führt zu einer unübersichtlichen Menge von Softwareversionen
und Updates.
Da das Visualisierungssystem auf der Basis der Microsoft Foundation
Classes (MFC) entwickelt wurde, ist es auf Plattformen der Firma Microsoft
ausgerichtet. Die Software ist mit der Zeit gewachsen und beinhaltet eine Vielzahl
von kundenspezifischen Sonderlösungen, wodurch der Wartungsaufwand
überproportional zunimmt.
Weitere Nachteile sind der Einsatz von spezieller W&H Software, welche
auf dem Visualisierungsterminal installiert werden muss, sowie die strukturelle
und optische Trennung der Serviceseiten von der Visualisierung auf der Anzeigeebene.
10

3 Konzeption einer neuen Prozessvisualisierung
Nach den Ergebnissen der Betrachtung des aktuellen Visualisierungskonzeptes
soll die neu zu konzipierende Visualisierung folgende Anforderungen
erfüllen:
• Bedienbilder und Serviceseiten in einer Oberfläche integriert
• Definition der Serviceseiten auf der Steuerung abgelegt
• Allgemeine Bedienbilder zentral auf dem Leitrechner abgelegt
• Einsatz von Standardtechnologien
• Verwendung bestehender Infrastruktur
• Skalierbare Anzahl von Steuerungen und Visualisierungsterminals
• Anzeige der Visualisierung ohne Zusatzsoftware auf verschiedenen
Plattformen
Die Bedienbilder der Visualisierung werden zur Laufzeit aus einer Beschreibung
im XML-Format generiert. Da es sich bei der Visualisierung um eine interaktive
Webanwendung handelt, ist eine Umsetzung durch statisches HTML nicht möglich.
Einen Ausweg bieten hier browserseitig ausgeführte Skriptsprachen wie
JavaScript. Die Nutzung derartiger Scriptsprachen erlaubt das Reagieren auf
Benutzeraktionen und das dynamische Ändern der Seiteninhalte und damit eine
effiziente Interaktion mit dem Benutzer.
Da eine Visualisierung nicht nur auf Benutzereingaben, sondern auch auf Ereignisse
der zu steuernden Anlage reagieren muss ist die alleinige Verwendung
von JavaScript nicht ausreichend. Die Webanwendung muss in der Lage sein
auf eingehende Informationen zu reagieren, damit der Benutzer in Echtzeit über
den Maschinenzustand informiert werden kann. Dazu muss die Anwendung
unangefordert eingehende Netzwerkpakete verarbeiten können. Diese Anforderung
kann mit JavaScript nicht erfüllt werden, da es über keine Schnittstelle zur
Netzwerkprogrammierung verfügt. Aus diesem Grund wird ein Java-Applet verwendet,
das der Kommunikation zu den restlichen Komponenten des Steuerungssystems
dient. Dieses Applet bildet somit die Schnittstelle zwischen der
Webanwendung und dem Maschinenumfeld.
11

Visualisierungsclient
Steuerung
Java-
Script
Kern
Applet
Webserver
UDP-Bibliothek
DOM-Baum
Darstellung im Browser
Applikation
Abb. 6: Architektur der Visualisierung
Die Gesamtarchitektur des neuen Visualisierungssystems ist in Abb. 6
dargestellt. Die Komponenten, die im Rahmen dieser Arbeit erstellt wurden,
sind in der Grafik gestrichelt eingezeichnet.
3.1 Organisation der Bedienbilder
Die Bedienoberfläche einer Maschinenvisualisierung setzt sich im Allgemeinen
aus einer Reihe von Bedienbildern zusammen. Jedes dieser Bedienbilder erfüllt
eine bestimmte Aufgabe und enthält die relevanten Bedienelemente wie Eingabefelder
oder Anzeigeelemente. Im Groben lassen sich die Bedienbilder in zwei
Gruppen kategorisieren. Zum einen die Bedienbilder, die die Bedienung der
Anlage als Ganzes umfassen, zum anderen Bedienbilder, die nur einer Steuerung
zugeordnet sind und deren Parametrierung und die Nutzung von Diagnosefunktionen
erlauben.
12

Abb. 7: Grundstruktur eines Bedienbildes
Das Bedienbild selbst lässt sich in zwei Abschnitte gliedern (siehe Abb. 7)
.Am oberen Bildschirmrand wird eine Kopfleiste mit Buttons für Bildwechsel angezeigt.
Oft werden in der Leiste auch zusätzliche grundlegende Betriebsdaten
der Anlage oder andere Meldungen angezeigt. Dieser Bereich des Bildschirms
ist bei allen Bedienbildern identisch. Im Abschnitt darunter befindet sich der eigentliche
Inhalt des Bedienbildes mit den Bedienelementen. Diese entsprechen
im Wesentlichen den Widgets 8 , die von der Programmierung auf PC-Systemen
bekannt sind. Dieser Bildbereich wird in Abhängigkeit zum angewählten Bedienbild
aus einer Bildbeschreibung generiert.
Da die Bedienung in der Regel über einen Touchscreen erfolgt, sind die
Bedienelemente speziell dafür ausgelegt. Es ist z.B. bei Eingabefeldern nicht
möglich und auch nicht notwendig, direkte Eingaben mit einer Tastatur durchzuführen.
Wählt der Benutzer ein Eingabefeld durch Tippen an, dann öffnet sich
eine Bildschirmtastatur für die Eingabe über den Touchscreen.
Die einzelnen Bedienelemente eines Bildes werden zur Laufzeit an einem
Raster mit variabler Größe ausgerichtet. Dadurch lässt sich die Visualisierung
mit dem Webbrowser zusammen skalieren, ohne für die Berechnung der Anordnung
der Bedienelemente weiteren Aufwand betreiben zu müssen. Jedes
8
Element einer grafischen Benutzeroberfläche eines Computerprogramms.
13

Bedienelement kann horizontal und vertikal eine oder mehrere Zellen dieses
Rasters einnehmen.
3.1.1 Kern der Visualisierungssoftware
Der Kern der Visualisierung umfasst die clientseitige Software, die im Webbrowser
läuft. Da die Bedienbilder als Webseite implementiert sind, wird ein
HTML-Grundgerüst verwendet. Dieses enthält die statische Implementierung
des Bildkopfes, der auf allen Bedienseiten identisch ist. Für die eigentliche Bedienseite
ist ein leeres HTML-Element vorgesehen, welches dynamisch zur
Laufzeit mit den Inhalten des angewählten Bedienbildes gefüllt wird. Neben
dem Bildkopf und dem Platzhalter für das Bedienbild enthält das HTML-
Grundgerüst die JavaScript-Klassen der Bedienelemente, den JavaScript-Code
zur Erzeugung der Bedienseite sowie das Applet zur Kommunikation mit den
Steuerungen. Lediglich der bildspezifische JavaScript-Code wird aus der Bilddefinition
nachgeladen.
Der anzeigende Client lädt den Kern von einem Webserver auf dem Leitrechner,
da er für alle Bedienbilder gleich ist. Während der Anzeige der Bedienbilder
bleibt der Kern im Browser geladen. Durch die zentrale Speicherung des
Kerns der Visualisierung ist sichergestellt, dass alle Clients dieselbe Version
der Software verwenden. Beim Update der Software muss daher nur der Leitrechner
aktualisiert werden 9 .
Der Kern verwaltet zudem die globale Liste aller Bedienbilder. Auf dem
Leitrechner liegt dafür eine Liste aller Steuerungen, die Bedienbilder zur Verfügung
stellen. Jede Steuerung hält wiederum eine Liste mit den Bildern bereit.
Diese Listen werden durch den Visualisierungskern im Webbrowser zu einer
globalen Bildliste zusammengeführt. Durch diesen Mechanismus ist gewährleistet,
dass auch bei einem Update der Bedienbilder einer Steuerung die globalen
Bildlisten immer auf dem aktuellen Stand gehalten werden, ohne etwas im Kern
der Visualisierung ändern zu müssen.
3.1.2 Definition eines Bedienbildes
Die Bedienbilder werden durch eine Definitionsdatei im XML-Format beschrieben.
Der Hauptinhalt der Bilddefinition ist die Auflistung aller Bedienele-
9
Zu Testzwecken kann auf dem Webserver der Steuerung ebenfalls ein Visualisierungskern
hinterlegt werden.
14

mente. Für jeden zur Verfügung stehenden Bedienelementtyp ist ein Tag im
XML-Schema definiert. Jeder Bedienelementtag hat eine Reihe von Attributen.
Allen Tags gemein sind die Attribute für die Position und die Größe des Bedienelements
im Raster des Bedienbildes. Zusätzlich zu diesen Standardattributen
enthält jeder Tag weitere, bedienelementspezifische Attribute, wie z.B. einen
Beschriftungstext oder eine angeschlossene Prozessvariable.
Bei einigen Bedienelementen können im Tag JavaScript-Abschnitte eingebettet
werden. Dies erlaubt weitergehende Funktionen im Bedienbild wie z.B.
visualisierungsseitige Verriegelungen von Eingabefeldern oder Ähnlichem. Neben
den Skriptabschnitten in den Bedienelementtags können noch Variablen im
Kontext des Bedienbildes sowie ein Initialisierungsskript und ein zyklisch aufgerufenes
Skript eingefügt werden. Durch die Deklaration von Variablen sind
komplexere Abläufe im Bedienbild implementierbar. Diese Variablen sind allerdings
nur lokal auf dem Visualisierungsrechner vorhanden. Sie werden nicht
zwischen den Bildinstanzen auf verschiedenen Visualisierungsterminals synchronisiert
und erlauben daher keine Querkommunikation zwischen den Bedienbildern.
Tagname
panel
label
enumdisplay
enuminput
numdisplay
Beschreibung
Zeigt ein statisches, farbig abgesetztes Panel mit
einem optionalen Text an
Zeigt einen statischen Text mit transparentem Hintergrund
an
Zeit in einem Anzeigefeld einen Text aus einem
Array von Texten an. Der ausgewählte Text bestimmt
sich durch den Wert der angeschlossenen
Prozessvariablen
Zeigt ein enumdisplay als Eingabefeld an. Bei Aktivieren
des Eingabefeldes wird ein Auswahldialog
mit den entsprechenden Texten angezeigt.
Zeigt einen numerischen Wert einer Prozessvariablen
in einem Anzeigefeld an. Der Wert wird mit
einer konfigurierbaren Anzahl an Nachkommastellen
dargestellt.
15

Tagname
numinput
toggle
button
funcdisplay
init
cyclic
variable
Beschreibung
Zeigt ein numdisplay als Eingabefeld an. Bei Aktivieren
des Eingabefeldes wird eine numerische
Tastatur eingeblendet, die die Eingabe eines neuen
Wertes für die entsprechende Prozessvariable
erlaubt.
Zeigt einen Button an, dessen Zustand durch eine
Prozessvariable gesetzt wird. Ein Betätigen des
Buttons setzt die Prozessvariable abhängig von
ihrem aktuellen Wert auf einen von zwei Werten
(on, off)
Zeigt einen Button an. Bei Betätigung des Buttons
wird das Skript im Tag aufgerufen,
Zeigt ein Anzeigefeld an. Der Wert des Anzeigefeldes
wird durch den Rückgabewert des Skriptes
im Tag definiert.
Deklariert das Initialisierungsskript. Es wird nach
dem Laden des Bildes aufgerufen.
Deklariert das zyklische Skript. Es wird bei jeder
Aktualisierung des Bedienbildes aufgerufen.
Der Tag deklariert eine Variable im Kontext des
Bedienbildes und initialisiert sie auf den angegebenen
Wert. In den anderen Skripten kann auf sie
mit this.variablenname zugegriffen werden.
Tabelle 1: Tags in der Bilddefinitionsdatei
3.1.3 Aufbau der Bedienelemente
Die Bedienelemente werden im JavaScript durch eine Klassenstruktur modelliert.
Eigenschaften, die bei allen Bedienelementen gleich sind, werden so durch
die Klassenhierarchie vererbt, die Komplexität der Implementierung wird dadurch
reduziert. Wichtige Funktionen der Bedienelemente sind nur einmal für
alle Bedienelemente in den höheren Hierarchieebenen implementiert.
16

Jedes Bedienelementobjekt erzeugt einen Document Object Model 10 –
Baum, der durch den Webbrowser dargestellt werden kann. Dieser DOM-Baum
umfasst neben den Informationen zum Aussehen des Bedienelementes und
dem angezeigten Inhalt (Prozessdaten, Texte, …) auch die Ereignisbehandlungsroutinen
zur Erzeugung der Interaktivität. Diese sind ebenfalls im
Bedienelementobjekt implementiert und somit zur jeweiligen Klasse von Bedienelementen
zugehörig. Sie verändern das Aussehen des Bedienelementes
beim Mausklick oder öffnen einen Eingabedialog.
Derartige Eingabedialoge sind nicht als Popup über den Webbrowser implementiert,
sondern als Dialog im Java-Applet, da im Applet eine bessere Kontrolle
des Aussehens des Dialoges möglich ist. Popups des Browsers können
aus Sicherheitsgründen nicht ohne Fensterrahmen und Adresszeile geöffnet
werden. Die rahmenlose Anzeige der Eingabedialoge ist aber wünschenswert.
Bei einem Dialog, der durch das Java-Applet erzeugt wird, ist eine Anzeige ohne
Fensterrahmen aber problemlos möglich.
Abb. 8: Klassenbaum der Bedienelemente
10 Modell einer Webseite als Baumstruktur. Der DOM-Baum ermöglicht den Zugriff und die
Veränderung der angezeigten Seite zur Laufzeit.
17

3.2 Funktion der Visualisierung
3.2.1 Initialisierung der Visualisierung
Nachdem das Visualisierungsterminal und der Webbrowser gestartet sind, lädt
der Kern der Visualisierung zunächst eine Liste aller angeschlossenen Steuerungen
vom Maschinenserver. Anschließend werden von allen Steuerungen die
Variablendefinitionen geladen und in das lokale Java-Applet der Visualisierung
eingelesen. Mit diesem Schritt ist der Zugriff auf die Prozessvariablen möglich.
Dann lädt der JavaScript-Code im Kern die Bilddefinition des ersten Bedienbildes
von der entsprechenden Steuerung und zeigt sie als Startseite an.
3.2.2 Erzeugung der Bedienseite aus der XML-Definition
Eine Anordnung von Bedienelementen wird durch die Klasse Bild modelliert.
Diese Klasse bietet Schnittstellen zum Einfügen von Bedienelementen und zum
Erzeugen des DOM-Baumes aus der Anordnung von Bedienelementen. Zum
eigentlichen Zugriff auf das DOM-Modell wird auf die standardisierten Schnittstellen
der Webbrowser zurückgegriffen [6]. Innerhalb der Klasse Bild wird die
Anordnung der Bedienelemente durch eine Liste von Bedienelementobjekten
abgebildet. Die Liste wird einmal erzeugt und kann anschließend jederzeit zur
Erstellung des DOM-Baumes wieder verwendet werden. Jedes Bedienelementobjekt
erzeugt einen DOM-Teilbaum, der das Bedienelement beschreibt. Die
Teilbäume werden durch die Klasse Bild zu einem DOM-Baum zusammengesetzt,
der den kompletten bildspezifischen Inhalt der Bedienseite beschreibt.
Der Webbrowser verwendet diesen Baum als Grundlage für die Darstellung der
Bedienseite am Bildschirm.
Die Klasse Bild wird ausschließlich zur Erzeugung der Kopfleiste des
Bedienbildes verwendet, da alle Bedienelemente direkt im JavaScript-
Quellcode eingefügt werden müssen. Um die Bedienseiten aus einer Definitionsdatei
erzeugen zu können, wird eine Klasse XmlBild aus der Klasse Bild
abgeleitet.
18

Abb. 9: Klassenstruktur eines Bedienbildes
Im Gegensatz zur Klasse Bild kann die Klasse XmlBild die Bedienelementliste
aus einer Definitionsdatei im XML-Format erzeugen. Zur Konstruktionszeit
des Objektes wird nur die URL der Datei übergeben. Geladen und Ausgewertet
wird die Definition erst, wenn der DOM-Baum zur Anzeige benötigt
wird. Durch die Anwendung des Lazy-Loading, des verzögerten Nachladens
von Informationen, werden die Ladezeit der Visualisierung im Browser und die
Last auf den Webservern der Steuerungen auf ein Minimum reduziert. Dies ist
insbesondere bei Parameterbildern sinnvoll, da sie meist nicht benutzt werden
und daher auch nicht vom Server übertragen werden müssen. Das Java-Applet
führt die eigentliche Übertragung der Definitionsdatei vom Webserver der entsprechenden
Steuerung durch. Die Übertragung von XML-Daten wäre auch mit
Ajax möglich, da die Datei aber nicht vom Quellserver des Skriptes geladen
wird, verhindert dies die Same Origin Policy des Webbrowsers [7]. Da das
Applet dieser Einschränkung nicht unterliegt, wird es zur Übertragung genutzt.
Zur Auswertung der Defintionsdatei wird aus der XML-Definition mittels
der DOM-Funktionen des Webbrowsers ebenfalls ein DOM-Baum erzeugt. In
19

diesem Baum entsprechen die einzelnen DOM-Knoten den Tags aus der XML-
Datei. Das Objekt der Klasse XmlBild arbeitet diesen Baum knotenweise ab und
fügt die entsprechenden Bedienelemente in das Bedienbild ein.
Anschließend wird die Instanz der Klasse XmlBild um automatisch generierte
Memberfunktionen erweitert. Der Funktionskörper wird dabei mittels der
JavaScript-Funktion eval() aus den benutzerspezifischen Skripten der Definitionsdatei
erzeugt. Diese Funktionen werden dann über die Bedienelementobjekte
mit Hilfe von JavaScript-Closures [8] an die Ereignisbehandlungsroutinen des
DOM-Modells der Bedienseite angeschlossen. Auf die gleiche Art und Weise
können durch die Bilddefinition auch Membervariablen hinzugefügt und initialisiert
werden.
Nachdem das Bedienbild erzeugt wurde, liefert die Klasse XmlBild den
DOM-Baum des Bedienbildes an den Kern der Visualisierung zurück. Dieser
ersetzt den aktuellen, bildspezifischen Teil der Bedienseite durch das neue Bedienbild.
Danach wird das Initialisierungsskript am Bildobjekt aufgerufen und
der Timer für das zyklische Aktualisieren der Seite gestartet. Der Timer ruft die
update()-Funktion des Bildobjektes auf, die wiederum jedes Bedienelement im
Bild aktualisiert. Nach der Aktualisierung der Bedienelemente ruft sie, sofern
vorhanden, das zyklische Skript des Bedienbildes auf.
20

Bild XmlUiManager Label
Button
Bild-DIV
Applet
create()
loadFile()
XML-Definition
Label()
Button()
create()
DOM-Baum
create()
DOM-Baum
DOM-Baum
replaceChild(DOM-Baum)
Abb. 10: Sequenzdiagramm zur Bilderzeugung
3.3 Schnittstelle von der Steuerung zur Weboberfläche
Die Weboberfläche muss zur Kommunikation mit der restlichen Steuerungshardware
eine Implementierung des verwendeten Kommunikationsprotokolls
enthalten. Dies ist mit den gängigen Scriptsprachen wie JavaScript nicht möglich,
da sie aus Sicherheitsgründen keinen Zugriff auf die Kommunikationsschnittstellen
des Rechners erlauben. Daher muss ein Programm in die Webseite
eingebettet werden, mit dem der Zugriff auf die Schnittstellen des Rechners
möglich ist. Diese Möglichkeit bieten z.B. ActiveX-Steuerelemente (C/C++)
und Java-Applets.
21

Der bedeutendste Nachteil von ActiveX-Steuerelementen besteht darin,
dass es sich um eine proprietäre Technologie der Firma Microsoft handelt, die
nur in Windows-Umgebungen unterstützt wird. Dadurch ist es nicht möglich, die
Visualisierung mit anderen Webbrowsern oder unter anderen Betriebssystemen
zu verwenden. Wegen dieser Probleme wird ActiveX als Brücke zwischen der
Webapplikation und der Buskommunikation nicht verwendet.
Im Gegensatz dazu bietet die Java-Plattform mit einem Java-Applet eine
weit verbreitete Basis zur Einbindung eines Programms in eine Webseite. Die
Möglichkeiten reichen hier von graphischen Benutzerschnittstellen über Multithreading
11 bis zur vollständigen Implementierung von Netzwerkprotokollen.
Java-Applets sind in allen gängigen Webbrowsern und Betriebssystemen lauffähig
und stellen somit keine Einschränkung für die Nutzbarkeit der Visualisierung
dar.
Visualisierungsterminal 1
Anzeigefeld A
SPS 1
Eingabefeld B
SPS 2
Anzeigefeld A
Eingabefeld B
SPS 3
Visualisierungsterminal 2
Abb. 11: Kommunikation via Java-Applet
Innerhalb eines Webbrowsers werden Java-Applets in einer Sandbox 12 mit
stark eingeschränkten Rechten ausgeführt, um zu verhindern, dass bösartiger
Code Schaden anrichten kann [9]. In der Sandbox können nur Verbindungen
zum Quellserver des Applets aufgebaut werden. Das Applet muss mit erweiterten
Rechten ausgeführt werden, damit es Zugriff auf die Prozessdaten der
11 Nebenläufiges oder paralleles Ausführen von Programmcode
12 Isolierte Ausführungsumgebung, die keinen Zugriff auf den ausführenden Computer erlaubt
22

Steuerungen erhalten kann. Dazu gibt es zum einen die Möglichkeit die benötigten
Rechte in einer Policy-Datei auf dem Clientrechner zu hinterlegen, zum
anderen kann man das Java-Applet als Jar-Datei packen und anschließend
signieren. Ein signiertes Applet erhält nach einmaliger Bestätigung des Benutzers
volle Zugriffsrechte auf den Computer. Damit ist auch ein Zugriff auf die
Kommunikationsschnittstellen des Client-Rechners möglich. Die zweite Variante
ist hier zu bevorzugen, da der Benutzer so keine Änderungen an Systemdateien
von Hand durchführen muss.
3.4 Kommunikationssysteme
3.4.1 CAN und andere Feldbussysteme
Es ist möglich, den CAN-Bus weiterhin als Kommunikationsschnittstelle zur Visualisierung
zu nutzen, da die Steuerungssoftware für Prozessdaten bereits auf
dieses System ausgerichtet ist. Für Parameter etc. wird jedoch zurzeit PVI genutzt.
Diese Funktionalität müsste dann für die CAN-Schnittstelle reimplementiert
werden, was einen hohen Aufwand nach sich ziehen würde.
Da für den CAN-Bus spezielle Schnittstellenkarten benötigt werden, stellt
sich das Problem, wie aus dem Java-Applet auf den Treiber zugegriffen werden
kann. Für die meisten Schnittstellenkarten wird vom Hersteller eine C/C++ API
zur Verfügung gestellt, auf die mit Hilfe des Java Native Interfaces zugegriffen
werden kann. Dafür muss eine spezielle Bibliothek als Brücke zwischen Java
und C/C++ erstellt werden, die mit dem Java-Applet ausgeliefert und auf dem
Clientrechner installiert werden muss. Gleiches gilt auch für andere Feldbussysteme
wie den Powerlink-Bus.
Vor-/Nachteile:
+ Bewährte Technik
+ N:M Kommunikation
+ Eine gemeinsame Steuerungsschnittstelle
- Spezielle Schnittstellenkarten benötigt
- Implementierungsaufwand für Parameterübertragung
- Keine Standard-API zur Ansteuerung der Karte
- Probleme bei Zugriff über Java-Applet
23

3.4.2 TCP basierte Protokolle
Da sowohl die Steuerungen, als auch die Visualisierungsterminals an ein gemeinsames
TCP/IP-Netzwerk angeschlossen sind, ist es nahe liegend, dieses
zur Übertragung der Prozessdaten und der Bilddefinitionen zu nutzen. So ist es
möglich, die vorhandenen Programmierschnittstellen der Java-
Klassenbibliotheken zu verwenden, wodurch der Entwicklungsaufwand für das
Applet deutlich reduziert wird. Der Steuerungshersteller B&R stellt Bibliotheken
zur Verfügung, die die Entwicklung von TCP- und UDP-basierten Anwendungen
auf der SPS erlauben.
Bei TCP handelt es sich um ein gesichertes Transportprotokoll, welches
verbindungsorientiert arbeitet und deshalb ohne Erweiterungen nur die Peer-
To-Peer 13 Kommunikation unterstützt. Die Visualisierung hat allerdings die Anforderung,
dass beliebig viele Visualisierungsclients auf die Daten einer Steuerung
zugreifen können. Damit dies mittels TCP erreicht werden kann, müssen
auf der Steuerung die Verbindungen zu allen Clients verwaltet und einzeln bedient
werden. Auf Grund der notwendigen Struktur 14 des Steuerungsprogramms
ergibt sich deshalb ein größerer Aufwand für die Erstellung der Steuerungssoftware.
Zusätzlich muss in der Visualisierung die Information hinterlegt sein,
welche Prozessvariable von welcher Steuerung zur Verfügung gestellt wird.
Das führt bei der Visualisierung zu zusätzlichen Fehlerquellen sowie zu einem
erhöhten Pflegeaufwand, da diese Information zusätzlich gepflegt werden
muss.
Vor-/Nachteile:
+ Standardprotokoll
+ Gesicherter Transport
- Punkt-zu-Punkt-Verbindungen
- Aufwändige Implementierung auf der Steuerungsseite
- Pflege von zusätzlichen Konfigurationsdaten
13 Zwei Teilnehmer kommunizieren direkt (Punkt-zu-Punkt) miteinander. Die Übertragung ist für
Dritte nicht sichtbar.
14 Programm wird zyklisch abgearbeitet. Nebenläufiges Ausführen von Code innerhalb eines
Programms ist nicht möglich.
24

3.4.3 UDP basierte Protokolle
Das UDP-Protokoll setzt im Gegensatz zu TCP keine Server-Client–Beziehung
der Kommunikationsknoten voraus, sondern erlaubt eine gleichberechtigte
Kommunikation der Teilnehmer. Da UDP verbindungslos arbeitet, müssen weder
steuerungsseitig noch in der Visualisierung Verbindungen verwaltet werden.
Obwohl UDP ein verbindungsloses Protokoll ist, müssen die einzelnen Kommunikationsteilnehmer
die IP-Adressen der anderen Knoten kennen, um Zugriff auf
deren Prozessvariablen zu erhalten.
Die Tatsache, dass UDP ohne weitere Maßnahmen nur ungesicherten Datentransport
erlaubt, stellt für die Übertragung der Daten von der Steuerung zur
Visualisierung kein grundlegendes Problem dar, da die Daten zyklisch gesendet
werden. Die Pakete von der Visualisierung zur Steuerung dürfen unter keinen
Umständen verloren gehen. Ein Paketverlust kann zum Beispiel dazu führen,
dass die Betätigung eines Buttons in der Visualisierung nicht von der Steuerung
empfangen wird und die Eingabe so wirkungslos bleibt. So ist es für diese Übertragungsrichtung
notwendig, den Transport gegen Paketverluste zu sichern.
Dies erfolgt in der Regel mit einem anwendungsspezifischen Protokoll, das auf
UDP aufbaut, und der Nutzung von Bestätigungsnachrichten.
Vor-/Nachteile:
+ Standardprotokoll
+ Verbindungslos
+ Geringer Implementierungsaufwand
+ Wenig Protokolloverhead
- Peer-To-Peer-Kommunikation
- Sicherer Transport nur durch zusätzliches Protokoll
3.4.4 UDP Mulitcast als Kommunikationsprotokoll
Da das UDP-Protokoll bereits die meisten Anforderungen an ein Protokoll für
die Visualisierung erfüllt, aber ebenfalls nur eine 1:1-Kommunikation bietet, wird
zusätzlich UDP-Multicast eingesetzt. Das System zeigt somit ein Verhalten, wie
es bereits vom CAN-Bus bekannt ist: ein Teilnehmer sendet ein Paket und alle
anderen Teilnehmer empfangen es.
25

Die Adressierung bei UDP-Multicast wird über IP-Gruppen realisiert, denen
jeweils eine Multicast-IP-Adresse zugeordnet wird. Diese wird wiederum in eine
Multicast-MAC 15 -Adresse umgerechnet. Alle Netzwerkkarten akzeptieren Pakete
mit diesen speziellen MAC-Adressen und leiten sie an den Protokollstack im
Betriebssystem weiter. Dieser verteilt wiederum die Pakete dann an die entsprechenden
Anwendungen weiter.
IPv4
235 0 0 7
1 1 1 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1
MAC
0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1
01 00 5E 00 00 07
Abb. 12: Adressumsetzung von IPv4 nach Ethernet-Multicast
Die Umsetzung von IP-Multicastadressen in Ethernet-Multicastadressen
geschieht durch Umkopieren der unteren 23 Bit der IPv4- in die MAC-Adresse
[10]. Diese Umsetzung ist surjektiv 16 , da mehrere IPv4-Adressen auf dieselbe
MAC-Adresse führen können. Das erlaubt bereits in der Netzwerkkarte eine
Vorfilterung der Pakete nach den niedrigen 23 Bit der Adresse. Die weitere Filterung
wird dann vom Betriebssystem des Computers durchgeführt.
Visu 2
Visu 1
UDP
Multicast Gruppe
235.0.0.0
SPS 1
SPS 2
15 Media Access Control Adresse – Hardware Adresse eines Netzwerkadapters, die weltweit
eindeutig vom Hersteller vergeben wird.
16 Mehrere Elemente des Definitionsbereiches werden auf ein Element des Wertebereiches
abgebildet.
26

Abb. 13: UDP-Multicast Kommunikationsmodell
Das N:M-Kommunikationsmodell ermöglicht das Austauschen von Prozessdaten
zwischen den einzelnen Teilnehmern, ohne dass bekannt sein muss,
von welcher Steuerung das Datum stammt oder welches Bedienterminal das
Datum auswertet. Es ergibt sich dadurch ein „loses“ Netzwerk, zu dem zur
Laufzeit neue Teilnehmer hinzugefügt oder entfernt werden können.
In einem solchen System können Ausfälle von Teilnehmern nicht erkannt
werden. Daher sendet jede Steuerung zyklisch ein Heartbeat 17 -Paket über den
Multicast an die anderen Kommunikationsteilnehmer. Falls diese Pakete ausbleiben,
können die anderen Kommunikationseilnehmer die Daten der entsprechenden
Steuerung als ungültig kennzeichnen und so die Anzeige und Verarbeitung
von veralteten Daten verhindern.
3.5 Übertragungsprotokoll
Zur Behebung der zuvor dargestellten Nachteile des UDP-Protokolls wird ein
weiteres Protokoll oberhalb von UDP eingesetzt. Es dient der variablenorientierten
Kommunikation der einzelnen Teilnehmer und der Sicherung des Transportes
von ereignisbasierten Nachrichten. Das Protokoll ist bewusst einfach gehalten,
um den Implementierungsaufwand und die Rechenlast auf den Steuerungen
gering zu halten. Sicherheitsanforderungen gegen Angriffe von Dritten sind
in der kontrollierten Maschinenumgebung nachrangig, da das Maschinennetz
im Normalfall keine oder eine gut geschützte Verbindung zum Unternehmensnetz
und damit zum Internet hat.
3.5.1 Funktion
Die Kommunikationsteilnehmer werden in Server- und in Clientknoten aufgeteilt.
Die Serverknoten stellen dabei die Steuerungen dar, die dem System Prozessvariablen
zur Verfügung stellen. Die Clientknoten sind Bedienterminals und
Steuerungen, die die Daten von den Servern entgegennehmen und anzeigen
oder weiterverarbeiten.
Die Übertragung der Daten vom Server zum Client wird entweder zyklisch
durch die Steuerungsapplikation oder auf Anfrage durch die Visualisierung an-
17 Paket ohne Inhalt um die Anwesenheit eines Kommunikationsteilnehmers zu zeigen
27

gestoßen. Den Clients ist auch ein schreibender Zugriff auf beliebige, serverseitig
konfigurierte, Prozessvariablen erlaubt. Die Datenübertragung vom Server
zum Client ist als ungesicherte Multicast-Übertragung möglich. Über diesen
Weg sollen vor allem zyklische Statusinformationen gesendet werden, bei denen
Paketverluste in Grenzen tolerierbar sind.
Der Server sendet nicht alle Prozessvariablen zyklisch, da sich ihre Werte
nicht laufend ändern und sie folglich nicht zyklisch aktualisiert werden müssen.
Aus diesem Grund ist ein clientgesteuerter Zugriff auf die Prozessvariablen
möglich. Da hier einzelne Pakete ereignisgesteuert gesendet werden, sind Paketverluste
nicht tolerierbar. Verlorene Pakete führen zum Beispiel dazu, dass
in der Visualisierung ein falscher oder kein Wert für einen Parameter angezeigt
wird. Deswegen muss diese Datenübertragung gegen Paketverluste gesichert
werden.
Die Sicherung von Multicast-Transporten setzt meist eine Unterstützung
des Netzes, z.B. durch intelligente Switche, voraus oder die Kenntnis der Kommunikationsteilnehmer
über die Netzwerktopologie [4]. Das Konzept der Sicherung
des Datentransportes mit ACK 18 -Paketen lässt sich nicht problemlos auf
die Multicast-Kommunikation übertragen, da in einem Multicast-Netz ein Paket
per Definition von mehreren Teilnehmern empfangen werden kann. Da ein Paket
auch von keinem Empfänger angenommen werden kann, ist es auch ein
zulässiger Fall, dass der Sender keine Bestätigung erhält. Damit in dieser Situation
der korrekte Versand der Nachrichten sichergestellt werden kann, muss der
Sender die Anzahl der Empfänger kennen, was aber in diesem Fall steuerungsseitig
einen hohen Aufwand bedeuten würde und auch im Widerspruch zu den
Verwendungsgründen eines Multicast-Netzes steht. Die meisten Methoden zur
Sicherung von Multicast-Transport zielen zudem auf die sichere Übertragung
von großen Datenmengen in großen Netzen ab. Die Verteilung von Prozessdaten
ähnelt eher dem Verteilen eines Streams von Audio oder Videodaten, da
Daten aus der Vergangenheit in der Regel uninteressant für die weitere Verarbeitung
sind.
Aus diesen Gründen ist der gesicherte Kanal als Unicast-Kommunikation
ausgelegt. Um dennoch die Eigenschaften des Multicast-Netzes beizubehalten,
werden Anfragen vom Client an einen Server über das Multicast-Netz gesendet.
18 Bestätigungspaket, das der Empfänger für ein empfangenes Paket an den Sender zurückschickt.
28

Der zuständige Server erkennt Anfragen, dass auf eine seiner Prozessvariablen
zugegriffen werden soll, an der Prozessvariablen-ID im Paket und sendet das
Antwortpaket als UDP-Unicast an den Client zurück. Erhält der Client keine
Antwort, dann sendet er die Anfrage nach einer festgelegten Zeitspanne neu.
Nach einer maximalen Anzahl von fehlgeschlagenen Sendeversuchen wird die
Übertragung durch das Applet abgebrochen.
Pakettyp
Übertragung Beschreibung
CYCLIC Multicast Zyklisch vom Server versendetes Datenpaket.
WRITE Multicast Ereignisorientiertes Datenpaket vom Client
zum Server.
WRITE_ACK Unicast Bestätigung des Datenpaketes vom Client
READ Multicast Fordert vom Server ein Prozessdatenpaket an
READ_ACK Unicast Bestätigung des Prozessdatenpaketes mit den
angeforderten Daten
Tabelle 2: UDP-Pakettypen
3.5.2 Paketformate
Jedes Paket enthält zur Erkennung von Paketverlusten eine Sequenznummer
(SEQ), die bei Paketen vom Client zum Server vom Sender festgelegt wird. Die
Antwortpakete vom Server enthalten die Sequenznummer des Paketes vom
Client.
Um die Prozessvariablen eindeutig zu identifizieren, werden eine Servernummer
(SRC) und eine Variablen-ID (PVID) eingeführt. Die Variablen-ID ist für
jeden Server eindeutig zu vergeben. Aus der Kombination der Servernummer
und der Variablen-ID ergibt sich eine systemweit eindeutige Identifizierung für
die Prozessvariablen.
Die Clients benötigen zur Auswertung der Pakete neben den eigentlichen
Daten eine Beschreibung, wie diese zu interpretieren sind. Dazu muss im System
die Definition der Prozessvariablen verteilt werden. Dies erfolgt über eine
Konfigurationsdatei auf der Steuerung. Sie enthält den Namen der Prozessvariablen,
den Datentyp und die Variablen-ID. Damit die Visualisierungsclients e-
29

enfalls diese Informationen nutzen können, muss die Datei über den Webserver
der Steuerung erreichbar sein.
32
0
SRC
SEQ 0
PVID
DATA (1 .. n Bytes)
TYPE = 1
Abb. 14: CYCLIC Paket (Server => Multicast => Client)
32
0
SRC
SEQ 0
PVID
DATA (1 .. n Bytes)
TYPE = 2
Abb. 15: WRITE Paket (Client => Multicast => Server)
32
0
SEQ = WRITE.SEQ 0
SRC
PVID
TYPE = 3
Abb. 16: WRITE_ACK Paket (Server => Client)
32
SRC
SEQ 0
PVID
TYPE = 4
0
Abb. 17: READ Paket (Client => Multicast => Server)
32
0
SEQ = READ.SEQ 0
SRC
PVID
DATA (1 .. n Bytes)
TYPE = 5
Abb. 18: READ_ACK Paket (Server => Client)
30

Datentyp Länge in Bytes Beschreibung
S8 1 -128 .. 127
U8 1 0 .. 255
S16 2 -32768 .. 32767
U16 2 0 .. 65535
S32 4 -2147483648 .. 2147483648
U32 4 0 .. 4294967295
FLOAT 4 -3.4e38 .. 3.4e38
STRING Variabel ASCII-Zeichenkette fixer Länge
BINARY Variabel Binärdaten ohne spezifiziertes Format
Tabelle 3: Datentypen für die Kommunikation zur Visualisierung
3.5.3 Implementierung des Protokolls im Java-Applet
Das Kommunikationsprotokoll ist vollständig im Java-Applet implementiert. Innerhalb
des Applets werden die Prozessvariablen durch Objekte gekapselt. Das
Applet abstrahiert das objektorientierte Datenmodell in eine einfache, prozedurale,
stringbasierte Schnittstelle, die für Javascriptanwendungen einfach zu benutzen
ist. Das Protokoll wird innerhalb des Applets durch die Klasse Udp-
Comm und einen protokollspezifisch erweiterten Socket umgesetzt. Die Klasse
UdpComm wertet die Konfigurationsdaten für die Prozessvariablen von der
Steuerung aus und legt für jede Variable ein typisiertes Variablenobjekt an. Eine
Hash-Tabelle 19 verwaltet die Variablenobjekte um einen effizienten Zugriff über
den Variablennamen zu erhalten. Da sich die Auswertung der Binärdaten der
Prozessvariablen jeweils im Datentyp unterscheidet, ist jedes Variablenobjekt
eine Instanz einer typisierten Variablenklasse, die von einer allgemeinen Klasse
Variable abgeleitet ist. Diese Basisklasse enthält bereits sämtliche Funktionen,
19 Datenstruktur, die die effiziente Zuordnung von einem Datensatz zu einem String erlaubt.
Die Suche nach einem Datensatz bei gegebenem String ist in konstanter Zeit möglich.
31

die alle Variablenobjekte gemeinsam haben. Die Unterklassen enthalten dann
die datentypspezifische Auswertung und Erzeugung der Daten für die UDP-
Pakete.
Abb. 19: Klassendiagramm des Java-Applets
Die einzelnen Variablenobjekte sind über ein Observer-Pattern mit dem
Socket verbunden. Dieser gibt empfangene Daten zur Auswertung an die einzelnen
Variablenobjekte weiter. Wird der Wert einer Prozessvariable über das
entsprechende Variablenobjekt aktualisiert, stößt es selbstständig über den Socket
das Senden des neuen Wertes an. Die Sicherung des Transportes durch
Timeouts und Retransmissions wird transparent im Socket realisiert. Dieser generiert
für jedes Paket eine Sequenznummer und speichert es nach dem Senden
mit dieser Nummer und einem Zeitstempel in einer Liste zwischen. Trifft
eine Bestätigungsnachricht für eine Sequenznummer von der bearbeitenden
Steuerung ein, dann entfernt eine Routine im Socket das entsprechende Paket
aus der Liste. Ein Thread durchsucht die Liste zyklisch nach Paketen, die vor
mehr als 500 Millisekunden gesendet wurden. Findet er ein entsprechendes
Paket, sendet er es mit derselben Sequenznummer erneut. Insgesamt wird die-
32

ser Vorgang höchstens dreimal wiederholt. Nach dem alle drei Sendeversuche
fehlgeschlagen sind, entfernt der Thread das Paket aus der Sendeliste.
Applikation VariableFloat Proto.Socket SPS
readVariable()
sendRead()
READ
Timer
READ
READ_ACK
parsePacket()
getValue()
Abb. 20: Sequenzdiagramm der Datenübertragung
Durch die Verlagerung der Auswertung der Datenpakete in einzelne typisierte
Klassen ist eine gute Erweiterbarkeit für neue Datentypen gegeben, da
nur eine neue Typklasse erstellt werden muss. Ansonsten sind keine weiteren
Änderungen erforderlich.
3.5.4 Kommunikationsprotokoll in der Steuerung
Die Schnittstelle des Kommunikationsprotokolls in der Steuerung funktioniert
ähnlich zur Schnittstelle des CAN-Treibers von B&R. Jeder an das Kommunikationssystem
angeschlossenen Prozessvariablen ist eine Ereignisvariable
zugeordnet. Die Applikationssoftware interagiert mit dem Kommunikationsprotokoll.
Durch das Setzen der Ereignisvariablen einer Prozessvariablen auf den
Wert mcastSEND kann die Applikation das Senden der entsprechenden Daten
anstoßen. Da die Daten in diesem Fall ungesichert über das Multicast-Netz an
33

die anderen Kommunikationsteilnehmer übertragen werden, sollte dieser Mechanismus
vor allem für die zyklische Übertragung genutzt werden.
Den schreibenden Zugriff eines Kommunikationsteilnehmers wird der
Applikationssoftware durch das Setzen der Ereignisvariablen auf mcastUPDA-
TED mitgeteilt. Nachdem der Protokolltreiber die Ereignisvariable gesetzt hat,
kann die Applikation mit der Auswertung der Daten beginnen. Nachdem die Applikation
fertig ist, sollte sie die Ereignisvariable auf mcastIDLE zurücksetzen,
damit der nächste Schreibzugriff erkannt werden kann.
Zur steuerungsseitigen Konfiguration des Protokolls müssen die Prozessvariablen
in der Steuerungssoftware angelegt und in einer Konfigurationsdatei
eingetragen werden. Die Konfigurationsdatei enthält pro Prozessvariable
eine Zeile mit der ID der Prozessvariablen, dem Datentyp, den Zugriffsrechten
für die anderen Kommunikationsteilnehmer und dem Namen.
Für die Kommunikation mit der Visualisierung sollten in der Steuerung
eigene Prozessvariablen vorgesehen werden, die ungeprüft nicht weiter verwendet
werden dürfen. Die Steuerungssoftware muss bei Schreibzugriffen
durch die Visualisierung, angezeigt durch eine gesetzte Ereignisvariable, den
eingegebenen Sollwert überprüfen und in ihre eigenen gespiegelten Sollwertvariablen
übernehmen. Diese Sollwerte sendet die Steuerung zur Anzeige an die
Visualisierung zurück und verwendet sie intern weiter. Durch diese Konvention
ist sichergestellt, dass durch ungültige Eingaben an der Visualisierung keine
Probleme verursacht werden können.
Für das Auslösen von einmaligen Aktionen (Triggern) wird ein ähnliches
Muster verwendet. Hier überprüft die Steuerungssoftware ebenfalls nur die Ereignisvariable
der entsprechenden Prozessvariablen. Durch einen Schreibzugriff
löst die Applikation nach Überprüfung etwaiger Randbedingungen die
Aktion aus und setzt die Ereignisvariable zurück.
34

Applikation
UDP
Applikation sendet
zyklisch
Ereignisvariable setzen
mcastSEND
Ereignisvariable rücksetzen
mcastIDLE
Ereignisvariable setzen
mcastUPDATED
UDP-Paket
senden
UDP-Paket
empfangen
Applikation prüft Ereignisvariable
Empfangener Wert
wird verarbeitet
Abb. 21: Kommunikation über Ereignisvariablen
Ereignisvariable rücksetzen
mcastIDLE
Start
Start
Ereignisv.
aktualisiert
Nein
Ereignisv.
aktualisiert
Nein
Ja
Ja
Sollwert
gültig
Nein
Randbed.
erfüllt
Nein
Ja
Sollwert ü-
bernehmen
Sollwert
begrenzen
Ja
Aktion ausführen
Gespiegelten
Sollwert
senden
Ende
Ende
Abb. 22: Verarbeitung von Sollwerten und Aktionen
35

3.6 Datenspeicherung
Die bereits angedeutete verteilte Speicherung der Definitionsdaten der Bedienbilder
bietet im Gegensatz zu einer zentralen Speicherung den Vorteil, dass die
Bedienbilder etc. mit den Steuerungen zu logischen Einheiten zusammengefasst
werden können. So existiert zusätzlich zum Webserver auf dem Leitstand
ein weiterer Webserver auf jeder Steuerung. Diese dienen in erster Linie als
Fileserver und stellen die Bildlisten, die Bilddefinitionen sowie die Konfigurationsdateien
für das Kommunikationsprotokoll zur Verfügung. Durch die Zusammenfassung
der Daten können die Bedienbilder und Variablendefinitionen bei
einem Update der Steuerungssoftware ohne weiteren Aufwand aktualisiert werden.
Browser
Bild
Bild
Bild
Leitrechner
SPS
Bild
Bild
Bild
Bild
HTML
JavaScript
Applet
Variablen
Abb. 23: Datenspeicherung für Bedienseiten
Zur Speicherung des Grundgerüstes der Visualisierung dient ein normaler
Webserver. Von diesem Server laden die Visualisierungsclients den Kern sowie
allgemeine Bedienbilder, die die gesamte Anlage betreffen und daher keiner
Steuerung zugeordnet werden können. Die Dateien sind in einer Ordnerstruktur
abgelegt, die für jede Kategorie von Dateien einen Unterordner enthält. Im Wurzelverzeichnis
des Servers befindet sich die eigentlichen HTML-Datei mit dem
Kern der Visualisierung.
Die Webserver auf den Steuerungen enthalten ausschließlich die Bilddefinitionen
ihrer Bedienbilder sowie die Konfigurationsdatei für die Prozessvariablen.
36

Sie enthalten im Gegensatz zum Leitstandsserver aber nur den Unterordner für
die Daten.
Pfad
/index.htm
/css
/data
/data/main.xml
/data/parameter_allg.xml
/data/variablen.ini
/images
/script
/script/udpcomm.jar
/script/bild.js
/script/util.js
/script/widgets.js
Beschreibung
Startseite der Visualisierung
Ordner für Cascading Stylesheets
Ordner für Bilddefinitionsdateien und
die Konfigurationsdatei der Prozessvariablen
Bilddefinition des Hauptbedienbildes
Bilddefinition für das allgemeine Parameterbild
Konfigurationsdatei für Prozessvariablen
Grafiken für die Visualisierung
Ordner mit den Skripten für die Visualisierung
Java-Applet zur Kommunikation
Implementierung der Klassen Bild und
XmlBild
Hilfsskripte z.B. für Klassenhierarchien
Implementierung der einzelnen Bedienelemente
Tabelle 4: Verzeichnisstruktur der Visualisierung
37

4 Implementierung am Beispiel eines Teststandes
In diesem Abschnitt werden die zuvor entwickelten Konzepte am Beispiel eines
Teststandes implementiert. Bei dem Teststand handelt es sich um ein Druckwerk
einer Flexodruckmaschine, das um einen Gegendruckzylinder ergänzt
wurde. Der Aufbau dient zum Vermessen und Ausregeln von Schwingungen,
die im Druckprozess auftreten.
Abb. 24: CAD-Rendering des Teststandes
Der Teststand verfügt über drei rotierende Zylinder die unabhängig von
einander angetrieben sind. Auf dem mittleren Zylinder, dem Formatzylinder (in
Fig. 14 grün dargestellt), ist eine Gummimatte - das Klischee - aufgeklebt. Die
Zylinder werden bei synchroner Umfangsgeschwindigkeit in Kontakt gebracht
und simulieren so den Druckprozess. Die zu untersuchenden Schwingungen
entstehen durch die Anlaufkanten des Klischees. Der Fomatzylinder und die
Rasterwalze (der Zylinder im Vordergrund) sind austauschbar. Dazu besitzen
sie an beiden Enden Lager, die zur Entnahme der Zylinder pneumatisch geöffnet
werden können.
Die Synchronisierung und Drehzahlregelung der Antriebe erfolgt über drei
Frequenzumrichter unter Kontrolle einer speicherprogrammierbaren Steuerung.
Die Frequenzumrichter sind über einen Powerlink-Bus mit der Steuerung ver-
38

unden. Zur Bedienung verfügt der Teststand über einen PC mit einem Touchpanel.
Dieser ist über ein gewöhnliches Ethernet-Netzwerk mit der SPS verbunden.
Abb. 25: Steuerungsarchitektur des Teststandes
Die Benutzeroberfläche des Teststandes soll folgende Anforderungen erfüllen:
• Vorgabe von Geschwindigkeitsprofilen
• Anzeige der aktuellen/maximalen Ströme der Motoren
• Anzeige der aktuellen Geschwindigkeit
• Parametrierung der Steuerung über eine Parameterseite
• Parametrierung der Antriebsregler über eine Parameterseite
39

4.1 Funktion des Teststands
Die Bedienung des Teststandes setzt sich aus dem Touchpanel mit der Visualisierung
und einigen Tastern am Schaltschrank zusammen.
Taster
Start
Handbetrieb
Stopp
Beschleunigen/Vor
Verzögern/Zurück
Funktion
Ein Tastendruck startet die Bewegung
des Teststands in Vorrückgeschwindigkeit
mit Drehmomentbegrenzung.
Der zweite Tastendruck stellt die Begrenzung
ab und gibt die Geschwindigkeitsrampen
frei. Jeder weitere
Tastendruck startet eine Geschwindigkeitsrampe
mit den Vorgabewerten
der Visualisierung.
Startet den Teststand im Handbetrieb.
Der Teststand kann dann über Taster
in beide Drehrichtungen bewegt werden.
Hält den Teststand unabhängig von
der Betriebsart an und schaltet die
Antriebe ab.
Im Automatikbetrieb wird die Geschwindigkeit
des Teststandes erhöht.
Im Handbetrieb dreht der Teststand
vorwärts.
Im Automatikbetrieb wird die Geschwindigkeit
des Teststandes verringert.
Im Handbetrieb dreht der
Teststand rückwärts.
Tabelle 5: Taster zur Bedienung des Teststands
40

Da sowohl Formatzylinder als auch Rasterwalze austauschbar sind, gibt es
die Möglichkeit, über einen Parameter deren Durchmesser und damit die Umfangsgeschwindigkeit
anzupassen. Da die eingegebenen Werte jedoch nicht
durch die Steuerung überprüft werden können, besteht die Gefahr, dass der
Formatzylinder mit den Messeinrichtungen durch eine falsche Eingabe beschädigt
werden kann. Um diese Gefahr zu verringern, ist der zweistufige Einschaltvorgang
mit Drehmomentbegrenzung vorgesehen. Im Falle einer fehlerhaften
Eingabe wird der Formatzylinder vom Gegendruckzylinder, der ohne Drehmomentbegrenzung
betrieben wird, mitgezogen. Auf diese Weise sollen Beschädigungen
der Messeinrichtungen verhindert werden.
4.2 Bedienoberfläche
Die Bedienoberfläche des Teststandes ist in zwei Bereiche gegliedert. Das
Hauptbedienbild erlaubt das Einstellen von Prozessdaten wie z.B. der Zielgeschwindigkeit
für Geschwindigkeitsrampen. Die Parameterseiten ermöglichen
die Eingabe von grundlegenden Betriebsparametern des Teststands wie z.B.
die maximale Geschwindigkeit, Nothaltrampen oder Reglerparametern. Für jeden
Antrieb gibt es ein eigenes Parameterbild mit den entsprechenden Antriebsparametern.
Abb. 26: Hauptbedienbild des Teststands
41

Das Hauptbild zeigt zusätzlich zur aktuellen Geschwindigkeit des Teststandes
auch Messwerte der drei Antriebe an. Neben den Anzeigen sind auch noch
Eingabefelder für den Zielwert einer Geschwindigkeitsrampe, die Beschleunigung
der Rampe und ein Eingabefeld zur Kontrolle der Klapplager vorhanden.
Am unteren Bildrand befindet sich ein Anzeigefeld für Fehlermeldungen der
Steuerung. Das allgemeine Parameterbild enthält zu jedem der drei Zylinder
einige grundlegende Parameter wie den Durchmesser, den maximalen Motorstrom
oder die Drehrichtung. Zusätzlich können allgemeine Einstellungen für
den Teststand, wie die maximale Geschwindigkeit, Standardwerte für Beschleunigungen
und die Geschwindigkeit für den Handbetrieb eingegeben werden.
Zwei Buttons erlauben sowohl das Lesen als auch das Schreiben der Parameter
aus dem Hintergrundspeicher der Steuerung. Über einen weiteren Button
kann die Steuerung neu gestartet werden.
Abb. 27: Parameterbild für allgemeine Parameter
Die Parameterbilder für die drei Antriebe sind jeweils identisch. Deshalb
werden sie hier am Beispiel des Bildes für den Gegendruckzylinder erläutert.
Zur Regelung der Antriebe verwendet der Frequenzumrichter der Firma B&R
eine Kaskadenregelung. Diese besteht aus drei ineinander verschachtelten Re-
42

gelkreisen. Der Sollwert des inneren Regelkreises ist dabei jeweils die Stellgröße
des äußeren.
Der äußerste Regelkreis ist der Lageregler. Er erhält seinen Sollwert von
der SPS-Software. Es handelt sich um einen PI-Regler mit den Parametern kv -
Proportionalverstärkung und tn - Integrierzeitkonstante. Mittels der Parameter
p_max und i_max kann eine Begrenzung der Stellgröße des Reglers eingestellt
werden. Die Parameter t_total und t_predict erlauben unter anderem eine Geschwindigkeitsaufschaltung
auf den Stellwert des Reglers und eine Buslaufzeitkompensierung
der Sollwerte, falls, wie hier der Fall, verschiedene Frequenzumrichter
über ein Bussystem gekoppelt werden. Der Lageregler erzeugt aus
der Soll- und Istposition ein Sollwert für den unterlagerten Drehzahlregler. Dieser
Regler ist ebenfalls ein PI-Regler mit den Parametern kv und tn. Für den
Drehzahlistwert kann mittels des Parameters t_filter noch ein Tiefpassfilter konfiguriert
werden. Der Drehzahlregler stellt den drehmomentbildenden Statorstrom.
Er wird nach einer Reihe von Filtern als Führungsgröße für den
Stromregler übernommen. Dieser Regler wird durch ein Datenmodul auf der
Steuerung automatisch konfiguriert und daher besteht keine Notwendigkeit,
diese Parameter über die Visualisierung zugänglich zu machen.
Abb. 28: Parameterbild für die Antriebsregelung
43

4.3 Steuerungssoftware
Bei der Steuerung handelt es sich um eine SPS des Typs CP360 von B&R. Die
Steuerung ist ein modular aufgebautes system. Sie besteht aus einer Grundplatte,
die die Stromversorgung sowie die eigentliche Steuerung als Steckmodul
enthält. Die Steuerung kann durch Baugruppen wie digitale oder analoge
Ein/Ausgänge erweitert werden. Zusätzlich bietet die CPU einen Steckplatz für
ein Schnittstellenmodul zur Kommunikation mit weiteren Geräten. In der verwendeten
Konfiguration wird ein Modul mit einer Powerlink- sowie einer CAN-
Schnittstelle verwendet. Der Prozessor der Steuerung wird mit einer Taktfrequenz
von 266MHz betrieben und die Applikationssoftware kann auf 32MByte
DRAM und 496KByte SRAM zurückgreifen.
Die Steuerungssoftware wird durch das Betriebssystem der SPS, der Automation
Runtime, in Tasks unterteilt, die einer Taskklasse zugeordnet sind.
Jeder Task innerhalb einer Taskklasse wird zyklisch mit einer durch die
Taskklasse festgelegten Zykluszeit und Priorität ausgeführt. Taskklassen mit
einer hohen Priorität können Klassen mit niedrigerer Priorität unterbrechen.
Task Zyklus [ms] Priorität Beschreibung
MessTask 0,8 1 Messwerterfassung der Antriebe,
Verarbeitung und CAN-Übertragung
an ein externes Messsystem
AchsTask 10 2 Ablaufsteuerung des Teststandes,
Ansteuerung der Frequenzumrichter
ParamTask 500 6 Verwaltung von Parameterdaten,
Lesen/Schreiben des Flashspeichers
UdpTask 5 8 Verarbeitung der UDP-Pakete der
Visualisierung, zyklisches Senden
der Istwerte an die Visualisierung.
Tabelle 6: Steuerungstasks
In den Tasks wird viel Code mehrfach genutzt, der in gemeinsamen Bibliotheken
abgelegt ist.
44

Bibliothek
McLib
UdpLib
AlarmLib
Beschreibung
Bibliothek mit Funktionsblöcken zur Achssteuerung und
Bewegungsprofilerzeugung
Funktionsblöcke zur Kommunikation mit der Visualisierung
über UDP
Funktionen zur Verwaltung der Alarmmeldungen in einer
Warteschlange.
Tabelle 7: Bibliotheken
Jeder Task besteht aus einer Initialisierungsfunktion, einer zyklischen Funktion
sowie einer Funktion, die beim Beenden des Tasks aufgerufen wird.
4.3.1 Task MessTask
Der Task MessTask dient zur Erfassung der Antriebsmesswerte. Die Messwerte
werden auf zwei Wegen aus den Antrieben gelesen. Einige Daten werden
zyklisch über den Powerlink-Bus (Zykluszeit 800us) übertragen. Diese Methode
wird für funktionsrelevante Daten wie Motorströme und die Lage des Formatzylinders
genutzt, die mit kurzen Zykluszeiten verarbeitet werden müssen.
Weniger relevante Daten, vor allem zur Anzeige in der Visualisierung, werden
über einen Servicekanal gelesen. Für diese Daten ist im zyklischen Powerlinktelegramm
ein fester Bereich vorgesehen. Es kann pro Powerlinkzyklus nur
eine Variable übertragen werden. Dadurch ist die Übertragungsgeschwindigkeit
dieses Kanals abhängig von der Anzahl der zu übertragenden Variablen begrenzt.
Aufgrund dieser Beschränkung ist dieser Kanal für Daten mit sehr kurzen
Zykluszeiten, wie z.B. der Formatzylinderposition, ungeeignet. Wegen des
sequentiellen Charakters dieser Übertragung wird sie durch eine State-Machine
kontrolliert, die den Ablauf der Übertragung mehrerer Variablen kontrolliert.
Neben dem eigentlichen Erfassen der Messwerte erfolgt in diesem Task
auch die Umrechnung der Werte zur Anzeige in der Visualisierung. Zusätzlich
bestimmt der Task auch die Spitzenwerte der Motorströme und die elektrische
Gesamtleistung des Teststands. Die Formatzylinderposition sowie der drehmomentbildende
Strom des Formatzylinders werden nach der Verarbeitung in
45

jedem Taskzyklus über die CAN-Schnittstelle der Steuerung an ein externes
Messwerterfassungssystem gesendet.
4.3.2 Task AchsTask
Dieser Task dient zur generellen Ansteuerung der Achsen. Er beinhaltet die
State-Machine der Ablaufsteuerung des Teststandes. Sie bildet die verschiedenen
Betriebsarten und Betriebsmodi des Systems ab. Die Zustandsübergänge
werden zum Beispiel durch Tastendrücke oder auch steuerungsinterne Ereignisse
ausgelöst. Zusätzlich enthält die State-Machine auch die Fehlerbehandlung
für Antriebsfehler, Nothaltbedingungen etc.
Abb. 29: Zustandsdiagramm „AchsTask“
Aus dem Zustand der State-Machine werden in Abhängigkeit von weiteren
Eingangssignalen die Signale für die Funktionsblöcke zur Steuerung der Umrichter
erzeugt. Diese Funktionsblöcke beinhalten wiederum Schrittketten, die
46

genau den Schritten entsprechen, die zur Kontrolle der Antriebe notwendig
sind. Sie senden Kommandos an die Umrichter, die dann schließlich zu den
gewünschten Bewegungen der Antriebe führen.
Daneben beinhaltet der Task auch die Erzeugung der digitalen Ausgangssignale
zur Ansteuerung der Motorlüfter, der Klapplager und der Leuchten in
den Bedientastern. Zusätzlich werden die Kommandos der Visualisierung zur
Parametrierung der Frequenzumrichter verarbeitet. Um ein derartiges Kommando
an einen Antrieb zu senden, greift die Visualisierung schreibend auf die
entsprechende Prozessvariable in der Steuerung zu. Diese erkennt den Zugriff
anhand der gesetzten Ereignisvariablen. Das Programm setzt daraufhin die Ereignisvariable
auf ihren Anfangswert zurück und stößt, wenn der Betriebszustand
der Steuerung dies zulässt, das entsprechende Kommando am Funktionsblock
der Achse an. Das Ende des Kommandos zeigt er an einem seiner
Ausgänge an, worauf das Steuerungsprogramm den Kommandoeingang des
Funktionsblocks zurücksetzt. Der Wert, auf den die Visualisierung die Prozessvariable
setzt ist irrelevant, da es sich um eine reine, ereignisbasierte Triggerfunktion
handelt.
4.3.3 Task ParamTask
Der Task ParamTask dient zur Verwaltung der Steuerungsparameter. Beim
Systemstart liest er die Parameter aus einem Datenmodul 20 und kopiert sie in
den Arbeitsspeicher. Falls das Datenmodul nicht existiert oder nicht lesbar ist,
wird es mit Standardwerten neu erzeugt. Die Visualisierung kann während des
Betriebes auf die Parameter lesend und schreibend zugreifen. Sie sind durch
die Variablenkonfiguration an die UDP-Kommunikation angeschlossen. Da sie
nur bei der Anzeige einer Parameterseite benötigt werden, werden die Parameter
nur durch eine Leseanfrage der Visualisierung übertragen. Die Visualisierung
hat auf diese Variablen vollen Schreibzugriff. Diese Art der Anbindung erzeugt
steuerungsseitig keinen zusätzlichen Programmieraufwand, da die Protokollimplementierung
den Zugriff selbstständig abwickelt.
Das Laden und Speichern der Parameter aus dem Datenmodul durch die
Visualisierung funktioniert analog zur Bearbeitung der Kommandos zur Reglerparametrierung.
20 Entspricht einer Konfigurationsdatei, die auf der Steuerung abgelegt ist.
47

4.3.4 Task UdpTask
Im UdpTask wird die Netzwerkschnittstelle der Steuerung verwaltet sowie die
Kommunikation zur Visualisierung durchgeführt. Die primäre Aufgabe dieses
Tasks ist das zyklische Aufrufen der UDP-Biblothek zur Verarbeitung von eingehenden
UDP-Paketen und zum Senden von Prozessvariablen. Zur Konfiguration
der Netzwerkschnittstelle enthält der Task eine State-Machine. Dieser
Automat liest nach dem Start der Steuerung die aktuelle IP-Adresse aus und
vergleicht sie mit der IP-Adresse aus den Parametern. Falls sie nicht identisch
sind, werden die Adresse und die Subnetzmaske auf den parametrierten Wert
gesetzt.
Neben der Verwaltung der Netzwerkschnittstelle und dem Aufruf der Kommunikationsbibliothek
wertet der Task Sollwerteingaben von der Visualisierung
aus. Dazu wird, ähnlich zu den Triggern, die Ereignisvariable beobachtet. Zeigt
sie eine Aktualisierung des Sollwertes der Visualisierung an, so überprüft das
Programm den Sollwert und kopiert ihn in eine gespiegelte Sollwertvariable der
Steuerung. Anschließend stößt es das Senden des gespiegelten Sollwertes
durch Setzen der entsprechenden Ereignisvariable an. Innerhalb der Steuerung
werden nur die gespiegelten und überprüften Sollwerte verwendet. So ist sichergestellt,
dass der Benutzer durch ungültige Eingaben keinen Schaden anrichten
kann. Auf die gespiegelten Sollwerte hat die Visualisierung keine schreibenden
Zugriffsrechte.
Um die Istwerte zyklisch an die Visualisierung und an andere Kommunikationsteilnehmer
zu versenden, wird ein Timer genutzt. Mit dessen Hilfe wird die
Übertragung der zyklischen Prozessvariablen an die Visualisierung angestoßen.
Die Heartbeat-Nachrichten werden durch einen ähnlichen Mechanismus
gesendet.
4.3.5 Bibliothek UdpLib
Die vollständige UDP-Kommunikation wird in der Bibliothek UdpLib implementiert.
Als Schnittstelle zur restlichen Software hat sie drei Funktionsblöcke und
zwei Funktionen. Die Funktionsblöcke werden für zyklische Funktionen, zur Initialisierung
und zum Beenden der Bibliothek verwendet. Die Funktionen erlauben
den Zugriff auf die jeweiligen Ereignisvariablen der Prozessvariablen.
48

Jeder Funktionsblock besitzt Ein- und Ausgänge. Die Eingänge werden durch
die Applikationssoftware gesetzt. Anschließend ruft sie den Funktionsblock auf.
Über die Ausgänge wird die Applikationssoftware über den Status des Funktionsblocks
informiert. Das Konzept des Funktionsblocks entspricht in etwa dem
einer Klasse in der objektorientierten Programmierung. Die Anwendung erstellt
zur Laufzeit eine Instanz des Funktionsblocks, was der Instanziierung einer
Klasse entspricht.
Name Richtung Beschreibung
ConfigFile IN Pfad zur Konfigurationsdatei für Variablenanschlüsse
LocalIp IN IP-Adresse der Netzwerkschnittstelle zur Visualisierung
GroupIp IN Adresse der Multicastgruppe
GroupPort IN Port, an den die Multicastpakete gesendet werden
PvCount IN Maximale Anzahl an Prozessvariablen, die angeschlossen
werden können.
Handle OUT Ein Handle, der den weiteren FUBs 21 der Bibliothek
übergeben werden muss.
Tabelle 8: Funktionsblock UdpInit
Der FUB UdpInit initialisiert die Bibliothek. Er muss einmal während der
INIT-Phase des Tasks aufgerufen werden. Die Bibliothek führt während der Initialisierung
Speicheroperation aus, die im zyklischen Teil des Tasks zu Zykluszeitverletzungen
führen könnten. Er bekommt als Eingangsdaten den vollständigen
Pfad zur Konfigurationsdatei, die IP der mit der Visualisierung verbundenen
der Netzwerkschnittstelle, die Multicast-IP und den Multicast-Port für die
Kommunikation zur Visualisierung. Diese Einstellungen müssen sowohl in der
Visualisierung als auch in allen angeschlossenen Steuerungen identisch gesetzt
sein. Während der Initialisierung liest die Bibliothek die Konfigurationsdatei
und schließt die Prozessvariablen in der Steuerung an. Falls eine Variable aus
der Konfigurationsdatei innerhalb der Steuerungssoftware nicht gefunden wer-
21 Funktionsblock
49

den kann, wird im Systemlog eine Warnmeldung ausgegeben und die Bibliothek
überspringt die Variable. Ebenso verhält sie sich, wenn eine Zeile der Konfigurationsdatei
ein ungültiges Format aufweist. Nach erfolgreichem Anschließen
der Prozessvariablen und dem Öffnen des UDP-Sockets liefert der Funktionsblock
auf dem Ausgang handle einen Wert ungleich 0 zurück.
Name Richtung Beschreibung
Handle IN Handle von UdpInit
Tabelle 9: Funktionsblock UdpCyclic
Im zyklischen Teil des Tasks muss der Funktionsblock UdpCyclic aufgerufen
werden. Er nimmt nur den Handle des FUB UdpInit als Eingang entgegen,
liefert jedoch keine Statusinformationen zurück
Name Richtung Beschreibung
Handle IN Handle von UdpInit
Tabelle 10: Funktionsblock UdpExit
Damit die Bibliothek z.B. beim Neuladen des Tasks in der Steuerung neu
initialisiert werden kann, muss sie korrekt beendet werden. Dazu muss der Task
in seiner Exit-Funktion den Funktionsblock UdpExit aufrufen. Er nimmt ebenfalls
als Eingang nur den Handle des FUB UdpInit entgegen.
4.3.6 Implementierung der Kommunikation
Die Kommunikationsbibliothek beinhaltet eine Liste mit allen angeschlossenen
Prozessvariablen aus der Konfigurationsdatei. Die Liste enthält für jede Variable
die Kombination aus ID und SRC-Kennung, einen Zeiger auf die Prozessvariable
im Speicher der Steuerung, die Länge der Prozessvariablen in der Steuerung
sowie die Ereignisvariable. Um die Adressen der Prozessvariablen im Speicher
der Steuerung zu finden wird eine Funktion des Betriebssystems der Steuerung
genutzt. Sie erlaubt das Auflösen von Variablennamen in Speicheradressen.
Während der Initialisierung der Bibliothek öffnet sie einen UDP-Socket.
Dieser wird für das Senden und Empfangen von Multicast-Nachrichten konfigu-
50

iert. Anschließend erzeugt die Bibliothek die Variablenliste aus der Konfigurationsdatei.
Dabei wird im Speicher eine Struktur angelegt, die den vollständigen
Zustand der Bibliothek enthält. Durch diesen Aufbau ist es möglich, mit mehreren
Instanzen der Bibliothek eine Steuerung in mehreren Multicastnetzen zu
verwenden.
Die bekannte Socketschnittstelle bildet die Netzwerkbibliothek des Steuerungsbetriebssystems
auf Funktionsblöcke ab. Es existieren Funktionsblöcke
zum Versenden und Empfangen von UDP-Nachichten. Die Eingänge der FUBs
entsprechen im Allgemeinen den Parametern der send() und receive()-
Funktionen der POSIX-API [5]. Zur Vermeidung von Zykluszeitverletzungen
arbeiten die Funktionsblöcke asynchron zum aufrufenden Task. Aus diesem
Grund muss der Funktionsblock für mindestens zwei Taskzyklen aufgerufen
werden, bevor er einen Status (Erfolg oder Fehler) zurückliefert. Die Bibliothek
kann deswegen nur in jedem zweiten Taskzyklus ein Paket versenden. Es ist
möglich, mehrere dieser Funktionsblöcke parallel auf einem Socket zu verwenden,
was aber bei konsequenter Umsetzung zu einem höheren Implementierungsaufwand
führen würde. Aus diesem Grund verwendet die Bibliothek zu
Zeit einen Funktionsblock zum Versenden der Unicastnachrichten zu den Visualisierungsclients
und einen weiteren zum Versenden von zyklischen Multicastnachrichten.
Das Senden von zyklischen Daten beeinflusst auf diese Weise
nicht die direkte Kommunikation zu den Clients.
Die Bibliothek durchsucht in jedem Taskzyklus das Prozessvariablenverzeichnis
nach Variablen, bei denen die Ereignisvariable auf den Wert
mcastSEND gesetzt wurde. Findet sie eine Variable mit gesetztem Flag, erzeugt
sie ein UDP-Paket mit den Daten und übergibt es an den Funktionsblock
zum Versenden von zyklischen Prozessdaten. Anschließend setzt sie die Ereignisvariable
zurück. Dieser Sendevorgang dauert mindestens zwei
Taskzyklen, kann abhängig von der Netzwerkauslastung und der Auslastung
der Steuerung auch länger dauern.
Für die Kommunikation mit den Clients wird ein Funktionsblock zum Empfangen
von UDP-Paketen verwendet. Dieser schreibt empfangene Pakete in
einen von der Anwendung bereitgestellten Puffer und signalisiert den Empfang
eines Paketes über seine Statusausgänge. Die Bibliothek wertet die empfangenen
Daten dann anhand des Typenfeldes des Paketes aus und reagiert mit ei-
51

ner entsprechenden Aktion. Nachdem die Anfrage bearbeitet wurde, wird eine
Unicast-Antwort an den Client zurückgesendet. Die IP-Adresse des Clients wird
im IP-Header des Anfragepaketes mit übertragen und steht der Protokollimplementierung
so als Zieladresse für die Antwort zur Verfügung. Da dieser Teil der
Bibliothek bereits eine neue Clientanfrage entgegen nehmen kann während die
vorherige noch gesendet wird, kann unter optimalen Bedingungen in jedem
Taskzyklus eine Anfrage bearbeitet werden.
Abb. 30: Zyklischer Datendurchsatz vs. Zykluszeit
Durch die Einschränkung der Sendegeschwindigkeit muss der Task, der den
zyklischen Teil der Bibliothek aufruft, mit einer relativ kurzen Zykluszeit ausgeführt
werden. Dies stellt für den Moment kein Problem dar, da ein einzelner Aufruf
der Bibliothek im Durchschnitt 29µs dauert.
Abb. 31: CPU-Auslastung vs. Zykluszeit
52

Die Anwendung für den Teststand sendet relativ wenig zyklische Daten (~22
Prozessvariablen/Sekunde). Aus diesem Grund wurde hier die einfachere Lösung
gewählt. Für weitere Anwendungen sollte die Bibliothek aber auf bessere
Senderaten und auf Effizienz optimiert werden.
4.3.7 Visualisierungsrechner
Bei dem Rechner, der zur Darstellung der Visualisierung verwendet wird, handelt
es sich um einen Provit 5000 Industrie-PC der Firma B&R. Es sind ein Pentium
3 mit 600 MHz sowie 256 MB Arbeitsspeicher verbaut. Als Betriebssystem
wird Microsoft Windows XP Professional verwendet, zur Anzeige der Visualisierung
dient der Microsoft Internet Explorer 8.
Im Autostart des Betriebssystems befindet sich ein Skript, das einen Startbildschirm
anzeigt, den Internet Explorer im Kiosk-Modus startet und die Visualisierung
anzeigt. Durch den Kioskmodus zeigt der Browser die Visualisierung ohne
Fensterrahmen und ohne Startleiste im Vollbildmodus, wodurch bei dem Benutzer
der Eindruck einer integrierten Bedienoberfläche vermittelt wird.
53

5 Ausblick
Der Inhalt dieser Arbeit stellt lediglich die Grundlage für ein mögliches Visualisierungssystem
dar. Wenn das System auf den Betrieb mit mehreren Steuerungen
ausgeweitet werden soll, können einige Funktionen wie z.B. die Verwaltung
der Alarmmeldungen nicht mehr auf einer Steuerung implementiert werden.
Derartige steuerungsübergreifende Funktionen sollten daher auf einem
eigenen Kommunikationsknoten betrieben werden, der mit den anderen Steuerungen
über das UDP-Protokoll kommuniziert. Ein solcher Kommunikationsknoten
könnte beispielsweise eine dedizierte Steuerung sein. Für diesen Zweck
kann auch eine Anwendung auf dem Leitrechner verwendet werden, da sie weniger
harte Echtzeitanforderungen als die Steuerungssoftware erfüllen muss.
Die Software würde gegenüber dem restlichen System teilweise wie ein Client
und teilweise wie ein Server auftreten. Einerseits stellt die Anwendung den Visualisierungen
Informationen zur Verfügung, andererseits liest sie Daten von
den einzelnen Steuerungen und verarbeitet sie. Neben der Verarbeitung von
Daten könnte diese Anwendung auch weitere Funktionen wie das Aufzeichnen
von Betriebsdaten über längere Zeiträume übernehmen.
Für ein derartiges Programm würde sich eine Architektur aus einem Grundprogramm,
das die Kommunikation zum Rest des Systems herstellt und einer Reihe
von Plugins, die die eigentliche Funktionalität bereitstellen, bestehen. Über
die Konfiguration der einzelnen Plugins kann die Anwendung auf Kundenwünsche
abgestimmt werden, ohne Funktionen auszuliefern, die nicht vom Kunden
erworben wurden. Ein weiterer Vorteil dieser modularen Architektur ist die klare
Trennung der Funktionalitäten durch die Plugins.
Da gerade in der Druckindustrie oft Bilddaten in der Prozessvisualisierung angezeigt
werden müssen, ist hier ebenfalls noch Verbesserungspotential zu sehen.
Es besteht die Möglichkeit mit einem weiteren Java-Applet Videodaten aus
einem Echtzeit-Multicaststream anzuzeigen. Dieses Applet kann als Bedienelement
in die Visualisierung eingebettet werden. Hier zeigt sich der große Vorteil
den mehrere, unabhängige Multicastnetzwerke bieten. Eines kann für die
Prozessdaten genutzt werden und ein weiteres z.B. für Bildinformationen. Die
verschiedenen Multicastnetzwerke können parallel existieren ohne sich gegenseitig
zu beeinflussen.
54

6 Abbildungsverzeichnis
Abb. 1: Struktur der Prozessvisualisierung ..........................................................1
Abb. 2: Abbildung einer Flexodruckmaschine......................................................2
Abb. 3: Ebenenmodelle der Prozessführung .......................................................3
Abb. 4: Netzwerkarchitektur des aktuellen Leitsystems ......................................5
Abb. 5: Kommunikationsmodell im CAN-Bus.......................................................9
Abb. 6: Architektur der Visualisierung................................................................12
Abb. 7: Grundstruktur eines Bedienbildes .........................................................13
Abb. 8: Klassenbaum der Bedienelemente........................................................17
Abb. 9: Klassenstruktur eines Bedienbildes.......................................................19
Abb. 10: Sequenzdiagramm zur Bilderzeugung ................................................21
Abb. 11: Kommunikation via Java-Applet ..........................................................22
Abb. 12: Adressumsetzung von IPv4 nach Ethernet-Multicast..........................26
Abb. 13: UDP-Multicast Kommunikationsmodell ...............................................27
Abb. 14: CYCLIC Paket (Server => Multicast => Client) ...................................30
Abb. 15: WRITE Paket (Client => Multicast => Server).....................................30
Abb. 16: WRITE_ACK Paket (Server => Client)................................................30
Abb. 17: READ Paket (Client => Multicast => Server) ......................................30
Abb. 18: READ_ACK Paket (Server => Client)..................................................30
Abb. 19: Klassendiagramm des Java-Applets ...................................................32
Abb. 20: Sequenzdiagramm der Datenübertragung ..........................................33
Abb. 21: Kommunikation über Ereignisvariablen...............................................35
Abb. 22: Verarbeitung von Sollwerten und Aktionen .........................................35
Abb. 23: Datenspeicherung für Bedienseiten ....................................................36
Abb. 24: CAD-Rendering des Teststandes........................................................38
Abb. 25: Steuerungsarchitektur des Teststandes..............................................39
Abb. 26: Hauptbedienbild des Teststands .........................................................41
Abb. 27: Parameterbild für allgemeine Parameter.............................................42
Abb. 28: Parameterbild für die Antriebsregelung...............................................43
Abb. 29: Zustandsdiagramm „AchsTask“...........................................................46
Abb. 30: Zyklischer Datendurchsatz vs. Zykluszeit ...........................................52
Abb. 31: CPU-Auslastung vs. Zykluszeit ...........................................................52
55

7 Tabellenverzeichnis
Tabelle 1: Tags in der Bilddefinitionsdatei .........................................................16
Tabelle 2: UDP-Pakettypen................................................................................29
Tabelle 3: Datentypen für die Kommunikation zur Visualisierung .....................31
Tabelle 4: Verzeichnisstruktur der Visualisierung..............................................37
Tabelle 5: Taster zur Bedienung des Teststands ..............................................40
Tabelle 6: Steuerungstasks................................................................................44
Tabelle 7: Bibliotheken.......................................................................................45
Tabelle 8: Funktionsblock UdpInit......................................................................49
Tabelle 9: Funktionsblock UdpCyclic .................................................................50
Tabelle 10: Funktionsblock UdpExit...................................................................50
56

8 Quellenverzeichnis
1. Heidepriem (2000): Prozessinformatik I: Grundzüge der Informatik, München,
1. Auflage, Seite 72ff.
2. Schnell, Wiedemann (2006): Bussysteme in der Automatisierungs- und
Prozesstechnik, 6. Auflage, Seite 120-121
3. Langmann (2004): Taschenbuch der Automatisierung, Leipzig, Seite 431ff.
4. Panda, Stunkel (1997): Communication and architectural support for network-based
parallel computing, San Antonio, Texas, USA, Seite
73ff
5. The Open Group, The IEEE (2008): The Open Group Base Specifications
Issue 7
6. http://de.selfhtml.org/javascript/objekte/node.htm
(Stand: 16. August 2010)
7. http://molily.de/js/sicherheit.html#same-origin-policy
(Stand: 22. August 2010)
8. Flanagan (2007): Javascript: Das umfassende Referenzwerk
Köln, 3. Auflage, Seite 155ff.
9. Oaks (2001): Java security
Sebastopol, California, USA, 2. Auflage, Seite 10ff.
10. Deering (1989): RFC1112: Host Extensions for IP Multicasting
57