ba yusufi cd - haw-hamburg.de · kamran yusufi entwicklung eines supervisory, control and data...
Post on 09-Oct-2019
3 Views
Preview:
TRANSCRIPT
Fakultät Technik und Informatik Faculty of Engineering and Computer Science Studiendepartment Informatik Department of Computer Science
Bachelorarbeit
Kamran Yusufi
Entwicklung eines Supervisory, Control And Data Aquisition Systems (SCADA) für Fahrerlose Auto-
nome Transportsysteme unter Verwendung von Standard-Software, Funktechnologien und TCP/IP-
Netzwerken
Kamran Yusufi
Entwicklung eines Supervisory, Control And Data Ac-quisition Systems (SCADA) für fahrerlose autonome Transportsysteme unter Verwendung von Standard-
Software, Funktechnologien und TCP/IP Netzwerken
Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung im Studiengang Technische Informatik am Studiendepartment Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuender Prüfer: Prof. Dr. rer. nat. Reinhard Baran Zweitgutachter: Prof. Dr. rer. nat. Stefan Pareigis Abgegeben am 11. Dezember 2006
Kamran Yusufi Thema der Bachelorarbeit
Entwicklung eines Supervisory, Control And Data Acquisition Systems (SCADA) für Fahrerlose Autonome Transportsysteme unter Verwendung von Standard-Software, Funktechnologien und TCP/IP Netzwerken
Stichworte
SCADA, Fahrerlose Autonome Transportsysteme, CAN, WLAN, Bluetooth, Lab-VIEW, WinCC, Aksenboard, TCP/IP, Telemetrie
Kurzzusammenfassung
In der vorliegenden Bachelorarbeit wurde ein Steuerungssystem für die drahtlose Steuerung, Überwachung und Prozessdatenerfassung eines fahrerlosen autonomen Systems entwickelt. Das entwickelte Steuerungssystem ist in der Lage die Steuerin-formationen vom Fahrzeug-Leitstand über CAN/WLAN-Modul an das Fahrzeug zu senden und die aktuelle Fahrzeugdaten wie Geschwindigkeit oder Richtungswinkel zu empfangen und diese zurück an den Leitstand zu übertragen. Die gesendeten bzw. empfangenen Steuerinformationen und die Sensormesswerte werden in einer Daten-bank abgespeichert. Der Leitstand für das Steuerungssystem wurde unter der Verwen-dung der grafischen Programmiersprache LabVIEW implementiert. Für eine Imple-mentation der WLAN-Kommunikation zwischen dem CAN/WLAN-Modul und dem Leitstand wurde Programmiersprache Java eingesetzt. Die Fahrzeugsteuerung und das CAN-Bus-Interface sind mit AKSENBOARD der FH-Brandenburg realisiert und un-ter Verwendung der Programmiersprache C implementiert.
Kamran Yusufi Title of the paper
Development of a Supervisory, Control And Data Acquisition Systems (SCADA) for a driverless autonomous transport System under the usage of a standard software, ra-dio technologies and TCP/IP Networks functionality
Keywords
SCADA, Driverless autonomous transport systems, CAN, WLAN, Bluethooth, Lab-VIEW, WinCC, Aksenboard, TCP/IP, Telemetrie
Abstract
This paper presents the development of a Supervisory, Control And Data Acquisition Systems of a driverless autonomous transport vehicle via WLAN and CAN-Bus, which is able to send the controlled information to the vehicle and receive the actual speed, the directions angel of the vehicle and the sensor values of the installed sensors. All these information will save in a Database. The graphical programming language LabVIEW is applied for the control area of this System. Sending and receiving of the controlled information, control of vehicle and CAN-Bus-Interface is implemented in Java and C programming languages, as calculation system for the vehicle, the micro-controller Aksenboard is applied, which is developed at the FH-Brandenburg.
IV
Danksagung
Ohne die Unterstützung einiger Personen hätte ich diese Bachelorarbeit in dieser Art nicht
bewerkstelligen können. Somit nutze ich die Möglichkeit denjenigen, die mich fachlich und
vor allem moralisch tatkräftig unterstützt haben, einen Dank auszusprechen:
Vielen Dank für die kontinuierliche Unterstützung durch die Professoren und Mitarbeiter der
HAW Hamburg, insbesondere ist gemeint:
Professor Reinhard Baran, für die Anregung, Kritik und Ermunterung.
Professor Stefan Pareigis für die Übernahme des Zweitgutachtens.
Die Mitarbeiter aus dem CPT-Labor für die fachliche und materielle Unterstützung.
Der herzlichste Gruß und Dank sei an meine unglaublich tolle Familie gerichtet, besonders an
meine Eltern, die sich immer um mein leibliches Wohlsein gekümmert haben und meinen
großen Bruder Patan, der sich für alle meine Probleme eingesetzt hat.
Ein riesengroßer Dank geht an Wolfgang und Lilo Schnelle, ohne euch wäre das Ganze über-
haupt nicht möglich gewesen. Danke für die moralische und finanzielle Unterstützung.
Besonderer Dank sei an Hella Neddermeyer gerichtet für die unzähligen Deutschunterrichts-
stunden. Ohne Beherrschung der deutschen Sprache währe so ein Studium nicht denkbar.
Ich danke einige meiner Kommilitonen und Freunden, deren Namen hier nicht auftauchen, die
aber mich während meiner Abschlussarbeit unterstützt haben. Danke Jungs, das war für mich
ein sehr spaßiges Studium.
Weiterhin gilt mein Dank Herrn Eric Robert und Maxim Van de Moortele für deren Zusam-
menarbeit zur Realisierung der Datenbankanbindung
Zum Schluss danke ich dem deutschen Volk und dem Steuerzahler für das Ermöglichen dieser
Ausbildung. Das ist ja nicht überall selbstverständlich.
V
Inhaltsverzeichnis
Danksagung....................................................................................................................... IV
Inhaltsverzeichnis............................................................................................ V
Tabellenverzeichnis...................................................................................... VII
Bilderverzeichnis .........................................................................................VIII
1 Einleitung.................................................................................................... 9
1.1 Motivation ................................................................................................................ 9
1.1.1 Autonome Fahrzeuge.......................................................................................... 9
1.1.2 Telemetrie ........................................................................................................ 10
1.1.3 Fernwartung ( Fahrzeuge, die selbstständig die Werkstatt rufen )...................... 11
1.1.4 WLAN ............................................................................................................. 12
1.2 Anforderung an das System..................................................................................... 13
1.3 Zielsetzung ............................................................................................................. 14
2 Theoretische Grundlagen......................................................................... 15
2.1 Fahrerlose Autonome Transportsysteme.................................................................. 15
2.2 CAN-Bus ................................................................................................................ 15
2.2.1 Übertragungsverfahren ..................................................................................... 16
2.2.2 Übertragungsrate und Leitungslänge................................................................. 17
2.2.3 CAN-Bus Topologie......................................................................................... 18
2.2.4 Objektidentifier ................................................................................................ 19
2.2.5 Arbitrierung (Aushandeln des Medienzugriffs), Priorität................................... 20
2.2.6 Frame-Aufbau .................................................................................................. 21
2.2.7 Sampling, Synchronisierung, Sicherung............................................................ 22
2.2.8 Gründe für den Einsatz des CAN-Busses .......................................................... 23
2.3 Kabellose Datenübertragung ................................................................................... 24
2.3.1 TCP/IP Netze.................................................................................................... 24
2.3.2 WLAN IEEE802.11x....................................................................................... 29
2.3.3 Bluetooth.......................................................................................................... 36
VI
3 Realisierung.............................................................................................. 39
3.1 Gesamtkonzept........................................................................................................ 39
3.2 Auswahl der optimalen Funktechnologie................................................................. 40
3.2.1 Grobe Selektion................................................................................................ 42
3.2.2 WLAN und Bluetooth im Vergleich .................................................................42
3.3 Benötigte Hardware für die Realisierung des Systems............................................. 46
3.3.1 Standard PC...................................................................................................... 46
3.3.2 WLAN-Interface............................................................................................... 46
3.3.3 PC-Lenkrad ...................................................................................................... 48
3.3.4 CAN/WLAN-Modul (IGW400/CAN)............................................................... 48
3.3.5 Aksenboard ...................................................................................................... 53
3.3.6 Fahrzeug........................................................................................................... 55
3.3.7 Infrarot-Distanzsensoren................................................................................... 56
3.4 Benötigte Standard-Software und Werkzeuge .........................................................57
3.4.1 LabVIEW ......................................................................................................... 57
3.4.2 WinCC ............................................................................................................. 63
3.4.3 LabVIEW vs. WinCC....................................................................................... 68
3.5 Realisierung und Implementation des Systems ........................................................ 68
3.5.1 Leitstand und seine Aufgaben........................................................................... 69
3.5.2 Die Funktionen des Leitstandes sind wie folgt aufgeteilt:.................................. 70
3.5.3 Prinzipieller Aufbau der Leitstand-Software .....................................................70
3.5.4 Schnittstellenspezifikation für das SCADA System .......................................... 73
3.5.5 Funktionsweise des CAN/WLAN-Moduls ........................................................ 75
3.5.6 CAN-Schnittstelle und Steuerung des Fahrzeuges............................................. 75
3.5.7 Implementation und Werkzeuge ....................................................................... 77
3.5.8 Access-Datenbank ............................................................................................ 81
4 Zusammenfassung.................................................................................... 82
4.1 Resümee ................................................................................................................. 82
4.2 Aussichten und Weiterführung ................................................................................ 83
Literaturverzeichnis....................................................................................... 84
Anhang............................................................................................................ 88
VII
Tabellenverzeichnis
Tabelle 2.1: Portstruktur [AnTan] ........................................................................................ 26 Tabelle 2.2: TCP/IP Kommunikation zwischen Client und Server........................................ 29 Tabelle 2.3: OSI-Schichten-Modell. [AnTan]....................................................................... 33 Tabelle 2.4: Übersicht WLAN nach IEEE 802.11 ................................................................ 35 Tabelle 3.1 Energieverbrauch bei WLAN und Bluetooth...................................................... 43 Tabelle 3.2 Latenzzeiten bei Bluetooth und WLAN ............................................................. 44 Tabelle 3.3 IEEE 802.11 vs. Bluetooth................................................................................. 45 Tabelle 3.4 Übersicht der ISM-Frequenzbereiche [Wal-Emb] ..............................................51 Tabelle 3.5 Aufbau des WLAN-Datenpaketes...................................................................... 73
VIII
Bilderverzeichnis
Bild 2.1: CAN-Bus Topologie.............................................................................................. 19 Bild 2.2 Datenübertragung mit OSI Schichten-Modell ......................................................... 25 Bild 2.3: IEEE 802.11-WLAN im Infrastruktur Mode [SSV1] ............................................. 32 Bild 3.1 Schematisches Konzept der Kommunikationsteilnehmer ........................................ 39 Bild 3.2 Funktechnik-Aktuelle Standards im Vergleich........................................................ 40 Bild 3.3 WLAN USB-Dongle .............................................................................................. 46 Bild 3.4 IP-Adressen-Konfiguration für ein PC-WLAN-Interface ........................................ 47 Bild 3.5 PC-Lenkrad, Gas-/Bremspedale.............................................................................. 48 Bild 3.6 CAN/WLAN-Modu [SSV1] ................................................................................... 48 Bild 3.7 Blockdiagramm des CAN-WLAN-Moduls [SSV1]................................................. 49 Bild 3.8 Übertragungsprotokoll für WLAN Funkverbindung [SSV1] ................................... 52 Bild 3.9 DasAksenboard ...................................................................................................... 53 Bild 3.10 Das Fahrzeug........................................................................................................ 55 Bild 3.11 Infrarot-Distanzsensor GP2D12 45 ...................................................................... 56 Bild 3.12: Blockdiagramm des LabVIEW Entwicklungssystems.......................................... 58 Bild 3.13: Frontpanel des LabVIEW Entwicklungssystems.................................................. 59 Bild 3.14 WinCC Grafikprogramm ...................................................................................... 64 Bild 3.15 Schematische Darstellung der Kommunikationsteilnehmer................................... 68 Bild 3.16 Leitstand des SCADA Steuerungssystem.............................................................. 69 Bild 3.17 Flussdiagramm der Leitstandschleifen zu Steuerung des Fahrzeuges..................... 71 Bild 3.18 Screenshot von der LabVIEW-Entwicklungsumgebung........................................ 78 Bild 3.19 Screenshot von der Eclipse-Entwicklungsumgebung.............................................79 Bild 3.20 Screenshot vom ConText-Editor ........................................................................... 80 Bild 3.21 Auszug aus der Datenbank.................................................................................... 81
9
1 Einleitung
1.1 Motivation
1.1.1 Autonome Fahrzeuge
Autonome Fahrzeuge, fahrerlose Transportsysteme, auch mobile Roboter genannt, stellen in
zunehmendem Umfang wichtige innerbetriebliche Kapazitäten für die Anlieferung und Wei-
terreichung von Rohmaterialien, Zwischen- oder auch Endprodukten zur Verfügung. Die
Fahrzeuge müssen in der Lage sein, bestimmte Betriebsstätten oder Positionen selbständig
anzusteuern, ohne an stationäre Hindernisse (Wände, Maschinen) oder bewegliche Objekte
(Menschen, andere Fahrzeuge) anzustoßen. Dazu bedarf es eines steuerbaren Fahrzeugs, das
die vorgegebenen Wege zurücklegen kann, einer angemessenen Sensorik, die in der Lage ist,
Hindernisse zu erkennen und ausreichend "Intelligenz", um den Hindernissen auszuweichen.
Autonome Fahrzeuge sind intelligente Fahrzeuge, die die ihnen übertragen Aufgaben ohne
menschliche Unterstützung durchführen können.
Die Anwendung solcher autonomer Systeme ist weit reichend. Nicht nur wegen der Kostenre-
duzierung und der Erhöhung der Effektivität, ist der Einsatz autonomer Fahrzeuge in der In-
dustrie wichtig, sondern ein weiterer wichtiger Aspekt für die Entwicklung und die Anwen-
dung autonomer Fahrzeug ist das Operieren solcher Fahrzeuge in Umgebungen die für Men-
schen gefährlich sind. Im militärischen aber auch im zivilen Bereich arbeitet die Forschung
daran solche autonomen Systeme zu entwickeln, die als Erkundungs- oder Bergungsgeräte in
schwer zugänglichen Bereichen eingesetzt werden können. Beispiel dafür sind: Minenräu-
mung oder Arbeiten in giftiger oder verstrahlter Umgebungen. In der Luft- und Raumfahrt-
technik werden autonome Systeme für den Einsatz auf fremden Planeten oder als Hilfsmittel
für Satelliten und Raumstationen entwickelt. Autonome Systeme stehen auch für eine Erhö-
hung der Effektivität und somit für Kostenreduzierung. Deswegen wird auch im industriellen
Bereich die Entwicklung der autonomen Systeme immer mehr vorangetrieben. Zur Wahr-
nehmung der Umwelt werden bei den autonomen Fahrzeugen Sensoren eingesetzt. Dadurch
wird sicheres Navigieren ermöglicht, und gleichzeitig ist durch Aktoren auch eine Manipula-
tion von Objekten möglich.
10
1.1.2 Telemetrie
Die Telemetrie wird seit 1920 für die Nachrichtenübermittlung aus Wetterballonen verwen-
det. Sie erlebte einen großen Aufschwung mit der Entwicklung der Großraketen in den 40er
Jahren. Unter den Begriff Telemetrie (= Fernmessung) versteht man die Übertragung von
Messwerten eines am Messort befindlichen Messfühlers (Sensor) zu einer räumlich getrenn-
ten Stelle. An dieser Empfangsstelle können die Messwerte entweder gesammelt und aufge-
zeichnet, oder auch sofort ausgewertet werden.
Telemetrie wird häufig durch einen Wirkungspfad zum erfassenden Sensor ergänzt, um so auf
gelieferte Messwerte mit geeigneten Maßnahmen reagieren zu können. Dieser Rück-Pfad
wird als Fernsteuerung (Telekommandierung, eng. Tele-Command) bezeichnet.
Eine Telemetrie, bei der Messdaten über größere Entfernungen übertragen werden, wird als
Fernfeldtelemetrie bezeichnet. Dies ist beispielsweise beim Sammeln von Wetterdaten, tech-
nischen Daten aus einem bewegten Fahrzeug (Flugzeug, Raumfahrzeug, Rennwagen), bei der
Übermittlung von dezentraler Verkehrsinformation oder auch bei der Übermittlung medizini-
scher Daten eingesetzter Sonden an die Außenwelt gegeben.
Als Nahfeldtelemetrie bezeichnet man Anwendungen, bei denen Daten über kurze Distanzen
von bewegten Maschinenteilen auf ruhende Empfänger übermittelt werden. So werden bei-
spielsweise Zustandsdaten von Gasturbinenrotoren oder Reifendrücke von drehenden Kfz-
Rädern übermittelt. Häufig werden die Daten an räumlich weit getrennten Messorten aufge-
nommen und per Telemetrie an eine zentrale Stelle gesendet, um dort aufgezeichnet und/oder
ausgewertet zu werden. In der Regel müssen die anfallenden Messwerte zunächst in eine ge-
eignete Form gebracht werden, damit sie telemetriert werden können.
Besondere Aufmerksamkeit erfordert die Übertragung von Gleichspannungssignalen, wie sie
z. B. bei resistiven oder kapazitiven Sensoren anfallen (z.B. Spannungsänderung an einem mit
konstantem Strom durchflossenen, temperaturabhängigen Widerstand).
Durch geeignete Maßnahmen ist eine solche Messpannung in eine Wechselspannung oder in
eine Pulsfolge umzusetzen, damit Versorgungsspannungsänderungen und Temperaturdriften
der Übertragungsbausteine keine Messwertänderung vortäuschen. Dafür geeignet ist bei-
spielsweise eine Pulsfolge, deren Pulsfrequenz oder Pulsdauer vom Widerstands- oder Kapa-
zitätswert des Fühlers abhängt.
11
Die Übertragungsfrequenz des Telemetriesenders kann mit einer solchen Pulsfolge oder auch
mit einem vom Sensor unmittelbar gelieferten Wechselstromsignal moduliert werden.
Im Empfänger wird dieses Signal durch eine geeignete Demodulation zurückgewonnen und
daraus der zugehörige Messwert abgeleitet. Ein bei analogen Messsignalen angewendetes
Verfahren ist beispielsweise ein Pulsformer mit nachgeschaltetem Tiefpassfilter. Heute sind
praktisch nur noch digitale Telemetriesysteme gebräuchlich. Der erfasste Messwert wird vor
Ort mit Hilfe eines Analog-Digital-Wandlers (ADC = A/D-Converter) in eine binäre Zeichen-
folge umgesetzt, die anschließend mit geeignet moduliertem Träger telemetriert und emp-
fangsseitig ohne Informationsverluste rekonstruiert werden kann. Hier findet ein Datenver-
kehr zwischen zwei Stationen statt, bei der die steuernde Messwerte empfangen (downlink)
und die sensortragende die aus den Messwerten abgeleiteten Kommandos befolgen kann
(uplink). Der Sensorträger vor Ort ist dabei mit Aktoren ausgestattet, die von einem Bediener
aus der Ferne aufgrund der gelieferten Sensorinformationen gesteuert werden können. Bei-
spiele hierfür sind Spezialroboter oder mit Kamera und Telemetrie versehene Flugobjekte.
1.1.3 Fernwartung ( Fahrzeuge, die selbstständig die Werkstatt rufen )
Aktuelle Forschungen zeigen, dass in Zukunft nicht nur Industrieanlagen, sondern auch Pkw,
Lkw und Schienenfahrzeuge aus der Ferne gewartet werden können. [Siemens]
Noch gibt es das nicht serienmäßig, aber in nicht allzu ferner Zukunft gehört die Ferndiagno-
se und -Wartung bei Straßen- und Schienenfahrzeugen zum Alltag, davon sind die Forscher
bei Siemens überzeugt. Folgendes Szenario soll eine Telemetrieanwendung darstellen:
Peter Schulz ist gerade unterwegs im Raum Hamburg, als sein Autotelefon klingelt. Der Pro-
duktmanager einer Medizintechnik-Firma nimmt über seine Freisprechanlage das Gespräch
an. Am anderen Ende der Leitung ist ein Mitarbeiter seiner Kfz-Werkstatt. "Ihr Auto hat uns
gemeldet, dass in Kürze die Bremsbeläge an Ihrem Fahrzeug getauscht werden müssen. Au-
ßerdem ist das Motoröl an der Verschleißgrenze, das müsste auch gewechselt werden. Um
Folgeschäden zu vermeiden, sollten Sie beides spätestens nach tausend Kilometern beheben
lassen.", "Ich komme aber erst in fünf Tagen nach Hamburg zurück", entgegnet Schulz. "Kein
Problem", sagt der Kfz-Meister. Er schlägt vor, einen Fachbetrieb in Hannover zu suchen und
den Wagen dort anzumelden. Kurze Zeit später teilt ihm der Automechaniker die Adresse
12
einer Werkstatt in Hannover und einen passenden Termin mit. Peter Schulz fährt beruhigt
weiter.
Die Gründe, eine Fernwartung zu realisieren, sind: Die fortschreitende Globalisierung im Ver-
kehrsmarkt und der dadurch verstärkte Wettbewerb zwingen Transportgewerbe und Herstel-
ler, die Kostensenkung anzustreben. Außerdem müssen sich die Fahrzeug-Hersteller von ih-
ren Mitbewerbern differenzieren. Mit der Ferndiagnose können sie einen verbesserten Service
anbieten und gleichzeitig die Kundenbindung intensivieren. Denn dadurch fallen für den
Fahrer die lästigen Serviceintervalle weg. Der Kunde muss nur dann zur Werkstatt, wenn
wirklich eine Wartung nötig ist. Somit spart auch er Zeit und Geld.
1.1.4 WLAN
Einsatzszenarien für Funknetze gibt es seit über zehn Jahren, bislang vorwiegend für vertikale
Märkte wie Flughäfen, Bahnhöfe, Einkaufszentren, Krankenhäuser, aber auch für Autover-
mietungen oder Restaurants (so genannte Hot Spots).
In vielen anderen industriellen und technischen Bereichen gibt es die Möglichkeiten, solche
Funknetze anzubieten, in denen man wie zum Beispiel von einem beweglichen Objekt, kabel-
los und dynamisch die Sensor-Messwerte an einen Arbeitsplatz senden, sie dort be- und wei-
ter verarbeiten können. Diese Möglichkeiten sind noch nicht annähernd ausgeschöpft.
Überall da, wo mehrere Daten von verschiedenen Komponenten mobil erfasst werden müssen
oder ein sofortiger Zugriff auf hochaktuelle Daten erforderlich ist, erleichtern WLANs
(WLAN eng. Wireless Local Area Network) das Leben und senken Kosten. Die Anwender
merken meist überhaupt nicht, dass sie in einem Funknetz arbeiten.
Die sonst so fehlerträchtige Konfiguration des Netzwerks entfällt, wenn es einmal eingerichtet
ist. Die Mobilität durch WLANs sorgt in Firmen und allen anderen Bereichen jederzeit für
schnellen Zugriff auf aktuelle Informationen, egal wo sich der fahrende Mess-Wagen oder
ein Mitarbeiter gerade befindet - irgendwo auf dem Betriebsgelände, in einem Komplex oder
im eigenen Büro. Das steigert die Produktivität und führt zu kürzeren Reaktionszeiten.
13
Im Rahmen dieser Bachelorarbeit soll diese Technik insbesondere angewendet werden, um
die Mess-Sensoren mobiler zu machen bzw. die Steuerdaten und die Telemetriewerte von
einem mobilen Fahrzeug zu bekommen, und dabei gleichzeitig den Netzkontakt zu halten.
Zudem gewinnt Internet Remote Control immer mehr an Bedeutung - auch hier kann diese
Technik flexiblere Lösungen ermöglichen. In sofern ist eine WLAN-Technologie für Tele-
metrie Anwendungen sehr relevant
Eine WLAN Netzanbindung kann hier eine ideale Abhilfe schaffen. Zur Unterstützung sol-
cher Projekte kann die Anwendung eines WLAN-Netzes wertvolle Hilfe leisten, um größere
Datenmengen problemlos transformieren zu können. Außerdem kann damit der Nutzen eines
solchen Netzes für großflächigere Anwendungen untersucht werden.
1.2 Anforderung an das System
Die grundsätzliche Anforderung an das System ist, dass ein Autonomes Fahrerloses Fahrzeug
kabellos von einem stationären Rechner (Leitstand), manuell bzw. autonom gesteuert wird.
Des Weiteren soll es ein Steuerungssystem entwickelt werden, das einerseits eine Art Tele-
metrie und Fernwartung darstellt sowie andererseits Überwachung, Steuerung, und Prozessda-
tenerfassung realisiert.
Detailliertes Szenario einer Steuerung:
Die vom PC-Lenkrad und Pedalen gelesenen Steuerdaten sollen auf dem Leitstand visuali-
siert, und vom Leitstand aus durch eine Funktechnologie an das Fahrzeug zur Steuerung des
Fahrzeuges gesendet werden. Das Fahrzeug soll dann mit den empfangenen Daten gesteuert
werden und seine aktuellen Steuerdaten bzw. Sensorwerte zurück an den Leitsand senden.
Dies soll ebenfalls über Funktechnologien realisiert werden. Weiterhin sollten die Prozessda-
ten beim Leitstand empfangen, analysiert, visualisiert und zum Schluss in eine Datenbank
abgespeichert werden.
Für dieses Steuerungssystem soll zunächst ein Konzept, basierend auf die vorhandenen Tech-
nologien, entwickelt werden. Das Konzept soll anschließend implementiert und experimentell
getestet werden.
14
1.3 Zielsetzung
In Anbetracht der Anforderung an das System und mit Rückblick auf die Motivation ergeben
sich für diese Bachelorarbeit folgende Ziele:
1. Entwicklung eines SCADA (eng.: Supervisory Control And Data Acquisition) Steurungs-
systems zur drahtlosen Steuerung des fahrerlosen Transportsystem
2. Integration des vorhandenen CAN-WLAN-Moduls (eng. Controller Area Network)in das
entwickelten SCADA Steuerungssystem.
3. Die Kommunikation innerhalb und außerhalb des Systems soll hauptsächlich kabellos über
TCP/IP Netze funktionieren, was wiederum den Einsatz einer leistungseffizienten Technolo-
gie voraussetzt.
4. Die zu Steuerung des Fahrzeuges gesendete und vom Fahrzeug empfangenen Daten sollen
durch eine Standard-Software visualisiert und für Weiterbarbeitung in eine Datenbank abge-
speichert werden. Die Prozesse sollen dann automatisiert werden
5. Zusätzliches Ziel dieser Arbeit ist noch die Telemetrie-Anwendung eines fahrerlosen auto-
nomen Systems zu entwickeln.
15
2 Theoretische Grundlagen
2.1 Fahrerlose Autonome Transportsysteme
Autonome Fahrzeuge stellen hochkomplexe, dynamische Systeme dar, für deren Verwirkli-
chung die Forschungsergebnisse vieler Wissenschaftszweige zusammengeführt werden müs-
sen. So sind für die Fahrzeugführung - insbesondere bei hohen Geschwindigkeiten - die Me-
thoden der Regelungstechnik und Systemdynamik unverzichtbar. Zur Messung des Fahrzeug-
zustands und für die Wahrnehmung von Objekten in der Umgebung müssen die Signale un-
terschiedlichster Sensoren verarbeitet und fusioniert werden. GPS-Sensoren (Global Positio-
ning System), Radar und Echtzeitbildverarbeitung sind nur einige mögliche Informationsquel-
len für ein autonomes Fahrzeug. Mit zunehmender Anzahl von Fähigkeiten des autonomen
Fahrzeugs erhöht sich auch die Notwendigkeit einer flexiblen, effizienten Situationsanalyse
und Verhaltensentscheidung. Hier benötigt man geeignete Methoden zur Wissensrepräsentati-
on, Verhaltensmodellierung und künstlichen Intelligenz.
2.2 CAN-Bus1
Der CAN-Bus, auch CAN Controller Area Network genannt, wurde 1991 von der Firma
Bosch für den Einsatz in Kraftfahrzeugen entwickelt. Das Protokoll ist in der ISO 11898 in-
ternational standardisiert. Viele Halbleiterhersteller unterstützen den Bus in Interface-
Bausteinen, Automatisierungstechnik und Mikrocontrollern. Der CAN-Bus stellt eine kosten-
günstige Alternative zum Kabelbaum zur Verfügung und somit ist der CAN eine preiswerte
Schnittstelle. Das primäre Ziel des CAN-Busses ist die Kommunikation zwischen den Teil-
nehmern, die an diesen Bus angeschlossen sind.
Es gibt mehrere Bussysteme, die auf dem CAN-Bus basieren, die Protokolle aber erweitert
oder vereinfacht haben: CANopen / CANopen-Safety, DeviceNet / DeviceNet Safety, ESA-
LAN, SafetyBUS.
1 Quellen: [CoArNe], [CANCoAr], [Bosch], [CAN-CIA]
16
Der CAN-Bus ist ein serieller Datenbus mit einer Übertragungsrate von bis zu 1.000.000
Bit/s, das entspricht ca. 30 DIN-A4-Seiten. Es handelt sich um eine konsequente Vernetzung
der Fahrzeugelektronik in so genannten CAN-Bus-Systemen. Hier werden die Impulse nicht
mehr über einzelne Kabelstränge, sondern über eine gemeinsame "Datenautobahn" übertra-
gen. Bei der Kommunikation auf dem Bus werden alle Nachrichten gleichzeitig mit entge-
gengesetztem Signal zur Masse über zwei Leitungen gesendet (CAN-Low und CAN-High
Leitung). Dadurch können Störspannungen, die eines der beiden Signale abschwächen oder
verstärken dabei gleichzeitig das andere beeinflussen. So sind Fehlerinformationen nahe aus-
geschlossen.
Typische CAN-Bus Teilnehmer sind:
• Automatisierungsgeräte wie z.B. SPS (Speicherbare Programmier Steuerung)
• Personal Computer
• Ein/Ausgabemodule
• Antriebssteuerung
• Analysegeräte wie z. B. CAN-Monitor
• Bedien und Eingabegeräte als Mensch-Maschinen Interface(HMI, Human Machine Inter-
face)
• Sensoren und Aktoren
2.2.1 Übertragungsverfahren
Der CAN-Bus arbeitet nach dem CSMA/CA (Carrier Sense Multiple Access / Collision A-
voidance) Verfahren (nicht zu verwechseln mit CSMA/CD wie beim Ethernet). Dabei werden
Kollisionen beim Buszugriff durch die Arbitrierung oder Bit-Arbitrierung vermieden (siehe
2.2.5 Arbitrierung). Des Weiteren kommt zur Datensicherung ein CRC-Verfahren zum Ein-
satz. Zur fortlaufenden Synchronisierung der Busteilnehmer wird Bitstopfen (bit stuffing)
verwendet (siehe 2.2.6 Fram Aufbau). Der Bus ist entweder mit Kupferleitungen oder über
Glasfaser ausgeführt. Zur schnellen Datenübertragung zwischen den Steuergeräten wird in der
17
Kfz-Technik das CAN-Bussystem verwendet. Der CAN-Bus arbeitet nach dem "Multi-Master
Prinzip": Mehrere gleichberechtigte Steuergeräte (=Busteilnehmer) sind durch eine topologi-
sche Anordnung (siehe 2.2.3 CAN-Bus topologie) miteinander verbunden.
Im Falle von Kupferleitungen arbeitet der CAN-Bus mit Differenzsignalen. Er wird norma-
lerweise mit 3 Leitungen ausgeführt: CAN_HIGH, CAN_LOW und CAN_GND (Masse).
CAN_LOW enthält den komplementären Pegel von CAN_HIGH gegen Masse. Dadurch kön-
nen Gleichtaktstörungen unterdrückt werden, da ja die Differenz gleich bleibt.
Die Übertragung der Daten erfolgt so, dass ein Bit, je nach dem Zustand, entweder dominant
oder rezessiv auf den Busleitungen wirkt. Ein dominantes überschreibt dabei ein rezessives
Bit.
2.2.2 Übertragungsrate und Leitungslänge
Es wird zwischen einem Highspeed- und einem Lowspeed-Bus unterschieden. Bei einem
Highspeed-Bus beträgt die maximale Datenübertragungsrate 1Mbit/s, bei Lowspeed
125kBit/s. Die maximale (theoretische) Leitungslänge beträgt z.B. bei 1Mbit/s 40m, bei
500kBit/s sind 100m möglich und bei 125kBit/s 500m. Diese Maximalwerte beruhen darauf,
dass die Zeit, die ein Signal am Bus anliegt (Bitzeit, Bit/Sekunde), umso kürzer ist, je höher
die Übertragungsrate ist. Mit zunehmender Leitungslänge steigt jedoch die Zeit, die ein Signal
braucht, bis es am anderen Ende des Busses angekommen ist (Ausbreitungsgeschwindigkeit).
Daher darf die Zeit, die ein Signal am Bus liegt, nicht kürzer sein als die Zeit, die ein Signal
braucht, um sich auszubreiten. Zu beachten ist, dass sich das Signal nicht nur ausbreitet, son-
dern auch innerhalb der Signalzeit der Empfänger auf den Sender reagieren muss .Der Sender
muss wiederum die eventuelle Buspegeländerung des/der Empfänger mitbekommen (siehe
auch Arbitrierung). Deshalb ist die max. Leitungslänge etwas komplexer zu berechnen. Es
müssen Verzögerungszeiten auf der Leitung, des Tranceiver (Sender und Empfänger), des
Controllers (Sender und Empfänger) und der gesetzte Abtastzeitpunkt (Sender und Empfän-
ger) berücksichtigt werden.
Als Busmedium werden nach ISO11898-2 (High-Speed Medium Access Unit) Twisted-Pair-
Kabel mit einem Wellenwiderstand von 108...132 Ohm empfohlen.
18
Die maximale Teilnehmeranzahl auf physikalischer Ebene hängt von den verwendeten Bus-
treiberbausteinen (Transceiver, physikalische Anschaltung an den Bus) ab. Mit gängigen Bau-
steinen sind 32, 64 oder bis zu 110 (mit Einschränkungen bis zu 128) Teilnehmer pro Leitung
möglich (Erweiterungsmöglichkeit über Repeater oder Bridge).
2.2.3 CAN-Bus Topologie
Das CAN-Netzwerk wird als Linienstruktur aufgebaut. Stichleitungen sind in eingeschränk-
tem Umfang zulässig. Des Weiteren sind auch ein ringförmiger Bus (Infotainment Bereich)
sowie ein sternförmiger Bus (Zentralverrieglung) möglich. Beide Varianten haben im Ver-
gleich zum linienförmigen Bus jeweils einen Nachteil:
Im ringförmigen Bus sind alle Steuergeräte in Reihe geschaltet, so dass bei einem Ausfall
eines Steuergeräts der gesamte Bus ausfällt.
Der sternförmige Bus wird meist von einem Zentralrechner gesteuert, da diesen alle Informa-
tionen passieren müssen, mit der Folge, dass bei einem Ausfall des Zentralrechners keine In-
formationen weitergeleitet werden können. Bei einem Ausfall eines einzelnen Steuergeräts
funktioniert der Bus weiter.
Der lineare Bus hat den Vorteil, dass alle Steuergeräte parallel zu einer zentralen Leitung ge-
hen. Nur wenn diese ausfällt, funktioniert der Bus nicht mehr.
Bei einem Highspeed-Bus müssen zusätzlich 2 Abschlusswiderstände von je 120 Ohm (zwi-
schen CAN_HIGH und CAN_LOW) an dem jeweiligen Ende verwendet werden (Siehe Bild
2.1 CAN-Bus Topologie)
19
Bild 2.1: CAN-Bus Topologie
Als Anschlüsse haben sich 9pol.-D-SUB-Steckverbinder durchgesetzt. In Feldgeräten werden
meist 5 Polige M12-Steckverbinder verwendet. Eine Übertragung von Daten und Energie ist
optional vorgesehen.
2.2.4 Objektidentifier
Der Objektidentifier kennzeichnet den Inhalt einer Nachricht, nicht das Gerät. Zum Beispiel
kann in einem Messsystem den Parametern Temperatur, Spannung, Druck jeweils ein eigener
Identifier zugewiesen sein. Die Empfänger entscheiden anhand des Identifiers, ob die Nach-
richt für sie relevant ist oder nicht.
Zudem dient ein Objektidentifier auch einer Priorisierung der Nachrichten.
Die Spezifikation definiert zwei verschiedene Identifier-Formate:
• 11-bit Identifier, auch "Base frame format" genannt. Es können also 2032 Nachrichtentypen
durch den CAN-Bus gesendet werden.
• 29-bit Identifier, auch "Extended frame format" genannt. Damit sind es über 500 Millionen
verschiedene Nachrichtentypen definierbar.
125 Ohm 125 Ohm
CAN_L
CAN_H
CAN-Knoten 1
CAN-Knoten 3
CAN-Knoten 2
CAN-Knoten 4
20
Ein Teilnehmer kann Empfänger und Sender von Nachrichten mit beliebig vielen Identifiern
sein, aber umgekehrt darf es zu einem Identifier immer nur maximal einen Sender geben (da-
mit die Arbitrierung funktioniert).
2.2.5 Arbitrierung (Aushandeln des Medienzugriffs), Priorität
Der Buszugriff wird verlustfrei mittels der bitweisen Arbitrierung auf Basis der Identifier der
zu sendenden Nachrichten aufgelöst. Dazu sensiert jeder Sender den Bus, während er gerade
den Identifier sendet. Senden zwei Teilnehmer gleichzeitig, so überschreibt das erste domi-
nante Bit eines der beiden, das entsprechend rezessive des anderen, welcher dieses erkennt
und seinen Übertragungsversuch beendet, damit der andere seine Daten übertragen kann.
Verwenden beide Teilnehmer den gleichen Identifier wird ein Error-Frame erzeugt (siehe
2.2.6 Frame-Aufbau). Daher empfiehlt der Standard, dass ein Identifier auch nur von maximal
einem Teilnehmer verwendet werden soll.
Durch dieses Verfahren ist auch eine Hierarchie der Nachrichten untereinander gegeben. Die
Nachricht mit dem niedrigsten Identifier darf "immer" übertragen werden. Für die Übertra-
gung von zeitkritischen Nachrichten kann also ein Identifier hoher Priorität (= niedrige ID,
z.B. 0) vergeben werden, um ihnen so Vorrang bei der Übertragung zu gewähren. Dennoch
kann selbst bei hoch priorisierten Botschaften der Sendezeitpunkt zeitlich nicht genau vorher
bestimmt werden (nichtdeterministisches Verhalten).
21
2.2.6 Frame-Aufbau
Es gibt vier verschiedene Arten von Frames:
• Daten-Frame dient dem Transport von bis zu 8 Oktetten Daten
• Remote-Frame dient der Anforderung eines Daten-Frames von einem anderen Teil-
nehmer
• Error-Frame signalisiert allen Teilnehmern eine erkannte Fehlerbedingung in der
Übertragung
• Overload-Frame dient als Zwangspause zwischen Daten- und Remote-Frames
Ein Daten-Frame ist logisch wie folgt aufgebaut:
• Start of Frame (SOF) = ein dominantes bit
• Arbitrierungsfeld bestehend aus einem Identifier-Segment (11 bit oder 29+2 bit)
plus einem RTR bit (Remote Transmission Request, siehe unten )
• Kontrollfeld (CTRL) = 6 bit (2 bit reserviert + 4 bit Länge der Daten)
• Datenfeld (DATA) = 0-64 bit (in Einheiten von 8 bit)
• Prüfsummenfeld (CRC) = 16 bit (15 bit CRC plus einem rezessiven CRC-Delimiter
bit) Bestätigungsfeld (ACK) 2 bit, bestehend aus einem ACK-Slot (siehe untenstehen-
de Erläuterung) plus einem rezessiven ACK-Delimiter
• End of Frame (EOF) 7 bit (rezessiv)
• Intermission (IFS - Intermission Frame Space) = 3 bit (=min. Anzahl der Bits die
aufeinanderfolgende Botschaften trennt)
Bitstopfen (bit stuffing) kann die physikalische Länge eines Frames vergrößern. Beim Bit-
stopfen wird nach fünf gleichpoligen Bits ein komplementäres Bit (sog. Stopfbit) in den logi-
schen Bitstrom eingefügt. Bitstopfen wirkt auf Start of frame (SOF) bis einschließlich Prüf-
summenfeld (CRC) von Daten- sowie Remote-Frames und dient der Nachsynchronisation der
Teilnehmer innerhalb eines Frames.
22
RTR (Remote Transmission Request)
Ein gesetztes RTR-Bit kennzeichnet einen Remote-Frame (rezessiv). Mit Hilfe eines Remo-
teframe kann ein Teilnehmer einen anderen auffordern, seine Daten zu senden.
Im Falle eines "Extended Identifiers" (siehe 2.2.4 Objektidentifier), wird das RTR-Bit durch
das SSR-Bit (Substitute Remote Request) ersetzt und ebenfalls rezessiv gesendet. In diesem
Fall wird das nachfolgende IDE-Bit ebenfalls rezessiv gesendet, wodurch ein "Extended Iden-
tifier" signalisiert wird. Im Anschluss werden die restlichen 18 Bit des Identifiers und an-
schließend das eigentliche RTR-Bit gesendet. Das IDE-Bit zählt hierbei logisch zum "Ar-
bitrierungsfeld", wobei das Kontrollfeld aber weiterhin aus 6 Bit besteht.
Die Datenlänge muss entsprechend der zu erwartenden Datenlänge gesetzt werden (Fehler-
quelle: Viele Entwickler setzen die Datenlänge = 0 - dies ist falsch; ebenso sind CAN-
Controller am Markt, welche RTR-Frames nur mit der Datenlänge 0 senden können). Der
Objectidentifier ist derselbe, wie der der angeforderten Nachricht.
Der Acknowledge-Slot wird verwendet, um den Empfang eines korrekten CAN-Frames zu
quittieren. Jeder Empfänger, der keinen Fehler feststellen konnte, setzt einen dominanten Pe-
gel an der Stelle des ACK-Slots und überschreibt somit den rezessiven Pegel des Senders.
2.2.7 Sampling, Synchronisierung, Sicherung
Sampling: CAN-Controller können den Bus einmal oder dreimal pro Bit abtasten. Beim
3fach-sampling entscheidet die Mehrheit über den aktuellen Zustand (dominant = 0 oder re-
zessiv = 1).
Synchronisierung und Zeitquanten: Ein Bit wird in sog. Zeitquanten unterteilt. Sie entspre-
chen einem Vielfachen des Controllertaktes. In jedem Zeitquantum wird nur einmal abgetas-
tet. Eine Flanke wird erkannt, wenn der Abtastwert vor dem Zeitquantum einen anderen Wert
hat als der Wert danach. Die Nachsynchronisierung synchronisiert somit nur auf ein Zeitquan-
tum und nicht auf die Flanke.
Sicherung der Daten: Erkennt ein Empfänger eine Fehlerbedingung, sendet er einen Error-
Frame und veranlasst so alle Teilnehmer, den Frame zu verwerfen. Sollten andere Teilnehmer
23
diese Fehlerbedingung nicht erkannt haben, senden sie ihrerseits direkt im Anschluss ein wei-
teres Error-Frame. Hiermit wird eine weitere Sicherheitsfunktion des CAN Protokolls mög-
lich. Um zu vermeiden, dass einzelne Teilnehmer durch irrtümlich erkannte Fehlerbedingun-
gen dauerhaft den Nachrichtentransport blockieren, enthält jeder Teilnehmer Fehlerzähler.
Diese Zähler erlauben nach den Regeln der Spezifikation, einen fehlerhaft arbeitenden Teil-
nehmer in zwei Stufen des Betriebszustands vom Bus zu trennen, wenn er wiederholt Fehler
erkennt, welche andere Teilnehmer nicht erkennen oder wiederholt fehlerhafte Frames ver-
sendet. Die Zustände nennen sich error active (normal), error passive (Teilnehmer darf nur
noch passive - das heißt rezessive - Error-Frames senden) und Bus off (Teilnehmer darf nicht
mehr senden).
Der Sender wiederholt nach dem Error-Frame seine Datenübertragung. Auch der Sender kann
durch die zuvor erwähnten Fehlerzähler vom Bus getrennt werden, wenn die Datenübertra-
gung dauerhaft fehlschlägt. Verschiedene Fehlerfälle führen zu einer unterschiedlich großen
Erhöhung des Fehlerzählers.
2.2.8 Gründe für den Einsatz des CAN-Busses
Im Bezug auf das SCADA-Steuerungssystem hat der CAN-Bus folgende Gründe für
seinen Einsatz:
• Bei der Übermittlung der Pakete wird jedem übermittelten Datenpaket eine Prioritätsstufe
zugeordnet. So können wichtige Daten (z. B. Bremsinformationen) wenige wichtige Daten
(wie Richtungsanzeige also Blinklicht) kurzzeitig verdrängen.
• Das Gesamtsystem ist zuverlässig. Es enthält z.B. weniger störanfällige Steckverbindungen.
• Verdrahtung weniger komplex und dadurch kosteneffektiver.
• Die Installation wird einfacher und Veränderung leichter möglich.
• Zusätzliche Elemente (z.B. Steuereinheiten bzw. Aksenboard oder Atmel-Prozessoren) kön-
nen hinzugefügt oder deren Einbauort in einem CAN-Bus problemlos verändert werden. So
was währe mit einer RS232-Schnittstelle nicht möglich.
24
• Die Diagnosefähigkeit des Systems wird entweder erst möglich oder verbessert.
• Es kann beinahe an jeder beliebigen Stelle in das System eingegriffen werden, um Daten
abzulesen und/oder Parameter und evtl. sogar ganze Kennfelder zu ändern.
2.3 Kabellose Datenübertragung
2.3.1 TCP/IP Netze2
TCP (Transmission Control Protocol)
In der TCP/IP-Protokollfamilie übernimmt TCP als verbindungsorientiertes Protokoll die
Aufgabe der Datensicherheit und der Datenflusssteuerung. Es ergreift Maßnahmen bei einem
Datenverlust. Die Funktionsweise von TCP besteht darin, den Datenstrom der Anwendungen
aufzuteilen, mit einem Header zu versehen und an das IP zu übergeben. Beim Empfänger
werden die Datenpakete sortiert und wieder zusammengesetzt.
Jedem Datenpaket, das TCP verschickt, wird ein Header vorangestellt, der die folgenden Da-
ten enthält:
• Sender-Port
• Empfänger-Port
• Paket-Reihenfolge (Nummer)
• Prüfsumme
• Quittierungsnummer
2 Quelle: [AnTan]
25
Datenpakete, die über IP ihr Ziel erreichen, werden von TCP zusammengesetzt und über die
Port-Nummer an eine Anwendung übergeben. Dieser Port wird ständig von einem Prozess,
Dienst oder einer Anwendung abgehört. Die Port-Nummer 1 bis 1024 ist jeweils fest einer
Anwendung oder einem Dienst zugeordnet. Alle anderen Port-Nummern können belegt wer-
den, sofern sie frei sind.
Bild 2.2 Datenübertragung mit OSI Schichten-Modell
26
Durch die Port-Struktur ist es möglich, dass mehrere Anwendungen gleichzeitig über das
Netzwerk Verbindungen zu Kommunikationspartnern aufbauen können.
Well Known Ports 1 - 1023 Diese Ports sind fest einer Anwen-
dung oder einem Protokoll zugeord-
net. Die feste Zuordnung ermöglicht
eine einfachere Konfiguration durch
den Benutzer. Er kommt so mit dem
Protokoll TCP in Kontakt.
Die Verwaltung dieser Ports über-
nimmt die Internet Assigned Numbers
Authority (IANA).
Registered Ports 1024 - 49151 Diese Ports sind für Dienste vorgese-
hen.
Dynamically Allocated
Ports
49152 - 65535 Diese Ports werden dynamisch zuge-
wiesen. Jeder Client kann diese Ports
nutzen. Wenn ein Prozess einen Port
benötigt, fordert er diesen bei seinem
Host an.
Tabelle 2.1: Portstruktur [AnTan]
27
IP (Internet Protocol)
Das Internet Protocol, kurz IP, wird im Zusammenhang mit der Protokollfamilie TCP/IP ge-
nannt und verwendet. Es hat maßgeblich die Aufgabe, Datenpakete zu adressieren und in ei-
nem verbindungslosen paketorientierten Netzwerk zu vermitteln (Routing). Dazu haben alle
Stationen und Endgeräte eine eigene Adresse im Netzwerk. Sie dient nicht nur zur Identifika-
tion, sondern auch zum Erkennen eines Teilnetzes, in dem sich eine Station befindet.
Der Header eines IP-Datenpaketes enthält folgende Einträge:
• IP-Version
• Paketlänge
• Lebenszeit
• Prüfsumme
• Senderadresse
• Empfängeradresse
Die IP-Adresse nach IP Version 4 ist 32 Bit groß/lang. Sie ist in 4 Byte zerlegt und wird durch
Punkte voneinander getrennt (xxx.xxx.xxx.xxx). Jedes Byte kann einen Wert von 0 bis 255
annehmen.
Die IP-Adressen werden in 5 Klassen eingeteilt. In jeder Klasse haben die Netz-ID und die
Host-ID unterschiedliche Gewichtungen. IPv6-Adressen bestehen aus 128 Bit und werden als
Kette von 16-Bit-Zahlen in Hexadezimalform getrennt durch einen Doppelpunkt (":") darge-
stellt. Folgen von Nullen können einmalig durch einen doppelten Doppelpunkt ("::") abge-
kürzt werden. Da in URLs der Doppelpunkt mit der optionalen Portangabe kollidiert, werden
IPv6-Adressen in eckige Klammern gesetzt.
28
Sockets
Die Socket-Schnittstelle dient als standardisierte Programmierschnittstelle zwischen dem
Anwendungsprogramm und TCP/IP. Neben der rechnerübergreifenden Kommunikation von
Prozessen über TCP/IP, wird sie auch zur lokalen Interprozesskommunikation genutzt.
Die Socket-Schnittstelle kommt aus der UNIX-Welt. Mit dem 4.2BSD wurden die Sockets in
UNIX eingeführt. Eine allgemein verfügbare Spezifikation, die auf den UNIX-Sockets ba-
siert, wurde von der Firma Mircosoft unter der Bezeichnung WinSock in das WOSA aufge-
nommen und wurde damit ein etablierter Standard.
Ein großer Vorteil der Verwendung von Sockets ist ihre Homogenität, d. h. eine Kommunika-
tion über Sockets ist unabhängig von dem Standort der Prozesse, dem Betriebssystem, der
Rechnerarchitektur und dem Übertragungsmedium.
Der Aufbau einer TCP/IP Verbindung aus einem Anwenderprogramm wird durch die Ver-
wendung von Sockets sehr einfach. Der Anwendungssoftware stehen die in Tabelle gezeigten
TCP-Systemaufrufe zur Verfügung.
Zum Aufbau einer Verbindung werden vom Client und Server mit Hilfe des Funktionsaufru-
fes socket() eine Instanz der Socket-Schnittstelle erstellt und das Transportprotokoll festge-
legt. Durch den Systemaufruf bind() legt der Server den lokalen Host und den lokalen Port
fest. Damit ist die Adresse festgelegt, auf welcher der Server dem Client antwortet. Nach dem
Aufruf der Funktionen listen() und accept() wartet der Server auf ein connect() des Clients.
Der Client bekommt mit dem connect()-Aufruf implizit eine lokale Adresse zugewiesen und
übergibt sie dem Server. Die Verbindung ist nun aufgebaut und Client und Server können mit
read()- und write()-Funktionen bidirektionalen, byteorientierten Datenaustausch betreiben.
Durch den Systemaufruf close() wird die Verbindung abgebaut.
29
Tabelle 2.2 vergleicht eine Socket-Verbindung zwecks Anschaulichkeit mit einem Telefonge-
spräch.
Prozess 1 Prozess 2 Funktion Analogie
Server Client
socket() socket() Socket erstellen Telefonhörer abheben
write() write() Daten über die Schnittstelle senden Reden
read() read() Daten empfangen Zuhören
close() close() Socket schließen Auflegen
Tabelle 2.2: TCP/IP Kommunikation zwischen Client und Server
2.3.2 WLAN IEEE802.11x3
Motivation
Mögliche Einsatzgebiete der WLAN Technologien sind:
• Drahtloses Surfen, kein Kabelsalat
• Günstige alternative (Ergänzung) zu UMTS und GPRS
• Zufriedenstellende Datenraten für den mobilen Internetnutzer (Multimedia Dienste)
• Schneller Aufbau der Zugangsnetze z.B.(CEBIT Messe)
• Informationszeitalter, Information, Kommunikation, Mobilität besonders wichtig
• Hochschulnetze und öffentliche Hotspots so wie Automatisierungstechnik
• Mitarbeiter oft in Besprechungen und Vorträgen, im Netzwerk- und Rechnerraum
• Abgeschnitten von Informationen, aber aktuelle Informationen notwendig
3 Quelle: [IEEE 802.11.x], [JosGut], [AnHac], [WLABuc], [ShoRan], [ WLANBlu]
30
Geschichte
Obwohl WLAN eigentlich erst in den letzten Jahren vermehrt genutzt wird und auch bei Pri-
vathaushalten im Kommen ist, hat die Technik von WLAN eine relativ lange Geschichte, vor-
ausgesetzt jedenfalls, man fasst die Anfänge des WLAN relativ weit. So betrachtet beginnt die
Geschichte von WLAN bereits in den 1940er Jahren. Damals wurde nämlich bereits ein Pa-
tent für das so benannte "Frequency Hopping" angemeldet. Dahinter verbarg sich die Idee,
einen Torpedo per Funk in ein Ziel zu steuern und dabei so oft die Frequenz zu wechseln,
dass es dem Feind unmöglich wäre den Torpedo vorzeitig abzuschießen. Diese Idee war ihrer
Zeit eindeutig voraus. Noch interessanter und beeindruckender wird das ganze, wenn man
weiß, dass die Idee nicht von einem Techniker oder Militaristen stammt, sondern von einer
österreichischen Schauspielerin und einem Musiker. Die Namen der beiden WLAN-Pioniere -
wenn man so will - waren Hedy Lamarr und George Antheil.
Konkreter kann man aber erst in den 1960er Jahren von den Anfängen des WLAN sprechen.
1969 machte nämlich die Universität von Hawaii einen sehr interessanten Ansatz in Richtung
WLAN. Es wurde ein Funknetzwerk entwickelt, das die verschiedenen Standorte der Univer-
sität verbinden sollte. Dazu muss man wissen, dass die Universität von Hawaii sozusagen auf
verschiedenen Inseln verteilt ist. Das Funknetzwerk sollte also die verschiedenen Bereiche
mit einem Zentralrechner auf der Insel Oahu verbinden, was auch gelang. Das Funknetzwerk
trug den schönen Namen Aloha-Net.
Die Arbeitsgruppe 802 des Institute of Electrical and Electronic Engineers (IEEE) begann
Ende 80er Jahren, sich drahtlosen Netzwerktechnologien zu widmen. Daraus entstand der
heutige Standard IEEE802.11 und somit die Spezifikation für Media Access Control (MAC)
und Physical Leyer(PHY). Das sind Grundsteine aller wirless LAN’s, die am 26. Juni 1997
vom IEEE bestätigt wurden.
Funktion des WLAN’s
Um verstehen zu können wie WLAN funktioniert, muss man sich bei dieser Technik einige
Dinge vor Augen führen.
Für die Technik und das Funktionieren von WLAN ist zunächst einmal der grundsätzliche
Aufbau von Funknetzen wichtig. Es gibt hierbei verschiedene Möglichkeiten, wie man Funk-
31
netze aufbauen und strukturieren kann: Je nachdem kommt man zu unterschiedlichen Vor-
und Nachteilen. Eine Möglichkeit ist zum Beispiel der Peer-to-Peer-Modus. Hier gibt es näm-
lich keinen Access-Point, sondern das Funknetz besteht nur aus Mitgliedern, die sich selbst
organisieren und untereinander kommunizieren. Dagegen gibt es im so genannten Infrastruc-
ture-Modus immer mindestens einen Access-Point, über den die Kommunikation und Organi-
sation läuft. Neben diesen beiden Hauptgruppen gibt es noch weitere Möglichkeiten und tech-
nische Raffinessen, allerdings sind diese hauptsächlich etwas für Experten und spielen bei der
grundsätzlichen Einführung in die WLAN-Technologie keine entscheidende Rolle.
WLAN ist auf jeden Fall zunächst einmal als ein solches Funknetz wie oben erwähnt zu be-
trachten und bietet damit eine sehr praktische Funktechnik zur Übertragung von Computerda-
ten und Ähnlichem an. Der für WLAN verwendete Standard ist der Standard IEEE 802.11
und dessen Nachfolger, denn seit der Entstehung von WLAN wurden die Standards immer
wieder verändert und verbessert.
WLAN ist also ein Computernetzwerk, das praktisch gesehen das Ethernetkabel durch eine
Funkverbindung ersetzt. Für das Arbeiten mit dem Computer bedeutet dies aber keinen Unter-
schied zu einer Verbindung mit einem Ethernetkabel, denn für ein Betriebssystem wie zum
Beispiel Windows und die Programme erscheint es bei einer WLAN-Verbindung so, als ob
der Computer über ein Ethernetkabel angeschlossen wäre.
Da es mittlerweile viele verschiedene Technologien im Bereich WLAN gibt und weil die
Nutzung verschiedener Standards ebenfalls Auswirkungen hat, ist es schwer, allgemeingültig
Aussagen über WLAN zu treffen. Man kann lediglich ein paar Gemeinsamkeiten hervorheben
und natürlich den Unterschied zu kabelgebundenen Netzwerken betonen. Dieser ist folgender:
es existiert bei WLAN keine Verbindung der Netzwerkkarte mit einem Kupferkabel oder
Ähnlichem, sondern die Übertragung erfolgt durch die Luft. Dadurch ergeben sich bei den
meisten WLANs die Probleme mit der Bandbreite, denn alle verfügbaren Sender streiten sich
um die verfügbare Bandbreite. Das andere Problem, das durch die Übertragung durch die Luft
entsteht, ist das Problem mit der Sicherheit, denn die Zugriffe können nur schwer konfiguriert
werden. Zu guter Letzt ist noch zu erwähnen, dass es natürlich eine Rolle spielt, ob die Funk-
wellen wirklich nur durch die Luft gehen, oder ob sie Hindernisse durchdringen müssen.
32
WLANs sind primär als LAN-Kabelersatz für die PC-Vernetzung gedacht.
Ein typisches WLAN ist folgend dargestellt. (Siehe Bild 2.3 IEEE 802.11-WLAN im Infra-
struktur Mode)
Bild 2.3: IEEE 802.11-WLAN im Infrastruktur Mode [SSV1]
Wireless LAN arbeitet auf der Bitübertragungsschicht des OSI-Schichten-Modells. (Siehe
Tabelle 2.3 OSI-Schichten-Modell) Drahtlose Netzwerkkarten lassen sich deshalb ohne Prob-
leme in jedes System einbinden. Auf bestimmte Protokolle ist man nicht angewiesen. Wire-
less LAN ist vollkommen protokolltransparent, wie jedes andere IEEE-802-Netzwerk auch.
Obwohl Wireless LAN protokollunabhängig arbeitet, können sich Probleme in der Praxis mit
einigen Protokollen und Anwendungen ergeben. Ausschlaggebende Faktoren sind die höhere
Bitfehlerrate (Bit Error Rate, BER) und die größere Verzögerung bei der Übertragung von
Daten. Es liegt in der Natur des Wireless LAN, dass die zur Übertragung benötigte Zeit länger
ist als im drahtgebundenen LAN. Ein einfacher Ping hat im drahtgebundenen LAN eine
Round Trip Time von weniger als einer Millisekunde. Im Wireless LAN liegt die Zeit für ein
Ping bei bis zu vier Millisekunden. Anwendungen, die ein kurzes Delay benötigen, haben in
einem Wireless LAN nichts verloren.
Der Access Point (AP) ist innerhalb des Wireless LAN das einzige aktive Schicht-2-Element.
Vergleichbar mit einer Bridge verbindet er zwei Netzwerke mit unterschiedlicher physikali-
scher Schicht, bsw. das Wireless LAN mit dem drahtgebundenen Ethernet oder Token Ring.
33
4 Transport-Schicht (TCP/IP) TCP
3 Netzwerk-Schicht (IP) IP
2 Logical Linck Control 802.2
2 Medium Access Control (MAC) CSMA,VCD
1 Physical Layer (PL) DSSS,FHSS,Infrarot
Tabelle 2.3: OSI-Schichten-Modell. [AnTan]
Der Funknetz-Standard definiert einen gemeinsamen MAC-Layer (Medium Access Control)
für drei spezifische Physical Layer (PL). Zwei davon sind den Funk-LANs, einer dem Infra-
rotnetz zugeordnet.
Im Funknetz wird als Frequenzbereich das ISM-Band (2,4 GHz) von 2,400 bis 2,4835 GHz
genutzt. In diesem Frequenzband stehen 79 Kanäle mit jeweils 1 MHz Bandbreite zu Verfü-
gung. Mindestbandbreite liegt bei einem MBit/s. Optional lässt es sich auch auf 2 MBit/s er-
weitern.
Die Infrarot-Variante nutzt die Frequenzen von 850 bis 950 Nanometer (Licht). Die verwen-
dete diffuse IR-Übertragung erfordert keine exakte Ausrichtung von Sender und Empfänger.
Die maximal 10 Meter weite Sichtlinie sollte trotzdem hindernisfrei sein, um unnötige Beein-
trächtigungen bei der Datenübertragung auszuschließen.
Das ISM-Frequenzband (Industrial, Scientific, Medicine) kann für Anwendungen in Industrie,
Wissenschaft und Medizin frei und ohne Lizenz benutzt werden (Siehe Tabelle 2.2 Übersicht
WLAN nach IEEE 802.11). Das bedeutet, dass auf privatem Grund und Boden keine Gebüh-
ren bezahlt werden müssen. Das ISM-Frequenzband ist weltweit als lizenzfrei anerkannt.
In diesem Frequenzspektrum um 2,4 GHz konkurrieren viele Standards und propritäre Funk-
techniken der unterschiedlichsten Hersteller und Anwendungen, unglücklicherweise auch
Geräte des täglichen Gebrauchs, z. B. Mikrowellenherde und schnurlose Telefone. Die Reali-
sierbarkeit eines Funknetzwerkes nach 802.11 hängt also maßgeblich von der Nutzung ande-
34
rer Produkte in diesem Frequenzspektrum ab. Z. B. nutzen auch Bluetooth-Endgeräte für den
Kurzstreckenfunk dieses Frequenzspektrum. Störungen sind da nicht ausgeschlossen.
Um die Anforderungen an die Datensicherheit zu erfüllen sind im Wireless LAN Standard
bereits Mechanismen dafür integriert. Damit die Funkverbindung weder gestört noch abgehört
werden kann, wird mit dem Bandspreizverfahren das Signal über ein möglichst breites Fre-
quenzspektrum aufgeteilt.
Um den Datenverkehr innerhalb der Funkzelle zu sichern, werden die Daten zwischen den
Stationen mit WEP (Wired Equivalency Privacy) verschlüsselt. Die Nutzdaten werden mittels
des RC4-Algorithmus mit den Key-Längen 40 oder 104 Bit verschlüsselt.
WEP wurde bereits als nicht besonders sicher eingestuft. Unter Umständen sind weitere Si-
cherungsmaßnahmen, wie z. B. VPN mit IPsec oder Protokolle mit SSL notwendig.
Hauptproblem bei Funknetzwerken ist die Abhängigkeit des Datendurchsatzes von der
Reichweite. Die angegebenen Brutto-Übertragungsraten von 1 und 2 MBit in der Sekunde
reduzieren sich in der Praxis auf wenige kBit. Je weiter man sich vom Access Point entfernt,
desto geringer wird auch der Datendurchsatz. Ab einem bestimmten Punkt wird die Verbin-
dung quälend langsam oder bricht ganz ab.
35
Standard 802.11 802.11b B802.11b+ 802.11a 802.11g
Frequenzbereich 2,4 GHz 2,4 GHz 2,4 GHz 5 GHz 2,4 GHz
Datendurchsatz 2 MBit/s 11 MBit/s 22 MBit/s 54 MBit/s 54 MBit/s
Kompatibel zu 802.11b 802.11b+/g 802.11b/g - 802.11b/b+
Übertragungsrate 2,4 GHz 5.2 GHz
1/ 2 IEEE 802.11 -
5,5 / 11 MBit/s IEEE 802.11b -
22/33/44 MBit/s IEEE 802.11b+/PBCC -
6 bis 54 MBit/s IEEE 802.11g IEEE 802.11a/h
Tabelle 2.4: Übersicht WLAN nach IEEE 802.11
Reichweiten von WLAN
Ein Nachteil von WLAN ist immer noch die Reichweite dieser Technologie, die Technolo-
gien wie UMTS und GPRS noch nicht das Wasser reichen kann. Man kann sich mit seinem
Laptop nur eine bestimmte Entfernung zum Access-Point erlauben, denn sonst sind bestimmte
Übertragungsraten nicht mehr möglich beziehungsweise die Verbindung reißt ganz ab.
Die Reichweite von WLAN hängt grundsätzlich von verschiedenen Faktoren ab. Der wich-
tigste ist wohl der des Raumes und der der direkten Umgebung.
Grundsätzlich kann man sagen, dass die Reichweite von WLAN ständig verbessert wird. Die
Reichweite von 802.11a war zum Beispiel im Vergleich zu 802.11b und 802.11g sehr viel
niedriger, was damit zusammenhängt, dass bei höheren Frequenzen die Dämpfung höher ist
und die alten Standards bei 5 GHz liefen, während die neueren bei 2,4GHz laufen.
36
Normale Antennen kommen im Freien auf etwa 300 Meter, in Gebäuden mit dünnen Wänden
auf etwa 40 Meter und in allen anderen Räumlichkeiten hängt die Reichweite ganz von den
verwendeten Materialien ab. Mit speziell gerichteten Antennen können die Werte fürs Freie
weit übertroffen werden, vorausgesetzt es besteht Sichtkontakt. Dann können Werte um 20
Kilometer erreicht werden. Antennen bringen also in jedem Fall einen Sende- wie Empfangs-
gewinn.
2.3.3 Bluetooth4
Bluetooth
Bluetooth ist eine Lösung zur einfachen Anbindung von Peripheriegeräten (z.B. mobile End-
geräte wie Handys, PDA's und Notebooks) über eine drahtlose Schnittstelle. Der Standard
wurde von der Firma Ericsson eingeleitet, die Bluetooth seinen Namen gab. Bluetooth (Blau-
zahn) wurde der vor rund 1000 Jahren herrschende dänische König Harald II genannt, der in
Dänemark nach wie vor hohes Ansehen genießt. Der Standard wird durch die BSIG (Blue-
tooth Special Interest Group) gefördert und wurde erstmals 1998 vorgestellt. Zusammen mit
Ericsson bilden neun Unternehmen die so genannte Promoter Group, wobei jedoch mittler-
weile wesentlich mehr Unternehmen der Interessengruppe angehören.
Bluetooth - Grundlagen
Bluetooth arbeitet im 2,4 GHz ISM-Band (Industrial, Scientific and Medical-Band), das li-
zenzfrei genutzt werden kann. Dies ist das gleiche Frequenzband, wie es die Wireless LAN
Standards IEEE802.11b und IEEE802.11g nutzen. Dabei gibt es drei unterschiedliche Sende-
klassen. Die Sendeklasse 3 mit einer Empfindlichkeit von –70 dBm, einer Leistung von 1mW,
einer theoretischen Reichweite von 10 m und einer Netzgröße im Piconet-Bereich. Dies ist die
Klasse, in welcher die meisten heutigen Bluetooth Geräte arbeiten. Auch wenn dies laut Defi-
nition der Bereich eines PANs ist, so ist Bluetooth doch nicht auf diese Leistung beschränkt.
Durch nachgeschaltete Leistungsverstärker kann die Ausgangsleistung wesentlich gesteigert
werden. Dabei arbeitet die Signalklasse 2 mit einer Empfindlichkeit von 4 dBm, einer Leis-
37
tung von 2,5 mW, einer theoretischen Reichweite von 30 m und einer Netzgröße im Nanonet-
Bereich. Die maximale Leistung wird jedoch in der Signalklasse 1 erreicht, mit einer Emp-
findlichkeit von 20 dBm, einer Leistung von 100 mW, einer theoretischen Reichweite von
100 m und einer Netzgröße im Mikronet Bereich. Netze der Sendeklassen 3 und 2 sind dabei
dem PAN-Bereich zuzuordnen, wobei Netze der Sendeklasse 1 den Grenzfall zum LAN dar-
stellen. Es muss jedoch berücksichtigt werden, dass in den heutigen Bluetooth-Lösungen ma-
ximal Datenraten von 1 MB/s zu realisieren sind. An zukünftigen Erweiterungen wird jedoch
bereits gearbeitet; so wird eine Verdoppelung der Datenrate auf 2 MB/s angestrebt.
Wie bereits erwähnt, arbeitet Bluetooth in dem 2,4 GHz ISM-Band, wobei der genaue Ar-
beits-Frequenzbereich von 2,402 GHz bis 2,480 GHz liegt. Als Zugriffsverfahren wird ein
schnelles Frequenzsprungverfahren, das Frequency Hopping Spread Spectrum (FHSS), ver-
wendet. Dabei werden 1600-mal je Sekunde Frequenzwechsel vollzogen, die in 79 Schritten
zu je 1 MHz zueinander liegen. Bluetooth stellt hierbei einen Breitbandkanal für Sprach- und
Datenübertragung zur Verfügung, wobei sich bis zu drei Sprachkanäle mit jeweils 64 KB/s
betreiben lassen. Prinzipiell kann zwischen einer synchronen und einer asynchronen Übertra-
gung gewählt werden. Die synchrone Übertragung stellt eine Datenübertragungsrate von
433,9 KB/s zur Verfügung. Bei der asynchronen Übertragung kann eine Datenübertragungsra-
te von 723,2 KB/s in Downloadrichtung und 57,6 KB/s in Uploadrichtung realisiert werden.
Bluetooth kennt drei verschiedene Sicherheitsstufen, wobei nur in der dritten Stufe verschie-
dene Verschlüsselungsmethoden zum Tragen kommen. So kann beim Verbindungsaufbau die
Authentifizierung mit 128 bit und bei der Datenübertragung eine Verschlüsselung von 8 bit
bis 128 bit erfolgen.
Bluetooth - Netz
In der Sendeklasse 3 bezeichnet man die Netzgröße als Piconet. In einem Piconet dürfen ma-
ximal acht Bluetooth-Geräte miteinander kommunizieren. Die Bluetooth-Geräte identifizieren
sich über eine 48 bit lange Identifikationsnummer, wobei das erste aktive Gerät in dem Netz
als Master fungiert und für die Steuerung des Frequenz-Hopping zuständig ist. Das bedeutet,
dass in einem Piconet ein Master und maximal sieben Slaves arbeiten können. Weiterhin kön-
nen jedoch bis zu 255 Bluetooth-Geräte als passive Slaves geparkt werden. Diese Geräte kön-
4 Quellen: [WLABlu], [BlToo], ], [ WLANBlu]
38
nen dann über den Master aktiviert werden, sofern dies nötig wird. Darüber hinaus besteht die
Möglichkeit des Zusammenschlusses mehrerer Piconets zu einem so genannten Scatternet.
Hierbei übernimmt ein gemeinsamer Slave die Vermittlungsfunktion zwischen beiden Pico-
nets.
Bluetooth - Vorteile/Nachteile
Die Bluetooth-Technologie ist eine Bereicherung im PAN-Segment und ermöglicht eine ein-
fache Anbindung von Peripheriegeräten. Der Vorteil eines solchen offenen Standards ist die
rasche Akzeptanz am Markt. Dies kann jedoch nicht uneingeschränkt gesehen werden, da
diese in Teilbereichen sehr stark unterschiedlich ist. Sofern die Entwicklungsziele einer sehr
preiswerten Einchip-Lösung der Bluetooth-Komponenten eingehalten werden, steht dem brei-
ten Einsatz nichts im Wege. Durch den Markennamen Bluetooth wird zudem gewährleistet,
dass eine Interoperabilität mit Bluetooth-Geräten verschiedener Hersteller erfüllt werden
kann. Durch die Nutzung des 2,4-GHz-Frequenzbandes kann es jedoch zu Störungen mit
WLAN-Komponenten kommen, die nach den Standards IEEE802.11b oder IEEE802.11g
ebenfalls im ISM-Band arbeiten. Auch die Anwendung von Bluetooth zur vernetzten Daten-
übertragung ist kritisch zu betrachten, da dies den Grenzfall vom WPAN zum WLAN dar-
stellt. Hierzu haben die Industriestandards nach IEEE802.11 eine wesentlich breitere Durch-
dringung am Markt und eine ausgereiftere Technologie.
39
3 Realisierung
3.1 Gesamtkonzept
In Anbetracht der Anforderungen an das System und die Datenübertragung wie zum Beispiel
bei den meisten Einsätzen werden die Steuerdaten bzw. Sensorwerte von Prozessen zyklisch
ausgelesen und bearbeitet. Die errechneten Werte werden an andere Prozesse bzw. Aktoren
weiter gegeben, was natürlich ein regelmäßiger Nachrichtenverkehr voraussetzt. Für das
Steuerungssystem wird folgender schematisches Konzept (siehe Bild 3.1) entworfen.
Bild 3.1 Schematisches Konzept der Kommunikationsteilnehmer
40
3.2 Auswahl der optimalen Funktechnologie5
Bild 3.2 Funktechnik-Aktuelle Standards im Vergleich
In Anbetracht der Zielsetzung und der derzeit vorliegenden Standards (Siehe Bild 3.2: Funk-
technik-Aktuelle Standards im Vergleich) kann die Verwendung der Funktechnologie und der
Standard-Software festgelegt werden. Da sich das Netzwerk auf kurze bis mittellange Distanz
ausbreitet(10-200 Meter), befindet sich das System im Bereich des kabellosen persönlichen
Netzwerkes (WPAN) bis hin zu dem kabellosen lokalen Netzwerkes (WLAN).
Die zu diesen Netzwerkarten zugeordneten standardisierten Technologien sind:
- WLAN
- Infrarot
- Bluetooth
- ZigBee
5 Quellen: [ATan], [AHac], [BT]
41
Die Anforderung an die Übertragungsgeschwindigkeit ist gering. Sendedaten und Steuer-
kommandos an das Aksenboard und somit an Servomotoren sind Pakete mit einer Datenlänge
von maximal 8 Byte, die eine durchschnittlich geringe Bandbreite erfordern.
Rechenbeispiel: In einem Netzwerk befinden sich 400 Knoten. Jeder Teilnehmer sendet pro
Sekunde ein 30 Byte großes Datenpaket an das zentrale Modul(10 Byte Informationsgehalt
und pauschal 20 Byte Header-Daten). Ein empfangenes Paket wird durch ein 20 Byte großes
Antwortpaket bestätigt. Am zentralen Modul kann eine maximale Bitrate von 160 kBit/s
(20x8=160) entstehen. Jede der hier betrachteten Technologien gewährleistet diesen Daten-
satz. Um sich für die geeignete Technologie zu entscheiden, werden die oben genannten Stan-
dards an Hand folgender Kriterien miteinander verglichen:
- Geschwindigkeit / Bandbereite
Es werden hauptsächlich kleine Datenmengen transportiert. Steuerkommandos für das
Fahrzeug und somit an Servomotoren sowie Sensorenwerte werden in Stringform übertra-
gen und benötigen nur geringe Datenübertragungsgeschwindigkeiten.
- Energieverbrauch
Der CAN/WLAN-Umsetzer-Modul (9 Volt Spannungsversorgung), der Aksenboard und
die Sharp-Sensoren (5-8 Volt) und die Servomotoren(12 Volt) werden mit Batterien ver-
sorgt. Der Leitstand ist eine Applikation und läuft auf dem Standardrechner mit dem Be-
triebsystem Windows XP, versorgt über normale Netzspannung.
- Reichweite:
Wie oben erwähnt, erstrebt das System die Reichweite eines WLAN.
- Latenzzeit:
Die Latenzzeit beschreibt die Zeit eines Datenpaketes vom Sender zum Empfänger. Sie
setzt sich
1. aus der Zeit der eigentlichen Übertragung und der
2. aus den Verarbeitungszeiten bei Sender und Empfänger zusammen.
In dieser Betrachtung steht der zweite Punkt im Vordergrund.
42
3.2.1 Grobe Selektion
Die Infrarot-Technik ist hier ungeeignet, da stets Sichtkontakt zwischen den miteinander
kommunizierenden Kommunikationsteilnehmern bestehen muss. Der eigentliche Vergleich
beschränkt sich somit auf die Techniken Bluetooth und WLAN.
3.2.2 WLAN und Bluetooth im Vergleich
• Geschwindigkeit/Bandbreite
Bluetooth und WLAN arbeiten in den 2,4 GHz-Bereichen des ISM-Band. Bluetooth verwen-
det das Frequenzsprung-Verfahren FHSS und erreicht eine Verbindungsrate von 723 kBit pro
Sekunde, wobei praktisch eine Datenübertragungsrate von rund 125 kBit pro Sekunde erlangt
wird. Ebenfall in Anbetracht der Anforderungen an das verteilte System sind beide Technolo-
gien bezüglich der Übertragungsrate geeignet.
• Reichweite
Die Reichweite von Bluetooth liegt, abhängig von der Klasse, bei 10 bis 100 Metern. Große
Entfernungen erfordern erheblich mehr Sendeleistung (Klasse I: 100 m bei 100 mW, Klasse
III: 10 m bei 1 mW). WLAN hat eine Reichweite bis zu 300 Metern, wobei im Mittel 50 Me-
ter erwartet werden können. Um erwartete Netzwerke mit einer Reichweite von bis zu 300
Metern aufzubauen, reichen direkte Verbindungen von Gerät zu Gerät nicht aus. Große Ent-
fernungen fordern das Routing und die Weiterleitung von Paketen innerhalb der Netzwerke,
was zwar von beiden Standards unterstützt wird, aber bei Bluetooth mit relativ hohem Auf-
wand verbunden ist. Die mit Abstand größte Reichweite mit ca. 200 - 300 Metern direkt zwi-
schen zwei Geräten erreicht WLAN.
43
• Anzahl der Netzwerkteilnehmer
Die Architektur des Bluetooth-Netzwerkes unterteilt sich in zwei Komponenten, dem Pico-
und dem Scatternetz. Ein Piconetz enthält bis zu 255 Teilnehmer, bestehend aus einem Master
und Slaves. Da der Master sieben Sendeslots an die Slaves vergeben kann, können insgesamt
lediglich acht Geräte gleichzeitig aktiv sein. Einzelne Knoten können sich in mehreren Pico-
netzen befinden, wodurch ein Scatternetz entsteht. Bluetooth schränkt die Netzspontaneität
durch die geringe Anzahl gleichzeitig verteilbarer Sendeslotts ein, zudem wird die Größe des
Netzwerkes durch die Anzahl adressierbarer Knoten beschränkt. Drahtlose Netzwerke werden
in Funkzellen eingeteilt. Eine Funkzelle besteht im Minimum aus einem Sender/Empfänger-
Paar und wird als der Raum definiert, in dem alle Sender und Empfänger dieselbe Frequenz
und/oder denselben Code benutzen. WLAN ist also ein Computernetzwerk, das praktisch ge-
sehen das Ethernetkabel durch eine Funkverbindung ersetzt. Für das Arbeiten mit dem Com-
puter bedeutet dies aber keinen Unterschied zu einer Verbindung mit einem Ethernetkabel.
Also, wie in einem normalen Netz können mehrere Teilnehmer 232, also 4.294.967.296 Teil-
nehmer angeschlossen werden.
• Energieverbrauch
Bei Betrachtung des Leistungsverbrauchs der beiden Technologien beim Senden und Emp-
fangen von Daten, sowie im Standby-Modus gibt es kaum Differenzen. Ein unterschiedlicher
Energieverbrauch kommt durch die Art und Weise des Sendens und Empfangens zustande.
Die PHY-Schicht von Bluetooth fordert ständig die Synchronisation der Module untereinan-
der. Somit verweilen die Module kaum im Standby- Modus und verbrauchen verhältnismäßig
viel Energie. WLAN hat einen Ressourcenverbrauch von mindestens einem Megabyte RAM
und sein Energieverbrauch übersteigt die Kapazitäten kleiner Module(siehe Tabelle 3.1 Ener-
gieverbrauch bei den WLAN und Bluetooth).
Technologie Sendeleistung[mW] Leistungsaufnahme[mW] Energieverbrauch
pro Bit[nJ]
Bluetooth(10m) 1 90 90 WLAN 280 ca. 2000 ca. 180
Tabelle 3.1 Energieverbrauch bei WLAN und Bluetooth
44
Anzahl der Netzwerkteilnehmer
Die Anzahl der Knoten ist abhängig von der Art der Anwendung. Die maximale Netzteilneh-
mer sollte maximal 10 Teilnehmer sein.
• Latenzzeiten
Große Unterschiede bestehen bei den Beitritts- und Anforderungszeiten zwischen den Tech-
nologien. Je kürzer die Latenzzeit, desto schneller die Übertragung eines Datenpaketes von
einem Netzwerkteilnehmer zum anderen. Besonders der Zeitaufwand, bis ein Bluetooth-
Modul vom schlafenden in den aktiven Zustand gewechselt ist, wird nicht den Anforderungen
eines Sensornetzwerkes gerecht.
Bluetooth WLAN
Beitritt in ein Netzwerk > 3s ~ 3ms
Zugriff eines aktiven Knotens ~ 2ms ~15 ms
Tabelle 3.2 Latenzzeiten bei Bluetooth und WLAN
45
IEEE 802.11 vs. Bluetooth
Während der Entwicklung des WLAN-Standards 802.11 und Bluetooth haben sich schnell
Gemeinsamkeiten eingestellt. Beide Funknetzstandards arbeiten im Frequenzband 2,4 GHz
und sollen die unterschiedlichsten Geräte über Funk miteinander verbinden. Beide Standards
zeichnen sich durch unterschiedliche Stärken aus und kommen dadurch in verschiedenen Ge-
räten auf den Markt. Wireless LAN übertrifft Bluetooth in seiner Reichweite und Übertra-
gungsgeschwindigkeit und kommt deshalb in lokalen Netzwerken zum Einsatz. Bluetooth ist
mit geringen Hardwarekosten, niedrigem Stromverbrauch und Echtzeitfähigkeit in den Berei-
chen Sprachübertragung, Audio-Video-Lösungen und Adhoc-Verbindungen zwischen
Kleinstgeräten besser geeignet. Bluetooth löst hier Irda (Infrarot) erfolgreich ab.
Bluetooth IEEE 802.11
723 kBit/s 11-54 MBit/s
Bis zu 10 m
(mit FEC auch bis zu 100m)
Bis zu 100m – 300m
(einige km mit externen Antennen als Richt-
funk )
8 (aktive Geräte pro Piconet) 256 und mehr Geräte pro Netzwerk
Verschiedene Verwendungszwecke LAN
Extrem Stromsparend Höherer Stromverbrauch
Tabelle 3.3 IEEE 802.11 vs. Bluetooth
Ergebnis
In Anbetracht der Vorteile von WLAN gegenüber Bluetooth und mit der Berücksichtigung
des CAN/WLAN-Moduls wird als Funktechnik für das für das SCADA Steuerungssystem die
WLAN Technologie verwendet.
46
3.3 Benötigte Hardware für die Realisierung des Systems
3.3.1 Standard PC
Ein Standard Windows-PC, der als Plattform für den Leitstand dienen soll, der mit einem
WLAN-Interface (siehe Bild 3.3 WLAN USB-Dongle) in Form eines USB-Dongles aus-
gestattet ist. Zusätzlich noch ein PC-Lenkrad Logitech® MOMO® Racing (siehe Bild 3.5),
das folgend noch beschrieben wird. Es wird mit Gas- und Bremspedal ebenfalls auch über
USB an dem Windows-PC angeschlossen.
3.3.2 WLAN-Interface
Um eine Telemetrie per WLAN innerhalb kürzester Zeit zu erproben, braucht man lediglich
einen Windows-PC mit einer WLAN-Schnittstelle, zum Beispiel einem preiswerten WLAN
USB-Dongle. (Siehe Bild 3.3)
Bild 3.3 WLAN USB-Dongle
Zunächst sollte die WLAN-Schnittstelle des PCs in den Ad-hoc-Modus gesetzt werden.
Hierfür findet man in der WLAN-Treibersoftware, welche als Zubehör zu jedem PC-WLAN-
Interface installiert wurde, die entsprechenden Einstellmöglichkeiten.
Die IP-Adresse für das WLAN-Interface des PCs sollte mit dem statischen Wert 192.128.3.1
versehen werden. Windows XP bietet in der Systemsteuerung die entsprechenden Dialoge
zur Konfiguration. Bild 3.4 zeigt die IP-Adressen-Konfiguration eines Windows-
Betriebssystems.
47
Bild 3.4 IP-Adressen-Konfiguration für ein PC-WLAN-Interface
Die drahtlose Steuerdatenübertragung per WLAN ist beim Einsatz der richtigen Werkzeuge
sehr schnell und einfach möglich. Ein großer Vorteil ist der hohe Standardisierungsgrad durch
IEEE802.11- Vorgaben im Hinblick auf Hardware und Software. Dadurch ergibt sich ein
deutlicher Investitionsschutz im Vergleich zu propritären Funklösungen in den 433 und 868
MHz Funkbändern. Also, die Kommunikation zum Fahrzeug findet über das USB-WLAN-
Interface statt. Dieses ist, so wie oben gezeigt, konfiguriert, so dass es sich automatisch mit
dem IGW400/CAN verbindet.
48
3.3.3 PC-Lenkrad
Das Einlesen der Steuerdaten aus dem PC-Lenkrad und Gas/Bremspedalen kann man mit we-
nig Programmieraufwand mit der Programmiersprache G LabVIEW erreichen. Da ich am
Anfang mit der grafischen Programmiersprache LabVIEW absolut keine Erfahrung hatte, hat
es mir einwenig Zeit gekostet, bis ich die Initialisierung der Hardware programmieren konnte.
Bild 3.5 PC-Lenkrad, Gas-/Bremspedale
3.3.4 CAN/WLAN-Modul (IGW400/CAN)
Die Datenübertragung von dem Leitstand zum Fahrzeug erfolgt über den CAN/WLAN-
Modul (IGW400/CAN) von der Firma SSV-Embedded Systems. Das CAN/WLAN-Modul
wandelt die WLAN-Pakete in CAN um.
Bild 3.6 CAN/WLAN-Modu [SSV1]
49
IGW400/CAN erlaubt, die Daten zwischen den Kommunikationsteilnehmern mit einer
WLAN - Schnittstelle über den TCP/IP Port zu tauschen. Diese Daten können nicht nur von
CAN/WLAN –Modul, sondern auch vom anderen PC sogar PDA’s erfasst werden, die dieses
Profil suporten und die notwendige Schnittstelle haben.
Die ausführliche Beschreibung von technischen Charakteristiken des Gerätes soll die Ent-
wicklung der Steuerungssoftware unterstützen. Der CAN/WLAN –Modul IGW7400-CAN
integriert typische Messungen und Steuerungen in ein 802.11b/g-kompatiblen WLAN. Dieses
sehr kompakte System ist als kleine, einfache Schnittstelle zu benutzen, die alle möglichen
Datenbestandteile der industriellen Automatisierung sammelt und sie über WLAN überträgt.
Bild 3.7 zeigt das Blockdiagramm des IGW/400-CAN. UART1-Schnittstlle (Universal
Asynchronous Receiver Transmitter) hat eine Beziehung zur WLAN-Einheit über den Level-
Shifter der Sub-D RS232-Schnittstelle.
UART2-Schnitstelle hat eine interne Kommunikation zum Mikrocontroller. Dieses Steue-
rungssystem basiert auf einem ARM7TDMI Mikrocontroller, der 256 KBytes Flash und 16
KBytes SRAM (Static Random Access Memory) Arbeitsspeicher besitzt.
Bild 3.7 Blockdiagramm des CAN-WLAN-Moduls [SSV1]
50
Eigenschaften und technische Daten des CAN-WLAN-Moduls
51
Telemetrieanwendungen nutzen häufig Funkstrecken auf Basis der ISM-Frequenzen
(ISM = Industrial, Scientific, Medical = frei nutzbare HF-Frequenzbereiche).
Die folgende Tabelle 3.4 liefert einen Überblick zu den wichtigsten ISM-Frequenzbereichen
für den deutschsprachigen Raum.
Diese Frequenzen können ohne weitere Anmeldungen und ohne Kosten zur Datenübertragung
und Datenübermittlung verwendet werden. Die maximal zulässigen Sendeleistungen und an-
dere Parameter sind allerdings vorgegeben und müssen eingehalten werden. Weiterhin ist zu
beachten, dass es inzwischen in der Praxis sehr viele ISM-Anwendungen gibt. Da elektro-
magnetische Wellen nicht an Grundstücks- oder Gebäudegrenzen halten, sind Beeinträchti-
gungen durch andere Applikationen an der Tagesordnung. Jeder Anwender muss selbst für die
notwendige Betriebssicherheit sorgen.
Frequenzbereich Typische Anwendung
6,76 MHz – 6,79 MHz Verschiedene Anwendung
13,55 MHz – 13,56 MHz RFID
26,95 MHz – 27,28 MHz Funkfernsteuerung
40,66 MHz – 40,7 MHz Funkfernsteuerung
433,05 MHz – 434,79 MHz Sensoren und Aktoren, Funkfersteuerung
868,00 MHz – 870 MHz Sensoren und Aktoren, Funkfersteuerung
2,40 GHz – 2,50 GHz Bluetooth, WLAN, ZigBee, Video
5,72 GHz – 5,87GHz WLAN
Tabelle 3.4 Übersicht der ISM-Frequenzbereiche [Wal-Emb]
52
Funkübertragung von Daten per 433 MHz, 868 MHz und 2,4 GHz. Die Realisierung der
Funkprotokolle blieb aber bisher weitestgehend dem Anwender überlassen. Als folge davon
findet man unzählige Anwendungen mit anwenderspezifischen Protokollen. Lediglich Blue-
tooth und WLAN (Wireless LANs) gemäß IEEE 802.11- zwei Funkverfahren für ISM-
Frequenzen im Bereich von 2,4 bis 2,5 GHz- bieten vollständig definierte Übertragungsproto-
kolle. Folgende Abbildung zeigt als Beispiel die Protokollbestandteile einer WLAN- Funk-
verbindung gemäß IEEE 802.11. Oberhalb des 802.11- MAC kommen typischerweise
TCP/IP- Protokolle zur Anwendung.
Bild 3.8 Übertragungsprotokoll für WLAN Funkverbindung [SSV1]
53
3.3.5 Aksenboard
Das Aksenboard ist für die Robotik und Embedded-Systeme von der Fachhochschule Bran-
denburg entwickelt worden, die sich sowohl
• im privaten Bereich
• als Forschungs- und Ausbildungsplattform an Hochschulen oder
• auch als Basis für industrielle Anwendungen (Rapid Prototyping von Robotern)
eignet
Herzstück des Systems ist der Mikroprozessor SAB 80C515A. Die Anbindung üblicher Peri-
pherie von Kleinrobotern erfolgt über das Aksenboard.
Bild 3.9 DasAksenboard
Das Aksenboard besteht aus folgenden Komponenten:
• Mikroprozessor SAB 80C515A.
• 64 KB Flash, 8 KB Flash.
• 4 Motortreiber (in Drehzahl und Richtung variierbar).
• 3 Servo-Ausgänge, Sie können durch Software auf maximal 8 Servo-Ausgänge erweitert
werden.
54
• 15 analoge Eingänge. Unterschiedliche Arten von Sensoren, z. B. Sensoren für Abstand,
Infrarot, Licht können angeschlossen werden. Die analogen Eingänge sind mit einem Pull-up-
Widerstand verbunden.
• 16 digitale Ports. Sie können als Ein- bzw. Ausgang konfiguriert werden.
• 4 schaltbare Leistungstreiber, z.B. Infrarotsender, Lämpchen und LED.
• 1 Infrarotausgang mit Leistungstreiber
• 3 Encoder-Eingänge zum Erfassen von Drehzahlen.
• DIP-Schalter (vierfach). Der DIP-Schalter eignet sich gut zur Auswahl von verschiedenen
Programmteilen oder Betriebsarten.
• Zweizeiliges LCD , je 16 Zeichen.
• CAN-Interface 1 Mbit (optional).
• Bluetooth-Verbindung zum PC (optional).
Das Aksenboard ist mit einer seriellen Schnittstelle ausgestattet. Diese Schnittstelle ermög-
licht den Datenaustausch zwischen dem Aksenboard und ein Computer bzw. ein Peripheriege-
rät. Für die Kommunikation zwischen Aksenboard und anderer Hardware besitzt das Aksen-
board ein CAN-Bus.
Die Kommunikation ist paketorientiert. Es kann mit Geschwindigkeiten von bis zu einem
Megabit gesendet werden. Programme für das Aksenboard werden in der Sprache C geschrie-
ben. Um das Aksenboard zu programmieren, werden zwei Programme benötigt. Das ist zum
einen der Compiler, der den Quelltext in für das Board verständlichen Maschinencode über-
setzt und zum anderen der Aksen-Flasher, der diesen Maschinencode auf das Board überträgt.
Die Fachhochschule Brandenburg stellt alle Software und Informationen zur Verfügung, die
zu Programmierung des Aksenboardes benötigt werden [Aks-Bor].
55
3.3.6 Fahrzeug
Für die Durchführung der Arbeit steht ein Modell-Lastfahrzeug der Firma Wedico. zur Verfü-
gung. Der ist im Maßstab 1:16 gebaut. Das Modell-Lastfahrzeug besteht aus einer 3-achsigen
Sattelzugmaschine und einem 2-achsigen Auflieger.
Bild 3.10 Das Fahrzeug
Aus der Bauanleitung [WEDI] kann die Verdrahtung der elektrischen Fahrzeugkomponenten
entnommen werden. Der elektrische Antriebsmotor wirkt über ein 3-Gang-Schaltgetriebe auf
die beiden Hinterachsen der Zugmaschine.
Die Zugmaschine ist außer mit der zum Fahren erforderlichen Elektrik auch mit Beleuchtung
und einem Geräuschgenerator ausgestattet. Diese Funktionen werden von der Fernsteuerung
bedient. Der Blinker für die linke und rechte Seite wird in Abhängigkeit vom Lenkeinschlag
der Vorderräder automatisch geschaltet. Auch die Bremslichter und der Rückfahrscheinwerfer
werden automatisch gesteuert. Der Auflieger ist mit Glühlampen für Blinker, Rücklicht und
Bremslicht ausgestattet. Diese werden durch ein mehradriges Kabel von der Zugmaschine mit
Strom versorgt. Der Fahrmotor, das Schaltgetriebe und die Lenkung können direkt mit dem
Servoport eines Mikrocontrollers verbunden werden. Der Fahrmotor ist mit einem Fahrregler
verbunden. Der Fahrregler versorgt den Fahrmotor mit elektrischer Energie. Dabei wird die
angelegte Spannung an Fahrmotor nicht kontinuierlich sondern stufenweise durch den Fahr-
regler verändert. Diese Abstufungen werden als Fahrstufen bezeichnet. Jeder Fahrstufe wird
eine Nummer [ ]45,40−∈n zugeordnet. Positive Nummern gehören zu Fahrstufen, bei denen
56
das Fahrzeug vorwärts fährt. Zum Rückwärtsfahren werden Fahrstufen mit negativer Nummer
verwendet. Mit der Fahrstufe 0=n wird der Motor ausgeschaltet. Mit steigendem Betrag n
vergrößert sich auch die Spannung an den Fahrregler.
3.3.7 Infrarot-Distanzsensoren
Die Infrarot-Distanzsensoren erfassen einen einzigen Punkt, der sich senkrecht zum Mittel-
punkt zwischen Sender und Empfänger des Sensors befindet. Mit dieser Technik ist die Erfas-
sung der gesamten Umgebung eines Fahrzeugs unmöglich. Trotz dieses Nachteils werden die
Infrarot-Distanzsensoren in vielen Forschungseinrichtungen im Bereich der autonomen Ro-
boter und Fahrzeuge für experimentelle Zwecke eingesetzt. Der Grund dafür ist, dass diese
Sensoren im Vergleich zur Radarsensoren und Sehsystemen sehr günstig sind. Außerdem sind
sie einfach zu bedienen. Sie brauchen wenig Strom, sind nicht rechenintensiv und können an
einem einfachen Controller angeschlossen werden. Abhängig von der Entfernung des erfass-
ten Objekts gibt die Auswertelektronik dieser Sensoren die Spannung Uout als Analogsignal
aus [CONRAD]. Eine Auswertsoftware soll dann aus dem Wert des Ausgangssignals die Ent-
fernung berechnen. Sehr beliebt sind die Infrarot- Distanzsensoren der Firma Sharp. Sie ha-
ben unterschiedliche Reichweiten. Diese Sensoren arbeiten im Nahbereich ziemlich genau
aber im Grenzbereich lässt die Zuverlässigkeit stark nach.
Bild 3.11 Infrarot-Distanzsensor GP2D12 45
57
3.4 Benötigte Standard-Software und Werkzeuge
3.4.1 LabVIEW 6
LabVIEW (Laboratory Virtual Instrument Engineering Workbench), eine grafische Entwick-
lungsumgebung wurde Anfang der achtziger Jahre von der Firma National Instruments ent-
wickelt, um eine Art Mensch-Maschinen-Kommunikation zu führen.
Diese grafische Entwicklungsumgebung verknüpft zwei bewährte Programmiermethoden mit
einander, den Datenfluss und die strukturierte Programmierung, und integriert sie in eine ein-
zige grafische Programmierumgebung, die alle Elemente einer modernen Benutzeroberfläche
bereitstellt.
Also, LabVIEW ist eine grafische Programmiersprache, die hauptsächlich für messtechnische
Aufgaben eingesetzt wird - von der einfachen Datenerfassung bis zur komplexen Prüfstands-
steuerung. LabVIEW ist auch zur Prozessautomatisierung, Auswertung, Analyse und Doku-
mentation von (Mess-) Daten sehr gut geeignet.
In LabVIEW werden Symbole an Stelle von Textzeilen verwendet, um den Programmablauf
zu erstellen. Im Gegensatz zu textbasierten Programmiersprachen, bei denen die Programm-
ausführung von Anweisungen gesteuert wird, verwendet LabVIEW die sog. Datenflusspro-
grammierung, bei welcher der Fluss der Daten den Programmablauf steuert.
6 Quelle: [LabVIEW]
58
LabVIEW-Programme werden als virtuelle Instrumente, kurz “VIs” bezeichnet, da sie hin-
sichtlich ihres Erscheinungsbilds und ihrer Funktionalität realen Instrumenten wie etwa Oszil-
loskopen oder Multimetern nachempfunden sind. Sie bestehen aus zwei Komponenten: das
Frontpanel enthält die Benutzerschnittstelle, das Blockdiagramm den graphischen Programm-
code siehe Bild 3.12.
Dieser wird von einem Compiler abgearbeitet, dadurch ist die Performance vergleichbar mit
den anderen Hochsprachen. LabVIEW enthält eine umfangreiche Sammlung von Werkzeugen
zur Erfassung, Analyse, Darstellung und Speicherung von Daten sowie zum Debuggen von
Programmcode.
Bild 3.12: Blockdiagramm des LabVIEW Entwicklungssystems
59
Die virtuellen Instrumente, so genannte VIs, dienen beispielsweise zur Darstellung von erfass-
ten Messwerten (z.B.: von Sensoren) oder zur Steuerung einer realen, komplexen Industriean-
lage. Mit entsprechenden LabVIEW-Treibern bzw. offenen VIs werden Mess.- und Steuersig-
nale der I/O-Hardware entlockt. Sie lassen sich zudem über eine schier unendliche Vielfalt an
Funktionen mit den virtuellen Steuer- und Anzeigeelementen beliebig, verdrahtungsorientiert
verknüpfen. Dabei können recht komplexe Hierarchien entstehen.
Zur Erstellung einer Benutzeroberfläche in LabVIEW, des so genannten Frontpanels siehe
Bild 3.13, dienen Bedien- und Anzeigeelemente. Bedienelemente umfassen Drehknöpfe,
Drucktasten, Drehregler und sonstige Eingabeelemente. Zu den Anzeigeelementen zählen z.B.
Graphen oder LEDs. Nach Fertigstellung der Benutzeroberfläche wird mit Hilfe von VIs und
Strukturen der Programmcode zur Steuerung der Objekte auf dem Frontpanel erstellt. Dieser
Code befindet sich im Blockdiagramm.
Bild 3.13: Frontpanel des LabVIEW Entwicklungssystems
60
LabVIEW enthält selbst in der Base-Edition schon eine große Bibliothek an Subroutinen für
die Gerätekommunikation und die Auswertung und Darstellung von Messdaten. Ein Grund-
satz gilt immer: Was es nicht gibt, kann man programmieren, da LabVIEW eine vollwertige
Programmiersprache ist. Und darüber hinaus läßt sich LabVIEW durch DLLs um jede nur
denkbare Funktion erweitern.
• LabVIEW - Base Package - enthält die Entwicklungsumgebung mit den Basis-Routinen und
Werkzeugen
• LabVIEW - Full Development System - Zusätzliche Funktionen zur Analyse und Report
Generation etc.
• LabVIEW - Professional Development System - Zusätzliche Werkzeuge zum Projekt-
Management
Die Anschlüsse wie GPIB-, PXI-, VXI- und seriellen Geräten (USB, RS-232 und RS-485),
Probibus, CAN-Bus aber auch TCP/IP werden von LabVIEW unterstüzt. Darüber hinaus kann
man mit anderen Applikationen über das Internet, über ActiveX und DDE kommunizieren
und auf SQL-Datenbanken zugreifen. Zusätzlich ist es möglich, ActiveX-Objekte in Lab-
VIEW einzubinden und LabVIEW-Code von anderen Umgebungen aufzurufen. Bereits exis-
tierender Code kann in Form einer DLL unter Windows aufgerufen werden oder in einer ge-
meinsam benutzten Bibliothek (Shared Library) unter anderen Plattformen.
Virtuelle Instrumentierung erhöht die Flexibilität, das heisst: Durch die Kombination von
LabVIEW mit Standard-Datenerfassungsgeräten und Hardware zur Steuerung der Messgeräte
kann man virtuelle Instrumente erzeugen und vielfältig nutzen. Während traditionelle Messge-
räte durch die Konzeption des Herstellers begrenzt sind, kann ein virtuelles Instrument als
eine Vielzahl von Instrumenten arbeiten, z. B. als Temperaturmonitor, Voltmeter, Streifen-
schreiber, Digitalisierer oder als Signalanalysator.
Außerdem Virtuelle Instrumentierung spart Zeit und Kosten, indem sie die Möglichkeit bietet,
benutzerdefinierte Systeme in einem Bruchteil der Zeit zu erstellen, die man mit traditionellen
Methoden brauchen würde. In der Entwicklung erhält man seine Antworten schneller und hat
man die Zeit für die sorgfältigeren Tests. Die Qualität steigt bei kürzeren Produktvorlaufzei-
ten.
61
Vorteile
-LabVIEW stellt zahlreiche Bibliotheken zur Kommunikation mit der Hardware (Serielle
Schnittstelle, PCI-Karten etc.) zur Verfügung,
- die LabVIEW-Werkzeuge sind speziell für Anwendungen rund um die Datenaufnahme, -
darstellung und -analyse gedacht.
-LabVIEW erleichtert die Fehlersuche durch die Möglichkeit der Kontrolle einzelner Pro-
grammschritte. Außer den eben genannten Gründen sind noch andere Vorteile anzubringen,
die LabView gegenüber anderen Programmiersprachen bietet:
-LabVIEW stellt standardmäßig eine große Anzahl numerischer Algorithmen (statistische
Algorithmen, Kurvenanpassung) zur Verfügung,
-LabVIEW übernimmt das Speicher-Management bei mehrdimensionalen Matrizen oder bei
der Erzeugung bzw. Vernichtung der Objekte, d.h.: Das Löschen der erzeugte aber nicht mehr
verwendbare Objekte werden nicht wie z.B. in andere Hochsprachen vom Programmierer
übernommen, sondern vom Speichermanagement ( Also kein malloc", calloc" usw.),
-LabVIEW ermöglicht die einfache Darstellung von ein- und zweidimensionalen Graphen,
- viele Hardwareanbieter bieten mittlerweile LabVIEW-Bibliotheken und Demo-VIs an,
- Multitasking und die Kommunikation zwischen den einzelnen VIs ist sehr einfach zu imp-
lementieren, ebenso laufen LabVIEW-Programme sehr gut auf Multiprozessor-Maschinen
(die neue Intel Hyper Thread-CPU eingeschlossen),
-LabVIEW ist plattformunabhängig, d.h. in Windows programmierte VIs lassen sich problem-
los auf Linux oder Solaris übertragen und umgekehrt.
-LabVIEW beinhaltet umfangreiche TCP/IP Funktionen, d.h. es ist ein leichtes, zu verarbei-
tende Aufgaben auf mehrere Rechner in einem Netzwerk zu verteilen
62
Nachteile
- Kleine Änderungen können aufwendige Neustrukturierungen nach sich ziehen, wenn das
Schaffen von Raum auf dem Blockdiagramm durch Verschieben geschieht. Denn dann müs-
sen die Drähte und Symbole oftmals neu geordnet werden, um die Übersichtlichkeit wieder-
herzustellen. Alternativ kann aber auch ein Teil des Codes in ein neues Unterprogramm aus-
gelagert werden.
- Um keinen Drahtwirrwarr zu erzeugen, werden von weniger versierten Nutzern oft vermehrt
Variablen eingeführt, die die Geschwindigkeit herabsetzen und dem Datenflussmodell wider-
sprechen. Erfahrene 'Verdrahter' definieren zusammengesetzte Datentypen, um weniger Dräh-
te verlegen zu müssen.
- Der einfache Einstieg in die LabVIEW-Programmierung verleitet leider dazu, "einfach
drauflos zu programmieren", allerdings kann auch die grafische Programmierung nicht die
ordentliche Planung des Projektes ersetzen.
- Die Signalorientierung führte in früheren Versionen zu einem Polling der Signalquellen und
GUI-Elemente in Schleifen, anstatt zu einem von Ereignissen ausgelösten Signalfluss. Seit
LabVIEW 7 existieren auch sehr weitgehend konfigurierbare Eventstrukturen, die auf Ereig-
nisse aus dem Benutzerinterface und auf Systemereignisse reagieren können. Das vermeidet
beim Pollen verschwendete Rechenzeit und erlaubt sehr effektive Konstrukte, insbesondere
beim Benutzerinterface.
- Ausführbare LabVIEW-Programme können vom Entwicklungssystem zwar erstellt werden,
erfordern jedoch die Installation einer Laufzeitumgebung auf dem Zielsystem (und mögli-
cherweise kostenpflichtige Lizenzen für bestimmte Module). Und man benötigt für jede Ziel-
plattform einen plattformabhängigen und kostenpflichtigen 'Application Builder'.
63
3.4.2 WinCC 7
WinCC steht für Windows Control Center, entwickelt und vermarktet von der Firma Siemens.
Es ist ein Prozessvisualisierungssystem für komplette Bedien- und Beobachtungsfunktionali-
tät auf Standard-PCs Microsoft Windows 2000 / XP und NT.
Mit WinCC lassen sich für jeden Einsatzzweck individuell projektierte Bedienoberflächen
erstellen - zur sicheren Prozessführung und zur Optimierung der gesamten Produktion in den
Fabriken.
Eingesetzt wird WinCC als Prozesssteuerungs-Interface für vielerlei Industrienanwendungen,
seien es, Bedien- oder Beobachtungsanwendungen oder komplexe Leitaufgaben. Besonders in
den Bereichen Kennzeichnungstechnik, Logistik, Automatisierung, Messtechnik, Regelungs-
technik, Steuerungstechnik und Identifikation wird WinCC oft als Warenwirtschaftssystem,
Materialflusssystem auf einem Materialflussrechner und zur Steuerung verschiedenster ande-
rer Abläufe verwendet. Dazu werden in einem Grafikprogramm (s. Bild 3.14) Objekte mit
Variablen und/oder Scripten verknüpft und je nach Zustand oder Wert dargestellt. Es können
zum Beispiel Messwerte visualisiert oder Zustandsmeldungen von Ventilen angezeigt werden.
Gleichzeitig ist es möglich durch Benutzereingaben per Maus oder Tastatur diese Objekte zu
steuern. Weiterhin können Störmeldungen dargestellt werden, wodurch der Bediener in der
Lage ist, schnell auf Störungen zu reagieren. Fehlerfälle wie ein Förderbandstillstand können
so recht schnell erkannt werden. Das System ist sehr flexibel, so dass fast jede Darstellung
und auch fast jede Steuerung möglich ist.
7 Quellen : [WinCC1], [WinCC2]
64
Bild 3.14 WinCC Grafikprogramm
Bei weit über 80.000 Installationen weltweit hat sich WinCC mittlerweile als Industriestan-
dard und Marktführer in Europa etabliert und bildet zudem auch die Basis für andere Leitsys-
teme von Siemens.
In der Wasserwirtschaft wird WinCC zur Bedienung, Steuerung und Überwachung von Trink-
, Brauch-, Betriebs- und Abwasseranlagen eingesetzt. WinCC erfüllt alle Anforderungen, die
an ein modernes Leitsystem auf PC-Basis gestellt werden.
Beispiele:
• Es ist Skalierbar für Einplatz- und Mehrplatzlösungen, bei Bedarf auch redundant
• Es ist Einfach integrierbar in bestehende Anlagen und Anbindung an überlagerte Systeme
durch vielfältige Ankopplungsmöglichkeiten an die unterlagerten Steuerungen
• Es ermöglicht Fernbedienung und –Überwachung durch Einsatz von Web-Technologien
• Es ist jederzeit erweiterbar über Optionen und Add-ons und Standard-Schnittstellen
65
Durch den Einsatz vom Web-Technologie in Verbindung mit Thin-Client-Lösungen hat man
mit WinCC die Möglichkeit, seine Anlage orts- und plattform-unabhängig zu bedienen:
• In der Warte: WinCC als Standard-Leitsystem
• Am Schaltschrank: Bedienung über Clients oder Thin-Clients (Multi Panels oder PC)
• Mobil auf der Anlage: Visualisierung oder Diagnose über PDA
• Von Außenstationen oder von Zuhause: Bedienung und Service über Internet/Intranet
WinCC-Funktionsübersicht:
Zugangsberechtigung
Jedem Benutzer kann im System eine eigene Identität, mit Benutzername, Passwort und Be-
dienberechtigung zugeordnet werden. Mit dieser Identität muss er sich "einloggen", um
Zugriff zum System zu bekommen. Der Identität können unterschiedliche Funktionen für die
Bedienung der Anlage, für verschiedene Bereiche der Anlage oder für die Parametrierung des
Systems zugeordnet werden. Alle Eingriffe in das System können registriert und mit der Iden-
tität des Benutzers gespeichert werden. Über die Option Logon ist eine zentrale, anlagenweite
Benutzerverwaltung möglich, die in das Windows User Management integriert ist.
Historische Daten
WinCC bietet die Möglichkeit der Prozessdatenerfassung und Archivierung mit anschließen-
der Analyse und Präsentation von Messwerten und Ereignissen. Die Archivierung erfolgt ei-
ner hoch performanten Standard-Datenbank (Microsoft SQL Server 2003). Archivierte Daten
können für Berechnungen und Dokumentationen in WinCC oder anderen Programmen be-
nutzt werden. Dazu bietet WinCC eine Fülle von Standard-Zugriffs- und Auswertemöglich-
keiten.
66
Berichte / Protokolle
Berichte/ Protokolle mit übersichtlicher Darstellung der Daten mittels Text und grafischen
Symbolen, Balkendiagrammen oder Kurven können einfach kreiert werden. Berichte/ Proto-
kolle können automatisch nach Zeit oder auch bei bestimmten Ereignissen ausgegeben wer-
den.
Eine Protokollierung kann über das WinCC Add-on erfolgen. Dabei können Mess- und Zähl-
werte, Labordaten, Rechenwerte und Betriebsmeldungen erfasst und archiviert und über Be-
richte protokolliert werden: z.B. 24-Stunden-Bericht, Tages-, -Monats-, -Jahresberichte, Be-
triebstagebuch und Protokolle.
Alarm und Ereignisse
Eine Anlage kann in mehrere Alarmbereiche aufgeteilt werden. Einzelnen Alarmen können
unterschiedliche Prioritäten und Meldeklassen zugeordnet werden. Sie können zu verschiede-
nen Zielen, wie Drucker, Prozessbild, Alarmliste, Personenrufanlage etc. geschickt werden.
Quittierungen von Alarmen können direkt im Prozessbild oder über eine Alarmliste erfolgen.
Es besteht darüber hinaus die Möglichkeit, Alarme an überlagerte Systeme weiterzuleiten und
Quittierungen von dort in Empfang zu nehmen. Es stehen umfangreiche Filter-, Sortier- und
Statistikfunktionen zur Auswertung von Alarmen und Ereignissen zur Verfügung.
Betriebsstundenzähler
Mit Hilfe eines Betriebsstundenzählers können die Laufzeiten von Aggregaten in der Anlage
überwacht werden. Nach einer vorgewählten Zeit erfolgt eine Meldung auf dem Drucker; die-
se wird auch in eine Datenbank geschrieben.
67
Bedienen und Beobachten über das Web
Der WinCC/Web Navigator bietet die Möglichkeit, die Anlage auch über das Internet oder
firmeninterne Intranet zu bedienen und zu beobachten, ohne dass dazu Änderungen am
WinCC-Projekt notwendig sind. Am Web-Client genügt dazu ein Browser (z.B. Microsoft
Internet Explorer). Web-Clients können in die anlagenweite Benutzerverwaltung integriert
werden.
WinCC beseteht aus folgenden Basissystemen:
• Das Bediensystem verwaltet die Benutzeraccounts und Variablen
• Das Grafiksystem stellt durch vorgefertigte Zeichnungen das Visualisierungssystem zu-
sammen.
• Das Meldesystem listet Alarme und Warnungen auf, die auf Wunsch quittierungspflichtig
sind.
• Durch die Archivierung bzw. Protokollierung werden Messwerte abgespeichert und darge-
stellt.
Vorteile
Durch die dreifache Durchgängigkeit in Projektierung/Programmierung, Datenhaltung, Kom-
munikation und die integrierte Diagnose werden die Engineeringskosten einer Automatisie-
rungslösung erheblich gesenkt.
Nachteile
• Beim Anpassen an eine komplexe AT-Architektur sind zusätzliche Werkzeuge nötig
• Viele interessante Funktionen nur mit S7-400 möglich
• Leider nur für große Projekte einsetzbar
68
3.4.3 LabVIEW vs. WinCC
Mit der Berücksichtigung der Vorteile und Nachteile der beiden Standard-Software (s. Kapitel
3.4) bezogen auf das SCADA Steuerungssystem ist WinCC mehr oder minder für Massen-
produktion an den Fabriken bzw. große Projekte konzipiert und nicht so wie LabView für
kleinere Projekte wie dieses sehr gut geeignet. Daher fällt die Entscheidung als Standard-
Software für das SCADA Steuerungssystem LabView einzusetzen.
3.5 Realisierung und Implementation des Systems
Die Realisierung des Systems gliedert sich in mehreren logischen Einheiten, die sich wie
nachfolgend weiter unterteilen. Das Konzept wird nach Untersuchen der vorhandenen Tech-
nologien realisiert und implementiert. (s. Bild 3.15 )
Bild 3.15 Schematische Darstellung der Kommunikationsteilnehmer
69
3.5.1 Leitstand und seine Aufgaben
Es ist die Anforderung an den Leitstand, dass der sich nicht auf dem Fahrzeug, sondern abge-
setzt davon befinden soll. Daraus resultiert dann auch die Forderung nach einer drahtlosen
Anbindung und Kommunikation mit dem Fahrzeug. Der Leitstand realisiert das Mensch-
Maschine-Interface, über das eine Kommunikation stattfindet. Die interne Kommunikation
zwischen Leitstand und dem Fahrzeug basiert auf eine TCP/IP und CAN-Protokoll. Für die
eigentliche Übertragung wird eine Funkverbindung gemäß IEEE 802.11g eingesetzt, da das
auch ein Teil der Anforderung an das System ist.
Bild 3.16 Leitstand des SCADA Steuerungssystem
70
3.5.2 Die Funktionen des Leitstandes sind wie folgt aufgeteilt:
● Einlesen von Steuerinformationen mittels PC-Lenkrad
● Visualisierung der Prozessvariablen
● Auswahl des Fahrmodus (Autonom / Manuell)
● Drahtlose Kommunikation mit dem Fahrzeug
● Verwaltung der Steuerdaten in der Datenbank
Der Leitstand hat die Aufgabe, die Daten (Richtung- und Geschwindigkeit-Soll-Werte) aus
einem PC-Lenkrad zu lesen, sie zu visualisieren und sie mit der Fahr-Modusinformation für
CAN-Frame zum Senden an das Fahrzeug darzustellen. Des Weiteren übernimmt der Leit-
stand die Aufgabe, die aktuell vom Fahrzeug gesendeten Steuerdaten so wie die Sensorwerte
vom Fahrzeug zu visualisieren und sie in eine Datenbank ab zu speichern.
Da die entwickelte Software auf dem Fahrzeug die Möglichkeit bietet, das Fahrzeug manuell
bzw. autonom zu steuern, kann man bei der Bedieneinheit durch einen Fahrmodus-Schalter
die Steuerungsart wählen.
Im Falle, dass das Fahrzeug autonom fahren soll, fährt das Fahrzeug Wand entlang. Im manu-
ellen Fahrmodus kann man das Fahrzeug vom Leitstand aus durch das Lenkrad und die Peda-
len in allen Richtungen steuern.
3.5.3 Prinzipieller Aufbau der Leitstand-Software
Für die Gestaltung der Leitstandsoftware sollte man eigentlich Modelle des Software Engi-
neering anwenden, aber bei der Verwendung der Standard-Software LabVIEW ist man ge-
zwungen mit Schleifen zu arbeiten. Deswegen gestaltet sich die Leitstandsoftware grundsätz-
lich als zwei Endlosschleifen, welche folgend als Flussdiagramm beschrieben wird, siehe Bild
3.17.
71
Bild 3.17 Flussdiagramm der Leitstandschleifen zu Steuerung des Fahrzeuges
72
Nach dem die Leitstandsoftware gestartet worden ist, wird erstmal die Initialisierung der PC-
Lenkrad und Gas/Bremspedalen sowie das Öffnen einer TCP/IP Socket-Schnittstelle stattfin-
den. Durch die Initialisierung der Hardware wird der Software die Hardware bekannt gemacht
und es wird vorbereitet, die Steuerdaten aus der Hardware zu lesen.
Beim Öffnen einer TCP/IP Socket-Schnittstelle wird ein Socket zum Aufbau einer Verbin-
dung vom Client und Server mit Hilfe des OPEN-TCP VI’s erstellt und damit eine Instanz der
Socket-Schnittstelle geschaffen und das Transportprotokoll festgelegt. Wie man aus der Sen-
de-Schleife entnehmen kann, worden nach der Initialisierung der angeschlossenen Hardware
die Daten aus dem PC-Lenkrad und Pedalen eingelesen und in lokale Variablen abgespeichert
bzw. auf dem Leitstand visualisiert. Darauf folgend wird der Fahrmodus berücksichtigt.
Die gelesenen Steuerdaten werden für die Servomotoren in der Sende-Schleife umgerechnet,
um eine Rechenlast für das Aksenboard zu vermeiden, da es mit nur 8 Bit rechnet.
Der Zahlenbereich von Lenkrad und Pedalen ist von -32767 bis 32767, d.h.: von 0 bis -32767
in Links-Richtung und von 0 bis 32767 in Rechts-Richtung. Für die Geschwindigkeit des
Fahrzeuges entspricht 0 dem Stillstand bis 32767 der höchste Geschwindigkeit vorwärts, so
wie bis -32676 rückwärts. Nach der Umrechnung der Steuerdaten wird eine Zahl/Hex-String-
Umwandlung so wie Stringkonkatinierung stattfinden.
Um Daten über TCP zu senden, wird in dieser Schleife TCP-Schreiben -VI verwendet. Der
konkatinierte String wird dann per TCP-Schreiben-VI and den Kommunikationsrechner ge-
sendet. Damit der Puffer des CAN/WLAN-Moduls nicht mit gesendeten Steuerdaten überlas-
tet wird, wiederholt die Sende-Schleife die Prozedur alle 50ms einmal.
Die Empfangs-Schleife funktioniert aus Synchronisationsgründen ebenfalls alle 50 ms wie
die Sende-Schleife. In der Empfangs-Schleife werden die aktuell gesendeten Daten aus dem
Fahrzeug gelesen. Um Daten über TCP zu empfangen werden TCP-Lesen-VI verwendet.
Die durch TCP-Lesen-VI gelesenen Daten werden analysiert, visualisiert und schließlich in
eine Datenbank abgespeichert.
73
3.5.4 Schnittstellenspezifikation für das SCADA System
Die Kommunikation der Daten zwischen den Rechnern soll zum einen über WLAN zwischen
dem Leitstand und dem Kommunikationsserver und zum anderen über den CAN-Bus zum
Aksenboard realisiert werden.
Für sämtliche Nachrichten beider Busse wird die MSB-Byteorder (Most significant byte first)
festgelegt. Alle Nachrichten werden zyklisch versand. Falls keine Informationen über die zu
versendeten Daten bzw. Änderung der Daten vorliegen, so werden auch keine Daten gesendet,
das heißt: es wird im Kommunikationsserver geprüft ob Datenänderungen vorliegen oder
nicht? Diese Überprüfung dient dazu, das CAN-WLAN-Modul nicht mit gleichen Daten zu
überlasten.
Der CAN-Bus wird mit einer Baudrate von 125 kBits/ s betrieben, allerdings die Baudraten-
änderung kann man jeder Zeit vornehmen. Für die Regelungstechnik ist es unerlässlich, dass
wichtige Daten ihren Empfänger innerhalb garantierter Zeiten erreichen. Zu diesem Zweck
wird die Paket-ID des CAN-Standards eingesetzt, um die Zugriffspriorität zu bestimmen. Das
aber kommt bei dieser Kommunikation nicht zustande, da es in diesem Netz nur einen Knoten
gibt. Der Datenteil kann von null bis acht Byte variieren. Die 29 Bit der Paket-ID werden hier
für Priorität und Knoten des Netzes nicht separiert. Wie schon oben erwähnt, ist bei einem
einknotigen Netz die Paket-ID nicht notwendig.
Die anwendungsspezifischen Datenpakete beginnen stets mit dem ASCII Zeichen “T“, gefolgt
von den 29 Bit CAN-ID, dann die Angabe der Datenlänge(0-8)in Byte und anschließend die
Steuerdaten der zugehörigen Prozessvariablen je nach Datenlänge in Hex-Value.
Die Pakete haben somit eine Länge von 12 Byte.
T Paket-ID (29 Bit) Datenlänge (0-8) Nutzdaten (8Byte)
Tabelle 3.5 Aufbau des WLAN-Datenpaketes
74
Aufgaben des JAVA Kommunikationsservers
Da eine direkte TCP/IP Kommunikation zwischen Leitsatnd (LabVIEW) und CAN-WALN-
Modul trotz langer Untersuchungen aus Einstellungsgründen des CAN/WLAN-Moduls nicht
möglich war, wurde ein Kommunikationsrechner unter Verwendung der Programmiersprache
Java implementiert. Er fungiert als eine Brücke zwischen Leitstand und CAN/WLAN-Modul.
Der Kommunikationsserver hat die Aufgabe einerseits eine Verbindung über TCP/IP zu
CAN/WLAN-Modul aufzubauen, sie mit Kanal/Baudrateneinstellungen zu initialisieren und
andererseits die Verbindung ebenfalls über TCP/IP zu LabVIEW zu etablieren. Eine Neben-
läufigkeit der Prozesse wird durch Sende und Empfangs Threads realisiert. Der Kommunika-
tiossrechner besteht aus 2 Threads, Sende- und Empfangs-Thread, die ein reibungsloses Sen-
den und Empfangen der Daten bereitstellen. Zusätzlich noch aus vier While-Schleifen. Die
erste While-Schleife ist für die Kommunikation zwischen LabVEW-Client und Java-Server
zuständig. Die zweite Schleife übernimmt die Aufgabe, die vom LabVIEW-Client empfange-
nen Daten zu analysieren und aus denen nach CAN-Spezifikation ein Paket zusammen zu
bauen. Dieses Paket wird in dieser Schleife zusammen gebaut und besteht aus folgenden
Komponenten:
- „T“, Der Buchstabe T stehet für Transmission. Das CAN/WALN-Modul erwartet den Buch-
staben T am Anfang des Paketes, um Daten von WLAN zu CAN bzw. von CAN zu WLAN
zu übersetzen.
- ID des Pakets mit 29 Bit („Extended CAN-Frame 2.0B“), also zur Identifizierung des
Netzknotens bzw. zu Identifizierung des Nachrichtentyps.
- Datenlänge 0 bis 8 Byte, Angabe der Datenlänge, damit das CAN/WLAN-Modul weiß, wie
viele Daten zum Übersetzen ankommen.
- Daten, eigentliche Nutzdaten, die zur Steuerung des Fahrzeuges bestimmt sind.
Nach dem das CAN-Frame Paket erstellt und zusammen gebaut worden ist, wird es an das
CAN/WLAN-Modul gesendet.
Die dritte Schleife beschäftigt sich ebenfalls mit der Kommunikation zwischen CAN/WLAN-
Modul und Java-Server.
75
Die vierte Schleife hat die Aufgabe, die empfangenen Daten zu analysieren und aus dem
CAN-Frame die Nutzdaten heraus zu fischen und sie danach an den Leitstand(LabVIEW-
Client) zu senden.
3.5.5 Funktionsweise des CAN/WLAN-Moduls
Im Rahmen dieser Bachelorarbeit übernimmt der IGW400/CAN (CAN/WLAN-Modul) die
Datenumsetzung. Mit anderen Worten: Der Datenaustausch zwischen dem Leitstand und dem
Fahrzeug wird über eine WLAN-Verbindung und den CAN-Bus abgewickelt. Die vom
Kommunikationsserver zusammengebauten und vom Sende-Thread gesendeten Pakete kom-
men bei CAN-WLAN-Modul an. Der CAN-WLAN-Modul wandelt die empfangenen
WLAN-Pakete in CAN-Pakete um und sendet sie über den CAN-Bus zum Aksenboard. Das
heißt: das Modul arbeitet wie die oben definierte Schnittstellenspezifikation (siehe Tabelle
3.5).
Darüber hinaus wird aus dem empfangenen String durch den Microkontroller ein CAN-Frame
nach vordefiniertem „Extended“-CAN-Frame zum Übertragen gebildet, und dieser Frame
wird dann auf den CAN-Bus geschickt. In diesem Projekt wird nur der eine Kanal des CAN-
Busses zum Senden und Empfangen benutzt. Allerdings besteht die Möglichkeit, beide Kanä-
le zu verwenden.
3.5.6 CAN-Schnittstelle und Steuerung des Fahrzeuges
Auf dem Aksenboard ist eine CAN-Schnittstelle programmiert, die die CAN-Pakete liest.
Da die CAN-Schnittstelle optional ist, sind die Funktionen zur Ansteuerung des Fahrzeuges in
einer eigenen Datei untergebracht. Um die Funktionen nutzen zu können, müssen die Dateien
can.c und can.h sich im Projektverzeichnis befinden. Die Datei can.c muss kompiliert und
zum Lenkvorgang hinzugefügt werden, während der Header can.h per include-Anweisung in
den Quellcode eingebunden wird.
Die Initialisierung der CAN-Schnittstelle übernimmt die Funktion void CanInit (void) . Die
Konfigurationseinstellungen in dieser Funktion sind in der gut dokumentierten can.c einge-
stellt. Sie können manuell jeder Zeit nach anderen Spezifikationen geändert werden. Die
76
Kommunikation erfolgt über die Funktionen int CanEmpfang (struct CAN_MSG xdata
*CanBotschaft) und int CanSenden (struct CAN_MSG xdata *CanBotschaft), wobei bei-
den ein Zeiger auf die Datenstruktur CAN_MSG übergeben werden muss. Beide Funktionen
geben im Erfolgsfall eine 1 (also TRUE), ansonsten eine 0 (FALLS) aus.
int CanEmpfang (struct CAN_MSG xdata *CanBotschaft); holt eine empfangene CAN-
Botschaft von der CAN-Schnittstelle ab und füllt damit die übergebene CAN_MSG-Struktur.
int CanSenden (struct CAN_MSG xdata *CanBotschaft); sendet die übergebene CanBot-
schaft. [CoArNe]
CAN-ID und die Nutzdaten werden aus der übergebenen CAN_MSG-Struktur ausgelesen und
in verschiedenen Puffern gespeichert. Die Nutzdaten werden dann über Aksenboard durch die
Funktionen void lenk(unsigned int impulebereite) und void fahr(unsigned int geschwin-
digkeit) an die Servomotoren zum Lenken und Steuern des Fahrzeuges weiter geleitet. Inner-
halb der beiden Funktionen void lenk() und void fahr() werden dann die Funktionen ser-
vo(LENK_SERVO, lenkServoWert) und servo(FAHR_SERVO, fahrServoWert) aufgeru-
fen und denen dann die aktuelle Richtung und Geschwindigkeitswerte übergeben. Das Fahr-
zeug reagiert dann der empfangenen Steuerwerte entsprechend.
Aber auch umgekehrt, Daten vom Fahrzeug und die aktuelle Geschwindigkeit, Lenkradstel-
lung oder auch Sensorwerte aus analogen bzw. digitalen Ports werden gelesen und zum Leit-
stand über den CAN-Bus durch die intCanSenden (struct CAN_MSG xdata
*CanBotschaft) Funktion gesendet. Das Aksenboard verwendet wiederum die gleiche Ver-
bindung und den gleichen Paketaufbau, um Steuerinformationen sowie die aktuellen Sensor-
werte an den Leitstand zu senden.
77
Für die autonome Steuerung des Fahrzeugs wird der Teilcode von Herrn Zubaidullah Arsa-
lans Bachelorarbeit verwendet bzw. der Teilcode wird in den Sourcecode zur autonomen
Steuerung des Fahrzeuges integriert [Arsalan].
So bald man am Leitstand den Fahrmodusschalter von manuell auf autonom umschaltet, än-
dert sich die Steuerung des Fahrzeugs von Manuell auf Automatik und das Fahrzeug fährt
dann nach dem vorprogrammierten Programm dann autonom einer Wand entlang weiter.
3.5.7 Implementation und Werkzeuge
Die Realisierung des SCADA-Systems (Leitstand, Kommunikationsrechner, CAN-
Schnittstelle und Fahrzeugsteuerung) erfolgt unter dem Betriebsystem Windows XP und der
Verwendung der grafischen Programmierung LabVIEW, Java und C. Die Visualisierung der
Prozessvariablen beim Leitstand (Fahrzeugrichtung und Fahrzeuggeschwindigkeit), Zusam-
mensetzung der CAN-Frame, so wie TCP/IP Client zum Steuerdaten Senden/Empfangen wird
mit LabVIEW programmiert. Ausschlaggebend für die Verwendung von LabVIEW, statt ei-
ner herkömmlichen Programmierung (z.B. Java oder C) war das Vorhandensein der umfang-
reichen Bibliotheken, die den Programmieraufwand deutlich gering halten.
Die entstehende Anzeige und die Bedienelemente erlauben die Gestaltung einer ansprechen-
den Bedienoberfläche. Hinzu kommt die Unterstützung einer breiten Palette von I/O-Geräten
wie zum Beispiel dem verwendeten PC-Lenkrad. LabVIEW gewinnt seine Stärke jedoch erst
durch die eigene Programmiersprache G, die es einem Programmierer ermöglicht, die erfor-
derlichen Funktionen selbst zu implementieren und ein den eigenen Wünschen entsprechen-
des Programm zu programmieren bzw. zu verwirklichen.
78
Mit der LabVIEW Entwicklungsumgebung lassen sich ausführbare Programme bzw. Dateien,
also das so genannte VI (Visual Instrument) erstellen. Für deren Ausführung ist die Installati-
on der LabVIEW Runtime Engine zwingend erforderlich, die auch Bestandteil der Entwick-
lungsumgebung ist. Es ist zu beachten, dass für die Installation der Runtime Engine die Ad-
ministratorrechte benötigt werden. Im Bild 3.18 abgebildete LabVIEW-Umgebung entpricht
der LabVIEW Version 7.1.
Bild 3.18 Screenshot von der LabVIEW-Entwicklungsumgebung
79
Außerdem beansprucht das SCADA-System eine reibungslose Kommunikation zwischen den
Kommunikationsteilnehmern. Um die Anwendung und damit den Anwender nicht fest an ein
Betriebssystem zu binden, wird als Programmiersprache JAVA (Version1.5.0) für die Imple-
mentation des Kommunikationsservers verwendet. Darüber hinaus ist die Socketschnittstellen
Programmierung unter Java einfacher und im Vergleich zu C nicht so zeitaufwendig. Die Ent-
wicklung findet unter Windows XP statt, als Entwicklungsumgebung bietet sich das freie Ec-
lipse [ECli] siehe Bild 3.19 in der Version 3.1 an.
Bild 3.19 Screenshot von der Eclipse-Entwicklungsumgebung
80
Das Aksenboard ist mit einem CAN-Bus Interface bestückt. Für die Steuerung des Systems
muss diese CAN-Schnittstelle nach CAN-Spezifikation gelesen werden. Das CAN-
Schnittstellen Programm zum Lesen des CAN-Busses, Steuerung der Servomotoren so wie
Lesen der Sensorports und das Senden der Daten an Leitstand wurde unter Verwendung der
Programmiersprache C geschrieben und mithilfe des freien C-Compilers avr-gcc übersetzt. Da
die Entwicklung unter dem Betriebssystem Windows XP stattfindet, kommt die Software-
sammlung WinAVR in der Version 4.1 zum Einsatz. Sie beinhaltet neben dem Compiler und
anderen Tools die Laufzeitbibliotheken [avr-libs] und die zugehörige Dokumentation. Um den
Quellcode zu schreiben, wird der Texteditor ConTEXT [ConTex] in der Version 2.0.5.48
verwendet siehe Bild 3.20.
Bild 3.20 Screenshot vom ConText-Editor
81
3.5.8 Access-Datenbank
Laut der Anforderung an das System, benötigt der Leitstand einen Datenbankzugriff, um die
vom PC-Lenkrad/Gas-Bremspedalen gelesenen Steuerinformationen (Soll-Werte) bzw. aus
dem Fahrzeug gelesenen Steuerinformationen (Ist-Werte) und die Sensorenwerte in die Da-
tenbank abzuspeichern.
Dieser Teil der Realisierung am System, also die Programmierung der Lab-
VIEW/Datenbankschnittstelle wurde aufbauend auf den Voruntersuchungen von Eric Robert
und Maxim Van de Moortele realisiert. [EricMaxim]
Die Datenbank-VI ist an die Leitstandsoftware angepasst. Die empfangenen Telemetrie und
Sensordaten können je nach Datum und Uhrzeit problemlos in die Datenbank abgespeichert
werden. Die zugehörige VI wird im Anhang angehängt. Bild 3.21 stellt einen Auszug aus der
Datenbank dar.
Bild 3.21 Auszug aus der Datenbank
82
4 Zusammenfassung
4.1 Resümee
Ziel dieser Bachelorarbeit war die Bereitstellung einer Kommunikationsschnittstelle zwischen
einem Leitstand und einem autonomen fahrerlosen Transportsystem. Des Weiteren war das
Ziel eine Art Telemetrie bzw. Automatisierung, Überwachung der Prozesse so wie die Ver-
waltung und Abspeicherung der entstandenen Ergebnisse zu realisieren.
Es wurde zuerst auf die theoretischen Grundlagen der zu verwendeten Technologien einge-
gangen und deren Funktionsweise untersucht. Die Analyse der vorhandenen Technologien
führte zur Auswahl von WLAN und LabVIEW.
Anschließend wurde ein Lösungskonzept erstellt. Die für dieses Konzept benötigte Hardware
wurde aufgelistet und deren Funktionsweise dargestellt.
Des Weiteren wurden zwei Standard-Software untersucht und die für das Konzept passende
Software ausgewählt.
Eine reibungslose Kommunikation und der Datenaustausch zwischen den Kommunikations-
teilnehmern sind nach der Anforderung an System im Kapitel 1.2 gegeben.
Mit dem im Rahmen dieser Bachelorarbeit entwickelten Steuerungssystem ist es jetzt möglich
aus einem Leitstand drahtlos ein autonomes fahrerloses Transportsystem zu steuern.
83
4.2 Aussichten und Weiterführung
Es gibt auch weiterführende Möglichkeiten diese Arbeit weiter zu entwickeln. Der nächste
Schritt währe die Realisierung des Systems für mehre autonome Fahrzeuge aus einem Leit-
stand. Also, eine Kommunikation zwischen mehreren Fahrzeugen und somit einen Datenaus-
tausch der Kommunikationsteilnehmer und deren Verwaltung.
Es sind auch mehrere Optimierungsmöglichkeiten im Design des Konzepts denkbar: z.B.
- Eine Datenverschlüsselung auf Grund der Funktechnologie. Dann kann man die gesendeten
Datenpakete je nach Wichtigkeit verschlüsseln.
- Ferner eine Videobildanzeige mittels einer separaten Anwendung durch Web-Browser.
Da LabView ActiveX-Container für die Oberflächengestaltung anbietet, ist es möglich, einen
solchen in die Bedieneinheit zu integrieren und ihn mit dem obligatorischen Internet-Explorer
zu verknüpfen.
84
Literaturverzeichnis
Bücher und Dokumentationen:
[JoGut] IEEE 108.11.x Low-Rate Wireless Personal Area Networks: Enabling Wireless
Sensor Networks
Jose A. Gutierrez, Edgar H. Callaway, Raymond Barrett
ISBN 0-7381-3557-7
[AnHac] Wireless Sensor Network Designs
Anna Hac
ISBN 0-470-86736-1
[WLANBlu] Das große Buch Wireless LAN & Bluetooth
Andreas Lerg & Annette Stolz
ISBN 3-8158-2500-8
[WLABlu] Wireless LANs and Bluetooth
Yang Xiao, Yi Pan
ISBN 1-59454-432-8 (hardcover)
[AnTan] Computernetzwerke
Andrew S. Tanenbaum
4. Auflage, 2003, Pearson Studium
ISBN 3-8273-7046-9
[CANCoAr] CAN Controller Area Networks
Wolfhard Lawrenz(Hrsg) (2000)
ISBN 3-7785-2780-0
[CoArNe] Controller Area Network
Konrad Etschberger
ISBN 3-446-21776-2
85
[LabVIEW] LabVIEW für Studenten
Rahman Jamal, Andere Hagenstedt (2004)
Addison-Wesley München
ISBN 3-8273-7154-6
[GuiKru] Handbuch der Java-Programmierung
Guido Krüger
ISBN 3-8273-2201-4
[WEDI] Wedico 2001 WEDICO: Wedico Bauanleitung Elektrische Anlage,
Art.-Nr. 782. 17.04.2001
[EricMaxim] Praktikumsreport zur Datenbankanbindung PDF
Eric Robert und Maxim Van de Moortele
Juni 2006
[Arsalan] Bachelorarbeit
Zubaidullah Arsalan
Februar 2006
WWW -Referenzen:
[CAN-CIA] CAN, CAN in Automation (CAN-CIA), CAN Specification 2.0, Part B
http://www.can-cia.ru/CAN20B.pdf
(Letzter Zugriff: 10.06.2006)
[Bosch] Firma BOSCH, BOSCH CAN Specification Version 2.0, 1991
http://www.semiconductors.bosch.de/pdf/can2spec.pdf
(Letzter Zugriff: 12.06.2006)
[ShoRan] Short Range Wireless Lecture
http://www.isas.tuwien.ac.at/upload/downl/shortrangewirelessleture
_2005_1.pdf
(Letzter Zugriff: 16.09.2006)
86
[WLABuc] WLAN Buch
http://www.feld-it.de/wlanbuch.pdf
(Letzter Zugriff: 17.09.2006)
[IEEE802.11.x] Specification Wireless LAN Networks
http://standards.ieee.org/getieee802/download/802.15.4-2003.pdf
(Letzter Zugriff: 18.09.2006)
[BlToo] Informationen Bluetooth
http://de.wikipedia.org/wiki/Bluetooth
Letzter Zugriff: 12.08.2006)
[WinCC1] WinCC Version 6 Systembeschreibung
http://www.softguide.de/prog_h/ph_0281.htm
(Letzter Zugriff: 28.09.2006)
[WinCC2] Systembeschreibung
http://www.automation.siemens.com/hmi/html_00/
products/software/wincc/index.htm
(Letzter Zugriff: 29.09.2006)
[ECli] Eclipse und SWT-Bibliothek
http://www.eclipse.org/
(Letzter Zugriff: 12.05.2006)
[ConTex] Labor für Künstliche Intelligenz an der FHB
http://ots.fhbrandenburg.de/index.php
(Letzter Zugriff: 10.06.2006)
[AksBor] Labor für Künstliche Intelligenz an der FHB
http://ots.fhbrandenburg.de/index.php
(Letzter Zugriff: 10.06.2006)
[Conr-05] Infrarot Distanzsensoren
http://www.conrad.de
(Letzter Zugriff: 13.010.2006)
87
[Wal-Emb] Walter, Embedded Internet in der Industrieautomation.
Hüthig Verlag 2004.])
http://www.ssv-embedded.de/ de/igw400-APN1.pdf])
(Letzter Zugriff: 08.06.2006)
[Aks_Bor]. Labor für Künstliche Intelligenz an der FHB
http://ots.fhbrandenburg.de/index.php.
(Letzter Zugriff: 10.06.2006)
[Siemens] Forschung und Innovation
http://w4.siemens.de/FuI/de/archiv/zeitschrift/heft1_00
/artikel10/index.html
(Letzter Zugriff: 19.09.2006)
[SSV1] SSV Embedded Systems Documents
http://www.ssv-comm.de/de/bilderarchiv.htm
(Letzter Zugriff: 10.06.2006)
88
Anhang
Im Anhang befindet sich eine CD-ROM mit folgendem Inhalt:
� Aksenboard_CD � Bachelor_PDF � Datenabnk � Dokumentation_PDF � SCADA_Video � Sourcecode
• Das Verzeichnis Aksenboard_CD enthält die Bibliotheken des Aksen-
Boards, das Handbuch und alle benötigte Programme zum Programmierung
des Aksen-Boards.
• Das Verzeichnis Bachelor_PDF enthält diese Bachelorarbeit im PDF-Format.
• Im Verzeichnis Datenbank befindet sich die Accessdatenbank
• Das Verzeichnis Dokumentation_PDF beinhaltet die elektronische Literatur, die im Rahmen
dieser Arbeit benutzt wurde.
• Im Verzeichnis SCADA_Video befinden sich die Videoaufnahmen, die während des
Tests des autonomen Modell-Fahrzeuges aufgenommen wurde.
• Das Verzeichnis Sourcecode enthält die VI’s des Leitstandes, den Quellcode des Java-
Kommunikationsservers, das Datenbankanbindung VI, den Quellcode des CAN-Interfaces
und den Quellcode der Fahrzeugsteuerung
Versicherung über Selbstständigkeit
Hiermit versichere ich, dass ich die vorliegende Arbeit im Sinne der Prüfungs-ordnung nach §22(4) ohne fremde Hilfe selbstständig verfasst und nur die ange-gebenen Hilfsmittel benutzt habe.
_____________________________________ ____________________________
Ort, Datum Unterschrift
top related