Entwicklung eines Supervisory, Control and Data

Bachelorarbeit
Kamran Yusufi
Entwicklung eines Supervisory, Control And Data
Aquisition Systems (SCADA) für Fahrerlose Autonome Transportsysteme unter Verwendung von
Standard-Software, Funktechnologien und TCP/IPNetzwerken
Fakultät Technik und Informatik
Studiendepartment Informatik
Faculty of Engineering and Computer Science
Department of Computer Science
Kamran Yusufi
Entwicklung eines Supervisory, Control And Data Acquisition Systems (SCADA) für fahrerlose autonome
Transportsysteme unter Verwendung von StandardSoftware, 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, LabVIEW, 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 Steuerinformationen 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 Datenbank abgespeichert. Der Leitstand für das Steuerungssystem wurde unter der Verwendung der grafischen Programmiersprache LabVIEW implementiert. Für eine Implementation 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 unter 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, radio technologies and TCP/IP Networks functionality
Keywords
SCADA, Driverless autonomous transport systems, CAN, WLAN, Bluethooth, LabVIEW, 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 microcontroller Aksenboard is applied, which is developed at the FH-Brandenburg.
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 überhaupt 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 Deutschunterrichtsstunden. 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 Zusammenarbeit 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.
IV
Inhaltsverzeichnis
Danksagung....................................................................................................................... IV
Inhaltsverzeichnis............................................................................................ V
Tabellenverzeichnis...................................................................................... VII
Bilderverzeichnis .........................................................................................VIII
1
Einleitung.................................................................................................... 9
1.1
2
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
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
V
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
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
4
Benötigte Hardware für die Realisierung des Systems ............................................. 46
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
Zusammenfassung.................................................................................... 82
4.1
Resümee ................................................................................................................. 82
4.2
Aussichten und Weiterführung ................................................................................ 83
Literaturverzeichnis....................................................................................... 84
Anhang............................................................................................................ 88
VI
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
VII
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
VIII
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 Weiterreichung 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 Kostenreduzierung und der Erhöhung der Effektivität, ist der Einsatz autonomer Fahrzeuge in der Industrie wichtig, sondern ein weiterer wichtiger Aspekt für die Entwicklung und die Anwendung autonomer Fahrzeug ist das Operieren solcher Fahrzeuge in Umgebungen die für Menschen 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äumung oder Arbeiten in giftiger oder verstrahlter Umgebungen. In der Luft- und Raumfahrttechnik 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 Wahrnehmung der Umwelt werden bei den autonomen Fahrzeugen Sensoren eingesetzt. Dadurch
wird sicheres Navigieren ermöglicht, und gleichzeitig ist durch Aktoren auch eine Manipulation von Objekten möglich.
9
1.1.2 Telemetrie
Die Telemetrie wird seit 1920 für die Nachrichtenübermittlung aus Wetterballonen verwendet. 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 getrennten Stelle. An dieser Empfangsstelle können die Messwerte entweder gesammelt und aufgezeichnet, 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, technischen Daten aus einem bewegten Fahrzeug (Flugzeug, Raumfahrzeug, Rennwagen), bei der
Übermittlung von dezentraler Verkehrsinformation oder auch bei der Übermittlung medizinischer 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 beispielsweise Zustandsdaten von Gasturbinenrotoren oder Reifendrücke von drehenden KfzRädern übermittelt. Häufig werden die Daten an räumlich weit getrennten Messorten aufgenommen 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 geeignete 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 beispielsweise eine Pulsfolge, deren Pulsfrequenz oder Pulsdauer vom Widerstands- oder Kapazitätswert des Fühlers abhängt.
10
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 Zeichenfolge umgesetzt, die anschließend mit geeignet moduliertem Träger telemetriert und empfangsseitig ohne Informationsverluste rekonstruiert werden kann. Hier findet ein Datenverkehr 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. Beispiele 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 Ferndiagnose 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 Produktmanager 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
11
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 Verkehrsmarkt und der dadurch verstärkte Wettbewerb zwingen Transportgewerbe und Hersteller, die Kostensenkung anzustreben. Außerdem müssen sich die Fahrzeug-Hersteller von ihren 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 Autovermietungen 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, kabellos und dynamisch die Sensor-Messwerte an einen Arbeitsplatz senden, sie dort be- und weiter 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.
12
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 Telemetrie Anwendungen sehr relevant
Eine WLAN Netzanbindung kann hier eine ideale Abhilfe schaffen. Zur Unterstützung solcher 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 Telemetrie und Fernwartung darstellt sowie andererseits Überwachung, Steuerung, und Prozessdatenerfassung realisiert.
Detailliertes Szenario einer Steuerung:
Die vom PC-Lenkrad und Pedalen gelesenen Steuerdaten sollen auf dem Leitstand visualisiert, 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 Prozessdaten 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 Technologien, entwickelt werden. Das Konzept soll anschließend implementiert und experimentell
getestet werden.
13
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) Steurungssystems 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 Technologie 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 abgespeichert werden. Die Prozesse sollen dann automatisiert werden
5. Zusätzliches Ziel dieser Arbeit ist noch die Telemetrie-Anwendung eines fahrerlosen autonomen Systems zu entwickeln.
14
2 Theoretische Grundlagen
2.1 Fahrerlose Autonome Transportsysteme
Autonome Fahrzeuge stellen hochkomplexe, dynamische Systeme dar, für deren Verwirklichung die Forschungsergebnisse vieler Wissenschaftszweige zusammengeführt werden müssen. So sind für die Fahrzeugführung - insbesondere bei hohen Geschwindigkeiten - die Methoden der Regelungstechnik und Systemdynamik unverzichtbar. Zur Messung des Fahrzeugzustands und für die Wahrnehmung von Objekten in der Umgebung müssen die Signale unterschiedlichster Sensoren verarbeitet und fusioniert werden. GPS-Sensoren (Global Positioning System), Radar und Echtzeitbildverarbeitung sind nur einige mögliche Informationsquellen 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äsentation, 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 international standardisiert. Viele Halbleiterhersteller unterstützen den Bus in InterfaceBausteinen, Automatisierungstechnik und Mikrocontrollern. Der CAN-Bus stellt eine kostengü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 Teilnehmern, 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, ESALAN, SafetyBUS.
1
Quellen: [CoArNe], [CANCoAr], [Bosch], [CAN-CIA]
15
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" übertragen. Bei der Kommunikation auf dem Bus werden alle Nachrichten gleichzeitig mit entgegengesetztem 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 ausgeschlossen.
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 Interface)
• Sensoren und Aktoren
2.2.1 Übertragungsverfahren
Der CAN-Bus arbeitet nach dem CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance) 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 Einsatz. 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
16
Kfz-Technik das CAN-Bussystem verwendet. Der CAN-Bus arbeitet nach dem "Multi-Master
Prinzip": Mehrere gleichberechtigte Steuergeräte (=Busteilnehmer) sind durch eine topologische Anordnung (siehe 2.2.3 CAN-Bus topologie) miteinander verbunden.
Im Falle von Kupferleitungen arbeitet der CAN-Bus mit Differenzsignalen. Er wird normalerweise 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önnen 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, sondern 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änger) berücksichtigt werden.
Als Busmedium werden nach ISO11898-2 (High-Speed Medium Access Unit) Twisted-PairKabel mit einem Wellenwiderstand von 108...132 Ohm empfohlen.
17
Die maximale Teilnehmeranzahl auf physikalischer Ebene hängt von den verwendeten Bustreiberbausteinen (Transceiver, physikalische Anschaltung an den Bus) ab. Mit gängigen Bausteinen 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änktem 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 Vergleich 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 Informationen passieren müssen, mit der Folge, dass bei einem Ausfall des Zentralrechners keine Informationen 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 gehen. 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 (zwischen CAN_HIGH und CAN_LOW) an dem jeweiligen Ende verwendet werden (Siehe Bild
2.1 CAN-Bus Topologie)
18
CAN-Knoten 1
CAN-Knoten 2
CAN_H
125 Ohm
125 Ohm
CAN_L
CAN-Knoten 3
CAN-Knoten 4
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 Nachricht 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.
19
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 (damit 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 dominante 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 Übertragung 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).
20
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 Teilnehmer
• 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 untenstehende 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 Bitstopfen wird nach fünf gleichpoligen Bits ein komplementäres Bit (sog. Stopfbit) in den logischen Bitstrom eingefügt. Bitstopfen wirkt auf Start of frame (SOF) bis einschließlich Prüfsummenfeld (CRC) von Daten- sowie Remote-Frames und dient der Nachsynchronisation der
Teilnehmer innerhalb eines Frames.
21
RTR (Remote Transmission Request)
Ein gesetztes RTR-Bit kennzeichnet einen Remote-Frame (rezessiv). Mit Hilfe eines Remoteframe 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 Identifier" signalisiert wird. Im Anschluss werden die restlichen 18 Bit des Identifiers und anschließend das eigentliche RTR-Bit gesendet. Das IDE-Bit zählt hierbei logisch zum "Arbitrierungsfeld", wobei das Kontrollfeld aber weiterhin aus 6 Bit besteht.
Die Datenlänge muss entsprechend der zu erwartenden Datenlänge gesetzt werden (Fehlerquelle: Viele Entwickler setzen die Datenlänge = 0 - dies ist falsch; ebenso sind CANController 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 Pegel 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 rezessiv = 1).
Synchronisierung und Zeitquanten: Ein Bit wird in sog. Zeitquanten unterteilt. Sie entsprechen einem Vielfachen des Controllertaktes. In jedem Zeitquantum wird nur einmal abgetastet. 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 Zeitquantum und nicht auf die Flanke.
Sicherung der Daten: Erkennt ein Empfänger eine Fehlerbedingung, sendet er einen ErrorFrame und veranlasst so alle Teilnehmer, den Frame zu verwerfen. Sollten andere Teilnehmer
22
diese Fehlerbedingung nicht erkannt haben, senden sie ihrerseits direkt im Anschluss ein weiteres Error-Frame. Hiermit wird eine weitere Sicherheitsfunktion des CAN Protokolls möglich. Um zu vermeiden, dass einzelne Teilnehmer durch irrtümlich erkannte Fehlerbedingungen dauerhaft den Nachrichtentransport blockieren, enthält jeder Teilnehmer Fehlerzähler.
Diese Zähler erlauben nach den Regeln der Spezifikation, einen fehlerhaft arbeitenden Teilnehmer in zwei Stufen des Betriebszustands vom Bus zu trennen, wenn er wiederholt Fehler
erkennt, welche andere Teilnehmer nicht erkennen oder wiederholt fehlerhafte Frames versendet. 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übertragung 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önnen hinzugefügt oder deren Einbauort in einem CAN-Bus problemlos verändert werden. So
was währe mit einer RS232-Schnittstelle nicht möglich.
23
• 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 Daten enthält:
• Sender-Port
• Empfänger-Port
• Paket-Reihenfolge (Nummer)
• Prüfsumme
• Quittierungsnummer
2
Quelle: [AnTan]
24
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 werden, sofern sie frei sind.
Bild 2.2 Datenübertragung mit OSI Schichten-Modell
25
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 Anwendung oder einem Protokoll zugeordnet. Die feste Zuordnung ermöglicht
eine einfachere Konfiguration durch
den Benutzer. Er kommt so mit dem
Protokoll TCP in Kontakt.
Die Verwaltung dieser Ports übernimmt die Internet Assigned Numbers
Authority (IANA).
Registered Ports
1024 - 49151
Diese Ports sind für Dienste vorgesehen.
Dynamically Allocated
Ports
49152 - 65535
Diese Ports werden dynamisch zugewiesen. 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]
26
IP (Internet Protocol)
Das Internet Protocol, kurz IP, wird im Zusammenhang mit der Protokollfamilie TCP/IP genannt und verwendet. Es hat maßgeblich die Aufgabe, Datenpakete zu adressieren und in einem verbindungslosen paketorientierten Netzwerk zu vermitteln (Routing). Dazu haben alle
Stationen und Endgeräte eine eigene Adresse im Netzwerk. Sie dient nicht nur zur Identifikation, 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 (":") dargestellt. Folgen von Nullen können einmalig durch einen doppelten Doppelpunkt ("::") abgekürzt werden. Da in URLs der Doppelpunkt mit der optionalen Portangabe kollidiert, werden
IPv6-Adressen in eckige Klammern gesetzt.
27
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 basiert, wurde von der Firma Mircosoft unter der Bezeichnung WinSock in das WOSA aufgenommen und wurde damit ein etablierter Standard.
Ein großer Vorteil der Verwendung von Sockets ist ihre Homogenität, d. h. eine Kommunikation ü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 Verwendung 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 Funktionsaufrufes socket() eine Instanz der Socket-Schnittstelle erstellt und das Transportprotokoll festgelegt. 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.
28
Tabelle 2.2 vergleicht eine Socket-Verbindung zwecks Anschaulichkeit mit einem Telefongesprä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]
29
Geschichte
Obwohl WLAN eigentlich erst in den letzten Jahren vermehrt genutzt wird und auch bei Privathaushalten im Kommen ist, hat die Technik von WLAN eine relativ lange Geschichte, vorausgesetzt 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 Patent 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 Universitä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 Funk30
netze aufbauen und strukturieren kann: Je nachdem kommt man zu unterschiedlichen Vorund Nachteilen. Eine Möglichkeit ist zum Beispiel der Peer-to-Peer-Modus. Hier gibt es nämlich keinen Access-Point, sondern das Funknetz besteht nur aus Mitgliedern, die sich selbst
organisieren und untereinander kommunizieren. Dagegen gibt es im so genannten Infrastructure-Modus immer mindestens einen Access-Point, über den die Kommunikation und Organisation läuft. Neben diesen beiden Hauptgruppen gibt es noch weitere Möglichkeiten und technische 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 betrachten und bietet damit eine sehr praktische Funktechnik zur Übertragung von Computerdaten 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 Unterschied 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 Funkwellen wirklich nur durch die Luft gehen, oder ob sie Hindernisse durchdringen müssen.
31
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 Infrastruktur 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 Probleme in jedes System einbinden. Auf bestimmte Protokolle ist man nicht angewiesen. Wireless 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 physikalischer Schicht, bsw. das Wireless LAN mit dem drahtgebundenen Ethernet oder Token Ring.
32
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 Infrarotnetz 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 erweitern.
Die Infrarot-Variante nutzt die Frequenzen von 850 bis 950 Nanometer (Licht). Die verwendete 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 Beeinträ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ühren 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 Funktechniken der unterschiedlichsten Hersteller und Anwendungen, unglücklicherweise auch
Geräte des täglichen Gebrauchs, z. B. Mikrowellenherde und schnurlose Telefone. Die Realisierbarkeit eines Funknetzwerkes nach 802.11 hängt also maßgeblich von der Nutzung ande-
33
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 Frequenzspektrum 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 Sicherungsmaß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 Verbindung quälend langsam oder bricht ganz ab.
34
Standard
802.11
Frequenzbereich 2,4 GHz
802.11b
B802.11b+
802.11a
802.11g
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 Technologien 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 wichtigste 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.
35
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 Empfangsgewinn.
2.3.3 Bluetooth4
Bluetooth
Bluetooth ist eine Lösung zur einfachen Anbindung von Peripheriegeräten (z.B. mobile Endgerä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 (Blauzahn) 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 (Bluetooth Special Interest Group) gefördert und wurde erstmals 1998 vorgestellt. Zusammen mit
Ericsson bilden neun Unternehmen die so genannte Promoter Group, wobei jedoch mittlerweile wesentlich mehr Unternehmen der Interessengruppe angehören.
Bluetooth - Grundlagen
Bluetooth arbeitet im 2,4 GHz ISM-Band (Industrial, Scientific and Medical-Band), das lizenzfrei 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 Sendeklassen. 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 Definition 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-
36
tung von 2,5 mW, einer theoretischen Reichweite von 30 m und einer Netzgröße im NanonetBereich. Die maximale Leistung wird jedoch in der Signalklasse 1 erreicht, mit einer Empfindlichkeit 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 darstellen. Es muss jedoch berücksichtigt werden, dass in den heutigen Bluetooth-Lösungen maximal 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 Arbeits-Frequenzbereich von 2,402 GHz bis 2,480 GHz liegt. Als Zugriffsverfahren wird ein
schnelles Frequenzsprungverfahren, das Frequency Hopping Spread Spectrum (FHSS), verwendet. 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 Übertragung 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übertragungsrate 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 verschiedene 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 maximal 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önnen jedoch bis zu 255 Bluetooth-Geräte als passive Slaves geparkt werden. Diese Geräte kön4
Quellen: [WLABlu], [BlToo], ], [ WLANBlu]
37
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 Piconets.
Bluetooth - Vorteile/Nachteile
Die Bluetooth-Technologie ist eine Bereicherung im PAN-Segment und ermöglicht eine einfache 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 breiten 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 darstellt. Hierzu haben die Industriestandards nach IEEE802.11 eine wesentlich breitere Durchdringung am Markt und eine ausgereiftere Technologie.
38
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
39
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: Funktechnik-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]
40
Die Anforderung an die Übertragungsgeschwindigkeit ist gering. Sendedaten und Steuerkommandos 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 Datensatz. Um sich für die geeignete Technologie zu entscheiden, werden die oben genannten Standards 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 übertragen 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 versorgt. Der Leitstand ist eine Applikation und läuft auf dem Standardrechner mit dem Betriebsystem 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.
41
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 verwendet 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 Technologien 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 Meter 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 Entfernungen 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 Aufwand verbunden ist. Die mit Abstand größte Reichweite mit ca. 200 - 300 Metern direkt zwischen zwei Geräten erreicht WLAN.
42
• Anzahl der Netzwerkteilnehmer
Die Architektur des Bluetooth-Netzwerkes unterteilt sich in zwei Komponenten, dem Picound 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 Piconetzen 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ängerPaar 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 gesehen das Ethernetkabel durch eine Funkverbindung ersetzt. Für das Arbeiten mit dem Computer 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 Teilnehmer angeschlossen werden.
• Energieverbrauch
Bei Betrachtung des Leistungsverbrauchs der beiden Technologien beim Senden und Empfangen 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 untereinander. 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 Energieverbrauch bei den WLAN und Bluetooth).
Technologie
Sendeleistung[mW]
Leistungsaufnahme[mW]
Energieverbrauch
pro Bit[nJ]
Bluetooth(10m)
WLAN
1
280
90
ca. 2000
90
ca. 180
Tabelle 3.1 Energieverbrauch bei WLAN und Bluetooth
43
Anzahl der Netzwerkteilnehmer
Die Anzahl der Knoten ist abhängig von der Art der Anwendung. Die maximale Netzteilnehmer sollte maximal 10 Teilnehmer sein.
• Latenzzeiten
Große Unterschiede bestehen bei den Beitritts- und Anforderungszeiten zwischen den Technologien. Je kürzer die Latenzzeit, desto schneller die Übertragung eines Datenpaketes von
einem Netzwerkteilnehmer zum anderen. Besonders der Zeitaufwand, bis ein BluetoothModul 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
44
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 Geräten auf den Markt. Wireless LAN übertrifft Bluetooth in seiner Reichweite und Übertragungsgeschwindigkeit und kommt deshalb in lokalen Netzwerken zum Einsatz. Bluetooth ist
mit geringen Hardwarekosten, niedrigem Stromverbrauch und Echtzeitfähigkeit in den Bereichen 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
Bis zu 100m – 300m
(mit FEC auch bis zu 100m)
(einige km mit externen Antennen als Richtfunk )
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.
45
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 ausgestattet 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-WLANInterface
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 WindowsBetriebssystems.
46
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-WLANInterface statt. Dieses ist, so wie oben gezeigt, konfiguriert, so dass es sich automatisch mit
dem IGW400/CAN verbindet.
47
3.3.3 PC-Lenkrad
Das Einlesen der Steuerdaten aus dem PC-Lenkrad und Gas/Bremspedalen kann man mit wenig 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/WLANModul (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]
48
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 Entwicklung 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 LevelShifter der Sub-D RS232-Schnittstelle.
UART2-Schnitstelle hat eine interne Kommunikation zum Mikrocontroller. Dieses Steuerungssystem 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]
49
Eigenschaften und technische Daten des CAN-WLAN-Moduls
50
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 andere 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 elektromagnetische Wellen nicht an Grundstücks- oder Gebäudegrenzen halten, sind Beeinträchtigungen 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]
51
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 Bluetooth und WLAN (Wireless LANs) gemäß IEEE 802.11- zwei Funkverfahren für ISMFrequenzen im Bereich von 2,4 bis 2,5 GHz- bieten vollständig definierte Übertragungsprotokolle. Folgende Abbildung zeigt als Beispiel die Protokollbestandteile einer WLAN- Funkverbindung 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]
52
3.3.5 Aksenboard
Das Aksenboard ist für die Robotik und Embedded-Systeme von der Fachhochschule Brandenburg 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 Peripherie 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.
53
• 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-upWiderstand 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öglicht den Datenaustausch zwischen dem Aksenboard und ein Computer bzw. ein Peripheriegerät. Für die Kommunikation zwischen Aksenboard und anderer Hardware besitzt das Aksenboard 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 geschrieben. 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 übersetzt 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].
54
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 Fahrregler verändert. Diese Abstufungen werden als Fahrstufen bezeichnet. Jeder Fahrstufe wird
eine Nummer n ∈ [− 40,45] zugeordnet. Positive Nummern gehören zu Fahrstufen, bei denen
55
das Fahrzeug vorwärts fährt. Zum Rückwärtsfahren werden Fahrstufen mit negativer Nummer
verwendet. Mit der Fahrstufe n = 0 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 Mittelpunkt zwischen Sender und Empfänger des Sensors befindet. Mit dieser Technik ist die Erfassung der gesamten Umgebung eines Fahrzeugs unmöglich. Trotz dieses Nachteils werden die
Infrarot-Distanzsensoren in vielen Forschungseinrichtungen im Bereich der autonomen Roboter 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 erfassten Objekts gibt die Auswertelektronik dieser Sensoren die Spannung Uout als Analogsignal
aus [CONRAD]. Eine Auswertsoftware soll dann aus dem Wert des Ausgangssignals die Entfernung berechnen. Sehr beliebt sind die Infrarot- Distanzsensoren der Firma Sharp. Sie haben 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
56
3.4 Benötigte Standard-Software und Werkzeuge
3.4.1 LabVIEW6
LabVIEW (Laboratory Virtual Instrument Engineering Workbench), eine grafische Entwicklungsumgebung wurde Anfang der achtziger Jahre von der Firma National Instruments entwickelt, 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 einzige 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üfstandssteuerung. LabVIEW ist auch zur Prozessautomatisierung, Auswertung, Analyse und Dokumentation 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 Programmausführung von Anweisungen gesteuert wird, verwendet LabVIEW die sog. Datenflussprogrammierung, bei welcher der Fluss der Daten den Programmablauf steuert.
6
Quelle: [LabVIEW]
57
LabVIEW-Programme werden als virtuelle Instrumente, kurz “VIs” bezeichnet, da sie hinsichtlich ihres Erscheinungsbilds und ihrer Funktionalität realen Instrumenten wie etwa Oszilloskopen oder Multimetern nachempfunden sind. Sie bestehen aus zwei Komponenten: das
Frontpanel enthält die Benutzerschnittstelle, das Blockdiagramm den graphischen Programmcode 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
58
Die virtuellen Instrumente, so genannte VIs, dienen beispielsweise zur Darstellung von erfassten Messwerten (z.B.: von Sensoren) oder zur Steuerung einer realen, komplexen Industrieanlage. Mit entsprechenden LabVIEW-Treibern bzw. offenen VIs werden Mess.- und Steuersignale 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
59
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 Grundsatz 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 ProjektManagement
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 LabVIEW einzubinden und LabVIEW-Code von anderen Umgebungen aufzurufen. Bereits existierender Code kann in Form einer DLL unter Windows aufgerufen werden oder in einer gemeinsam 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 Messgeräte durch die Konzeption des Herstellers begrenzt sind, kann ein virtuelles Instrument als
eine Vielzahl von Instrumenten arbeiten, z. B. als Temperaturmonitor, Voltmeter, Streifenschreiber, 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 Produktvorlaufzeiten.
60
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 Programmschritte. 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 implementieren, 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 problemlos auf Linux oder Solaris übertragen und umgekehrt.
-LabVIEW beinhaltet umfangreiche TCP/IP Funktionen, d.h. es ist ein leichtes, zu verarbeitende Aufgaben auf mehrere Rechner in einem Netzwerk zu verteilen
61
Nachteile
- Kleine Änderungen können aufwendige Neustrukturierungen nach sich ziehen, wenn das
Schaffen von Raum auf dem Blockdiagramm durch Verschieben geschieht. Denn dann müssen die Drähte und Symbole oftmals neu geordnet werden, um die Übersichtlichkeit wiederherzustellen. Alternativ kann aber auch ein Teil des Codes in ein neues Unterprogramm ausgelagert werden.
- Um keinen Drahtwirrwarr zu erzeugen, werden von weniger versierten Nutzern oft vermehrt
Variablen eingeführt, die die Geschwindigkeit herabsetzen und dem Datenflussmodell widersprechen. Erfahrene 'Verdrahter' definieren zusammengesetzte Datentypen, um weniger Drähte 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 Ereignisse 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öglicherweise kostenpflichtige Lizenzen für bestimmte Module). Und man benötigt für jede Zielplattform einen plattformabhängigen und kostenpflichtigen 'Application Builder'.
62
3.4.2 WinCC7
WinCC steht für Windows Control Center, entwickelt und vermarktet von der Firma Siemens.
Es ist ein Prozessvisualisierungssystem für komplette Bedien- und Beobachtungsfunktionalitä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, Regelungstechnik, Steuerungstechnik und Identifikation wird WinCC oft als Warenwirtschaftssystem,
Materialflusssystem auf einem Materialflussrechner und zur Steuerung verschiedenster anderer 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]
63
Bild 3.14 WinCC Grafikprogramm
Bei weit über 80.000 Installationen weltweit hat sich WinCC mittlerweile als Industriestandard und Marktführer in Europa etabliert und bildet zudem auch die Basis für andere Leitsysteme 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
64
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 Bedienberechtigung 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 Identitä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ßender Analyse und Präsentation von Messwerten und Ereignissen. Die Archivierung erfolgt einer hoch performanten Standard-Datenbank (Microsoft SQL Server 2003). Archivierte Daten
können für Berechnungen und Dokumentationen in WinCC oder anderen Programmen benutzt werden. Dazu bietet WinCC eine Fülle von Standard-Zugriffs- und Auswertemöglichkeiten.
65
Berichte / Protokolle
Berichte/ Protokolle mit übersichtlicher Darstellung der Daten mittels Text und grafischen
Symbolen, Balkendiagrammen oder Kurven können einfach kreiert werden. Berichte/ Protokolle können automatisch nach Zeit oder auch bei bestimmten Ereignissen ausgegeben werden.
Eine Protokollierung kann über das WinCC Add-on erfolgen. Dabei können Mess- und Zählwerte, Labordaten, Rechenwerte und Betriebsmeldungen erfasst und archiviert und über Berichte protokolliert werden: z.B. 24-Stunden-Bericht, Tages-, -Monats-, -Jahresberichte, Betriebstagebuch 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 verschiedenen 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; diese wird auch in eine Datenbank geschrieben.
66
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 zusammen.
• Das Meldesystem listet Alarme und Warnungen auf, die auf Wunsch quittierungspflichtig
sind.
• Durch die Archivierung bzw. Protokollierung werden Messwerte abgespeichert und dargestellt.
Vorteile
Durch die dreifache Durchgängigkeit in Projektierung/Programmierung, Datenhaltung, Kommunikation und die integrierte Diagnose werden die Engineeringskosten einer Automatisierungslö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
67
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 Massenproduktion 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 StandardSoftware 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 Technologien realisiert und implementiert. (s. Bild 3.15 )
Bild 3.15 Schematische Darstellung der Kommunikationsteilnehmer
68
3.5.1 Leitstand und seine Aufgaben
Es ist die Anforderung an den Leitstand, dass der sich nicht auf dem Fahrzeug, sondern abgesetzt davon befinden soll. Daraus resultiert dann auch die Forderung nach einer drahtlosen
Anbindung und Kommunikation mit dem Fahrzeug. Der Leitstand realisiert das MenschMaschine-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
69
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 Leitstand 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 manuellen Fahrmodus kann man das Fahrzeug vom Leitstand aus durch das Lenkrad und die Pedalen in allen Richtungen steuern.
3.5.3 Prinzipieller Aufbau der Leitstand-Software
Für die Gestaltung der Leitstandsoftware sollte man eigentlich Modelle des Software Engineering anwenden, aber bei der Verwendung der Standard-Software LabVIEW ist man gezwungen mit Schleifen zu arbeiten. Deswegen gestaltet sich die Leitstandsoftware grundsätzlich als zwei Endlosschleifen, welche folgend als Flussdiagramm beschrieben wird, siehe Bild
3.17.
70
Bild 3.17 Flussdiagramm der Leitstandschleifen zu Steuerung des Fahrzeuges
71
Nach dem die Leitstandsoftware gestartet worden ist, wird erstmal die Initialisierung der PCLenkrad und Gas/Bremspedalen sowie das Öffnen einer TCP/IP Socket-Schnittstelle stattfinden. 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 Verbindung 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 Sende-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-StringUmwandlung 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 gesendet. Damit der Puffer des CAN/WLAN-Moduls nicht mit gesendeten Steuerdaten überlastet 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.
72
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
73
Aufgaben des JAVA Kommunikationsservers
Da eine direkte TCP/IP Kommunikation zwischen Leitsatnd (LabVIEW) und CAN-WALNModul 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 Nebenläufigkeit der Prozesse wird durch Sende und Empfangs Threads realisiert. Der Kommunikatiossrechner besteht aus 2 Threads, Sende- und Empfangs-Thread, die ein reibungsloses Senden 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 empfangenen 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 Buchstaben 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/WLANModul und Java-Server.
74
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(LabVIEWClient) 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 kommen 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 CANBusses 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 eingestellt. Sie können manuell jeder Zeit nach anderen Spezifikationen geändert werden. Die
75
Kommunikation erfolgt über die Funktionen int CanEmpfang (struct CAN_MSG xdata
*CanBotschaft) und int CanSenden (struct CAN_MSG xdata *CanBotschaft), wobei beiden 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 CANBotschaft von der CAN-Schnittstelle ab und füllt damit die übergebene CAN_MSG-Struktur.
int CanSenden (struct CAN_MSG xdata *CanBotschaft); sendet die übergebene CanBotschaft. [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. Innerhalb der beiden Funktionen void lenk() und void fahr() werden dann die Funktionen
ser-
vo(LENK_SERVO, lenkServoWert) und servo(FAHR_SERVO, fahrServoWert) aufgerufen und denen dann die aktuelle Richtung und Geschwindigkeitswerte übergeben. Das Fahrzeug reagiert dann der empfangenen Steuerwerte entsprechend.
Aber auch umgekehrt, Daten vom Fahrzeug und die aktuelle Geschwindigkeit, Lenkradstellung oder auch Sensorwerte aus analogen bzw. digitalen Ports werden gelesen und zum Leitstand über den CAN-Bus durch die intCanSenden (struct CAN_MSG xdata
*CanBotschaft) Funktion gesendet. Das Aksenboard verwendet wiederum die gleiche Verbindung und den gleichen Paketaufbau, um Steuerinformationen sowie die aktuellen Sensorwerte an den Leitstand zu senden.
76
Für die autonome Steuerung des Fahrzeugs wird der Teilcode von Herrn Zubaidullah Arsalans 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, ändert 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), Zusammensetzung der CAN-Frame, so wie TCP/IP Client zum Steuerdaten Senden/Empfangen wird
mit LabVIEW programmiert. Ausschlaggebend für die Verwendung von LabVIEW, statt einer herkömmlichen Programmierung (z.B. Java oder C) war das Vorhandensein der umfangreichen Bibliotheken, die den Programmieraufwand deutlich gering halten.
Die entstehende Anzeige und die Bedienelemente erlauben die Gestaltung einer ansprechenden 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 erforderlichen Funktionen selbst zu implementieren und ein den eigenen Wünschen entsprechendes Programm zu programmieren bzw. zu verwirklichen.
77
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 Installation der LabVIEW Runtime Engine zwingend erforderlich, die auch Bestandteil der Entwicklungsumgebung ist. Es ist zu beachten, dass für die Installation der Runtime Engine die Administratorrechte benötigt werden. Im Bild 3.18 abgebildete LabVIEW-Umgebung entpricht
der LabVIEW Version 7.1.
Bild 3.18 Screenshot von der LabVIEW-Entwicklungsumgebung
78
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 Implementation des Kommunikationsservers verwendet. Darüber hinaus ist die Socketschnittstellen
Programmierung unter Java einfacher und im Vergleich zu C nicht so zeitaufwendig. Die Entwicklung findet unter Windows XP statt, als Entwicklungsumgebung bietet sich das freie Eclipse [ECli] siehe Bild 3.19 in der Version 3.1 an.
Bild 3.19 Screenshot von der Eclipse-Entwicklungsumgebung
79
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 CANSchnittstellen 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 Softwaresammlung 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
80
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 Datenbank 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
81
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 Verwaltung und Abspeicherung der entstandenen Ergebnisse zu realisieren.
Es wurde zuerst auf die theoretischen Grundlagen der zu verwendeten Technologien eingegangen 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 Kommunikationsteilnehmern 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.
82
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 Leitstand. Also, eine Kommunikation zwischen mehreren Fahrzeugen und somit einen Datenaustausch 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.
83
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
84
[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)
85
[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)
86
[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)
87
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 AksenBoards, 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 JavaKommunikationsservers, das Datenbankanbindung VI, den Quellcode des CAN-Interfaces
und den Quellcode der Fahrzeugsteuerung
88
Versicherung über Selbstständigkeit
Hiermit versichere ich, dass ich die vorliegende Arbeit im Sinne der Prüfungsordnung nach §22(4) ohne fremde Hilfe selbstständig verfasst und nur die angegebenen Hilfsmittel benutzt habe.
_____________________________________
____________________________
Ort, Datum
Unterschrift