Fakultät Technik und Informatik Faculty of Engineering and Computer Science Studiendepartment Informatik Department of Computer Science

Bachelorarbeit

Kamran Yusufi

Entwicklung eines Supervisory, Control And Data Aquisition Systems (SCADA) für Fahrerlose Auto-

nome Transportsysteme unter Verwendung von Standard-Software, Funktechnologien und TCP/IP-

Netzwerken

Kamran Yusufi

Entwicklung eines Supervisory, Control And Data Ac-quisition Systems (SCADA) für fahrerlose autonome Transportsysteme unter Verwendung von Standard-

Software, Funktechnologien und TCP/IP Netzwerken

Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung im Studiengang Technische Informatik am Studiendepartment Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuender Prüfer: Prof. Dr. rer. nat. Reinhard Baran Zweitgutachter: Prof. Dr. rer. nat. Stefan Pareigis Abgegeben am 11. Dezember 2006

Kamran Yusufi Thema der Bachelorarbeit

Entwicklung eines Supervisory, Control And Data Acquisition Systems (SCADA) für Fahrerlose Autonome Transportsysteme unter Verwendung von Standard-Software, Funktechnologien und TCP/IP Netzwerken

Stichworte

SCADA, Fahrerlose Autonome Transportsysteme, CAN, WLAN, Bluetooth, Lab-VIEW, WinCC, Aksenboard, TCP/IP, Telemetrie

Kurzzusammenfassung

In der vorliegenden Bachelorarbeit wurde ein Steuerungssystem für die drahtlose Steuerung, Überwachung und Prozessdatenerfassung eines fahrerlosen autonomen Systems entwickelt. Das entwickelte Steuerungssystem ist in der Lage die Steuerin-formationen vom Fahrzeug-Leitstand über CAN/WLAN-Modul an das Fahrzeug zu senden und die aktuelle Fahrzeugdaten wie Geschwindigkeit oder Richtungswinkel zu empfangen und diese zurück an den Leitstand zu übertragen. Die gesendeten bzw. empfangenen Steuerinformationen und die Sensormesswerte werden in einer Daten-bank abgespeichert. Der Leitstand für das Steuerungssystem wurde unter der Verwen-dung der grafischen Programmiersprache LabVIEW implementiert. Für eine Imple-mentation der WLAN-Kommunikation zwischen dem CAN/WLAN-Modul und dem Leitstand wurde Programmiersprache Java eingesetzt. Die Fahrzeugsteuerung und das CAN-Bus-Interface sind mit AKSENBOARD der FH-Brandenburg realisiert und un-ter Verwendung der Programmiersprache C implementiert.

Kamran Yusufi Title of the paper

Development of a Supervisory, Control And Data Acquisition Systems (SCADA) for a driverless autonomous transport System under the usage of a standard software, ra-dio technologies and TCP/IP Networks functionality

Keywords

SCADA, Driverless autonomous transport systems, CAN, WLAN, Bluethooth, Lab-VIEW, WinCC, Aksenboard, TCP/IP, Telemetrie

Abstract

This paper presents the development of a Supervisory, Control And Data Acquisition Systems of a driverless autonomous transport vehicle via WLAN and CAN-Bus, which is able to send the controlled information to the vehicle and receive the actual speed, the directions angel of the vehicle and the sensor values of the installed sensors. All these information will save in a Database. The graphical programming language LabVIEW is applied for the control area of this System. Sending and receiving of the controlled information, control of vehicle and CAN-Bus-Interface is implemented in Java and C programming languages, as calculation system for the vehicle, the micro-controller Aksenboard is applied, which is developed at the FH-Brandenburg.

IV

Danksagung

Ohne die Unterstützung einiger Personen hätte ich diese Bachelorarbeit in dieser Art nicht

bewerkstelligen können. Somit nutze ich die Möglichkeit denjenigen, die mich fachlich und

vor allem moralisch tatkräftig unterstützt haben, einen Dank auszusprechen:

Vielen Dank für die kontinuierliche Unterstützung durch die Professoren und Mitarbeiter der

HAW Hamburg, insbesondere ist gemeint:

Professor Reinhard Baran, für die Anregung, Kritik und Ermunterung.

Professor Stefan Pareigis für die Übernahme des Zweitgutachtens.

Die Mitarbeiter aus dem CPT-Labor für die fachliche und materielle Unterstützung.

Der herzlichste Gruß und Dank sei an meine unglaublich tolle Familie gerichtet, besonders an

meine Eltern, die sich immer um mein leibliches Wohlsein gekümmert haben und meinen

großen Bruder Patan, der sich für alle meine Probleme eingesetzt hat.

Ein riesengroßer Dank geht an Wolfgang und Lilo Schnelle, ohne euch wäre das Ganze über-

haupt nicht möglich gewesen. Danke für die moralische und finanzielle Unterstützung.

Besonderer Dank sei an Hella Neddermeyer gerichtet für die unzähligen Deutschunterrichts-

stunden. Ohne Beherrschung der deutschen Sprache währe so ein Studium nicht denkbar.

Ich danke einige meiner Kommilitonen und Freunden, deren Namen hier nicht auftauchen, die

aber mich während meiner Abschlussarbeit unterstützt haben. Danke Jungs, das war für mich

ein sehr spaßiges Studium.

Weiterhin gilt mein Dank Herrn Eric Robert und Maxim Van de Moortele für deren Zusam-

menarbeit zur Realisierung der Datenbankanbindung

Zum Schluss danke ich dem deutschen Volk und dem Steuerzahler für das Ermöglichen dieser

Ausbildung. Das ist ja nicht überall selbstverständlich.

V

Inhaltsverzeichnis

Danksagung....................................................................................................................... IV

Inhaltsverzeichnis............................................................................................ V

Tabellenverzeichnis...................................................................................... VII

Bilderverzeichnis .........................................................................................VIII

1 Einleitung.................................................................................................... 9

1.1 Motivation ................................................................................................................ 9

1.1.1 Autonome Fahrzeuge.......................................................................................... 9

1.1.2 Telemetrie ........................................................................................................ 10

1.1.3 Fernwartung ( Fahrzeuge, die selbstständig die Werkstatt rufen )...................... 11

1.1.4 WLAN ............................................................................................................. 12

1.2 Anforderung an das System..................................................................................... 13

1.3 Zielsetzung ............................................................................................................. 14

2 Theoretische Grundlagen......................................................................... 15

2.1 Fahrerlose Autonome Transportsysteme.................................................................. 15

2.2 CAN-Bus ................................................................................................................ 15

2.2.1 Übertragungsverfahren ..................................................................................... 16

2.2.2 Übertragungsrate und Leitungslänge................................................................. 17

2.2.3 CAN-Bus Topologie......................................................................................... 18

2.2.4 Objektidentifier ................................................................................................ 19

2.2.5 Arbitrierung (Aushandeln des Medienzugriffs), Priorität................................... 20

2.2.6 Frame-Aufbau .................................................................................................. 21

2.2.7 Sampling, Synchronisierung, Sicherung............................................................ 22

2.2.8 Gründe für den Einsatz des CAN-Busses .......................................................... 23

2.3 Kabellose Datenübertragung ................................................................................... 24

2.3.1 TCP/IP Netze.................................................................................................... 24

2.3.2 WLAN IEEE802.11x....................................................................................... 29

2.3.3 Bluetooth.......................................................................................................... 36

VI

3 Realisierung.............................................................................................. 39

3.1 Gesamtkonzept........................................................................................................ 39

3.2 Auswahl der optimalen Funktechnologie................................................................. 40

3.2.1 Grobe Selektion................................................................................................ 42

3.2.2 WLAN und Bluetooth im Vergleich .................................................................42

3.3 Benötigte Hardware für die Realisierung des Systems............................................. 46

3.3.1 Standard PC...................................................................................................... 46

3.3.2 WLAN-Interface............................................................................................... 46

3.3.3 PC-Lenkrad ...................................................................................................... 48

3.3.4 CAN/WLAN-Modul (IGW400/CAN)............................................................... 48

3.3.5 Aksenboard ...................................................................................................... 53

3.3.6 Fahrzeug........................................................................................................... 55

3.3.7 Infrarot-Distanzsensoren................................................................................... 56

3.4 Benötigte Standard-Software und Werkzeuge .........................................................57

3.4.1 LabVIEW ......................................................................................................... 57

3.4.2 WinCC ............................................................................................................. 63

3.4.3 LabVIEW vs. WinCC....................................................................................... 68

3.5 Realisierung und Implementation des Systems ........................................................ 68

3.5.1 Leitstand und seine Aufgaben........................................................................... 69

3.5.2 Die Funktionen des Leitstandes sind wie folgt aufgeteilt:.................................. 70

3.5.3 Prinzipieller Aufbau der Leitstand-Software .....................................................70

3.5.4 Schnittstellenspezifikation für das SCADA System .......................................... 73

3.5.5 Funktionsweise des CAN/WLAN-Moduls ........................................................ 75

3.5.6 CAN-Schnittstelle und Steuerung des Fahrzeuges............................................. 75

3.5.7 Implementation und Werkzeuge ....................................................................... 77

3.5.8 Access-Datenbank ............................................................................................ 81

4 Zusammenfassung.................................................................................... 82

4.1 Resümee ................................................................................................................. 82

4.2 Aussichten und Weiterführung ................................................................................ 83

Literaturverzeichnis....................................................................................... 84

Anhang............................................................................................................ 88

VII

Tabellenverzeichnis

Tabelle 2.1: Portstruktur [AnTan] ........................................................................................ 26 Tabelle 2.2: TCP/IP Kommunikation zwischen Client und Server........................................ 29 Tabelle 2.3: OSI-Schichten-Modell. [AnTan]....................................................................... 33 Tabelle 2.4: Übersicht WLAN nach IEEE 802.11 ................................................................ 35 Tabelle 3.1 Energieverbrauch bei WLAN und Bluetooth...................................................... 43 Tabelle 3.2 Latenzzeiten bei Bluetooth und WLAN ............................................................. 44 Tabelle 3.3 IEEE 802.11 vs. Bluetooth................................................................................. 45 Tabelle 3.4 Übersicht der ISM-Frequenzbereiche [Wal-Emb] ..............................................51 Tabelle 3.5 Aufbau des WLAN-Datenpaketes...................................................................... 73

VIII

Bilderverzeichnis

Bild 2.1: CAN-Bus Topologie.............................................................................................. 19 Bild 2.2 Datenübertragung mit OSI Schichten-Modell ......................................................... 25 Bild 2.3: IEEE 802.11-WLAN im Infrastruktur Mode [SSV1] ............................................. 32 Bild 3.1 Schematisches Konzept der Kommunikationsteilnehmer ........................................ 39 Bild 3.2 Funktechnik-Aktuelle Standards im Vergleich........................................................ 40 Bild 3.3 WLAN USB-Dongle .............................................................................................. 46 Bild 3.4 IP-Adressen-Konfiguration für ein PC-WLAN-Interface ........................................ 47 Bild 3.5 PC-Lenkrad, Gas-/Bremspedale.............................................................................. 48 Bild 3.6 CAN/WLAN-Modu [SSV1] ................................................................................... 48 Bild 3.7 Blockdiagramm des CAN-WLAN-Moduls [SSV1]................................................. 49 Bild 3.8 Übertragungsprotokoll für WLAN Funkverbindung [SSV1] ................................... 52 Bild 3.9 DasAksenboard ...................................................................................................... 53 Bild 3.10 Das Fahrzeug........................................................................................................ 55 Bild 3.11 Infrarot-Distanzsensor GP2D12 45 ...................................................................... 56 Bild 3.12: Blockdiagramm des LabVIEW Entwicklungssystems.......................................... 58 Bild 3.13: Frontpanel des LabVIEW Entwicklungssystems.................................................. 59 Bild 3.14 WinCC Grafikprogramm ...................................................................................... 64 Bild 3.15 Schematische Darstellung der Kommunikationsteilnehmer................................... 68 Bild 3.16 Leitstand des SCADA Steuerungssystem.............................................................. 69 Bild 3.17 Flussdiagramm der Leitstandschleifen zu Steuerung des Fahrzeuges..................... 71 Bild 3.18 Screenshot von der LabVIEW-Entwicklungsumgebung........................................ 78 Bild 3.19 Screenshot von der Eclipse-Entwicklungsumgebung.............................................79 Bild 3.20 Screenshot vom ConText-Editor ........................................................................... 80 Bild 3.21 Auszug aus der Datenbank.................................................................................... 81

9

1 Einleitung

1.1 Motivation

1.1.1 Autonome Fahrzeuge

Autonome Fahrzeuge, fahrerlose Transportsysteme, auch mobile Roboter genannt, stellen in

zunehmendem Umfang wichtige innerbetriebliche Kapazitäten für die Anlieferung und Wei-

terreichung von Rohmaterialien, Zwischen- oder auch Endprodukten zur Verfügung. Die

Fahrzeuge müssen in der Lage sein, bestimmte Betriebsstätten oder Positionen selbständig

anzusteuern, ohne an stationäre Hindernisse (Wände, Maschinen) oder bewegliche Objekte

(Menschen, andere Fahrzeuge) anzustoßen. Dazu bedarf es eines steuerbaren Fahrzeugs, das

die vorgegebenen Wege zurücklegen kann, einer angemessenen Sensorik, die in der Lage ist,

Hindernisse zu erkennen und ausreichend "Intelligenz", um den Hindernissen auszuweichen.

Autonome Fahrzeuge sind intelligente Fahrzeuge, die die ihnen übertragen Aufgaben ohne

menschliche Unterstützung durchführen können.

Die Anwendung solcher autonomer Systeme ist weit reichend. Nicht nur wegen der Kostenre-

duzierung und der Erhöhung der Effektivität, ist der Einsatz autonomer Fahrzeuge in der In-

dustrie wichtig, sondern ein weiterer wichtiger Aspekt für die Entwicklung und die Anwen-

dung autonomer Fahrzeug ist das Operieren solcher Fahrzeuge in Umgebungen die für Men-

schen gefährlich sind. Im militärischen aber auch im zivilen Bereich arbeitet die Forschung

daran solche autonomen Systeme zu entwickeln, die als Erkundungs- oder Bergungsgeräte in

schwer zugänglichen Bereichen eingesetzt werden können. Beispiel dafür sind: Minenräu-

mung oder Arbeiten in giftiger oder verstrahlter Umgebungen. In der Luft- und Raumfahrt-

technik werden autonome Systeme für den Einsatz auf fremden Planeten oder als Hilfsmittel

für Satelliten und Raumstationen entwickelt. Autonome Systeme stehen auch für eine Erhö-

hung der Effektivität und somit für Kostenreduzierung. Deswegen wird auch im industriellen

Bereich die Entwicklung der autonomen Systeme immer mehr vorangetrieben. Zur Wahr-

nehmung der Umwelt werden bei den autonomen Fahrzeugen Sensoren eingesetzt. Dadurch

wird sicheres Navigieren ermöglicht, und gleichzeitig ist durch Aktoren auch eine Manipula-

tion von Objekten möglich.

10

1.1.2 Telemetrie

Die Telemetrie wird seit 1920 für die Nachrichtenübermittlung aus Wetterballonen verwen-

det. Sie erlebte einen großen Aufschwung mit der Entwicklung der Großraketen in den 40er

Jahren. Unter den Begriff Telemetrie (= Fernmessung) versteht man die Übertragung von

Messwerten eines am Messort befindlichen Messfühlers (Sensor) zu einer räumlich getrenn-

ten Stelle. An dieser Empfangsstelle können die Messwerte entweder gesammelt und aufge-

zeichnet, oder auch sofort ausgewertet werden.

Telemetrie wird häufig durch einen Wirkungspfad zum erfassenden Sensor ergänzt, um so auf

gelieferte Messwerte mit geeigneten Maßnahmen reagieren zu können. Dieser Rück-Pfad

wird als Fernsteuerung (Telekommandierung, eng. Tele-Command) bezeichnet.

Eine Telemetrie, bei der Messdaten über größere Entfernungen übertragen werden, wird als

Fernfeldtelemetrie bezeichnet. Dies ist beispielsweise beim Sammeln von Wetterdaten, tech-

nischen Daten aus einem bewegten Fahrzeug (Flugzeug, Raumfahrzeug, Rennwagen), bei der

Übermittlung von dezentraler Verkehrsinformation oder auch bei der Übermittlung medizini-

scher Daten eingesetzter Sonden an die Außenwelt gegeben.

Als Nahfeldtelemetrie bezeichnet man Anwendungen, bei denen Daten über kurze Distanzen

von bewegten Maschinenteilen auf ruhende Empfänger übermittelt werden. So werden bei-

spielsweise Zustandsdaten von Gasturbinenrotoren oder Reifendrücke von drehenden Kfz-

Rädern übermittelt. Häufig werden die Daten an räumlich weit getrennten Messorten aufge-

nommen und per Telemetrie an eine zentrale Stelle gesendet, um dort aufgezeichnet und/oder

ausgewertet zu werden. In der Regel müssen die anfallenden Messwerte zunächst in eine ge-

eignete Form gebracht werden, damit sie telemetriert werden können.

Besondere Aufmerksamkeit erfordert die Übertragung von Gleichspannungssignalen, wie sie

z. B. bei resistiven oder kapazitiven Sensoren anfallen (z.B. Spannungsänderung an einem mit

konstantem Strom durchflossenen, temperaturabhängigen Widerstand).

Durch geeignete Maßnahmen ist eine solche Messpannung in eine Wechselspannung oder in

eine Pulsfolge umzusetzen, damit Versorgungsspannungsänderungen und Temperaturdriften

der Übertragungsbausteine keine Messwertänderung vortäuschen. Dafür geeignet ist bei-

spielsweise eine Pulsfolge, deren Pulsfrequenz oder Pulsdauer vom Widerstands- oder Kapa-

zitätswert des Fühlers abhängt.

11

Die Übertragungsfrequenz des Telemetriesenders kann mit einer solchen Pulsfolge oder auch

mit einem vom Sensor unmittelbar gelieferten Wechselstromsignal moduliert werden.

Im Empfänger wird dieses Signal durch eine geeignete Demodulation zurückgewonnen und

daraus der zugehörige Messwert abgeleitet. Ein bei analogen Messsignalen angewendetes

Verfahren ist beispielsweise ein Pulsformer mit nachgeschaltetem Tiefpassfilter. Heute sind

praktisch nur noch digitale Telemetriesysteme gebräuchlich. Der erfasste Messwert wird vor

Ort mit Hilfe eines Analog-Digital-Wandlers (ADC = A/D-Converter) in eine binäre Zeichen-

folge umgesetzt, die anschließend mit geeignet moduliertem Träger telemetriert und emp-

fangsseitig ohne Informationsverluste rekonstruiert werden kann. Hier findet ein Datenver-

kehr zwischen zwei Stationen statt, bei der die steuernde Messwerte empfangen (downlink)

und die sensortragende die aus den Messwerten abgeleiteten Kommandos befolgen kann

(uplink). Der Sensorträger vor Ort ist dabei mit Aktoren ausgestattet, die von einem Bediener

aus der Ferne aufgrund der gelieferten Sensorinformationen gesteuert werden können. Bei-

spiele hierfür sind Spezialroboter oder mit Kamera und Telemetrie versehene Flugobjekte.

1.1.3 Fernwartung ( Fahrzeuge, die selbstständig die Werkstatt rufen )

Aktuelle Forschungen zeigen, dass in Zukunft nicht nur Industrieanlagen, sondern auch Pkw,

Lkw und Schienenfahrzeuge aus der Ferne gewartet werden können. [Siemens]

Noch gibt es das nicht serienmäßig, aber in nicht allzu ferner Zukunft gehört die Ferndiagno-

se und -Wartung bei Straßen- und Schienenfahrzeugen zum Alltag, davon sind die Forscher

bei Siemens überzeugt. Folgendes Szenario soll eine Telemetrieanwendung darstellen:

Peter Schulz ist gerade unterwegs im Raum Hamburg, als sein Autotelefon klingelt. Der Pro-

duktmanager einer Medizintechnik-Firma nimmt über seine Freisprechanlage das Gespräch

an. Am anderen Ende der Leitung ist ein Mitarbeiter seiner Kfz-Werkstatt. "Ihr Auto hat uns

gemeldet, dass in Kürze die Bremsbeläge an Ihrem Fahrzeug getauscht werden müssen. Au-

ßerdem ist das Motoröl an der Verschleißgrenze, das müsste auch gewechselt werden. Um

Folgeschäden zu vermeiden, sollten Sie beides spätestens nach tausend Kilometern beheben

lassen.", "Ich komme aber erst in fünf Tagen nach Hamburg zurück", entgegnet Schulz. "Kein

Problem", sagt der Kfz-Meister. Er schlägt vor, einen Fachbetrieb in Hannover zu suchen und

den Wagen dort anzumelden. Kurze Zeit später teilt ihm der Automechaniker die Adresse

12

einer Werkstatt in Hannover und einen passenden Termin mit. Peter Schulz fährt beruhigt

weiter.

Die Gründe, eine Fernwartung zu realisieren, sind: Die fortschreitende Globalisierung im Ver-

kehrsmarkt und der dadurch verstärkte Wettbewerb zwingen Transportgewerbe und Herstel-

ler, die Kostensenkung anzustreben. Außerdem müssen sich die Fahrzeug-Hersteller von ih-

ren Mitbewerbern differenzieren. Mit der Ferndiagnose können sie einen verbesserten Service

anbieten und gleichzeitig die Kundenbindung intensivieren. Denn dadurch fallen für den

Fahrer die lästigen Serviceintervalle weg. Der Kunde muss nur dann zur Werkstatt, wenn

wirklich eine Wartung nötig ist. Somit spart auch er Zeit und Geld.

1.1.4 WLAN

Einsatzszenarien für Funknetze gibt es seit über zehn Jahren, bislang vorwiegend für vertikale

Märkte wie Flughäfen, Bahnhöfe, Einkaufszentren, Krankenhäuser, aber auch für Autover-

mietungen oder Restaurants (so genannte Hot Spots).

In vielen anderen industriellen und technischen Bereichen gibt es die Möglichkeiten, solche

Funknetze anzubieten, in denen man wie zum Beispiel von einem beweglichen Objekt, kabel-

los und dynamisch die Sensor-Messwerte an einen Arbeitsplatz senden, sie dort be- und wei-

ter verarbeiten können. Diese Möglichkeiten sind noch nicht annähernd ausgeschöpft.

Überall da, wo mehrere Daten von verschiedenen Komponenten mobil erfasst werden müssen

oder ein sofortiger Zugriff auf hochaktuelle Daten erforderlich ist, erleichtern WLANs

(WLAN eng. Wireless Local Area Network) das Leben und senken Kosten. Die Anwender

merken meist überhaupt nicht, dass sie in einem Funknetz arbeiten.

Die sonst so fehlerträchtige Konfiguration des Netzwerks entfällt, wenn es einmal eingerichtet

ist. Die Mobilität durch WLANs sorgt in Firmen und allen anderen Bereichen jederzeit für

schnellen Zugriff auf aktuelle Informationen, egal wo sich der fahrende Mess-Wagen oder

ein Mitarbeiter gerade befindet - irgendwo auf dem Betriebsgelände, in einem Komplex oder

im eigenen Büro. Das steigert die Produktivität und führt zu kürzeren Reaktionszeiten.

13

Im Rahmen dieser Bachelorarbeit soll diese Technik insbesondere angewendet werden, um

die Mess-Sensoren mobiler zu machen bzw. die Steuerdaten und die Telemetriewerte von

einem mobilen Fahrzeug zu bekommen, und dabei gleichzeitig den Netzkontakt zu halten.

Zudem gewinnt Internet Remote Control immer mehr an Bedeutung - auch hier kann diese

Technik flexiblere Lösungen ermöglichen. In sofern ist eine WLAN-Technologie für Tele-

metrie Anwendungen sehr relevant

Eine WLAN Netzanbindung kann hier eine ideale Abhilfe schaffen. Zur Unterstützung sol-

cher Projekte kann die Anwendung eines WLAN-Netzes wertvolle Hilfe leisten, um größere

Datenmengen problemlos transformieren zu können. Außerdem kann damit der Nutzen eines

solchen Netzes für großflächigere Anwendungen untersucht werden.

1.2 Anforderung an das System

Die grundsätzliche Anforderung an das System ist, dass ein Autonomes Fahrerloses Fahrzeug

kabellos von einem stationären Rechner (Leitstand), manuell bzw. autonom gesteuert wird.

Des Weiteren soll es ein Steuerungssystem entwickelt werden, das einerseits eine Art Tele-

metrie und Fernwartung darstellt sowie andererseits Überwachung, Steuerung, und Prozessda-

tenerfassung realisiert.

Detailliertes Szenario einer Steuerung:

Die vom PC-Lenkrad und Pedalen gelesenen Steuerdaten sollen auf dem Leitstand visuali-

siert, und vom Leitstand aus durch eine Funktechnologie an das Fahrzeug zur Steuerung des

Fahrzeuges gesendet werden. Das Fahrzeug soll dann mit den empfangenen Daten gesteuert

werden und seine aktuellen Steuerdaten bzw. Sensorwerte zurück an den Leitsand senden.

Dies soll ebenfalls über Funktechnologien realisiert werden. Weiterhin sollten die Prozessda-

ten beim Leitstand empfangen, analysiert, visualisiert und zum Schluss in eine Datenbank

abgespeichert werden.

Für dieses Steuerungssystem soll zunächst ein Konzept, basierend auf die vorhandenen Tech-

nologien, entwickelt werden. Das Konzept soll anschließend implementiert und experimentell

getestet werden.

14

1.3 Zielsetzung

In Anbetracht der Anforderung an das System und mit Rückblick auf die Motivation ergeben

sich für diese Bachelorarbeit folgende Ziele:

1. Entwicklung eines SCADA (eng.: Supervisory Control And Data Acquisition) Steurungs-

systems zur drahtlosen Steuerung des fahrerlosen Transportsystem

2. Integration des vorhandenen CAN-WLAN-Moduls (eng. Controller Area Network)in das

entwickelten SCADA Steuerungssystem.

3. Die Kommunikation innerhalb und außerhalb des Systems soll hauptsächlich kabellos über

TCP/IP Netze funktionieren, was wiederum den Einsatz einer leistungseffizienten Technolo-

gie voraussetzt.

4. Die zu Steuerung des Fahrzeuges gesendete und vom Fahrzeug empfangenen Daten sollen

durch eine Standard-Software visualisiert und für Weiterbarbeitung in eine Datenbank abge-

speichert werden. Die Prozesse sollen dann automatisiert werden

5. Zusätzliches Ziel dieser Arbeit ist noch die Telemetrie-Anwendung eines fahrerlosen auto-

nomen Systems zu entwickeln.

15

2 Theoretische Grundlagen

2.1 Fahrerlose Autonome Transportsysteme

Autonome Fahrzeuge stellen hochkomplexe, dynamische Systeme dar, für deren Verwirkli-

chung die Forschungsergebnisse vieler Wissenschaftszweige zusammengeführt werden müs-

sen. So sind für die Fahrzeugführung - insbesondere bei hohen Geschwindigkeiten - die Me-

thoden der Regelungstechnik und Systemdynamik unverzichtbar. Zur Messung des Fahrzeug-

zustands und für die Wahrnehmung von Objekten in der Umgebung müssen die Signale un-

terschiedlichster Sensoren verarbeitet und fusioniert werden. GPS-Sensoren (Global Positio-

ning System), Radar und Echtzeitbildverarbeitung sind nur einige mögliche Informationsquel-

len für ein autonomes Fahrzeug. Mit zunehmender Anzahl von Fähigkeiten des autonomen

Fahrzeugs erhöht sich auch die Notwendigkeit einer flexiblen, effizienten Situationsanalyse

und Verhaltensentscheidung. Hier benötigt man geeignete Methoden zur Wissensrepräsentati-

on, Verhaltensmodellierung und künstlichen Intelligenz.

2.2 CAN-Bus1

Der CAN-Bus, auch CAN Controller Area Network genannt, wurde 1991 von der Firma

Bosch für den Einsatz in Kraftfahrzeugen entwickelt. Das Protokoll ist in der ISO 11898 in-

ternational standardisiert. Viele Halbleiterhersteller unterstützen den Bus in Interface-

Bausteinen, Automatisierungstechnik und Mikrocontrollern. Der CAN-Bus stellt eine kosten-

günstige Alternative zum Kabelbaum zur Verfügung und somit ist der CAN eine preiswerte

Schnittstelle. Das primäre Ziel des CAN-Busses ist die Kommunikation zwischen den Teil-

nehmern, die an diesen Bus angeschlossen sind.

Es gibt mehrere Bussysteme, die auf dem CAN-Bus basieren, die Protokolle aber erweitert

oder vereinfacht haben: CANopen / CANopen-Safety, DeviceNet / DeviceNet Safety, ESA-

LAN, SafetyBUS.

1 Quellen: [CoArNe], [CANCoAr], [Bosch], [CAN-CIA]

16

Der CAN-Bus ist ein serieller Datenbus mit einer Übertragungsrate von bis zu 1.000.000

Bit/s, das entspricht ca. 30 DIN-A4-Seiten. Es handelt sich um eine konsequente Vernetzung

der Fahrzeugelektronik in so genannten CAN-Bus-Systemen. Hier werden die Impulse nicht

mehr über einzelne Kabelstränge, sondern über eine gemeinsame "Datenautobahn" übertra-

gen. Bei der Kommunikation auf dem Bus werden alle Nachrichten gleichzeitig mit entge-

gengesetztem Signal zur Masse über zwei Leitungen gesendet (CAN-Low und CAN-High

Leitung). Dadurch können Störspannungen, die eines der beiden Signale abschwächen oder

verstärken dabei gleichzeitig das andere beeinflussen. So sind Fehlerinformationen nahe aus-

geschlossen.

Typische CAN-Bus Teilnehmer sind:

• Automatisierungsgeräte wie z.B. SPS (Speicherbare Programmier Steuerung)

• Personal Computer

• Ein/Ausgabemodule

• Antriebssteuerung

• Analysegeräte wie z. B. CAN-Monitor

• Bedien und Eingabegeräte als Mensch-Maschinen Interface(HMI, Human Machine Inter-

face)

• Sensoren und Aktoren

2.2.1 Übertragungsverfahren

Der CAN-Bus arbeitet nach dem CSMA/CA (Carrier Sense Multiple Access / Collision A-

voidance) Verfahren (nicht zu verwechseln mit CSMA/CD wie beim Ethernet). Dabei werden

Kollisionen beim Buszugriff durch die Arbitrierung oder Bit-Arbitrierung vermieden (siehe

2.2.5 Arbitrierung). Des Weiteren kommt zur Datensicherung ein CRC-Verfahren zum Ein-

satz. Zur fortlaufenden Synchronisierung der Busteilnehmer wird Bitstopfen (bit stuffing)

verwendet (siehe 2.2.6 Fram Aufbau). Der Bus ist entweder mit Kupferleitungen oder über

Glasfaser ausgeführt. Zur schnellen Datenübertragung zwischen den Steuergeräten wird in der

17

Kfz-Technik das CAN-Bussystem verwendet. Der CAN-Bus arbeitet nach dem "Multi-Master

Prinzip": Mehrere gleichberechtigte Steuergeräte (=Busteilnehmer) sind durch eine topologi-

sche Anordnung (siehe 2.2.3 CAN-Bus topologie) miteinander verbunden.

Im Falle von Kupferleitungen arbeitet der CAN-Bus mit Differenzsignalen. Er wird norma-

lerweise mit 3 Leitungen ausgeführt: CAN_HIGH, CAN_LOW und CAN_GND (Masse).

CAN_LOW enthält den komplementären Pegel von CAN_HIGH gegen Masse. Dadurch kön-

nen Gleichtaktstörungen unterdrückt werden, da ja die Differenz gleich bleibt.

Die Übertragung der Daten erfolgt so, dass ein Bit, je nach dem Zustand, entweder dominant

oder rezessiv auf den Busleitungen wirkt. Ein dominantes überschreibt dabei ein rezessives

Bit.

2.2.2 Übertragungsrate und Leitungslänge

Es wird zwischen einem Highspeed- und einem Lowspeed-Bus unterschieden. Bei einem

Highspeed-Bus beträgt die maximale Datenübertragungsrate 1Mbit/s, bei Lowspeed

125kBit/s. Die maximale (theoretische) Leitungslänge beträgt z.B. bei 1Mbit/s 40m, bei

500kBit/s sind 100m möglich und bei 125kBit/s 500m. Diese Maximalwerte beruhen darauf,

dass die Zeit, die ein Signal am Bus anliegt (Bitzeit, Bit/Sekunde), umso kürzer ist, je höher

die Übertragungsrate ist. Mit zunehmender Leitungslänge steigt jedoch die Zeit, die ein Signal

braucht, bis es am anderen Ende des Busses angekommen ist (Ausbreitungsgeschwindigkeit).

Daher darf die Zeit, die ein Signal am Bus liegt, nicht kürzer sein als die Zeit, die ein Signal

braucht, um sich auszubreiten. Zu beachten ist, dass sich das Signal nicht nur ausbreitet, son-

dern auch innerhalb der Signalzeit der Empfänger auf den Sender reagieren muss .Der Sender

muss wiederum die eventuelle Buspegeländerung des/der Empfänger mitbekommen (siehe

auch Arbitrierung). Deshalb ist die max. Leitungslänge etwas komplexer zu berechnen. Es

müssen Verzögerungszeiten auf der Leitung, des Tranceiver (Sender und Empfänger), des

Controllers (Sender und Empfänger) und der gesetzte Abtastzeitpunkt (Sender und Empfän-

ger) berücksichtigt werden.

Als Busmedium werden nach ISO11898-2 (High-Speed Medium Access Unit) Twisted-Pair-

Kabel mit einem Wellenwiderstand von 108...132 Ohm empfohlen.

18

Die maximale Teilnehmeranzahl auf physikalischer Ebene hängt von den verwendeten Bus-

treiberbausteinen (Transceiver, physikalische Anschaltung an den Bus) ab. Mit gängigen Bau-

steinen sind 32, 64 oder bis zu 110 (mit Einschränkungen bis zu 128) Teilnehmer pro Leitung

möglich (Erweiterungsmöglichkeit über Repeater oder Bridge).

2.2.3 CAN-Bus Topologie

Das CAN-Netzwerk wird als Linienstruktur aufgebaut. Stichleitungen sind in eingeschränk-

tem Umfang zulässig. Des Weiteren sind auch ein ringförmiger Bus (Infotainment Bereich)

sowie ein sternförmiger Bus (Zentralverrieglung) möglich. Beide Varianten haben im Ver-

gleich zum linienförmigen Bus jeweils einen Nachteil:

Im ringförmigen Bus sind alle Steuergeräte in Reihe geschaltet, so dass bei einem Ausfall

eines Steuergeräts der gesamte Bus ausfällt.

Der sternförmige Bus wird meist von einem Zentralrechner gesteuert, da diesen alle Informa-

tionen passieren müssen, mit der Folge, dass bei einem Ausfall des Zentralrechners keine In-

formationen weitergeleitet werden können. Bei einem Ausfall eines einzelnen Steuergeräts

funktioniert der Bus weiter.

Der lineare Bus hat den Vorteil, dass alle Steuergeräte parallel zu einer zentralen Leitung ge-

hen. Nur wenn diese ausfällt, funktioniert der Bus nicht mehr.

Bei einem Highspeed-Bus müssen zusätzlich 2 Abschlusswiderstände von je 120 Ohm (zwi-

schen CAN_HIGH und CAN_LOW) an dem jeweiligen Ende verwendet werden (Siehe Bild

2.1 CAN-Bus Topologie)

19

Bild 2.1: CAN-Bus Topologie

Als Anschlüsse haben sich 9pol.-D-SUB-Steckverbinder durchgesetzt. In Feldgeräten werden

meist 5 Polige M12-Steckverbinder verwendet. Eine Übertragung von Daten und Energie ist

optional vorgesehen.

2.2.4 Objektidentifier

Der Objektidentifier kennzeichnet den Inhalt einer Nachricht, nicht das Gerät. Zum Beispiel

kann in einem Messsystem den Parametern Temperatur, Spannung, Druck jeweils ein eigener

Identifier zugewiesen sein. Die Empfänger entscheiden anhand des Identifiers, ob die Nach-

richt für sie relevant ist oder nicht.

Zudem dient ein Objektidentifier auch einer Priorisierung der Nachrichten.

Die Spezifikation definiert zwei verschiedene Identifier-Formate:

• 11-bit Identifier, auch "Base frame format" genannt. Es können also 2032 Nachrichtentypen

durch den CAN-Bus gesendet werden.

• 29-bit Identifier, auch "Extended frame format" genannt. Damit sind es über 500 Millionen

verschiedene Nachrichtentypen definierbar.

125 Ohm 125 Ohm

CAN_L

CAN_H

CAN-Knoten 1

CAN-Knoten 3

CAN-Knoten 2

CAN-Knoten 4

20

Ein Teilnehmer kann Empfänger und Sender von Nachrichten mit beliebig vielen Identifiern

sein, aber umgekehrt darf es zu einem Identifier immer nur maximal einen Sender geben (da-

mit die Arbitrierung funktioniert).

2.2.5 Arbitrierung (Aushandeln des Medienzugriffs), Priorität

Der Buszugriff wird verlustfrei mittels der bitweisen Arbitrierung auf Basis der Identifier der

zu sendenden Nachrichten aufgelöst. Dazu sensiert jeder Sender den Bus, während er gerade

den Identifier sendet. Senden zwei Teilnehmer gleichzeitig, so überschreibt das erste domi-

nante Bit eines der beiden, das entsprechend rezessive des anderen, welcher dieses erkennt

und seinen Übertragungsversuch beendet, damit der andere seine Daten übertragen kann.

Verwenden beide Teilnehmer den gleichen Identifier wird ein Error-Frame erzeugt (siehe

2.2.6 Frame-Aufbau). Daher empfiehlt der Standard, dass ein Identifier auch nur von maximal

einem Teilnehmer verwendet werden soll.

Durch dieses Verfahren ist auch eine Hierarchie der Nachrichten untereinander gegeben. Die

Nachricht mit dem niedrigsten Identifier darf "immer" übertragen werden. Für die Übertra-

gung von zeitkritischen Nachrichten kann also ein Identifier hoher Priorität (= niedrige ID,

z.B. 0) vergeben werden, um ihnen so Vorrang bei der Übertragung zu gewähren. Dennoch

kann selbst bei hoch priorisierten Botschaften der Sendezeitpunkt zeitlich nicht genau vorher

bestimmt werden (nichtdeterministisches Verhalten).

21

2.2.6 Frame-Aufbau

Es gibt vier verschiedene Arten von Frames:

• Daten-Frame dient dem Transport von bis zu 8 Oktetten Daten

• Remote-Frame dient der Anforderung eines Daten-Frames von einem anderen Teil-

nehmer

• Error-Frame signalisiert allen Teilnehmern eine erkannte Fehlerbedingung in der

Übertragung

• Overload-Frame dient als Zwangspause zwischen Daten- und Remote-Frames

Ein Daten-Frame ist logisch wie folgt aufgebaut:

• Start of Frame (SOF) = ein dominantes bit

• Arbitrierungsfeld bestehend aus einem Identifier-Segment (11 bit oder 29+2 bit)

plus einem RTR bit (Remote Transmission Request, siehe unten )

• Kontrollfeld (CTRL) = 6 bit (2 bit reserviert + 4 bit Länge der Daten)

• Datenfeld (DATA) = 0-64 bit (in Einheiten von 8 bit)

• Prüfsummenfeld (CRC) = 16 bit (15 bit CRC plus einem rezessiven CRC-Delimiter

bit) Bestätigungsfeld (ACK) 2 bit, bestehend aus einem ACK-Slot (siehe untenstehen-

de Erläuterung) plus einem rezessiven ACK-Delimiter

• End of Frame (EOF) 7 bit (rezessiv)

• Intermission (IFS - Intermission Frame Space) = 3 bit (=min. Anzahl der Bits die

aufeinanderfolgende Botschaften trennt)

Bitstopfen (bit stuffing) kann die physikalische Länge eines Frames vergrößern. Beim Bit-

stopfen wird nach fünf gleichpoligen Bits ein komplementäres Bit (sog. Stopfbit) in den logi-

schen Bitstrom eingefügt. Bitstopfen wirkt auf Start of frame (SOF) bis einschließlich Prüf-

summenfeld (CRC) von Daten- sowie Remote-Frames und dient der Nachsynchronisation der

Teilnehmer innerhalb eines Frames.

22

RTR (Remote Transmission Request)

Ein gesetztes RTR-Bit kennzeichnet einen Remote-Frame (rezessiv). Mit Hilfe eines Remo-

teframe kann ein Teilnehmer einen anderen auffordern, seine Daten zu senden.

Im Falle eines "Extended Identifiers" (siehe 2.2.4 Objektidentifier), wird das RTR-Bit durch

das SSR-Bit (Substitute Remote Request) ersetzt und ebenfalls rezessiv gesendet. In diesem

Fall wird das nachfolgende IDE-Bit ebenfalls rezessiv gesendet, wodurch ein "Extended Iden-

tifier" signalisiert wird. Im Anschluss werden die restlichen 18 Bit des Identifiers und an-

schließend das eigentliche RTR-Bit gesendet. Das IDE-Bit zählt hierbei logisch zum "Ar-

bitrierungsfeld", wobei das Kontrollfeld aber weiterhin aus 6 Bit besteht.

Die Datenlänge muss entsprechend der zu erwartenden Datenlänge gesetzt werden (Fehler-

quelle: Viele Entwickler setzen die Datenlänge = 0 - dies ist falsch; ebenso sind CAN-

Controller am Markt, welche RTR-Frames nur mit der Datenlänge 0 senden können). Der

Objectidentifier ist derselbe, wie der der angeforderten Nachricht.

Der Acknowledge-Slot wird verwendet, um den Empfang eines korrekten CAN-Frames zu

quittieren. Jeder Empfänger, der keinen Fehler feststellen konnte, setzt einen dominanten Pe-

gel an der Stelle des ACK-Slots und überschreibt somit den rezessiven Pegel des Senders.

2.2.7 Sampling, Synchronisierung, Sicherung

Sampling: CAN-Controller können den Bus einmal oder dreimal pro Bit abtasten. Beim

3fach-sampling entscheidet die Mehrheit über den aktuellen Zustand (dominant = 0 oder re-

zessiv = 1).

Synchronisierung und Zeitquanten: Ein Bit wird in sog. Zeitquanten unterteilt. Sie entspre-

chen einem Vielfachen des Controllertaktes. In jedem Zeitquantum wird nur einmal abgetas-

tet. Eine Flanke wird erkannt, wenn der Abtastwert vor dem Zeitquantum einen anderen Wert

hat als der Wert danach. Die Nachsynchronisierung synchronisiert somit nur auf ein Zeitquan-

tum und nicht auf die Flanke.

Sicherung der Daten: Erkennt ein Empfänger eine Fehlerbedingung, sendet er einen Error-

Frame und veranlasst so alle Teilnehmer, den Frame zu verwerfen. Sollten andere Teilnehmer

23

diese Fehlerbedingung nicht erkannt haben, senden sie ihrerseits direkt im Anschluss ein wei-

teres Error-Frame. Hiermit wird eine weitere Sicherheitsfunktion des CAN Protokolls mög-

lich. Um zu vermeiden, dass einzelne Teilnehmer durch irrtümlich erkannte Fehlerbedingun-

gen dauerhaft den Nachrichtentransport blockieren, enthält jeder Teilnehmer Fehlerzähler.

Diese Zähler erlauben nach den Regeln der Spezifikation, einen fehlerhaft arbeitenden Teil-

nehmer in zwei Stufen des Betriebszustands vom Bus zu trennen, wenn er wiederholt Fehler

erkennt, welche andere Teilnehmer nicht erkennen oder wiederholt fehlerhafte Frames ver-

sendet. Die Zustände nennen sich error active (normal), error passive (Teilnehmer darf nur

noch passive - das heißt rezessive - Error-Frames senden) und Bus off (Teilnehmer darf nicht

mehr senden).

Der Sender wiederholt nach dem Error-Frame seine Datenübertragung. Auch der Sender kann

durch die zuvor erwähnten Fehlerzähler vom Bus getrennt werden, wenn die Datenübertra-

gung dauerhaft fehlschlägt. Verschiedene Fehlerfälle führen zu einer unterschiedlich großen

Erhöhung des Fehlerzählers.

2.2.8 Gründe für den Einsatz des CAN-Busses

Im Bezug auf das SCADA-Steuerungssystem hat der CAN-Bus folgende Gründe für

seinen Einsatz:

• Bei der Übermittlung der Pakete wird jedem übermittelten Datenpaket eine Prioritätsstufe

zugeordnet. So können wichtige Daten (z. B. Bremsinformationen) wenige wichtige Daten

(wie Richtungsanzeige also Blinklicht) kurzzeitig verdrängen.

• Das Gesamtsystem ist zuverlässig. Es enthält z.B. weniger störanfällige Steckverbindungen.

• Verdrahtung weniger komplex und dadurch kosteneffektiver.

• Die Installation wird einfacher und Veränderung leichter möglich.

• Zusätzliche Elemente (z.B. Steuereinheiten bzw. Aksenboard oder Atmel-Prozessoren) kön-

nen hinzugefügt oder deren Einbauort in einem CAN-Bus problemlos verändert werden. So

was währe mit einer RS232-Schnittstelle nicht möglich.

24

• Die Diagnosefähigkeit des Systems wird entweder erst möglich oder verbessert.

• Es kann beinahe an jeder beliebigen Stelle in das System eingegriffen werden, um Daten

abzulesen und/oder Parameter und evtl. sogar ganze Kennfelder zu ändern.

2.3 Kabellose Datenübertragung

2.3.1 TCP/IP Netze2

TCP (Transmission Control Protocol)

In der TCP/IP-Protokollfamilie übernimmt TCP als verbindungsorientiertes Protokoll die

Aufgabe der Datensicherheit und der Datenflusssteuerung. Es ergreift Maßnahmen bei einem

Datenverlust. Die Funktionsweise von TCP besteht darin, den Datenstrom der Anwendungen

aufzuteilen, mit einem Header zu versehen und an das IP zu übergeben. Beim Empfänger

werden die Datenpakete sortiert und wieder zusammengesetzt.

Jedem Datenpaket, das TCP verschickt, wird ein Header vorangestellt, der die folgenden Da-

ten enthält:

• Sender-Port

• Empfänger-Port

• Paket-Reihenfolge (Nummer)

• Prüfsumme

• Quittierungsnummer

2 Quelle: [AnTan]

25

Datenpakete, die über IP ihr Ziel erreichen, werden von TCP zusammengesetzt und über die

Port-Nummer an eine Anwendung übergeben. Dieser Port wird ständig von einem Prozess,

Dienst oder einer Anwendung abgehört. Die Port-Nummer 1 bis 1024 ist jeweils fest einer

Anwendung oder einem Dienst zugeordnet. Alle anderen Port-Nummern können belegt wer-

den, sofern sie frei sind.

Bild 2.2 Datenübertragung mit OSI Schichten-Modell

26

Durch die Port-Struktur ist es möglich, dass mehrere Anwendungen gleichzeitig über das

Netzwerk Verbindungen zu Kommunikationspartnern aufbauen können.

Well Known Ports 1 - 1023 Diese Ports sind fest einer Anwen-

dung oder einem Protokoll zugeord-

net. Die feste Zuordnung ermöglicht

eine einfachere Konfiguration durch

den Benutzer. Er kommt so mit dem

Protokoll TCP in Kontakt.

Die Verwaltung dieser Ports über-

nimmt die Internet Assigned Numbers

Authority (IANA).

Registered Ports 1024 - 49151 Diese Ports sind für Dienste vorgese-

hen.

Dynamically Allocated

Ports

49152 - 65535 Diese Ports werden dynamisch zuge-

wiesen. Jeder Client kann diese Ports

nutzen. Wenn ein Prozess einen Port

benötigt, fordert er diesen bei seinem

Host an.

Tabelle 2.1: Portstruktur [AnTan]

27

IP (Internet Protocol)

Das Internet Protocol, kurz IP, wird im Zusammenhang mit der Protokollfamilie TCP/IP ge-

nannt und verwendet. Es hat maßgeblich die Aufgabe, Datenpakete zu adressieren und in ei-

nem verbindungslosen paketorientierten Netzwerk zu vermitteln (Routing). Dazu haben alle

Stationen und Endgeräte eine eigene Adresse im Netzwerk. Sie dient nicht nur zur Identifika-

tion, sondern auch zum Erkennen eines Teilnetzes, in dem sich eine Station befindet.

Der Header eines IP-Datenpaketes enthält folgende Einträge:

• IP-Version

• Paketlänge

• Lebenszeit

• Prüfsumme

• Senderadresse

• Empfängeradresse

Die IP-Adresse nach IP Version 4 ist 32 Bit groß/lang. Sie ist in 4 Byte zerlegt und wird durch

Punkte voneinander getrennt (xxx.xxx.xxx.xxx). Jedes Byte kann einen Wert von 0 bis 255

annehmen.

Die IP-Adressen werden in 5 Klassen eingeteilt. In jeder Klasse haben die Netz-ID und die

Host-ID unterschiedliche Gewichtungen. IPv6-Adressen bestehen aus 128 Bit und werden als

Kette von 16-Bit-Zahlen in Hexadezimalform getrennt durch einen Doppelpunkt (":") darge-

stellt. Folgen von Nullen können einmalig durch einen doppelten Doppelpunkt ("::") abge-

kürzt werden. Da in URLs der Doppelpunkt mit der optionalen Portangabe kollidiert, werden

IPv6-Adressen in eckige Klammern gesetzt.

28

Sockets

Die Socket-Schnittstelle dient als standardisierte Programmierschnittstelle zwischen dem

Anwendungsprogramm und TCP/IP. Neben der rechnerübergreifenden Kommunikation von

Prozessen über TCP/IP, wird sie auch zur lokalen Interprozesskommunikation genutzt.

Die Socket-Schnittstelle kommt aus der UNIX-Welt. Mit dem 4.2BSD wurden die Sockets in

UNIX eingeführt. Eine allgemein verfügbare Spezifikation, die auf den UNIX-Sockets ba-

siert, wurde von der Firma Mircosoft unter der Bezeichnung WinSock in das WOSA aufge-

nommen und wurde damit ein etablierter Standard.

Ein großer Vorteil der Verwendung von Sockets ist ihre Homogenität, d. h. eine Kommunika-

tion über Sockets ist unabhängig von dem Standort der Prozesse, dem Betriebssystem, der

Rechnerarchitektur und dem Übertragungsmedium.

Der Aufbau einer TCP/IP Verbindung aus einem Anwenderprogramm wird durch die Ver-

wendung von Sockets sehr einfach. Der Anwendungssoftware stehen die in Tabelle gezeigten

TCP-Systemaufrufe zur Verfügung.

Zum Aufbau einer Verbindung werden vom Client und Server mit Hilfe des Funktionsaufru-

fes socket() eine Instanz der Socket-Schnittstelle erstellt und das Transportprotokoll festge-

legt. Durch den Systemaufruf bind() legt der Server den lokalen Host und den lokalen Port

fest. Damit ist die Adresse festgelegt, auf welcher der Server dem Client antwortet. Nach dem

Aufruf der Funktionen listen() und accept() wartet der Server auf ein connect() des Clients.

Der Client bekommt mit dem connect()-Aufruf implizit eine lokale Adresse zugewiesen und

übergibt sie dem Server. Die Verbindung ist nun aufgebaut und Client und Server können mit

read()- und write()-Funktionen bidirektionalen, byteorientierten Datenaustausch betreiben.

Durch den Systemaufruf close() wird die Verbindung abgebaut.

29

Tabelle 2.2 vergleicht eine Socket-Verbindung zwecks Anschaulichkeit mit einem Telefonge-

spräch.

Prozess 1 Prozess 2 Funktion Analogie

Server Client

socket() socket() Socket erstellen Telefonhörer abheben

write() write() Daten über die Schnittstelle senden Reden

read() read() Daten empfangen Zuhören

close() close() Socket schließen Auflegen

Tabelle 2.2: TCP/IP Kommunikation zwischen Client und Server

2.3.2 WLAN IEEE802.11x3

Motivation

Mögliche Einsatzgebiete der WLAN Technologien sind:

• Drahtloses Surfen, kein Kabelsalat

• Günstige alternative (Ergänzung) zu UMTS und GPRS

• Zufriedenstellende Datenraten für den mobilen Internetnutzer (Multimedia Dienste)

• Schneller Aufbau der Zugangsnetze z.B.(CEBIT Messe)

• Informationszeitalter, Information, Kommunikation, Mobilität besonders wichtig

• Hochschulnetze und öffentliche Hotspots so wie Automatisierungstechnik

• Mitarbeiter oft in Besprechungen und Vorträgen, im Netzwerk- und Rechnerraum

• Abgeschnitten von Informationen, aber aktuelle Informationen notwendig

3 Quelle: [IEEE 802.11.x], [JosGut], [AnHac], [WLABuc], [ShoRan], [ WLANBlu]

30

Geschichte

Obwohl WLAN eigentlich erst in den letzten Jahren vermehrt genutzt wird und auch bei Pri-

vathaushalten im Kommen ist, hat die Technik von WLAN eine relativ lange Geschichte, vor-

ausgesetzt jedenfalls, man fasst die Anfänge des WLAN relativ weit. So betrachtet beginnt die

Geschichte von WLAN bereits in den 1940er Jahren. Damals wurde nämlich bereits ein Pa-

tent für das so benannte "Frequency Hopping" angemeldet. Dahinter verbarg sich die Idee,

einen Torpedo per Funk in ein Ziel zu steuern und dabei so oft die Frequenz zu wechseln,

dass es dem Feind unmöglich wäre den Torpedo vorzeitig abzuschießen. Diese Idee war ihrer

Zeit eindeutig voraus. Noch interessanter und beeindruckender wird das ganze, wenn man

weiß, dass die Idee nicht von einem Techniker oder Militaristen stammt, sondern von einer

österreichischen Schauspielerin und einem Musiker. Die Namen der beiden WLAN-Pioniere -

wenn man so will - waren Hedy Lamarr und George Antheil.

Konkreter kann man aber erst in den 1960er Jahren von den Anfängen des WLAN sprechen.

1969 machte nämlich die Universität von Hawaii einen sehr interessanten Ansatz in Richtung

WLAN. Es wurde ein Funknetzwerk entwickelt, das die verschiedenen Standorte der Univer-

sität verbinden sollte. Dazu muss man wissen, dass die Universität von Hawaii sozusagen auf

verschiedenen Inseln verteilt ist. Das Funknetzwerk sollte also die verschiedenen Bereiche

mit einem Zentralrechner auf der Insel Oahu verbinden, was auch gelang. Das Funknetzwerk

trug den schönen Namen Aloha-Net.

Die Arbeitsgruppe 802 des Institute of Electrical and Electronic Engineers (IEEE) begann

Ende 80er Jahren, sich drahtlosen Netzwerktechnologien zu widmen. Daraus entstand der

heutige Standard IEEE802.11 und somit die Spezifikation für Media Access Control (MAC)

und Physical Leyer(PHY). Das sind Grundsteine aller wirless LAN’s, die am 26. Juni 1997

vom IEEE bestätigt wurden.

Funktion des WLAN’s

Um verstehen zu können wie WLAN funktioniert, muss man sich bei dieser Technik einige

Dinge vor Augen führen.

Für die Technik und das Funktionieren von WLAN ist zunächst einmal der grundsätzliche

Aufbau von Funknetzen wichtig. Es gibt hierbei verschiedene Möglichkeiten, wie man Funk-

31

netze aufbauen und strukturieren kann: Je nachdem kommt man zu unterschiedlichen Vor-

und Nachteilen. Eine Möglichkeit ist zum Beispiel der Peer-to-Peer-Modus. Hier gibt es näm-

lich keinen Access-Point, sondern das Funknetz besteht nur aus Mitgliedern, die sich selbst

organisieren und untereinander kommunizieren. Dagegen gibt es im so genannten Infrastruc-

ture-Modus immer mindestens einen Access-Point, über den die Kommunikation und Organi-

sation läuft. Neben diesen beiden Hauptgruppen gibt es noch weitere Möglichkeiten und tech-

nische Raffinessen, allerdings sind diese hauptsächlich etwas für Experten und spielen bei der

grundsätzlichen Einführung in die WLAN-Technologie keine entscheidende Rolle.

WLAN ist auf jeden Fall zunächst einmal als ein solches Funknetz wie oben erwähnt zu be-

trachten und bietet damit eine sehr praktische Funktechnik zur Übertragung von Computerda-

ten und Ähnlichem an. Der für WLAN verwendete Standard ist der Standard IEEE 802.11

und dessen Nachfolger, denn seit der Entstehung von WLAN wurden die Standards immer

wieder verändert und verbessert.

WLAN ist also ein Computernetzwerk, das praktisch gesehen das Ethernetkabel durch eine

Funkverbindung ersetzt. Für das Arbeiten mit dem Computer bedeutet dies aber keinen Unter-

schied zu einer Verbindung mit einem Ethernetkabel, denn für ein Betriebssystem wie zum

Beispiel Windows und die Programme erscheint es bei einer WLAN-Verbindung so, als ob

der Computer über ein Ethernetkabel angeschlossen wäre.

Da es mittlerweile viele verschiedene Technologien im Bereich WLAN gibt und weil die

Nutzung verschiedener Standards ebenfalls Auswirkungen hat, ist es schwer, allgemeingültig

Aussagen über WLAN zu treffen. Man kann lediglich ein paar Gemeinsamkeiten hervorheben

und natürlich den Unterschied zu kabelgebundenen Netzwerken betonen. Dieser ist folgender:

es existiert bei WLAN keine Verbindung der Netzwerkkarte mit einem Kupferkabel oder

Ähnlichem, sondern die Übertragung erfolgt durch die Luft. Dadurch ergeben sich bei den

meisten WLANs die Probleme mit der Bandbreite, denn alle verfügbaren Sender streiten sich

um die verfügbare Bandbreite. Das andere Problem, das durch die Übertragung durch die Luft

entsteht, ist das Problem mit der Sicherheit, denn die Zugriffe können nur schwer konfiguriert

werden. Zu guter Letzt ist noch zu erwähnen, dass es natürlich eine Rolle spielt, ob die Funk-

wellen wirklich nur durch die Luft gehen, oder ob sie Hindernisse durchdringen müssen.

32

WLANs sind primär als LAN-Kabelersatz für die PC-Vernetzung gedacht.

Ein typisches WLAN ist folgend dargestellt. (Siehe Bild 2.3 IEEE 802.11-WLAN im Infra-

struktur Mode)

Bild 2.3: IEEE 802.11-WLAN im Infrastruktur Mode [SSV1]

Wireless LAN arbeitet auf der Bitübertragungsschicht des OSI-Schichten-Modells. (Siehe

Tabelle 2.3 OSI-Schichten-Modell) Drahtlose Netzwerkkarten lassen sich deshalb ohne Prob-

leme in jedes System einbinden. Auf bestimmte Protokolle ist man nicht angewiesen. Wire-

less LAN ist vollkommen protokolltransparent, wie jedes andere IEEE-802-Netzwerk auch.

Obwohl Wireless LAN protokollunabhängig arbeitet, können sich Probleme in der Praxis mit

einigen Protokollen und Anwendungen ergeben. Ausschlaggebende Faktoren sind die höhere

Bitfehlerrate (Bit Error Rate, BER) und die größere Verzögerung bei der Übertragung von

Daten. Es liegt in der Natur des Wireless LAN, dass die zur Übertragung benötigte Zeit länger

ist als im drahtgebundenen LAN. Ein einfacher Ping hat im drahtgebundenen LAN eine

Round Trip Time von weniger als einer Millisekunde. Im Wireless LAN liegt die Zeit für ein

Ping bei bis zu vier Millisekunden. Anwendungen, die ein kurzes Delay benötigen, haben in

einem Wireless LAN nichts verloren.

Der Access Point (AP) ist innerhalb des Wireless LAN das einzige aktive Schicht-2-Element.

Vergleichbar mit einer Bridge verbindet er zwei Netzwerke mit unterschiedlicher physikali-

scher Schicht, bsw. das Wireless LAN mit dem drahtgebundenen Ethernet oder Token Ring.

33

4 Transport-Schicht (TCP/IP) TCP

3 Netzwerk-Schicht (IP) IP

2 Logical Linck Control 802.2

2 Medium Access Control (MAC) CSMA,VCD

1 Physical Layer (PL) DSSS,FHSS,Infrarot

Tabelle 2.3: OSI-Schichten-Modell. [AnTan]

Der Funknetz-Standard definiert einen gemeinsamen MAC-Layer (Medium Access Control)

für drei spezifische Physical Layer (PL). Zwei davon sind den Funk-LANs, einer dem Infra-

rotnetz zugeordnet.

Im Funknetz wird als Frequenzbereich das ISM-Band (2,4 GHz) von 2,400 bis 2,4835 GHz

genutzt. In diesem Frequenzband stehen 79 Kanäle mit jeweils 1 MHz Bandbreite zu Verfü-

gung. Mindestbandbreite liegt bei einem MBit/s. Optional lässt es sich auch auf 2 MBit/s er-

weitern.

Die Infrarot-Variante nutzt die Frequenzen von 850 bis 950 Nanometer (Licht). Die verwen-

dete diffuse IR-Übertragung erfordert keine exakte Ausrichtung von Sender und Empfänger.

Die maximal 10 Meter weite Sichtlinie sollte trotzdem hindernisfrei sein, um unnötige Beein-

trächtigungen bei der Datenübertragung auszuschließen.

Das ISM-Frequenzband (Industrial, Scientific, Medicine) kann für Anwendungen in Industrie,

Wissenschaft und Medizin frei und ohne Lizenz benutzt werden (Siehe Tabelle 2.2 Übersicht

WLAN nach IEEE 802.11). Das bedeutet, dass auf privatem Grund und Boden keine Gebüh-

ren bezahlt werden müssen. Das ISM-Frequenzband ist weltweit als lizenzfrei anerkannt.

In diesem Frequenzspektrum um 2,4 GHz konkurrieren viele Standards und propritäre Funk-

techniken der unterschiedlichsten Hersteller und Anwendungen, unglücklicherweise auch

Geräte des täglichen Gebrauchs, z. B. Mikrowellenherde und schnurlose Telefone. Die Reali-

sierbarkeit eines Funknetzwerkes nach 802.11 hängt also maßgeblich von der Nutzung ande-

34

rer Produkte in diesem Frequenzspektrum ab. Z. B. nutzen auch Bluetooth-Endgeräte für den

Kurzstreckenfunk dieses Frequenzspektrum. Störungen sind da nicht ausgeschlossen.

Um die Anforderungen an die Datensicherheit zu erfüllen sind im Wireless LAN Standard

bereits Mechanismen dafür integriert. Damit die Funkverbindung weder gestört noch abgehört

werden kann, wird mit dem Bandspreizverfahren das Signal über ein möglichst breites Fre-

quenzspektrum aufgeteilt.

Um den Datenverkehr innerhalb der Funkzelle zu sichern, werden die Daten zwischen den

Stationen mit WEP (Wired Equivalency Privacy) verschlüsselt. Die Nutzdaten werden mittels

des RC4-Algorithmus mit den Key-Längen 40 oder 104 Bit verschlüsselt.

WEP wurde bereits als nicht besonders sicher eingestuft. Unter Umständen sind weitere Si-

cherungsmaßnahmen, wie z. B. VPN mit IPsec oder Protokolle mit SSL notwendig.

Hauptproblem bei Funknetzwerken ist die Abhängigkeit des Datendurchsatzes von der

Reichweite. Die angegebenen Brutto-Übertragungsraten von 1 und 2 MBit in der Sekunde

reduzieren sich in der Praxis auf wenige kBit. Je weiter man sich vom Access Point entfernt,

desto geringer wird auch der Datendurchsatz. Ab einem bestimmten Punkt wird die Verbin-

dung quälend langsam oder bricht ganz ab.

35

Standard 802.11 802.11b B802.11b+ 802.11a 802.11g

Frequenzbereich 2,4 GHz 2,4 GHz 2,4 GHz 5 GHz 2,4 GHz

Datendurchsatz 2 MBit/s 11 MBit/s 22 MBit/s 54 MBit/s 54 MBit/s

Kompatibel zu 802.11b 802.11b+/g 802.11b/g - 802.11b/b+

Übertragungsrate 2,4 GHz 5.2 GHz

1/ 2 IEEE 802.11 -

5,5 / 11 MBit/s IEEE 802.11b -

22/33/44 MBit/s IEEE 802.11b+/PBCC -

6 bis 54 MBit/s IEEE 802.11g IEEE 802.11a/h

Tabelle 2.4: Übersicht WLAN nach IEEE 802.11

Reichweiten von WLAN

Ein Nachteil von WLAN ist immer noch die Reichweite dieser Technologie, die Technolo-

gien wie UMTS und GPRS noch nicht das Wasser reichen kann. Man kann sich mit seinem

Laptop nur eine bestimmte Entfernung zum Access-Point erlauben, denn sonst sind bestimmte

Übertragungsraten nicht mehr möglich beziehungsweise die Verbindung reißt ganz ab.

Die Reichweite von WLAN hängt grundsätzlich von verschiedenen Faktoren ab. Der wich-

tigste ist wohl der des Raumes und der der direkten Umgebung.

Grundsätzlich kann man sagen, dass die Reichweite von WLAN ständig verbessert wird. Die

Reichweite von 802.11a war zum Beispiel im Vergleich zu 802.11b und 802.11g sehr viel

niedriger, was damit zusammenhängt, dass bei höheren Frequenzen die Dämpfung höher ist

und die alten Standards bei 5 GHz liefen, während die neueren bei 2,4GHz laufen.

36

Normale Antennen kommen im Freien auf etwa 300 Meter, in Gebäuden mit dünnen Wänden

auf etwa 40 Meter und in allen anderen Räumlichkeiten hängt die Reichweite ganz von den

verwendeten Materialien ab. Mit speziell gerichteten Antennen können die Werte fürs Freie

weit übertroffen werden, vorausgesetzt es besteht Sichtkontakt. Dann können Werte um 20

Kilometer erreicht werden. Antennen bringen also in jedem Fall einen Sende- wie Empfangs-

gewinn.

2.3.3 Bluetooth4

Bluetooth

Bluetooth ist eine Lösung zur einfachen Anbindung von Peripheriegeräten (z.B. mobile End-

geräte wie Handys, PDA's und Notebooks) über eine drahtlose Schnittstelle. Der Standard

wurde von der Firma Ericsson eingeleitet, die Bluetooth seinen Namen gab. Bluetooth (Blau-

zahn) wurde der vor rund 1000 Jahren herrschende dänische König Harald II genannt, der in

Dänemark nach wie vor hohes Ansehen genießt. Der Standard wird durch die BSIG (Blue-

tooth Special Interest Group) gefördert und wurde erstmals 1998 vorgestellt. Zusammen mit

Ericsson bilden neun Unternehmen die so genannte Promoter Group, wobei jedoch mittler-

weile wesentlich mehr Unternehmen der Interessengruppe angehören.

Bluetooth - Grundlagen

Bluetooth arbeitet im 2,4 GHz ISM-Band (Industrial, Scientific and Medical-Band), das li-

zenzfrei genutzt werden kann. Dies ist das gleiche Frequenzband, wie es die Wireless LAN

Standards IEEE802.11b und IEEE802.11g nutzen. Dabei gibt es drei unterschiedliche Sende-

klassen. Die Sendeklasse 3 mit einer Empfindlichkeit von –70 dBm, einer Leistung von 1mW,

einer theoretischen Reichweite von 10 m und einer Netzgröße im Piconet-Bereich. Dies ist die

Klasse, in welcher die meisten heutigen Bluetooth Geräte arbeiten. Auch wenn dies laut Defi-

nition der Bereich eines PANs ist, so ist Bluetooth doch nicht auf diese Leistung beschränkt.

Durch nachgeschaltete Leistungsverstärker kann die Ausgangsleistung wesentlich gesteigert

werden. Dabei arbeitet die Signalklasse 2 mit einer Empfindlichkeit von 4 dBm, einer Leis-

37

tung von 2,5 mW, einer theoretischen Reichweite von 30 m und einer Netzgröße im Nanonet-

Bereich. Die maximale Leistung wird jedoch in der Signalklasse 1 erreicht, mit einer Emp-

findlichkeit von 20 dBm, einer Leistung von 100 mW, einer theoretischen Reichweite von

100 m und einer Netzgröße im Mikronet Bereich. Netze der Sendeklassen 3 und 2 sind dabei

dem PAN-Bereich zuzuordnen, wobei Netze der Sendeklasse 1 den Grenzfall zum LAN dar-

stellen. Es muss jedoch berücksichtigt werden, dass in den heutigen Bluetooth-Lösungen ma-

ximal Datenraten von 1 MB/s zu realisieren sind. An zukünftigen Erweiterungen wird jedoch

bereits gearbeitet; so wird eine Verdoppelung der Datenrate auf 2 MB/s angestrebt.

Wie bereits erwähnt, arbeitet Bluetooth in dem 2,4 GHz ISM-Band, wobei der genaue Ar-

beits-Frequenzbereich von 2,402 GHz bis 2,480 GHz liegt. Als Zugriffsverfahren wird ein

schnelles Frequenzsprungverfahren, das Frequency Hopping Spread Spectrum (FHSS), ver-

wendet. Dabei werden 1600-mal je Sekunde Frequenzwechsel vollzogen, die in 79 Schritten

zu je 1 MHz zueinander liegen. Bluetooth stellt hierbei einen Breitbandkanal für Sprach- und

Datenübertragung zur Verfügung, wobei sich bis zu drei Sprachkanäle mit jeweils 64 KB/s

betreiben lassen. Prinzipiell kann zwischen einer synchronen und einer asynchronen Übertra-

gung gewählt werden. Die synchrone Übertragung stellt eine Datenübertragungsrate von

433,9 KB/s zur Verfügung. Bei der asynchronen Übertragung kann eine Datenübertragungsra-

te von 723,2 KB/s in Downloadrichtung und 57,6 KB/s in Uploadrichtung realisiert werden.

Bluetooth kennt drei verschiedene Sicherheitsstufen, wobei nur in der dritten Stufe verschie-

dene Verschlüsselungsmethoden zum Tragen kommen. So kann beim Verbindungsaufbau die

Authentifizierung mit 128 bit und bei der Datenübertragung eine Verschlüsselung von 8 bit

bis 128 bit erfolgen.

Bluetooth - Netz

In der Sendeklasse 3 bezeichnet man die Netzgröße als Piconet. In einem Piconet dürfen ma-

ximal acht Bluetooth-Geräte miteinander kommunizieren. Die Bluetooth-Geräte identifizieren

sich über eine 48 bit lange Identifikationsnummer, wobei das erste aktive Gerät in dem Netz

als Master fungiert und für die Steuerung des Frequenz-Hopping zuständig ist. Das bedeutet,

dass in einem Piconet ein Master und maximal sieben Slaves arbeiten können. Weiterhin kön-

nen jedoch bis zu 255 Bluetooth-Geräte als passive Slaves geparkt werden. Diese Geräte kön-

4 Quellen: [WLABlu], [BlToo], ], [ WLANBlu]

38

nen dann über den Master aktiviert werden, sofern dies nötig wird. Darüber hinaus besteht die

Möglichkeit des Zusammenschlusses mehrerer Piconets zu einem so genannten Scatternet.

Hierbei übernimmt ein gemeinsamer Slave die Vermittlungsfunktion zwischen beiden Pico-

nets.

Bluetooth - Vorteile/Nachteile

Die Bluetooth-Technologie ist eine Bereicherung im PAN-Segment und ermöglicht eine ein-

fache Anbindung von Peripheriegeräten. Der Vorteil eines solchen offenen Standards ist die

rasche Akzeptanz am Markt. Dies kann jedoch nicht uneingeschränkt gesehen werden, da

diese in Teilbereichen sehr stark unterschiedlich ist. Sofern die Entwicklungsziele einer sehr

preiswerten Einchip-Lösung der Bluetooth-Komponenten eingehalten werden, steht dem brei-

ten Einsatz nichts im Wege. Durch den Markennamen Bluetooth wird zudem gewährleistet,

dass eine Interoperabilität mit Bluetooth-Geräten verschiedener Hersteller erfüllt werden

kann. Durch die Nutzung des 2,4-GHz-Frequenzbandes kann es jedoch zu Störungen mit

WLAN-Komponenten kommen, die nach den Standards IEEE802.11b oder IEEE802.11g

ebenfalls im ISM-Band arbeiten. Auch die Anwendung von Bluetooth zur vernetzten Daten-

übertragung ist kritisch zu betrachten, da dies den Grenzfall vom WPAN zum WLAN dar-

stellt. Hierzu haben die Industriestandards nach IEEE802.11 eine wesentlich breitere Durch-

dringung am Markt und eine ausgereiftere Technologie.

39

3 Realisierung

3.1 Gesamtkonzept

In Anbetracht der Anforderungen an das System und die Datenübertragung wie zum Beispiel

bei den meisten Einsätzen werden die Steuerdaten bzw. Sensorwerte von Prozessen zyklisch

ausgelesen und bearbeitet. Die errechneten Werte werden an andere Prozesse bzw. Aktoren

weiter gegeben, was natürlich ein regelmäßiger Nachrichtenverkehr voraussetzt. Für das

Steuerungssystem wird folgender schematisches Konzept (siehe Bild 3.1) entworfen.

Bild 3.1 Schematisches Konzept der Kommunikationsteilnehmer

40

3.2 Auswahl der optimalen Funktechnologie5

Bild 3.2 Funktechnik-Aktuelle Standards im Vergleich

In Anbetracht der Zielsetzung und der derzeit vorliegenden Standards (Siehe Bild 3.2: Funk-

technik-Aktuelle Standards im Vergleich) kann die Verwendung der Funktechnologie und der

Standard-Software festgelegt werden. Da sich das Netzwerk auf kurze bis mittellange Distanz

ausbreitet(10-200 Meter), befindet sich das System im Bereich des kabellosen persönlichen

Netzwerkes (WPAN) bis hin zu dem kabellosen lokalen Netzwerkes (WLAN).

Die zu diesen Netzwerkarten zugeordneten standardisierten Technologien sind:

- WLAN

- Infrarot

- Bluetooth

- ZigBee

5 Quellen: [ATan], [AHac], [BT]

41

Die Anforderung an die Übertragungsgeschwindigkeit ist gering. Sendedaten und Steuer-

kommandos an das Aksenboard und somit an Servomotoren sind Pakete mit einer Datenlänge

von maximal 8 Byte, die eine durchschnittlich geringe Bandbreite erfordern.

Rechenbeispiel: In einem Netzwerk befinden sich 400 Knoten. Jeder Teilnehmer sendet pro

Sekunde ein 30 Byte großes Datenpaket an das zentrale Modul(10 Byte Informationsgehalt

und pauschal 20 Byte Header-Daten). Ein empfangenes Paket wird durch ein 20 Byte großes

Antwortpaket bestätigt. Am zentralen Modul kann eine maximale Bitrate von 160 kBit/s

(20x8=160) entstehen. Jede der hier betrachteten Technologien gewährleistet diesen Daten-

satz. Um sich für die geeignete Technologie zu entscheiden, werden die oben genannten Stan-

dards an Hand folgender Kriterien miteinander verglichen:

- Geschwindigkeit / Bandbereite

Es werden hauptsächlich kleine Datenmengen transportiert. Steuerkommandos für das

Fahrzeug und somit an Servomotoren sowie Sensorenwerte werden in Stringform übertra-

gen und benötigen nur geringe Datenübertragungsgeschwindigkeiten.

- Energieverbrauch

Der CAN/WLAN-Umsetzer-Modul (9 Volt Spannungsversorgung), der Aksenboard und

die Sharp-Sensoren (5-8 Volt) und die Servomotoren(12 Volt) werden mit Batterien ver-

sorgt. Der Leitstand ist eine Applikation und läuft auf dem Standardrechner mit dem Be-

triebsystem Windows XP, versorgt über normale Netzspannung.

- Reichweite:

Wie oben erwähnt, erstrebt das System die Reichweite eines WLAN.

- Latenzzeit:

Die Latenzzeit beschreibt die Zeit eines Datenpaketes vom Sender zum Empfänger. Sie

setzt sich

1. aus der Zeit der eigentlichen Übertragung und der

2. aus den Verarbeitungszeiten bei Sender und Empfänger zusammen.

In dieser Betrachtung steht der zweite Punkt im Vordergrund.

42

3.2.1 Grobe Selektion

Die Infrarot-Technik ist hier ungeeignet, da stets Sichtkontakt zwischen den miteinander

kommunizierenden Kommunikationsteilnehmern bestehen muss. Der eigentliche Vergleich

beschränkt sich somit auf die Techniken Bluetooth und WLAN.

3.2.2 WLAN und Bluetooth im Vergleich

• Geschwindigkeit/Bandbreite

Bluetooth und WLAN arbeiten in den 2,4 GHz-Bereichen des ISM-Band. Bluetooth verwen-

det das Frequenzsprung-Verfahren FHSS und erreicht eine Verbindungsrate von 723 kBit pro

Sekunde, wobei praktisch eine Datenübertragungsrate von rund 125 kBit pro Sekunde erlangt

wird. Ebenfall in Anbetracht der Anforderungen an das verteilte System sind beide Technolo-

gien bezüglich der Übertragungsrate geeignet.

• Reichweite

Die Reichweite von Bluetooth liegt, abhängig von der Klasse, bei 10 bis 100 Metern. Große

Entfernungen erfordern erheblich mehr Sendeleistung (Klasse I: 100 m bei 100 mW, Klasse

III: 10 m bei 1 mW). WLAN hat eine Reichweite bis zu 300 Metern, wobei im Mittel 50 Me-

ter erwartet werden können. Um erwartete Netzwerke mit einer Reichweite von bis zu 300

Metern aufzubauen, reichen direkte Verbindungen von Gerät zu Gerät nicht aus. Große Ent-

fernungen fordern das Routing und die Weiterleitung von Paketen innerhalb der Netzwerke,

was zwar von beiden Standards unterstützt wird, aber bei Bluetooth mit relativ hohem Auf-

wand verbunden ist. Die mit Abstand größte Reichweite mit ca. 200 - 300 Metern direkt zwi-

schen zwei Geräten erreicht WLAN.

43

• Anzahl der Netzwerkteilnehmer

Die Architektur des Bluetooth-Netzwerkes unterteilt sich in zwei Komponenten, dem Pico-

und dem Scatternetz. Ein Piconetz enthält bis zu 255 Teilnehmer, bestehend aus einem Master

und Slaves. Da der Master sieben Sendeslots an die Slaves vergeben kann, können insgesamt

lediglich acht Geräte gleichzeitig aktiv sein. Einzelne Knoten können sich in mehreren Pico-

netzen befinden, wodurch ein Scatternetz entsteht. Bluetooth schränkt die Netzspontaneität

durch die geringe Anzahl gleichzeitig verteilbarer Sendeslotts ein, zudem wird die Größe des

Netzwerkes durch die Anzahl adressierbarer Knoten beschränkt. Drahtlose Netzwerke werden

in Funkzellen eingeteilt. Eine Funkzelle besteht im Minimum aus einem Sender/Empfänger-

Paar und wird als der Raum definiert, in dem alle Sender und Empfänger dieselbe Frequenz

und/oder denselben Code benutzen. WLAN ist also ein Computernetzwerk, das praktisch ge-

sehen das Ethernetkabel durch eine Funkverbindung ersetzt. Für das Arbeiten mit dem Com-

puter bedeutet dies aber keinen Unterschied zu einer Verbindung mit einem Ethernetkabel.

Also, wie in einem normalen Netz können mehrere Teilnehmer 232, also 4.294.967.296 Teil-

nehmer angeschlossen werden.

• Energieverbrauch

Bei Betrachtung des Leistungsverbrauchs der beiden Technologien beim Senden und Emp-

fangen von Daten, sowie im Standby-Modus gibt es kaum Differenzen. Ein unterschiedlicher

Energieverbrauch kommt durch die Art und Weise des Sendens und Empfangens zustande.

Die PHY-Schicht von Bluetooth fordert ständig die Synchronisation der Module untereinan-

der. Somit verweilen die Module kaum im Standby- Modus und verbrauchen verhältnismäßig

viel Energie. WLAN hat einen Ressourcenverbrauch von mindestens einem Megabyte RAM

und sein Energieverbrauch übersteigt die Kapazitäten kleiner Module(siehe Tabelle 3.1 Ener-

gieverbrauch bei den WLAN und Bluetooth).

Technologie Sendeleistung[mW] Leistungsaufnahme[mW] Energieverbrauch

pro Bit[nJ]

Bluetooth(10m) 1 90 90 WLAN 280 ca. 2000 ca. 180

Tabelle 3.1 Energieverbrauch bei WLAN und Bluetooth

44

Anzahl der Netzwerkteilnehmer

Die Anzahl der Knoten ist abhängig von der Art der Anwendung. Die maximale Netzteilneh-

mer sollte maximal 10 Teilnehmer sein.

• Latenzzeiten

Große Unterschiede bestehen bei den Beitritts- und Anforderungszeiten zwischen den Tech-

nologien. Je kürzer die Latenzzeit, desto schneller die Übertragung eines Datenpaketes von

einem Netzwerkteilnehmer zum anderen. Besonders der Zeitaufwand, bis ein Bluetooth-

Modul vom schlafenden in den aktiven Zustand gewechselt ist, wird nicht den Anforderungen

eines Sensornetzwerkes gerecht.

Bluetooth WLAN

Beitritt in ein Netzwerk > 3s ~ 3ms

Zugriff eines aktiven Knotens ~ 2ms ~15 ms

Tabelle 3.2 Latenzzeiten bei Bluetooth und WLAN

45

IEEE 802.11 vs. Bluetooth

Während der Entwicklung des WLAN-Standards 802.11 und Bluetooth haben sich schnell

Gemeinsamkeiten eingestellt. Beide Funknetzstandards arbeiten im Frequenzband 2,4 GHz

und sollen die unterschiedlichsten Geräte über Funk miteinander verbinden. Beide Standards

zeichnen sich durch unterschiedliche Stärken aus und kommen dadurch in verschiedenen Ge-

räten auf den Markt. Wireless LAN übertrifft Bluetooth in seiner Reichweite und Übertra-

gungsgeschwindigkeit und kommt deshalb in lokalen Netzwerken zum Einsatz. Bluetooth ist

mit geringen Hardwarekosten, niedrigem Stromverbrauch und Echtzeitfähigkeit in den Berei-

chen Sprachübertragung, Audio-Video-Lösungen und Adhoc-Verbindungen zwischen

Kleinstgeräten besser geeignet. Bluetooth löst hier Irda (Infrarot) erfolgreich ab.

Bluetooth IEEE 802.11

723 kBit/s 11-54 MBit/s

Bis zu 10 m

(mit FEC auch bis zu 100m)

Bis zu 100m – 300m

(einige km mit externen Antennen als Richt-

funk )

8 (aktive Geräte pro Piconet) 256 und mehr Geräte pro Netzwerk

Verschiedene Verwendungszwecke LAN

Extrem Stromsparend Höherer Stromverbrauch

Tabelle 3.3 IEEE 802.11 vs. Bluetooth

Ergebnis

In Anbetracht der Vorteile von WLAN gegenüber Bluetooth und mit der Berücksichtigung

des CAN/WLAN-Moduls wird als Funktechnik für das für das SCADA Steuerungssystem die

WLAN Technologie verwendet.

46

3.3 Benötigte Hardware für die Realisierung des Systems

3.3.1 Standard PC

Ein Standard Windows-PC, der als Plattform für den Leitstand dienen soll, der mit einem

WLAN-Interface (siehe Bild 3.3 WLAN USB-Dongle) in Form eines USB-Dongles aus-

gestattet ist. Zusätzlich noch ein PC-Lenkrad Logitech® MOMO® Racing (siehe Bild 3.5),

das folgend noch beschrieben wird. Es wird mit Gas- und Bremspedal ebenfalls auch über

USB an dem Windows-PC angeschlossen.

3.3.2 WLAN-Interface

Um eine Telemetrie per WLAN innerhalb kürzester Zeit zu erproben, braucht man lediglich

einen Windows-PC mit einer WLAN-Schnittstelle, zum Beispiel einem preiswerten WLAN

USB-Dongle. (Siehe Bild 3.3)

Bild 3.3 WLAN USB-Dongle

Zunächst sollte die WLAN-Schnittstelle des PCs in den Ad-hoc-Modus gesetzt werden.

Hierfür findet man in der WLAN-Treibersoftware, welche als Zubehör zu jedem PC-WLAN-

Interface installiert wurde, die entsprechenden Einstellmöglichkeiten.

Die IP-Adresse für das WLAN-Interface des PCs sollte mit dem statischen Wert 192.128.3.1

versehen werden. Windows XP bietet in der Systemsteuerung die entsprechenden Dialoge

zur Konfiguration. Bild 3.4 zeigt die IP-Adressen-Konfiguration eines Windows-

Betriebssystems.

47

Bild 3.4 IP-Adressen-Konfiguration für ein PC-WLAN-Interface

Die drahtlose Steuerdatenübertragung per WLAN ist beim Einsatz der richtigen Werkzeuge

sehr schnell und einfach möglich. Ein großer Vorteil ist der hohe Standardisierungsgrad durch

IEEE802.11- Vorgaben im Hinblick auf Hardware und Software. Dadurch ergibt sich ein

deutlicher Investitionsschutz im Vergleich zu propritären Funklösungen in den 433 und 868

MHz Funkbändern. Also, die Kommunikation zum Fahrzeug findet über das USB-WLAN-

Interface statt. Dieses ist, so wie oben gezeigt, konfiguriert, so dass es sich automatisch mit

dem IGW400/CAN verbindet.

48

3.3.3 PC-Lenkrad

Das Einlesen der Steuerdaten aus dem PC-Lenkrad und Gas/Bremspedalen kann man mit we-

nig Programmieraufwand mit der Programmiersprache G LabVIEW erreichen. Da ich am

Anfang mit der grafischen Programmiersprache LabVIEW absolut keine Erfahrung hatte, hat

es mir einwenig Zeit gekostet, bis ich die Initialisierung der Hardware programmieren konnte.

Bild 3.5 PC-Lenkrad, Gas-/Bremspedale

3.3.4 CAN/WLAN-Modul (IGW400/CAN)

Die Datenübertragung von dem Leitstand zum Fahrzeug erfolgt über den CAN/WLAN-

Modul (IGW400/CAN) von der Firma SSV-Embedded Systems. Das CAN/WLAN-Modul

wandelt die WLAN-Pakete in CAN um.

Bild 3.6 CAN/WLAN-Modu [SSV1]

49

IGW400/CAN erlaubt, die Daten zwischen den Kommunikationsteilnehmern mit einer

WLAN - Schnittstelle über den TCP/IP Port zu tauschen. Diese Daten können nicht nur von

CAN/WLAN –Modul, sondern auch vom anderen PC sogar PDA’s erfasst werden, die dieses

Profil suporten und die notwendige Schnittstelle haben.

Die ausführliche Beschreibung von technischen Charakteristiken des Gerätes soll die Ent-

wicklung der Steuerungssoftware unterstützen. Der CAN/WLAN –Modul IGW7400-CAN

integriert typische Messungen und Steuerungen in ein 802.11b/g-kompatiblen WLAN. Dieses

sehr kompakte System ist als kleine, einfache Schnittstelle zu benutzen, die alle möglichen

Datenbestandteile der industriellen Automatisierung sammelt und sie über WLAN überträgt.

Bild 3.7 zeigt das Blockdiagramm des IGW/400-CAN. UART1-Schnittstlle (Universal

Asynchronous Receiver Transmitter) hat eine Beziehung zur WLAN-Einheit über den Level-

Shifter der Sub-D RS232-Schnittstelle.

UART2-Schnitstelle hat eine interne Kommunikation zum Mikrocontroller. Dieses Steue-

rungssystem basiert auf einem ARM7TDMI Mikrocontroller, der 256 KBytes Flash und 16

KBytes SRAM (Static Random Access Memory) Arbeitsspeicher besitzt.

Bild 3.7 Blockdiagramm des CAN-WLAN-Moduls [SSV1]

50

Eigenschaften und technische Daten des CAN-WLAN-Moduls

51

Telemetrieanwendungen nutzen häufig Funkstrecken auf Basis der ISM-Frequenzen

(ISM = Industrial, Scientific, Medical = frei nutzbare HF-Frequenzbereiche).

Die folgende Tabelle 3.4 liefert einen Überblick zu den wichtigsten ISM-Frequenzbereichen

für den deutschsprachigen Raum.

Diese Frequenzen können ohne weitere Anmeldungen und ohne Kosten zur Datenübertragung

und Datenübermittlung verwendet werden. Die maximal zulässigen Sendeleistungen und an-

dere Parameter sind allerdings vorgegeben und müssen eingehalten werden. Weiterhin ist zu

beachten, dass es inzwischen in der Praxis sehr viele ISM-Anwendungen gibt. Da elektro-

magnetische Wellen nicht an Grundstücks- oder Gebäudegrenzen halten, sind Beeinträchti-

gungen durch andere Applikationen an der Tagesordnung. Jeder Anwender muss selbst für die

notwendige Betriebssicherheit sorgen.

Frequenzbereich Typische Anwendung

6,76 MHz – 6,79 MHz Verschiedene Anwendung

13,55 MHz – 13,56 MHz RFID

26,95 MHz – 27,28 MHz Funkfernsteuerung

40,66 MHz – 40,7 MHz Funkfernsteuerung

433,05 MHz – 434,79 MHz Sensoren und Aktoren, Funkfersteuerung

868,00 MHz – 870 MHz Sensoren und Aktoren, Funkfersteuerung

2,40 GHz – 2,50 GHz Bluetooth, WLAN, ZigBee, Video

5,72 GHz – 5,87GHz WLAN

Tabelle 3.4 Übersicht der ISM-Frequenzbereiche [Wal-Emb]

52

Funkübertragung von Daten per 433 MHz, 868 MHz und 2,4 GHz. Die Realisierung der

Funkprotokolle blieb aber bisher weitestgehend dem Anwender überlassen. Als folge davon

findet man unzählige Anwendungen mit anwenderspezifischen Protokollen. Lediglich Blue-

tooth und WLAN (Wireless LANs) gemäß IEEE 802.11- zwei Funkverfahren für ISM-

Frequenzen im Bereich von 2,4 bis 2,5 GHz- bieten vollständig definierte Übertragungsproto-

kolle. Folgende Abbildung zeigt als Beispiel die Protokollbestandteile einer WLAN- Funk-

verbindung gemäß IEEE 802.11. Oberhalb des 802.11- MAC kommen typischerweise

TCP/IP- Protokolle zur Anwendung.

Bild 3.8 Übertragungsprotokoll für WLAN Funkverbindung [SSV1]

53

3.3.5 Aksenboard

Das Aksenboard ist für die Robotik und Embedded-Systeme von der Fachhochschule Bran-

denburg entwickelt worden, die sich sowohl

• im privaten Bereich

• als Forschungs- und Ausbildungsplattform an Hochschulen oder

• auch als Basis für industrielle Anwendungen (Rapid Prototyping von Robotern)

eignet

Herzstück des Systems ist der Mikroprozessor SAB 80C515A. Die Anbindung üblicher Peri-

pherie von Kleinrobotern erfolgt über das Aksenboard.

Bild 3.9 DasAksenboard

Das Aksenboard besteht aus folgenden Komponenten:

• Mikroprozessor SAB 80C515A.

• 64 KB Flash, 8 KB Flash.

• 4 Motortreiber (in Drehzahl und Richtung variierbar).

• 3 Servo-Ausgänge, Sie können durch Software auf maximal 8 Servo-Ausgänge erweitert

werden.

54

• 15 analoge Eingänge. Unterschiedliche Arten von Sensoren, z. B. Sensoren für Abstand,

Infrarot, Licht können angeschlossen werden. Die analogen Eingänge sind mit einem Pull-up-

Widerstand verbunden.

• 16 digitale Ports. Sie können als Ein- bzw. Ausgang konfiguriert werden.

• 4 schaltbare Leistungstreiber, z.B. Infrarotsender, Lämpchen und LED.

• 1 Infrarotausgang mit Leistungstreiber

• 3 Encoder-Eingänge zum Erfassen von Drehzahlen.

• DIP-Schalter (vierfach). Der DIP-Schalter eignet sich gut zur Auswahl von verschiedenen

Programmteilen oder Betriebsarten.

• Zweizeiliges LCD , je 16 Zeichen.

• CAN-Interface 1 Mbit (optional).

• Bluetooth-Verbindung zum PC (optional).

Das Aksenboard ist mit einer seriellen Schnittstelle ausgestattet. Diese Schnittstelle ermög-

licht den Datenaustausch zwischen dem Aksenboard und ein Computer bzw. ein Peripheriege-

rät. Für die Kommunikation zwischen Aksenboard und anderer Hardware besitzt das Aksen-

board ein CAN-Bus.

Die Kommunikation ist paketorientiert. Es kann mit Geschwindigkeiten von bis zu einem

Megabit gesendet werden. Programme für das Aksenboard werden in der Sprache C geschrie-

ben. Um das Aksenboard zu programmieren, werden zwei Programme benötigt. Das ist zum

einen der Compiler, der den Quelltext in für das Board verständlichen Maschinencode über-

setzt und zum anderen der Aksen-Flasher, der diesen Maschinencode auf das Board überträgt.

Die Fachhochschule Brandenburg stellt alle Software und Informationen zur Verfügung, die

zu Programmierung des Aksenboardes benötigt werden [Aks-Bor].

55

3.3.6 Fahrzeug

Für die Durchführung der Arbeit steht ein Modell-Lastfahrzeug der Firma Wedico. zur Verfü-

gung. Der ist im Maßstab 1:16 gebaut. Das Modell-Lastfahrzeug besteht aus einer 3-achsigen

Sattelzugmaschine und einem 2-achsigen Auflieger.

Bild 3.10 Das Fahrzeug

Aus der Bauanleitung [WEDI] kann die Verdrahtung der elektrischen Fahrzeugkomponenten

entnommen werden. Der elektrische Antriebsmotor wirkt über ein 3-Gang-Schaltgetriebe auf

die beiden Hinterachsen der Zugmaschine.

Die Zugmaschine ist außer mit der zum Fahren erforderlichen Elektrik auch mit Beleuchtung

und einem Geräuschgenerator ausgestattet. Diese Funktionen werden von der Fernsteuerung

bedient. Der Blinker für die linke und rechte Seite wird in Abhängigkeit vom Lenkeinschlag

der Vorderräder automatisch geschaltet. Auch die Bremslichter und der Rückfahrscheinwerfer

werden automatisch gesteuert. Der Auflieger ist mit Glühlampen für Blinker, Rücklicht und

Bremslicht ausgestattet. Diese werden durch ein mehradriges Kabel von der Zugmaschine mit

Strom versorgt. Der Fahrmotor, das Schaltgetriebe und die Lenkung können direkt mit dem

Servoport eines Mikrocontrollers verbunden werden. Der Fahrmotor ist mit einem Fahrregler

verbunden. Der Fahrregler versorgt den Fahrmotor mit elektrischer Energie. Dabei wird die

angelegte Spannung an Fahrmotor nicht kontinuierlich sondern stufenweise durch den Fahr-

regler verändert. Diese Abstufungen werden als Fahrstufen bezeichnet. Jeder Fahrstufe wird

eine Nummer [ ]45,40−∈n zugeordnet. Positive Nummern gehören zu Fahrstufen, bei denen

56

das Fahrzeug vorwärts fährt. Zum Rückwärtsfahren werden Fahrstufen mit negativer Nummer

verwendet. Mit der Fahrstufe 0=n wird der Motor ausgeschaltet. Mit steigendem Betrag n

vergrößert sich auch die Spannung an den Fahrregler.

3.3.7 Infrarot-Distanzsensoren

Die Infrarot-Distanzsensoren erfassen einen einzigen Punkt, der sich senkrecht zum Mittel-

punkt zwischen Sender und Empfänger des Sensors befindet. Mit dieser Technik ist die Erfas-

sung der gesamten Umgebung eines Fahrzeugs unmöglich. Trotz dieses Nachteils werden die

Infrarot-Distanzsensoren in vielen Forschungseinrichtungen im Bereich der autonomen Ro-

boter und Fahrzeuge für experimentelle Zwecke eingesetzt. Der Grund dafür ist, dass diese

Sensoren im Vergleich zur Radarsensoren und Sehsystemen sehr günstig sind. Außerdem sind

sie einfach zu bedienen. Sie brauchen wenig Strom, sind nicht rechenintensiv und können an

einem einfachen Controller angeschlossen werden. Abhängig von der Entfernung des erfass-

ten Objekts gibt die Auswertelektronik dieser Sensoren die Spannung Uout als Analogsignal

aus [CONRAD]. Eine Auswertsoftware soll dann aus dem Wert des Ausgangssignals die Ent-

fernung berechnen. Sehr beliebt sind die Infrarot- Distanzsensoren der Firma Sharp. Sie ha-

ben unterschiedliche Reichweiten. Diese Sensoren arbeiten im Nahbereich ziemlich genau

aber im Grenzbereich lässt die Zuverlässigkeit stark nach.

Bild 3.11 Infrarot-Distanzsensor GP2D12 45

57

3.4 Benötigte Standard-Software und Werkzeuge

3.4.1 LabVIEW 6

LabVIEW (Laboratory Virtual Instrument Engineering Workbench), eine grafische Entwick-

lungsumgebung wurde Anfang der achtziger Jahre von der Firma National Instruments ent-

wickelt, um eine Art Mensch-Maschinen-Kommunikation zu führen.

Diese grafische Entwicklungsumgebung verknüpft zwei bewährte Programmiermethoden mit

einander, den Datenfluss und die strukturierte Programmierung, und integriert sie in eine ein-

zige grafische Programmierumgebung, die alle Elemente einer modernen Benutzeroberfläche

bereitstellt.

Also, LabVIEW ist eine grafische Programmiersprache, die hauptsächlich für messtechnische

Aufgaben eingesetzt wird - von der einfachen Datenerfassung bis zur komplexen Prüfstands-

steuerung. LabVIEW ist auch zur Prozessautomatisierung, Auswertung, Analyse und Doku-

mentation von (Mess-) Daten sehr gut geeignet.

In LabVIEW werden Symbole an Stelle von Textzeilen verwendet, um den Programmablauf

zu erstellen. Im Gegensatz zu textbasierten Programmiersprachen, bei denen die Programm-

ausführung von Anweisungen gesteuert wird, verwendet LabVIEW die sog. Datenflusspro-

grammierung, bei welcher der Fluss der Daten den Programmablauf steuert.

6 Quelle: [LabVIEW]

58

LabVIEW-Programme werden als virtuelle Instrumente, kurz “VIs” bezeichnet, da sie hin-

sichtlich ihres Erscheinungsbilds und ihrer Funktionalität realen Instrumenten wie etwa Oszil-

loskopen oder Multimetern nachempfunden sind. Sie bestehen aus zwei Komponenten: das

Frontpanel enthält die Benutzerschnittstelle, das Blockdiagramm den graphischen Programm-

code siehe Bild 3.12.

Dieser wird von einem Compiler abgearbeitet, dadurch ist die Performance vergleichbar mit

den anderen Hochsprachen. LabVIEW enthält eine umfangreiche Sammlung von Werkzeugen

zur Erfassung, Analyse, Darstellung und Speicherung von Daten sowie zum Debuggen von

Programmcode.

Bild 3.12: Blockdiagramm des LabVIEW Entwicklungssystems

59

Die virtuellen Instrumente, so genannte VIs, dienen beispielsweise zur Darstellung von erfass-

ten Messwerten (z.B.: von Sensoren) oder zur Steuerung einer realen, komplexen Industriean-

lage. Mit entsprechenden LabVIEW-Treibern bzw. offenen VIs werden Mess.- und Steuersig-

nale der I/O-Hardware entlockt. Sie lassen sich zudem über eine schier unendliche Vielfalt an

Funktionen mit den virtuellen Steuer- und Anzeigeelementen beliebig, verdrahtungsorientiert

verknüpfen. Dabei können recht komplexe Hierarchien entstehen.

Zur Erstellung einer Benutzeroberfläche in LabVIEW, des so genannten Frontpanels siehe

Bild 3.13, dienen Bedien- und Anzeigeelemente. Bedienelemente umfassen Drehknöpfe,

Drucktasten, Drehregler und sonstige Eingabeelemente. Zu den Anzeigeelementen zählen z.B.

Graphen oder LEDs. Nach Fertigstellung der Benutzeroberfläche wird mit Hilfe von VIs und

Strukturen der Programmcode zur Steuerung der Objekte auf dem Frontpanel erstellt. Dieser

Code befindet sich im Blockdiagramm.

Bild 3.13: Frontpanel des LabVIEW Entwicklungssystems

60

LabVIEW enthält selbst in der Base-Edition schon eine große Bibliothek an Subroutinen für

die Gerätekommunikation und die Auswertung und Darstellung von Messdaten. Ein Grund-

satz gilt immer: Was es nicht gibt, kann man programmieren, da LabVIEW eine vollwertige

Programmiersprache ist. Und darüber hinaus läßt sich LabVIEW durch DLLs um jede nur

denkbare Funktion erweitern.

• LabVIEW - Base Package - enthält die Entwicklungsumgebung mit den Basis-Routinen und

Werkzeugen

• LabVIEW - Full Development System - Zusätzliche Funktionen zur Analyse und Report

Generation etc.

• LabVIEW - Professional Development System - Zusätzliche Werkzeuge zum Projekt-

Management

Die Anschlüsse wie GPIB-, PXI-, VXI- und seriellen Geräten (USB, RS-232 und RS-485),

Probibus, CAN-Bus aber auch TCP/IP werden von LabVIEW unterstüzt. Darüber hinaus kann

man mit anderen Applikationen über das Internet, über ActiveX und DDE kommunizieren

und auf SQL-Datenbanken zugreifen. Zusätzlich ist es möglich, ActiveX-Objekte in Lab-

VIEW einzubinden und LabVIEW-Code von anderen Umgebungen aufzurufen. Bereits exis-

tierender Code kann in Form einer DLL unter Windows aufgerufen werden oder in einer ge-

meinsam benutzten Bibliothek (Shared Library) unter anderen Plattformen.

Virtuelle Instrumentierung erhöht die Flexibilität, das heisst: Durch die Kombination von

LabVIEW mit Standard-Datenerfassungsgeräten und Hardware zur Steuerung der Messgeräte

kann man virtuelle Instrumente erzeugen und vielfältig nutzen. Während traditionelle Messge-

räte durch die Konzeption des Herstellers begrenzt sind, kann ein virtuelles Instrument als

eine Vielzahl von Instrumenten arbeiten, z. B. als Temperaturmonitor, Voltmeter, Streifen-

schreiber, Digitalisierer oder als Signalanalysator.

Außerdem Virtuelle Instrumentierung spart Zeit und Kosten, indem sie die Möglichkeit bietet,

benutzerdefinierte Systeme in einem Bruchteil der Zeit zu erstellen, die man mit traditionellen

Methoden brauchen würde. In der Entwicklung erhält man seine Antworten schneller und hat

man die Zeit für die sorgfältigeren Tests. Die Qualität steigt bei kürzeren Produktvorlaufzei-

ten.

61

Vorteile

-LabVIEW stellt zahlreiche Bibliotheken zur Kommunikation mit der Hardware (Serielle

Schnittstelle, PCI-Karten etc.) zur Verfügung,

- die LabVIEW-Werkzeuge sind speziell für Anwendungen rund um die Datenaufnahme, -

darstellung und -analyse gedacht.

-LabVIEW erleichtert die Fehlersuche durch die Möglichkeit der Kontrolle einzelner Pro-

grammschritte. Außer den eben genannten Gründen sind noch andere Vorteile anzubringen,

die LabView gegenüber anderen Programmiersprachen bietet:

-LabVIEW stellt standardmäßig eine große Anzahl numerischer Algorithmen (statistische

Algorithmen, Kurvenanpassung) zur Verfügung,

-LabVIEW übernimmt das Speicher-Management bei mehrdimensionalen Matrizen oder bei

der Erzeugung bzw. Vernichtung der Objekte, d.h.: Das Löschen der erzeugte aber nicht mehr

verwendbare Objekte werden nicht wie z.B. in andere Hochsprachen vom Programmierer

übernommen, sondern vom Speichermanagement ( Also kein malloc", calloc" usw.),

-LabVIEW ermöglicht die einfache Darstellung von ein- und zweidimensionalen Graphen,

- viele Hardwareanbieter bieten mittlerweile LabVIEW-Bibliotheken und Demo-VIs an,

- Multitasking und die Kommunikation zwischen den einzelnen VIs ist sehr einfach zu imp-

lementieren, ebenso laufen LabVIEW-Programme sehr gut auf Multiprozessor-Maschinen

(die neue Intel Hyper Thread-CPU eingeschlossen),

-LabVIEW ist plattformunabhängig, d.h. in Windows programmierte VIs lassen sich problem-

los auf Linux oder Solaris übertragen und umgekehrt.

-LabVIEW beinhaltet umfangreiche TCP/IP Funktionen, d.h. es ist ein leichtes, zu verarbei-

tende Aufgaben auf mehrere Rechner in einem Netzwerk zu verteilen

62

Nachteile

- Kleine Änderungen können aufwendige Neustrukturierungen nach sich ziehen, wenn das

Schaffen von Raum auf dem Blockdiagramm durch Verschieben geschieht. Denn dann müs-

sen die Drähte und Symbole oftmals neu geordnet werden, um die Übersichtlichkeit wieder-

herzustellen. Alternativ kann aber auch ein Teil des Codes in ein neues Unterprogramm aus-

gelagert werden.

- Um keinen Drahtwirrwarr zu erzeugen, werden von weniger versierten Nutzern oft vermehrt

Variablen eingeführt, die die Geschwindigkeit herabsetzen und dem Datenflussmodell wider-

sprechen. Erfahrene 'Verdrahter' definieren zusammengesetzte Datentypen, um weniger Dräh-

te verlegen zu müssen.

- Der einfache Einstieg in die LabVIEW-Programmierung verleitet leider dazu, "einfach

drauflos zu programmieren", allerdings kann auch die grafische Programmierung nicht die

ordentliche Planung des Projektes ersetzen.

- Die Signalorientierung führte in früheren Versionen zu einem Polling der Signalquellen und

GUI-Elemente in Schleifen, anstatt zu einem von Ereignissen ausgelösten Signalfluss. Seit

LabVIEW 7 existieren auch sehr weitgehend konfigurierbare Eventstrukturen, die auf Ereig-

nisse aus dem Benutzerinterface und auf Systemereignisse reagieren können. Das vermeidet

beim Pollen verschwendete Rechenzeit und erlaubt sehr effektive Konstrukte, insbesondere

beim Benutzerinterface.

- Ausführbare LabVIEW-Programme können vom Entwicklungssystem zwar erstellt werden,

erfordern jedoch die Installation einer Laufzeitumgebung auf dem Zielsystem (und mögli-

cherweise kostenpflichtige Lizenzen für bestimmte Module). Und man benötigt für jede Ziel-

plattform einen plattformabhängigen und kostenpflichtigen 'Application Builder'.

63

3.4.2 WinCC 7

WinCC steht für Windows Control Center, entwickelt und vermarktet von der Firma Siemens.

Es ist ein Prozessvisualisierungssystem für komplette Bedien- und Beobachtungsfunktionali-

tät auf Standard-PCs Microsoft Windows 2000 / XP und NT.

Mit WinCC lassen sich für jeden Einsatzzweck individuell projektierte Bedienoberflächen

erstellen - zur sicheren Prozessführung und zur Optimierung der gesamten Produktion in den

Fabriken.

Eingesetzt wird WinCC als Prozesssteuerungs-Interface für vielerlei Industrienanwendungen,

seien es, Bedien- oder Beobachtungsanwendungen oder komplexe Leitaufgaben. Besonders in

den Bereichen Kennzeichnungstechnik, Logistik, Automatisierung, Messtechnik, Regelungs-

technik, Steuerungstechnik und Identifikation wird WinCC oft als Warenwirtschaftssystem,

Materialflusssystem auf einem Materialflussrechner und zur Steuerung verschiedenster ande-

rer Abläufe verwendet. Dazu werden in einem Grafikprogramm (s. Bild 3.14) Objekte mit

Variablen und/oder Scripten verknüpft und je nach Zustand oder Wert dargestellt. Es können

zum Beispiel Messwerte visualisiert oder Zustandsmeldungen von Ventilen angezeigt werden.

Gleichzeitig ist es möglich durch Benutzereingaben per Maus oder Tastatur diese Objekte zu

steuern. Weiterhin können Störmeldungen dargestellt werden, wodurch der Bediener in der

Lage ist, schnell auf Störungen zu reagieren. Fehlerfälle wie ein Förderbandstillstand können

so recht schnell erkannt werden. Das System ist sehr flexibel, so dass fast jede Darstellung

und auch fast jede Steuerung möglich ist.

7 Quellen : [WinCC1], [WinCC2]

64

Bild 3.14 WinCC Grafikprogramm

Bei weit über 80.000 Installationen weltweit hat sich WinCC mittlerweile als Industriestan-

dard und Marktführer in Europa etabliert und bildet zudem auch die Basis für andere Leitsys-

teme von Siemens.

In der Wasserwirtschaft wird WinCC zur Bedienung, Steuerung und Überwachung von Trink-

, Brauch-, Betriebs- und Abwasseranlagen eingesetzt. WinCC erfüllt alle Anforderungen, die

an ein modernes Leitsystem auf PC-Basis gestellt werden.

Beispiele:

• Es ist Skalierbar für Einplatz- und Mehrplatzlösungen, bei Bedarf auch redundant

• Es ist Einfach integrierbar in bestehende Anlagen und Anbindung an überlagerte Systeme

durch vielfältige Ankopplungsmöglichkeiten an die unterlagerten Steuerungen

• Es ermöglicht Fernbedienung und –Überwachung durch Einsatz von Web-Technologien

• Es ist jederzeit erweiterbar über Optionen und Add-ons und Standard-Schnittstellen

65

Durch den Einsatz vom Web-Technologie in Verbindung mit Thin-Client-Lösungen hat man

mit WinCC die Möglichkeit, seine Anlage orts- und plattform-unabhängig zu bedienen:

• In der Warte: WinCC als Standard-Leitsystem

• Am Schaltschrank: Bedienung über Clients oder Thin-Clients (Multi Panels oder PC)

• Mobil auf der Anlage: Visualisierung oder Diagnose über PDA

• Von Außenstationen oder von Zuhause: Bedienung und Service über Internet/Intranet

WinCC-Funktionsübersicht:

Zugangsberechtigung

Jedem Benutzer kann im System eine eigene Identität, mit Benutzername, Passwort und Be-

dienberechtigung zugeordnet werden. Mit dieser Identität muss er sich "einloggen", um

Zugriff zum System zu bekommen. Der Identität können unterschiedliche Funktionen für die

Bedienung der Anlage, für verschiedene Bereiche der Anlage oder für die Parametrierung des

Systems zugeordnet werden. Alle Eingriffe in das System können registriert und mit der Iden-

tität des Benutzers gespeichert werden. Über die Option Logon ist eine zentrale, anlagenweite

Benutzerverwaltung möglich, die in das Windows User Management integriert ist.

Historische Daten

WinCC bietet die Möglichkeit der Prozessdatenerfassung und Archivierung mit anschließen-

der Analyse und Präsentation von Messwerten und Ereignissen. Die Archivierung erfolgt ei-

ner hoch performanten Standard-Datenbank (Microsoft SQL Server 2003). Archivierte Daten

können für Berechnungen und Dokumentationen in WinCC oder anderen Programmen be-

nutzt werden. Dazu bietet WinCC eine Fülle von Standard-Zugriffs- und Auswertemöglich-

keiten.

66

Berichte / Protokolle

Berichte/ Protokolle mit übersichtlicher Darstellung der Daten mittels Text und grafischen

Symbolen, Balkendiagrammen oder Kurven können einfach kreiert werden. Berichte/ Proto-

kolle können automatisch nach Zeit oder auch bei bestimmten Ereignissen ausgegeben wer-

den.

Eine Protokollierung kann über das WinCC Add-on erfolgen. Dabei können Mess- und Zähl-

werte, Labordaten, Rechenwerte und Betriebsmeldungen erfasst und archiviert und über Be-

richte protokolliert werden: z.B. 24-Stunden-Bericht, Tages-, -Monats-, -Jahresberichte, Be-

triebstagebuch und Protokolle.

Alarm und Ereignisse

Eine Anlage kann in mehrere Alarmbereiche aufgeteilt werden. Einzelnen Alarmen können

unterschiedliche Prioritäten und Meldeklassen zugeordnet werden. Sie können zu verschiede-

nen Zielen, wie Drucker, Prozessbild, Alarmliste, Personenrufanlage etc. geschickt werden.

Quittierungen von Alarmen können direkt im Prozessbild oder über eine Alarmliste erfolgen.

Es besteht darüber hinaus die Möglichkeit, Alarme an überlagerte Systeme weiterzuleiten und

Quittierungen von dort in Empfang zu nehmen. Es stehen umfangreiche Filter-, Sortier- und

Statistikfunktionen zur Auswertung von Alarmen und Ereignissen zur Verfügung.

Betriebsstundenzähler

Mit Hilfe eines Betriebsstundenzählers können die Laufzeiten von Aggregaten in der Anlage

überwacht werden. Nach einer vorgewählten Zeit erfolgt eine Meldung auf dem Drucker; die-

se wird auch in eine Datenbank geschrieben.

67

Bedienen und Beobachten über das Web

Der WinCC/Web Navigator bietet die Möglichkeit, die Anlage auch über das Internet oder

firmeninterne Intranet zu bedienen und zu beobachten, ohne dass dazu Änderungen am

WinCC-Projekt notwendig sind. Am Web-Client genügt dazu ein Browser (z.B. Microsoft

Internet Explorer). Web-Clients können in die anlagenweite Benutzerverwaltung integriert

werden.

WinCC beseteht aus folgenden Basissystemen:

• Das Bediensystem verwaltet die Benutzeraccounts und Variablen

• Das Grafiksystem stellt durch vorgefertigte Zeichnungen das Visualisierungssystem zu-

sammen.

• Das Meldesystem listet Alarme und Warnungen auf, die auf Wunsch quittierungspflichtig

sind.

• Durch die Archivierung bzw. Protokollierung werden Messwerte abgespeichert und darge-

stellt.

Vorteile

Durch die dreifache Durchgängigkeit in Projektierung/Programmierung, Datenhaltung, Kom-

munikation und die integrierte Diagnose werden die Engineeringskosten einer Automatisie-

rungslösung erheblich gesenkt.

Nachteile

• Beim Anpassen an eine komplexe AT-Architektur sind zusätzliche Werkzeuge nötig

• Viele interessante Funktionen nur mit S7-400 möglich

• Leider nur für große Projekte einsetzbar

68

3.4.3 LabVIEW vs. WinCC

Mit der Berücksichtigung der Vorteile und Nachteile der beiden Standard-Software (s. Kapitel

3.4) bezogen auf das SCADA Steuerungssystem ist WinCC mehr oder minder für Massen-

produktion an den Fabriken bzw. große Projekte konzipiert und nicht so wie LabView für

kleinere Projekte wie dieses sehr gut geeignet. Daher fällt die Entscheidung als Standard-

Software für das SCADA Steuerungssystem LabView einzusetzen.

3.5 Realisierung und Implementation des Systems

Die Realisierung des Systems gliedert sich in mehreren logischen Einheiten, die sich wie

nachfolgend weiter unterteilen. Das Konzept wird nach Untersuchen der vorhandenen Tech-

nologien realisiert und implementiert. (s. Bild 3.15 )

Bild 3.15 Schematische Darstellung der Kommunikationsteilnehmer

69

3.5.1 Leitstand und seine Aufgaben

Es ist die Anforderung an den Leitstand, dass der sich nicht auf dem Fahrzeug, sondern abge-

setzt davon befinden soll. Daraus resultiert dann auch die Forderung nach einer drahtlosen

Anbindung und Kommunikation mit dem Fahrzeug. Der Leitstand realisiert das Mensch-

Maschine-Interface, über das eine Kommunikation stattfindet. Die interne Kommunikation

zwischen Leitstand und dem Fahrzeug basiert auf eine TCP/IP und CAN-Protokoll. Für die

eigentliche Übertragung wird eine Funkverbindung gemäß IEEE 802.11g eingesetzt, da das

auch ein Teil der Anforderung an das System ist.

Bild 3.16 Leitstand des SCADA Steuerungssystem

70

3.5.2 Die Funktionen des Leitstandes sind wie folgt aufgeteilt:

● Einlesen von Steuerinformationen mittels PC-Lenkrad

● Visualisierung der Prozessvariablen

● Auswahl des Fahrmodus (Autonom / Manuell)

● Drahtlose Kommunikation mit dem Fahrzeug

● Verwaltung der Steuerdaten in der Datenbank

Der Leitstand hat die Aufgabe, die Daten (Richtung- und Geschwindigkeit-Soll-Werte) aus

einem PC-Lenkrad zu lesen, sie zu visualisieren und sie mit der Fahr-Modusinformation für

CAN-Frame zum Senden an das Fahrzeug darzustellen. Des Weiteren übernimmt der Leit-

stand die Aufgabe, die aktuell vom Fahrzeug gesendeten Steuerdaten so wie die Sensorwerte

vom Fahrzeug zu visualisieren und sie in eine Datenbank ab zu speichern.

Da die entwickelte Software auf dem Fahrzeug die Möglichkeit bietet, das Fahrzeug manuell

bzw. autonom zu steuern, kann man bei der Bedieneinheit durch einen Fahrmodus-Schalter

die Steuerungsart wählen.

Im Falle, dass das Fahrzeug autonom fahren soll, fährt das Fahrzeug Wand entlang. Im manu-

ellen Fahrmodus kann man das Fahrzeug vom Leitstand aus durch das Lenkrad und die Peda-

len in allen Richtungen steuern.

3.5.3 Prinzipieller Aufbau der Leitstand-Software

Für die Gestaltung der Leitstandsoftware sollte man eigentlich Modelle des Software Engi-

neering anwenden, aber bei der Verwendung der Standard-Software LabVIEW ist man ge-

zwungen mit Schleifen zu arbeiten. Deswegen gestaltet sich die Leitstandsoftware grundsätz-

lich als zwei Endlosschleifen, welche folgend als Flussdiagramm beschrieben wird, siehe Bild

3.17.

71

Bild 3.17 Flussdiagramm der Leitstandschleifen zu Steuerung des Fahrzeuges

72

Nach dem die Leitstandsoftware gestartet worden ist, wird erstmal die Initialisierung der PC-

Lenkrad und Gas/Bremspedalen sowie das Öffnen einer TCP/IP Socket-Schnittstelle stattfin-

den. Durch die Initialisierung der Hardware wird der Software die Hardware bekannt gemacht

und es wird vorbereitet, die Steuerdaten aus der Hardware zu lesen.

Beim Öffnen einer TCP/IP Socket-Schnittstelle wird ein Socket zum Aufbau einer Verbin-

dung vom Client und Server mit Hilfe des OPEN-TCP VI’s erstellt und damit eine Instanz der

Socket-Schnittstelle geschaffen und das Transportprotokoll festgelegt. Wie man aus der Sen-

de-Schleife entnehmen kann, worden nach der Initialisierung der angeschlossenen Hardware

die Daten aus dem PC-Lenkrad und Pedalen eingelesen und in lokale Variablen abgespeichert

bzw. auf dem Leitstand visualisiert. Darauf folgend wird der Fahrmodus berücksichtigt.

Die gelesenen Steuerdaten werden für die Servomotoren in der Sende-Schleife umgerechnet,

um eine Rechenlast für das Aksenboard zu vermeiden, da es mit nur 8 Bit rechnet.

Der Zahlenbereich von Lenkrad und Pedalen ist von -32767 bis 32767, d.h.: von 0 bis -32767

in Links-Richtung und von 0 bis 32767 in Rechts-Richtung. Für die Geschwindigkeit des

Fahrzeuges entspricht 0 dem Stillstand bis 32767 der höchste Geschwindigkeit vorwärts, so

wie bis -32676 rückwärts. Nach der Umrechnung der Steuerdaten wird eine Zahl/Hex-String-

Umwandlung so wie Stringkonkatinierung stattfinden.

Um Daten über TCP zu senden, wird in dieser Schleife TCP-Schreiben -VI verwendet. Der

konkatinierte String wird dann per TCP-Schreiben-VI and den Kommunikationsrechner ge-

sendet. Damit der Puffer des CAN/WLAN-Moduls nicht mit gesendeten Steuerdaten überlas-

tet wird, wiederholt die Sende-Schleife die Prozedur alle 50ms einmal.

Die Empfangs-Schleife funktioniert aus Synchronisationsgründen ebenfalls alle 50 ms wie

die Sende-Schleife. In der Empfangs-Schleife werden die aktuell gesendeten Daten aus dem

Fahrzeug gelesen. Um Daten über TCP zu empfangen werden TCP-Lesen-VI verwendet.

Die durch TCP-Lesen-VI gelesenen Daten werden analysiert, visualisiert und schließlich in

eine Datenbank abgespeichert.

73

3.5.4 Schnittstellenspezifikation für das SCADA System

Die Kommunikation der Daten zwischen den Rechnern soll zum einen über WLAN zwischen

dem Leitstand und dem Kommunikationsserver und zum anderen über den CAN-Bus zum

Aksenboard realisiert werden.

Für sämtliche Nachrichten beider Busse wird die MSB-Byteorder (Most significant byte first)

festgelegt. Alle Nachrichten werden zyklisch versand. Falls keine Informationen über die zu

versendeten Daten bzw. Änderung der Daten vorliegen, so werden auch keine Daten gesendet,

das heißt: es wird im Kommunikationsserver geprüft ob Datenänderungen vorliegen oder

nicht? Diese Überprüfung dient dazu, das CAN-WLAN-Modul nicht mit gleichen Daten zu

überlasten.

Der CAN-Bus wird mit einer Baudrate von 125 kBits/ s betrieben, allerdings die Baudraten-

änderung kann man jeder Zeit vornehmen. Für die Regelungstechnik ist es unerlässlich, dass

wichtige Daten ihren Empfänger innerhalb garantierter Zeiten erreichen. Zu diesem Zweck

wird die Paket-ID des CAN-Standards eingesetzt, um die Zugriffspriorität zu bestimmen. Das

aber kommt bei dieser Kommunikation nicht zustande, da es in diesem Netz nur einen Knoten

gibt. Der Datenteil kann von null bis acht Byte variieren. Die 29 Bit der Paket-ID werden hier

für Priorität und Knoten des Netzes nicht separiert. Wie schon oben erwähnt, ist bei einem

einknotigen Netz die Paket-ID nicht notwendig.

Die anwendungsspezifischen Datenpakete beginnen stets mit dem ASCII Zeichen “T“, gefolgt

von den 29 Bit CAN-ID, dann die Angabe der Datenlänge(0-8)in Byte und anschließend die

Steuerdaten der zugehörigen Prozessvariablen je nach Datenlänge in Hex-Value.

Die Pakete haben somit eine Länge von 12 Byte.

T Paket-ID (29 Bit) Datenlänge (0-8) Nutzdaten (8Byte)

Tabelle 3.5 Aufbau des WLAN-Datenpaketes

74

Aufgaben des JAVA Kommunikationsservers

Da eine direkte TCP/IP Kommunikation zwischen Leitsatnd (LabVIEW) und CAN-WALN-

Modul trotz langer Untersuchungen aus Einstellungsgründen des CAN/WLAN-Moduls nicht

möglich war, wurde ein Kommunikationsrechner unter Verwendung der Programmiersprache

Java implementiert. Er fungiert als eine Brücke zwischen Leitstand und CAN/WLAN-Modul.

Der Kommunikationsserver hat die Aufgabe einerseits eine Verbindung über TCP/IP zu

CAN/WLAN-Modul aufzubauen, sie mit Kanal/Baudrateneinstellungen zu initialisieren und

andererseits die Verbindung ebenfalls über TCP/IP zu LabVIEW zu etablieren. Eine Neben-

läufigkeit der Prozesse wird durch Sende und Empfangs Threads realisiert. Der Kommunika-

tiossrechner besteht aus 2 Threads, Sende- und Empfangs-Thread, die ein reibungsloses Sen-

den und Empfangen der Daten bereitstellen. Zusätzlich noch aus vier While-Schleifen. Die

erste While-Schleife ist für die Kommunikation zwischen LabVEW-Client und Java-Server

zuständig. Die zweite Schleife übernimmt die Aufgabe, die vom LabVIEW-Client empfange-

nen Daten zu analysieren und aus denen nach CAN-Spezifikation ein Paket zusammen zu

bauen. Dieses Paket wird in dieser Schleife zusammen gebaut und besteht aus folgenden

Komponenten:

- „T“, Der Buchstabe T stehet für Transmission. Das CAN/WALN-Modul erwartet den Buch-

staben T am Anfang des Paketes, um Daten von WLAN zu CAN bzw. von CAN zu WLAN

zu übersetzen.

- ID des Pakets mit 29 Bit („Extended CAN-Frame 2.0B“), also zur Identifizierung des

Netzknotens bzw. zu Identifizierung des Nachrichtentyps.

- Datenlänge 0 bis 8 Byte, Angabe der Datenlänge, damit das CAN/WLAN-Modul weiß, wie

viele Daten zum Übersetzen ankommen.

- Daten, eigentliche Nutzdaten, die zur Steuerung des Fahrzeuges bestimmt sind.

Nach dem das CAN-Frame Paket erstellt und zusammen gebaut worden ist, wird es an das

CAN/WLAN-Modul gesendet.

Die dritte Schleife beschäftigt sich ebenfalls mit der Kommunikation zwischen CAN/WLAN-

Modul und Java-Server.

75

Die vierte Schleife hat die Aufgabe, die empfangenen Daten zu analysieren und aus dem

CAN-Frame die Nutzdaten heraus zu fischen und sie danach an den Leitstand(LabVIEW-

Client) zu senden.

3.5.5 Funktionsweise des CAN/WLAN-Moduls

Im Rahmen dieser Bachelorarbeit übernimmt der IGW400/CAN (CAN/WLAN-Modul) die

Datenumsetzung. Mit anderen Worten: Der Datenaustausch zwischen dem Leitstand und dem

Fahrzeug wird über eine WLAN-Verbindung und den CAN-Bus abgewickelt. Die vom

Kommunikationsserver zusammengebauten und vom Sende-Thread gesendeten Pakete kom-

men bei CAN-WLAN-Modul an. Der CAN-WLAN-Modul wandelt die empfangenen

WLAN-Pakete in CAN-Pakete um und sendet sie über den CAN-Bus zum Aksenboard. Das

heißt: das Modul arbeitet wie die oben definierte Schnittstellenspezifikation (siehe Tabelle

3.5).

Darüber hinaus wird aus dem empfangenen String durch den Microkontroller ein CAN-Frame

nach vordefiniertem „Extended“-CAN-Frame zum Übertragen gebildet, und dieser Frame

wird dann auf den CAN-Bus geschickt. In diesem Projekt wird nur der eine Kanal des CAN-

Busses zum Senden und Empfangen benutzt. Allerdings besteht die Möglichkeit, beide Kanä-

le zu verwenden.

3.5.6 CAN-Schnittstelle und Steuerung des Fahrzeuges

Auf dem Aksenboard ist eine CAN-Schnittstelle programmiert, die die CAN-Pakete liest.

Da die CAN-Schnittstelle optional ist, sind die Funktionen zur Ansteuerung des Fahrzeuges in

einer eigenen Datei untergebracht. Um die Funktionen nutzen zu können, müssen die Dateien

can.c und can.h sich im Projektverzeichnis befinden. Die Datei can.c muss kompiliert und

zum Lenkvorgang hinzugefügt werden, während der Header can.h per include-Anweisung in

den Quellcode eingebunden wird.

Die Initialisierung der CAN-Schnittstelle übernimmt die Funktion void CanInit (void) . Die

Konfigurationseinstellungen in dieser Funktion sind in der gut dokumentierten can.c einge-

stellt. Sie können manuell jeder Zeit nach anderen Spezifikationen geändert werden. Die

76

Kommunikation erfolgt über die Funktionen int CanEmpfang (struct CAN_MSG xdata

*CanBotschaft) und int CanSenden (struct CAN_MSG xdata *CanBotschaft), wobei bei-

den ein Zeiger auf die Datenstruktur CAN_MSG übergeben werden muss. Beide Funktionen

geben im Erfolgsfall eine 1 (also TRUE), ansonsten eine 0 (FALLS) aus.

int CanEmpfang (struct CAN_MSG xdata *CanBotschaft); holt eine empfangene CAN-

Botschaft von der CAN-Schnittstelle ab und füllt damit die übergebene CAN_MSG-Struktur.

int CanSenden (struct CAN_MSG xdata *CanBotschaft); sendet die übergebene CanBot-

schaft. [CoArNe]

CAN-ID und die Nutzdaten werden aus der übergebenen CAN_MSG-Struktur ausgelesen und

in verschiedenen Puffern gespeichert. Die Nutzdaten werden dann über Aksenboard durch die

Funktionen void lenk(unsigned int impulebereite) und void fahr(unsigned int geschwin-

digkeit) an die Servomotoren zum Lenken und Steuern des Fahrzeuges weiter geleitet. Inner-

halb der beiden Funktionen void lenk() und void fahr() werden dann die Funktionen ser-

vo(LENK_SERVO, lenkServoWert) und servo(FAHR_SERVO, fahrServoWert) aufgeru-

fen und denen dann die aktuelle Richtung und Geschwindigkeitswerte übergeben. Das Fahr-

zeug reagiert dann der empfangenen Steuerwerte entsprechend.

Aber auch umgekehrt, Daten vom Fahrzeug und die aktuelle Geschwindigkeit, Lenkradstel-

lung oder auch Sensorwerte aus analogen bzw. digitalen Ports werden gelesen und zum Leit-

stand über den CAN-Bus durch die intCanSenden (struct CAN_MSG xdata

*CanBotschaft) Funktion gesendet. Das Aksenboard verwendet wiederum die gleiche Ver-

bindung und den gleichen Paketaufbau, um Steuerinformationen sowie die aktuellen Sensor-

werte an den Leitstand zu senden.

77

Für die autonome Steuerung des Fahrzeugs wird der Teilcode von Herrn Zubaidullah Arsa-

lans Bachelorarbeit verwendet bzw. der Teilcode wird in den Sourcecode zur autonomen

Steuerung des Fahrzeuges integriert [Arsalan].

So bald man am Leitstand den Fahrmodusschalter von manuell auf autonom umschaltet, än-

dert sich die Steuerung des Fahrzeugs von Manuell auf Automatik und das Fahrzeug fährt

dann nach dem vorprogrammierten Programm dann autonom einer Wand entlang weiter.

3.5.7 Implementation und Werkzeuge

Die Realisierung des SCADA-Systems (Leitstand, Kommunikationsrechner, CAN-

Schnittstelle und Fahrzeugsteuerung) erfolgt unter dem Betriebsystem Windows XP und der

Verwendung der grafischen Programmierung LabVIEW, Java und C. Die Visualisierung der

Prozessvariablen beim Leitstand (Fahrzeugrichtung und Fahrzeuggeschwindigkeit), Zusam-

mensetzung der CAN-Frame, so wie TCP/IP Client zum Steuerdaten Senden/Empfangen wird

mit LabVIEW programmiert. Ausschlaggebend für die Verwendung von LabVIEW, statt ei-

ner herkömmlichen Programmierung (z.B. Java oder C) war das Vorhandensein der umfang-

reichen Bibliotheken, die den Programmieraufwand deutlich gering halten.

Die entstehende Anzeige und die Bedienelemente erlauben die Gestaltung einer ansprechen-

den Bedienoberfläche. Hinzu kommt die Unterstützung einer breiten Palette von I/O-Geräten

wie zum Beispiel dem verwendeten PC-Lenkrad. LabVIEW gewinnt seine Stärke jedoch erst

durch die eigene Programmiersprache G, die es einem Programmierer ermöglicht, die erfor-

derlichen Funktionen selbst zu implementieren und ein den eigenen Wünschen entsprechen-

des Programm zu programmieren bzw. zu verwirklichen.

78

Mit der LabVIEW Entwicklungsumgebung lassen sich ausführbare Programme bzw. Dateien,

also das so genannte VI (Visual Instrument) erstellen. Für deren Ausführung ist die Installati-

on der LabVIEW Runtime Engine zwingend erforderlich, die auch Bestandteil der Entwick-

lungsumgebung ist. Es ist zu beachten, dass für die Installation der Runtime Engine die Ad-

ministratorrechte benötigt werden. Im Bild 3.18 abgebildete LabVIEW-Umgebung entpricht

der LabVIEW Version 7.1.

Bild 3.18 Screenshot von der LabVIEW-Entwicklungsumgebung

79

Außerdem beansprucht das SCADA-System eine reibungslose Kommunikation zwischen den

Kommunikationsteilnehmern. Um die Anwendung und damit den Anwender nicht fest an ein

Betriebssystem zu binden, wird als Programmiersprache JAVA (Version1.5.0) für die Imple-

mentation des Kommunikationsservers verwendet. Darüber hinaus ist die Socketschnittstellen

Programmierung unter Java einfacher und im Vergleich zu C nicht so zeitaufwendig. Die Ent-

wicklung findet unter Windows XP statt, als Entwicklungsumgebung bietet sich das freie Ec-

lipse [ECli] siehe Bild 3.19 in der Version 3.1 an.

Bild 3.19 Screenshot von der Eclipse-Entwicklungsumgebung

80

Das Aksenboard ist mit einem CAN-Bus Interface bestückt. Für die Steuerung des Systems

muss diese CAN-Schnittstelle nach CAN-Spezifikation gelesen werden. Das CAN-

Schnittstellen Programm zum Lesen des CAN-Busses, Steuerung der Servomotoren so wie

Lesen der Sensorports und das Senden der Daten an Leitstand wurde unter Verwendung der

Programmiersprache C geschrieben und mithilfe des freien C-Compilers avr-gcc übersetzt. Da

die Entwicklung unter dem Betriebssystem Windows XP stattfindet, kommt die Software-

sammlung WinAVR in der Version 4.1 zum Einsatz. Sie beinhaltet neben dem Compiler und

anderen Tools die Laufzeitbibliotheken [avr-libs] und die zugehörige Dokumentation. Um den

Quellcode zu schreiben, wird der Texteditor ConTEXT [ConTex] in der Version 2.0.5.48

verwendet siehe Bild 3.20.

Bild 3.20 Screenshot vom ConText-Editor

81

3.5.8 Access-Datenbank

Laut der Anforderung an das System, benötigt der Leitstand einen Datenbankzugriff, um die

vom PC-Lenkrad/Gas-Bremspedalen gelesenen Steuerinformationen (Soll-Werte) bzw. aus

dem Fahrzeug gelesenen Steuerinformationen (Ist-Werte) und die Sensorenwerte in die Da-

tenbank abzuspeichern.

Dieser Teil der Realisierung am System, also die Programmierung der Lab-

VIEW/Datenbankschnittstelle wurde aufbauend auf den Voruntersuchungen von Eric Robert

und Maxim Van de Moortele realisiert. [EricMaxim]

Die Datenbank-VI ist an die Leitstandsoftware angepasst. Die empfangenen Telemetrie und

Sensordaten können je nach Datum und Uhrzeit problemlos in die Datenbank abgespeichert

werden. Die zugehörige VI wird im Anhang angehängt. Bild 3.21 stellt einen Auszug aus der

Datenbank dar.

Bild 3.21 Auszug aus der Datenbank

82

4 Zusammenfassung

4.1 Resümee

Ziel dieser Bachelorarbeit war die Bereitstellung einer Kommunikationsschnittstelle zwischen

einem Leitstand und einem autonomen fahrerlosen Transportsystem. Des Weiteren war das

Ziel eine Art Telemetrie bzw. Automatisierung, Überwachung der Prozesse so wie die Ver-

waltung und Abspeicherung der entstandenen Ergebnisse zu realisieren.

Es wurde zuerst auf die theoretischen Grundlagen der zu verwendeten Technologien einge-

gangen und deren Funktionsweise untersucht. Die Analyse der vorhandenen Technologien

führte zur Auswahl von WLAN und LabVIEW.

Anschließend wurde ein Lösungskonzept erstellt. Die für dieses Konzept benötigte Hardware

wurde aufgelistet und deren Funktionsweise dargestellt.

Des Weiteren wurden zwei Standard-Software untersucht und die für das Konzept passende

Software ausgewählt.

Eine reibungslose Kommunikation und der Datenaustausch zwischen den Kommunikations-

teilnehmern sind nach der Anforderung an System im Kapitel 1.2 gegeben.

Mit dem im Rahmen dieser Bachelorarbeit entwickelten Steuerungssystem ist es jetzt möglich

aus einem Leitstand drahtlos ein autonomes fahrerloses Transportsystem zu steuern.

83

4.2 Aussichten und Weiterführung

Es gibt auch weiterführende Möglichkeiten diese Arbeit weiter zu entwickeln. Der nächste

Schritt währe die Realisierung des Systems für mehre autonome Fahrzeuge aus einem Leit-

stand. Also, eine Kommunikation zwischen mehreren Fahrzeugen und somit einen Datenaus-

tausch der Kommunikationsteilnehmer und deren Verwaltung.

Es sind auch mehrere Optimierungsmöglichkeiten im Design des Konzepts denkbar: z.B.

- Eine Datenverschlüsselung auf Grund der Funktechnologie. Dann kann man die gesendeten

Datenpakete je nach Wichtigkeit verschlüsseln.

- Ferner eine Videobildanzeige mittels einer separaten Anwendung durch Web-Browser.

Da LabView ActiveX-Container für die Oberflächengestaltung anbietet, ist es möglich, einen

solchen in die Bedieneinheit zu integrieren und ihn mit dem obligatorischen Internet-Explorer

zu verknüpfen.

84

Literaturverzeichnis

Bücher und Dokumentationen:

[JoGut] IEEE 108.11.x Low-Rate Wireless Personal Area Networks: Enabling Wireless

Sensor Networks

Jose A. Gutierrez, Edgar H. Callaway, Raymond Barrett

ISBN 0-7381-3557-7

[AnHac] Wireless Sensor Network Designs

Anna Hac

ISBN 0-470-86736-1

[WLANBlu] Das große Buch Wireless LAN & Bluetooth

Andreas Lerg & Annette Stolz

ISBN 3-8158-2500-8

[WLABlu] Wireless LANs and Bluetooth

Yang Xiao, Yi Pan

ISBN 1-59454-432-8 (hardcover)

[AnTan] Computernetzwerke

Andrew S. Tanenbaum

4. Auflage, 2003, Pearson Studium

ISBN 3-8273-7046-9

[CANCoAr] CAN Controller Area Networks

Wolfhard Lawrenz(Hrsg) (2000)

ISBN 3-7785-2780-0

[CoArNe] Controller Area Network

Konrad Etschberger

ISBN 3-446-21776-2

85

[LabVIEW] LabVIEW für Studenten

Rahman Jamal, Andere Hagenstedt (2004)

Addison-Wesley München

ISBN 3-8273-7154-6

[GuiKru] Handbuch der Java-Programmierung

Guido Krüger

ISBN 3-8273-2201-4

[WEDI] Wedico 2001 WEDICO: Wedico Bauanleitung Elektrische Anlage,

Art.-Nr. 782. 17.04.2001

[EricMaxim] Praktikumsreport zur Datenbankanbindung PDF

Eric Robert und Maxim Van de Moortele

Juni 2006

[Arsalan] Bachelorarbeit

Zubaidullah Arsalan

Februar 2006

WWW -Referenzen:

[CAN-CIA] CAN, CAN in Automation (CAN-CIA), CAN Specification 2.0, Part B

http://www.can-cia.ru/CAN20B.pdf

(Letzter Zugriff: 10.06.2006)

[Bosch] Firma BOSCH, BOSCH CAN Specification Version 2.0, 1991

http://www.semiconductors.bosch.de/pdf/can2spec.pdf

(Letzter Zugriff: 12.06.2006)

[ShoRan] Short Range Wireless Lecture

http://www.isas.tuwien.ac.at/upload/downl/shortrangewirelessleture

_2005_1.pdf

(Letzter Zugriff: 16.09.2006)

86

[WLABuc] WLAN Buch

http://www.feld-it.de/wlanbuch.pdf

(Letzter Zugriff: 17.09.2006)

[IEEE802.11.x] Specification Wireless LAN Networks

http://standards.ieee.org/getieee802/download/802.15.4-2003.pdf

(Letzter Zugriff: 18.09.2006)

[BlToo] Informationen Bluetooth

http://de.wikipedia.org/wiki/Bluetooth

Letzter Zugriff: 12.08.2006)

[WinCC1] WinCC Version 6 Systembeschreibung

http://www.softguide.de/prog_h/ph_0281.htm

(Letzter Zugriff: 28.09.2006)

[WinCC2] Systembeschreibung

http://www.automation.siemens.com/hmi/html_00/

products/software/wincc/index.htm

(Letzter Zugriff: 29.09.2006)

[ECli] Eclipse und SWT-Bibliothek

http://www.eclipse.org/

(Letzter Zugriff: 12.05.2006)

[ConTex] Labor für Künstliche Intelligenz an der FHB

http://ots.fhbrandenburg.de/index.php

(Letzter Zugriff: 10.06.2006)

[AksBor] Labor für Künstliche Intelligenz an der FHB

http://ots.fhbrandenburg.de/index.php

(Letzter Zugriff: 10.06.2006)

[Conr-05] Infrarot Distanzsensoren

http://www.conrad.de

(Letzter Zugriff: 13.010.2006)

87

[Wal-Emb] Walter, Embedded Internet in der Industrieautomation.

Hüthig Verlag 2004.])

http://www.ssv-embedded.de/ de/igw400-APN1.pdf])

(Letzter Zugriff: 08.06.2006)

[Aks_Bor]. Labor für Künstliche Intelligenz an der FHB

http://ots.fhbrandenburg.de/index.php.

(Letzter Zugriff: 10.06.2006)

[Siemens] Forschung und Innovation

http://w4.siemens.de/FuI/de/archiv/zeitschrift/heft1_00

/artikel10/index.html

(Letzter Zugriff: 19.09.2006)

[SSV1] SSV Embedded Systems Documents

http://www.ssv-comm.de/de/bilderarchiv.htm

(Letzter Zugriff: 10.06.2006)

88

Anhang

Im Anhang befindet sich eine CD-ROM mit folgendem Inhalt:

� Aksenboard_CD � Bachelor_PDF � Datenabnk � Dokumentation_PDF � SCADA_Video � Sourcecode

• Das Verzeichnis Aksenboard_CD enthält die Bibliotheken des Aksen-

Boards, das Handbuch und alle benötigte Programme zum Programmierung

des Aksen-Boards.

• Das Verzeichnis Bachelor_PDF enthält diese Bachelorarbeit im PDF-Format.

• Im Verzeichnis Datenbank befindet sich die Accessdatenbank

• Das Verzeichnis Dokumentation_PDF beinhaltet die elektronische Literatur, die im Rahmen

dieser Arbeit benutzt wurde.

• Im Verzeichnis SCADA_Video befinden sich die Videoaufnahmen, die während des

Tests des autonomen Modell-Fahrzeuges aufgenommen wurde.

• Das Verzeichnis Sourcecode enthält die VI’s des Leitstandes, den Quellcode des Java-

Kommunikationsservers, das Datenbankanbindung VI, den Quellcode des CAN-Interfaces

und den Quellcode der Fahrzeugsteuerung

Versicherung über Selbstständigkeit

Hiermit versichere ich, dass ich die vorliegende Arbeit im Sinne der Prüfungs-ordnung nach §22(4) ohne fremde Hilfe selbstständig verfasst und nur die ange-gebenen Hilfsmittel benutzt habe.

_____________________________________ ____________________________

Ort, Datum Unterschrift