Leseprobe
Inhaltsverzeichnis
1 Einleitung
1.1 Interplanetarer Staub
1.2 ÜberdieseArbeit
1.2.1 Zielsetzung
1.2.2 Aufbau
2 Die Cassini-Huygens-Mission und der Cosmic-Dust-Analyzer
2.1 Beschreibung der Cassini-Huygens-Mission
2.2 Der Cosmic-Dust-Analyzer (CDA)
2.2.1 Aufgaben des CDAs
2.2.2 Aufbau und Funktionsweise des CDA
2.2.3 Der High-Rate-Detector
3 Beschreibung des Web-Interface
3.1 Beschreibung der Datenbank
3.2 Web-Interface zur Auswertung der CDA-Daten
3.2.1 Leistungen des Web-Interface
3.2.2 Aufbau und Motivation
3.2.3 Beschreibung des GUI
4 ÜbersichtüberdenDatenbestand
4.1 Definition der Drehachsen der Raumsonde
4.2 ÜbersichtüberdieBewegungCassinisiminterplanetaren Raum
4.3 Die Aufnahme eines Videos von Jupiter
4.4 Gesamtrate der vom CDA registrierten Ereignisse
5 Störungen und Testpulse
5.1 Störungen
5.2 Testpulse
5.3 Störung durch den RPWS-Sounder
5.4 Bow-Shock-Crossings
6 Einschläge von Staubteilchen
6.1 Jupiter-Staubstromteilchen
6.2 Gemeinsame Messung der Sonden Cassini und Galileo
6.3 Interplanetarer Staub
6 INHALTSVERZEICHNIS
7 Zusammenfassung der Datenklassen
A Aufbau und Installation des Web-Interface
A.1 Funktionsweise des GUI
A.2 Funktionsweise der Servlets
A.2.1 Die textbasierte Auslese: DataServlet.java
A.2.2 Die Auslese der Signale: TesinaServlet.java
A.2.3 Die Histogramm-Funktion: HistoryServlet.java
A.3 Einrichtung des Web-Servers
A.4 Installation des Datenbanktreibers
A.5 Persönliche Empfehlungen zum Thema Java
B Beschreibung der Tabellen der Datenbank
Literaturverzeichnis
Kapitel 1
Einleitung
1.1 Interplanetarer Staub
Interplanetarer Staub wurde erstmals 1683 von Cassini erwähnt, als er das Zodiakallicht erklärte. Er erkannte, daß das Zodiakallicht durch Streuung des Sonnenlichts an kleinen Staubpartikeln, die sich zwischen Sonne und Erde befinden, hervorgerufen wird.
Ein weiteres Phänomen, welches durch interplanetaren Staub hervorgerufen wird, sind Meteore und Sternschnuppen. Wenn ein Staubpartikel mit einem Durchmesser von ca. einem Zentimeter und einer Geschwindigkeit ≥ 10 km/s in die Erdatmosphäre eintritt, wird seine Bewegungsenergie in Wärme umgewandelt. Diese reicht aus, um das Teilchen zu verdampfen. Dabei l ösen sich seine Oberfläche- natome, welche aufgrund ihrer hohen kinetischen Energie die Gasmolek üle der Atmosphäre anregen und ionisieren k önnen. Entlang ihrer Trajektorie hinterlassen sie eine kilometerlange leuchtende Spur, die von der Erde aus zu beobachten ist.
Während man sich fr üher in der Staubforschung mit Beobachtungen des Zodiakallichts und der Me- teore begn ügen mußte, stellten sich mit den Fortschritten in der Luft- und Raumfahrttechnik weitere Observationsmethoden ein. In der Stratosphäre sammeln Flugzeuge mit speziellen Staubkollektoren Mikrometeoriten ein; Mondgestein weist sogenannte Mikrokrater auf, die durch Staubeinschlag her- vorgerufen wurden. Gegen Ende des 20. Jahrhunderts wurden eine Reihe von Raumsonden durch un- ser Sonnensystem geschickt, die, mit Staubdetektoren ausgestattet, Fluß, Ladung und z. T. die chem. Zusammensetzung der Staubpartikel im Sonnensystem messen. Einige Missionen sind in Tabelle 1.1 dargestellt.
Tabelle 1.1: Ausgewählte Raumsonden mit Staubdetektoren. Die Massengrenze bezieht sich auf Einschlagsgeschwindigkeiten von 20 km/s
Abbildung in dieser Leseprobe nicht enthalten
Durch theoretische Überlegungen und Messungen wurde u.a. festgestellt, daß Staubteilchen nur ei- ne begrenzte Lebenszeit im Sonnensystem haben. Kleine Partikel mit Durchmessern <1 µm werden durch den Strahlungsdruck des Sonnenwinds oder der Lorentzkraft aus dem Sonnensystem getrieben. Bei größeren Teilchen (Durchmesser ≤100 µm) überwiegen Gravitation und Poynting-Robertson- Effekt, so daß sie sich langsam der Sonne nähern. Berechnungen zeigen, daß ein 10 µm großes, steiniges Teilchen nur einige 104 Jahre benötigt, um sich aus einer Entfernung von 2 AE der Sonne so weit zu nähern, um zu verdampfen. Dieses geschieht je nach chemischer Zusammensetzung der Partikel in einer Entfernung von ca. 2-4 Sonnenradien (KRIVOV & Mitarb., 1998).
Demzufolge hätte unser Sonnensystem im Laufe seiner Existenz längst staubfrei werden m üssen, wenn es keine Quellen gäbe. Als Staubquellen wurden zuerst Kometen und Asteroiden identifiziert. Im Jahre 1992 entdeckte Ulysses Staubstr öme im Jupitersystem deren Quelle in den Vulkanen des Jupitermondes Io lagen (GR ÜN & Mitarb., 1993). Zudem wird unser Sonnensystem auch von inter- stellarem Staub durchsetzt.
Somit ermöglicht die Staubforschung durch die Untersuchung von Mikrometeoriten die Beschaffung von Informationen über ihre Mutterk örper, die auf andere Art kaum zugänglich sind. Abbildung 1.1 zeigt ein typisches Staubteilchen von ca. 15 µm Durchmesser. Aus der Linie, die die Elementhäufigkeit angibt, ist zu entnehmen, daß das Teilchen hohe Anteile von Magnesium, Silizium, Eisen und Schwefel besitzt.
1.2 ÜberdieseArbeit
1.2.1 Zielsetzung
Ziel dieser Arbeit ist die Präsentation erster Ergebnisse eines im Internet verf ügbaren Programms zur Visualisierung der vom Cosmic-Dust-Analyzer (CDA) an Bord der Raumsonde Cassini aufgenommenen Daten. Diese Daten sind in einer Datenbank im Max-Planck-Institut abgelegt. Um diese Daten Wissenschaftlern und anderen interessierten Personen in der ganzen Welt zur Verfügung zu stellen, wurde ein Web-Interface programmiert, das über verschiedene M öglichkeiten verfügt, Daten grafisch oder textbasiert darzustellen.
Neben der Erstellung des Programmes wird ein ÜberblicküberdenDatenbestandgegeben.Dabei werden die vorhandenen Daten anhand einiger Merkmale klassifiziert.
Die Arbeit mit dem Programm wird an einigen Beispielen gezeigt, indem verschiedene Ph änomene, die während des Flugs auftraten, analysiert werden.
1.2.2 Aufbau
In Kapitel 2 werden die Cassini-Huygens-Mission und der Cosmic-Dust-Analyzer (CDA) beschrie- ben. Die Messungen des CDA bilden den wissenschaftlichen Hintergrund dieser Arbeit. Für die Beschaffung und Analyse der Daten wurde vor allem das in Kapitel 3 beschriebene Web- Interface benutzt. Aus diesem Grund ist ihm ein ganzes Kapitel gewidmet, in dem sowohl seine Leistungen (Abschnitt 3.2), als auch sein Aufbau erklärt werden. Dem Leser, der nicht mit der Pro- grammiersprache Java vertraut ist, werden dabei wichtige Fachbegriffe kurz erkl ärt. Eine detailliertere Beschreibung des Programms ist im Anhang (A.2) zu finden. Die folgenden Kapitel widmen sich der Beschreibung des Datenbestands, wobei das Web-Interface zur Analyse benutzt wird. Kapitel 4 be- schreibt den Datenbestand als Ganzes, wobei die Untersuchung von Zusammenh ängen zwischen der Ausrichtung der Raumsonde und der Ereignisrate im Vordergrund steht. In Kapitel 5 werden St örun- gen und Testpulse beschrieben, während sich Kapitel 6 mit den registrierten Teilcheneinschlägen be- fasst.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1.1: Interplanetares Staubteilchen. Die Linie im unteren Teil des Bildes gibt die Elementhäufigkeit an, wie sie sich aus der charakteristischen R öntgenstrahlung ergibt, die durch hochenergetische Elektronen hervorgerufen wird.
Im Anhang befinden sich ein Kommentar zum Quellcode des Programms, der den Programmablauf und wichtige Methoden beschreibt (Kapitel A).
In Kapitel B sind Ausz üge aus einer Beschreibung der Datenbank zusammengefaßt. In ihm werden die durch das Web-Interface ausgelesenen Tabellen beschrieben.
Kapitel 2
2. Die Cassini-Huygens-Mission und der Cosmic-Dust-Analyzer
2.1 Beschreibung der Cassini-Huygens-Mission
Die Raumsonde Cassini (Abbildung 2.1, benannt nach dem italienisch-franz ösischen Astronom Jean- Dominique Cassini (1625-1712), wurde am 15. Oktober 1997 gestartet. Aufgrund ihrer großen Masse von 5,8t wurde sie zweimal durch das Gravitationsfeld der Venus, einmal durch das der Erde und einmal durch das des Jupiters beschleunigt (engl.: gravity-assist fly-by), um zus ätzlichen Impuls auf- zunehmen. Ihre Trajektorie im interplanetaren Raum ist in Abbildung 2.2 dargestellt. Zum Zeitpunkt der Erstellung dieser Arbeit befand sie sich zwischen Jupiter und Saturn. Sie wird ihr Ziel, das Sa- turnsystem, am 1. Juli 2004 erreichen. Danach soll sie im Laufe einer 4-j ährigen Mission den Saturn insgesamt 74 mal umkreisen und dabei den Planeten selbst, seine Monde, seine Magnetosph äre und sein Ringsystem erforschen (SPILKER, 1997).
Die europäische Sonde Huygens, die an Bord von Cassini mitfliegt, ist nach dem holl ändischen Mathematiker und Astronom Christian Huygens (1629-1695) benannt, der u.a. die Form der Saturnringe bestimmte und den Mond Titan entdeckte.
Titan ist nach dem Jupitermond Ganymed der zweitgr ößte Mond des Sonnensystems. Er besitzt eine dichte, größtenteils aus Stickstoff bestehende, Atmosphäre. Auf seiner Oberfläche werden Seen aus einem Methan/Ethan-Gemisch vermutet (DE PATER & LISSAUER, 2001).
Die Huygens-Sonde wird am 24. November 2004 in die Atmosph äre von Titan eindringen. Durch Fallschirme gebremst wird die Sonde innerhalb von 150 Minuten auf die Oberfl äche des Mondes prallen. Währenddessen werden verschiedene Experimente an Bord die Atmosph äre untersuchen, vor dem Aufprall werden Kameras die Oberfläche fotografieren. Sollte Huygens die Landung überstehen, reichen ihre Batterien noch aus, um bis zu 30 Minuten lang Daten von der Oberfl äche des Satelliten zu senden (SPILKER, 1997).
2.2 Der Cosmic-Dust-Analyzer (CDA)
Der Cosmic-Dust-Analyzer ist eines der zw ölf wissenschaftlichen Instrumente an Bord des CassiniOrbiters. Zugleich stellt er auch dasjenige Instrument dar, dessen Meßwerte die Grundlage f ür die in dieser Arbeit angef ührten Ausführungen bilden. Aus diesem Grund werden die Aufgaben des CDAs, sein Aufbau und seine Funktionsweise beschrieben.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1: Links im Bild ist der CDA zu erkennen
2.2.1 Aufgaben des CDAs
Die bisherigen Erkenntnisse aus in situ Messungen über das Saturnsystem beruhen auf den Resultaten der früheren Missionen Pioneer 11 (1979), Voyager 1 (1980) und Voyager 2 (1981). Diese Sonden erkannten, daß die Saturnringe aus tausenden von individuellen Ringen bestehen. Ein Viertel Jahrhundert nach Pioneer 11 wird Cassini das Saturnsystem erreichen. Im Gegegensatz zu seinen Vorgängern ist sie mit einem empfindlichen Staubdetektor ausgestattet. Die damit verbundenen wissenschaftlichen Aufgabenstellungen sind in folgender Liste zusammengefasst (SRAMA, 2001):
- Interplanetarer Raum
1. Ausweitung der Studien über interplanetaren Staub bis zur Saturnbahn.
2. Untersuchung der chem. Zusammensetzung von Staub im interplanetaren Raum und im Asteroideng ürtel.
3. Bestimmung des Flusses interstellarer Partikel während des solaren Maximums.
4. Suche nach Staubstr ömen aus dem Saturnsystem.
- Jupiter
1. Untersuchung der Dynamik der von Galileo und Ulysses entdeckten Io-Staubstr öme.
2. Untersuchung des Flusses von Staubstr ömen als Funktion der Entfernung von Jupiter.
3. Vergleich mit Messungen der Galileo-Sonde zur Bestimmung zeitlich ver änderlicher Phänomene.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.2: Trajektorie der Raumsonde Cassini im interplanetaren Raum.
4. Bestimmung der elementaren Zusammensetzung der Staubstromteilchen.
- Ringsystem des Saturn
1. Untersuchung der Staubverteilung nahe der Ringe im Hinblick auf Gr öße, Zusammenset- zung und Bahnen der Teilchen.
2. Chemische Analyse der Ringpartikel.
3. Suche nach Ringteilchen jenseits des E-Rings.
4. Untersuchung der f ür die E-Ring-Struktur verantwortlichen dynamischen Prozesse und der Wechselwirkung zwischen Ringteilchen und Magnetosph äre.
- Saturnmonde
1. Untersuchung, inwiefern die Eismonde des Saturn als Quelle f ür Staubteilchen in Betracht gezogen werden k önnen.
2. Bestimmung der chemischen Zusammensetzung von Ejektateilchen dieser Monde.
- Magnetosphäre des Saturn
1. Untersuchung von Staub als Quelle geladener Teilchen in der Magnetosph äre.
2. Suche nach kleinsten Staubpartikeln, die durch elektromagnetische Kr äfte dominiert wer- den.
2.2.2 Aufbau und Funktionsweise des CDA
Um den im vorigen Abschnitt genannten Aufgaben gerecht zu werden, wurden im Cosmic-Dust- Analyzer (CDA) 4 Komponenten integriert:
1. Das Eintrittsgittersystem QP (engl.: Primary charge) mißt die elektrische Prim ärladung und Geschwindigkeit eines durchfliegenden Teilchens. Ferner kann es zur Bestimmung der Teil- chentrajektorie genutzt werden.
2. Der Chemische Analysator CAT (engl.: Chemical Analyser Target) mißt Ladung und Massen- spektren beim Einschlag eines Teilchens.
3. Der Einschlagsionisationsdetektor IID (engl.: Impact ionisation detector) bestimmt physika- lische Parameter wie Teilchenmasse und Einschlagsgeschwindigkeit. Die Massenmessung er- folgt in einem Bereich von 10−15 − 10−5 g.
4. Der High-Rate-Detector HRD ist ein separater Detektor, der bis zu 104 Teilcheneinschläge pro Sekunde messen kann.
Die drei erstgenannten Komponenten wurden unter der wissenschaftlichen Leitung von Prof. E. Gr ün und durch Zusammenarbeit des Max-Planck-Instituts f ür Kernphysik in Heidelberg, der Universität Kent, des Instituts f ür Weltraumsensorik der DLR in Berlin sowie des Ingenieurb üro G. Pahl aus München, entwickelt. Sie werden auch unter dem Begriff Dust Analyzer (DA) zusammengefasst. Der HRD wurde an der Universität Chicago von John Simpson und Anthony Tuzzolino entwickelt und kann als eigenes Experiment angesehen werden. Er besteht aus zwei PVDF-Detektoren (PVDF: Polyvinyliden-Fluorid) mit denen sich Teilchenmassen bei Eischlagsraten bis zu 104 s−1 messen lassen. Diese werden in der Ringebene des Saturn erwartet.
Ein schematischer Querschnitt durch den CDA ist in Abbildung 2.3 zu sehen, in Tabelle 2.1 ist ein ÜberblicküberseineMeßeigenschaftengegeben(BRADLEY&Mitarb.,1996).
Funktionsweise
Tabelle 2.1: Meßeigenschaften des CDA
Abbildung in dieser Leseprobe nicht enthalten
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.3: Querschnitt durch den CDA
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.4: Schematischer Aufbau (links) und Signale (rechts) des CDA
Fliegt ein elektrisch geladenes Teilchen durch die zwei um 9◦ zur Detektorachse geneigten Ein- trittsgitter an der ÖffnungsseitedesDA,induziertesLadungssignaleaufdenGittern.Dadiesedirekt proportional zur Ladung des Teilchens sind, kann daraus dessen elektrische Ladung bestimmt wer- den. Die geneigte Geometrie der Gitter bewirkt asymmetrische Signalformen, die eine Bestimmung der Teilchentrajektorie erm öglichen. Die Länge eines Signals ist gleich der Zeit, die das Partikel zum
Durchfliegen der Gitter ben ötigt und somit zur Bestimmung der Teilchengeschwindigkeit geeignet. Nach Durchqueren des Gitters trifft das Partikel entweder auf das Gold- oder das zentrale Rhodiumtarget. In beiden Fällen erzeugt es ein Plasma, welches aus Elektronen, Ionen und Atomen des Targetund Projektilmaterials besteht.
Trifft das Teilchen auf das große Goldtarget, werden die Elektronen vom Target selbst aufgenommen. Die Ionen werden auf das Ionengitter, das auf einem Potential von -350 V liegt, fokussiert und produ- zieren dort ein positives Signal. Einige Ionen passieren die Ionengitter und hinterlassen ein Signal am Multiplier. Da die gesamte beim Einschlag erzeugte Ladung vom Target bzw. Ionengitter aufgenom- men wird, gibt deren Signalamplitude die Gesamtladung an. Das aus dem Goldtarget, dem Ionengitter und dem Multiplier bestehende System bildet den Einschlagsionisationsdetektor IID.
Das chemische Target liegt auf einem Potential von 1000 V, davor liegt in einem Abstand von 3 mm ein auf Masse gelegtes Beschleunigungsgitter. Dadurch wird das Plasma eines einschlagenden Teilchens schnell getrennt. Die Ionen werden weiter auf das Ionengitter (-350 V) beschleunigt, das sie auf den Multiplier fokussiert.
Abbildung 2.4 zeigt einen schematischen Aufbau des CDAs mit den erzeugten Signalen. Tabelle 2.2 faßt die gemessenen Parameter f ür die einzelnen Komponenten zusammen (SRAMA, 2001).
Tabelle 2.2: Zusammenfassung der in den einzelnen Kanälen gemessenen Parameter mit den jeweiligen Meßbereichen.
Abbildung in dieser Leseprobe nicht enthalten
2.2.3 Der High-Rate-Detector
Der High-Rate-Detector soll den Staubfluss und die Staubmassen im Saturnsystem messen, wo Teilchenraten erwartet werden, die über der Sättigungsschwelle des DA liegen. Um diese Aufgabe zu bewältigen wurde der von Simpson und Tuzzolini entwickelte Detektor, der sich schon bei den fr üheren Vega-1 und Vega-2 Missionen bewährt hatte, in den CDA integriert.
Der HRD besteht aus zwei 6 bzw. 24 µm dicken Sensoren aus dem Polymer Polyvinyliden-Fluorid.
2.2. DER COSMIC-DUST-ANALYZER (CDA) 11
Dieses Material ist permanent polarisiert. Ein schnelles Teilchen zerst ört beim Auftreffen auf den Detektor lokal einige Dipole, was in einem schnellen und starken Strompuls resultiert, der über die Ausleseelektronik ausgelesen wird.
Der Detektor besitzt eine gute Zeitaufl ösung, zudem hängt seine maximale Amplitude von der Geschwindigkeit und der Masse des einschlagenden Teilchens ab (SRAMA, 2001).
Kapitel 3
3 Beschreibung des Web-Interface
3.1 Beschreibung der Datenbank
Die in der Datenbank gespeicherten Ereignisse werden in zwei Klassen eingeteilt, es liegen L0-Daten und L1a-Daten vor. Die Bezeichnungen L0 und L1a entstammen einem Klassifizierungsschema der NASA um Datenprodukte zu beschreiben. Demnach sind L0-Daten Rohdaten, aus denen redundante Ereignisse und Übertragungsfehler entfernt worden sind. Als L1a werden solche Daten bezeichnet, die prozessiert wurden. Beispielsweise sind die Amplituden der L0-Signale in dn (digital number) an- gegeben, da die durch den Detektor gemessenen Signale in diese digitalen Werte konvertiert werden. Betrachtet man dagegen L1a-Signale, sind diese Werte in Coulomb bzw. Volt umgerechnet worden. Abbildung 3.1 zeigt das Signal eines Staubteilchens in zwei verschiedenen Darstellungen. Links im Bild ist das Signal zu sehen, wie es in der Tabelle L0 event gespeichert ist, in der rechten Bildh älfte ist das gleiche Signal dargestellt, wie es aus den L1a-Daten rekonstruiert wird. W ährend das L0-Signal noch das Umschalten des Detektors in einen anderen Meßbereich wiedergibt (zu sehen am pl ötlichen Abfallen der QI- und QT-Amplituden nach ca. 15 bzw. 3 µs), zeigt das L1a-Signal den tats ächlichen Signalverlauf an.
Zu jeder Datenklasse gibt es eine mit ”event“bezeichneteTabelle.DieseTabellenbeinhaltenInforma- tionen die die Ereignisse beschreiben. Beispielsweise werden diese Tabellen f ür die Rekonstruktion der Signalkurven oder das Auslesen von Amplituden ben ötigt.
Die Tabellen L0 event und L1 a event beinhalten diejenigen Daten, die tats ächlich auf der Erde vor- handen sind. Diese Daten repräsentieren jedoch nicht alle registrierten Ereignisse. Aufgrund der be- grenzten Speicherkapazität und Übertragungsrate an Bord der Sonde kann nur eine begrenzte Anzahl von Ereignissen gespeichert und zur Erde übertragen werden. Es kann vorkommen, daß bei hohen Ereignisraten oder niedriger ÜbertragungsratedieGrenzenderSpeicherkapazitätbzw.der Übertra- gungsraten erreicht werden. In diesem Fall wird das älteste Ereignis von dem neuen überschrieben. Um den Informationsverlust zu reduzieren, werden die registrierten Ereignisse anhand ihrer Signale einer von 20 Klassen zugeteilt. Die Software an Bord zählt nun die Anzahl der Ereignisse jeder die- ser Klassen. Diese Zählerstände werden ebenfalls zur Erde übertragen und in der Tabelle L0 counter gespeichert.
Eine weitere wichtige Tabelle ist
”L0_housekeeping“.InihrsindInformationenüberdenZustanddes
Instruments gespeichert. Es lassen sich beispielsweise Werte wie Temperatur und Schwellenspannungen am Detektor auslesen.
Daneben existieren noch weitere Tabellen, die allerdings f ür die Ausführung des Web-Interfaces nicht von Bedeutung sind.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.1: Darstellung des Signals eines interplanetaren Staubteilchens. Das linke Signal wurde aus der Tabelle L0 event, das rechte aus der Tabelle L1a event rekonstruiert. Das linke Signal zeigt in den Kanälen QI und QT das Umschalten des Detektors in einen anderen Meßbereich, bei dem L1a-Signal ist dieser Effekt korregiert worden.
3.2 Web-Interface zur Auswertung der CDA-Daten
3.2.1 Leistungen des Web-Interface
Zur Auswertung der Daten bzw. zur Visualisierung der Daten wurde ein Web-Interface erstellt, das unter der Adresse http://www.mpi-hd.mpg.de/dustdatabase/ zug änglich ist. Dieses ist in Java pro- grammiert und besteht im Wesentlichen aus drei Servlets1, die über JDBC2 auf die Datenbank, in der die durchden CDA aufgenommenen Daten abgespeichert sind, zugreifen. Dabei wird die Datenbank mit sogenannten Queries (Abfragen) in der Datenbanksprache SQL angesprochen. Die Kommunika- tion zwischen Benutzer und Servlet wird durch ein als Applet3 geschriebenes GUI (Graphical User Interface) realisiert.
Aus Gründen der Performance und Verständlichkeit wurde f ür jeden der drei Aufgabenbereiche, die im Folgenden beschrieben werden, ein separates Servlet geschrieben:
1. Auslese der L0- und L1a-Daten aus der Datenbank und grafische Darstellung der Verl äufe der Signalkurven. Die gew ünschten Kanäle können frei gewählt werden, bei den Kanälen QP und MP werden Teilbereiche zusätzlich mit Hilfe einer automatischen Zoom-Funktion vergr ößert dargestellt. Die Ausgabe der Signalkurven erfolgt über ein Applet, das die Grafiken im gif- Format anzeigt. Das Applet verf ügt weiterhin über Steuerbefehle, um verschiedene Plots an- zuzeigen, desweiteren werden Funktionen zum Speichern und Drucken bereitgestellt. Zudem kann man sich auch die einzelnen Punkte der Kurven als Wertetabelle mit Werten f ür Zeit und Ladung anzeigen lassen, die in andere Programme implementiert werden kann.
2. Grafische Darstellung der Datenrate. Die Anzahl der Ereignisse, die frei w ählbare Vorausset- zungen erf üllen, kann als Funktion der Zeit dargestellt werden. Die Ausgabe erfolgt wieder über ein Applet, welches über Schaltflächen verf ügt, um zwischen Balkendiagrammen und Kurven zu wählen (Abbildung 3.2). Jede Grafik läßt sich sowohl in linearem als auch im logarithmi- schen Maßstab anzeigen. Eine weitere Form der Darstellung erlaubt es, Histogramme zu er- stellen, die in Form von Balkendiagrammen die Häufigkeit von Ereignissen mit frei wählbaren Kriterien anzeigen. Desweiteren lassen sich auch die ausgelesenen Werte als Funktion der Zeit darstellen. Bei Darstellungen, die über der Zeit aufgetragen werden, k önnen diejenigen Berei- che farbig markiert werden, in denen der CDA ausgeschaltet war.
3. Letztendlich kann die R ückgabe der ausgelesenen Werte auch textbasiert im HTML- oder ASCII-Format erfolgen.
Eine detaillierte Beschreibung des Programms findet sich im Anhang A.2.
3.2.2 Aufbau und Motivation
Das Web-Interface und die mit ihm verbundenen Programme sind in Java geschrieben. Der große Vorteil von Java ist seine Plattformunabhängigkeit, d.h. Programme werden unter jedem Betriebs- system (z.B. UNIX, Linux, Solaris, Windows) ausgef ührt. Dieses ist aufgrund der virtuellen Java Maschine JVM (engl.: Java virtual machine) m öglich, die einen zuvor kompilierten Byte-Code in Maschinensprache übersetzt. Da Entwicklungen in der Computertechnik über einen Zeitraum von wenigen Jahren kaum abzuschätzen sind, bietet Java aufgrund seiner Portabilität größtmögliche Flexibilität.
Zudem bieten in Java programmierte Applets die M öglichkeit, eine interaktive Benutzerschnitt- stelle zu schaffen. Applets unterliegen strengen Sicherheitsrichtlinien und k önnen z.B. nicht auf Festplatten und Dateien des Clientrechners zugreifen oder selbstständig Netzwerkverbindungen zu fremden Servern aufbauen. Während diese Sicherheitsaspekte f ür den Benutzer von großem Vorteil sind und die generelle Akzeptanz von Applets erh öhen, stellen sie den Programmierer teilweise vor Schwierigkeiten. So ist es Applets nicht erlaubt, Cookies4 zu setzen oder, sofern es in Swing5 programmiert ist, auf den Zwischenspeicher zuzugreifen. JavaScript6 und ActiveX-Controls stellen ebenfalls eine M öglichkeit dar, eine entsprechende GUI zu erstellen. ActiveX-Controls werden auf
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.2: Beispiel zur Darstellung im Ratenmodus. Beide Grafiken zeigen den gesamten Datenbestand an. Im oberen Bild sind die Ereignisse in einem Balkendiagramm im linearen Maßstab dargestellt. Jeder Balken repräsentiert dabei einen Tag. Die Rate im unteren Bild ist über fünf Ereignisse gleitend gemittelt. Sie ist im logarithmischen Maßstab gezeichnet.
der Client-Festplatte gespeichert und haben somit Zugriff auf das Client-System. Aus diesem Grund wird ihre Ausf ührung von vielen Benutzern unterbunden. Die Ausf ührung von JavaScript ist zwar weniger gefährlich als die von ActiveX-Controls und zudem schneller als die von Applets, allerdings ist die Interpretation noch immer leicht abhängig vom Browser. Dar über hinaus bietet JavaScript nur einen sehr begrenzten Funktionsumfang. Da Applets und JavaScript miteinander kommunizieren k önnen, bietet sich die M öglichkeit die Stärken beider Sprachen zu nutzen.
Schließlich erm öglicht die Servlet-Technologie eine optimale Realisierung der Aufgaben des Servers. Noch vor wenigen Jahren wurden standardmäßig CGI-Programme7 erstellt, um dynamische Webseiten zu programmieren. Diese Programme k önnen in den verschiedensten Sprachen (z.B. C++, Perl, Visual Basic, Java) geschrieben werden. Sie erfassen die Anfragen des Clients, f ühren eine Applikation auf dem Server aus und geben Antworten, wie dynamisch generierte HTML-Seiten, an den Client zur ück. Ein Nachteil von CGI jedoch ist, daß bei jeder Anfrage die Applikation neu gestartet werden muß. Vor allem bei Java-Applikationen kann dieses sehr schnell große Mengen an Speicher und anderen Systemressourcen belegen.
Servlets bieten hier eine ebenso elegante wie effiziente Alternative: Im Gegensatz zur CGI-Anfrage, bei der jedesmal eine neue Applikation gestartet wird, leitet der Webserver die Anfrage an die Servlet-Engine weiter, von wo aus sie direkt zum Servlet geschickt wird. Die Servlet-Engine l ädt die benötigten Klassen in den Java-Virtual-Machine-Prozess und erzeugt eine einzige Instanz8 der Klasse.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.3: Darstellung der Dreischicht-Architektur. Die Applikationsschicht (Mitte) kommuni- ziert über das HTTP-Protokoll mit der Benutzerschicht (Links) und über JDBC mit der Datenbank.
Trifft eine neue Anfrage ein, wird ein neuer Thread9 gestartet, der die gleiche Instanz benutzt. Somit kann eine Instanz benutzt werden, um mehrere Anfragen zu bearbeiten, wodurch Systemressourcen gespart werden. Eine gute Beschreibung der Servlet-Programmierung findet sich im Buch von Marty Hall (HALL, 2000).
Dreischicht-Architektur
Durch die Verwendung von Servlets kann die in Abbildung 3.3 gezeigte Dreischicht-Architektur (engl. n-tier architecture) erreicht werden, die die Aufgaben auf die verschiedenen Schichten aufteilt. Auf der Benutzerebene (engl.: user interface), die sich auf der Seite des Clients befindet, kann somit die Präsentation ausgelagert werden. Die serverseitige Anwendungsschicht (engl.: application tier) beinhaltet den Applikationsserver mit den Servlets. Hier werden die Signale rekonstruiert, die Histo- gramme und Ratenplots erzeugt. Ebenfalls serverseitig befindet sich auf einem weiteren Computer die Datenbankschicht (engl.: data tier). Sie beinhaltet die Datenbank und die mit ihr verbundene Auslese- funktion.
Aufgrund dieser Verteilung der Aufgaben auf mehrere Rechner k önnen Systemressourcen geschont
werden, wodurch die Bedienung mehrerer
3.2.3 Beschreibung des GUI
”Klienten“gleichzeitigeffizienterablaufenkann.
Die grafische Benutzerschnittstelle gestattet die Auswahl zwischen den drei Modi textbasierte Ausle- se (Abbildung 3.4), Darstellung von Signalen (Abbildung 3.5) und Histogramm/Rate (Abbildung 3.6. Dabei unterst ützt sie den Benutzer bei der Erstellung von Queries (Abfragen) in der Datenbankspra- che SQL10. Die Auswahl geschieht durch ein Dropdown-Menüam oberen Bildrand. Die Oberfläche des GUI wird entsprechend der Auswahl geändert, die Anfrage wird an das entsprechende Servlet weitergeleitet. Unabhängig von der Auswahl verf ügt jede Oberfläche über folgende Objekte:
18 KAPITEL 3. BESCHREIBUNG DES WEB-INTERFACE
- Am oberen Bildrand befinden sich zwei Textfelder um den Benutzernamen und seine EmailAdresse einzugeben. Diese Angaben werden f ür administrative und statistische Zwecke gespeichert. Um die Eingabe bei wiederholten Anfragen abzuk ürzen, werden sie lokal auf dem Client-Rechner als Cookie gesichert.
- Rechts neben dem Feld f ür die Eingabe der Email-Adresse wird durch ein Dropdown-Menüder Darstellungsmodus eingestellt.
- ÜbereinweiteresDropdown-Menüläßtsichangeben,welcheTabelleausgelesenwerdensoll.
- In der linken Bildhälfte befinden sich acht Men üs zur Auswahl von Bedingungen, die in die Query einfließen k önnen. Diese bestehen jeweils aus einem logischen Operator (AND oder OR) zur Verkn üpfung, dem Namen der Bedingung in der jeweiligen Tabelle und einem Vergleichsoperator(<, ≤, =, ≥ oder>), die über Dropdown-Men üs auswählbar sind. Die m ögli- chen Bedingungen werden durch die Wahl der Tabelle bestimmt. Die Auswahl einer Bedingung wird aktiviert, wenn in das dem Vergleichsoperator sich anschließende Textfeld ein Wert einge- geben wird.
- Der betrachtete Zeitraum kann durch die Einstellung einer Unter- und Obergrenze f ür die Zeit festgelegt werden. Dabei wird das Jahr über ein Dropdown-Menübestimmt, die Einstellungen für Day of Year (DOY), Stunde und Minute erfolgen über Texteingabe.
- Unterhalb der Zeitauswahl befindet sich ein mit ”Caption“markiertesTextfeld.Derdorteinge- gebene Text erscheint als Bildunterschrift der generierten Grafiken.
- Jede Oberfläche verfügt über ein (Histogramm-Modus über zwei) Textfeld mit den Schalt- flächen ”Generate“und ”Submit“.EinKlickauf ”Generate“erstelltausdengewähltenEin- stellungen eine Query und zeigt diese im Textfeld an. Der Benutzer hat nun die M öglichkeit, sie im Textfeld zu editieren. Durch Dr ücken auf ”Submit“wirddieAbfrageandasentsprechende Servlet geschickt.
- Im unteren Bildteil befindet sich ein Textfeld, in dem Fehlermeldungen ausgegeben werden. Die Felder für die Auswahl der Bedingungen und des Zeitrahmens verf ügen über eine automatische Fehlererkennung. Fehlerhafte Queries k önnen unter SQL nicht ausgef ührt werden. Deshalb wird eine falsche Eingabe mit einem Warnton, einer Beschreibung des Fehlers und der Wiederherstellung des urspr ünglichen Wertes korrigiert.
Jede Benutzeroberfläche verfügt über weitere Einstellm öglichkeiten. Im textbasierten Fall gibt es eine Liste von Spaltennamen, die zusätzlich abgefragt werden k önnen, ohne daß sie Bedingungen unterliegen. Mehrfachauswahl ist dabei m öglich.
Die Oberfläche für die Signaldarstellung erm öglicht die Auswahl der betrachteten Kanäle anhand von Checkboxes. Zudem läßt sich eine maximale Anzahl an generierten Signalen wählen und die Bild- größe einstellen.
Wählt man den Histogrammodus, kann man die Anzahl der Balken bzw. die Intervall änge für die Ratenplots eingeben. Über eine Checkbox kann f ür jede Query zwischen der Darstellung der Datenrate oder der Werte eines Parameters als Funktion der Zeit gewählt werden. Im zweiten Fall wird der gewünschte Parameter über ein Dropdown-Menübestimmt. Zudem kann in diesem Fall die Bildgr öße gewählt werden. Die Grafiken m üssen eine minimale Gr öße von 350 Pixeln Länge und 150 Pixeln H öhe haben, damit die Beschriftungen des Koordinatensystems sich nicht überschneiden. Nach oben ist die Bildgröße nur durch den Arbeitsspeicher des Servers begrenzt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.4: Screenshot des GUI f ür die textbasierte Auslese.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.5: Screenshot des GUI f ür die Darstellung von Signalen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.6: Screenshot der Oberfläche zur Erzeugung von Ratenplots und Histogrammen.
[...]
1 Servlets sind serverseitige Java-Applikationen, die Anfragen von einer Webseite verarbeiten und Ergebnisse an diese zurücksenden
2 JDBC ist die vom Java-Entwickler sun bereitgestellte Anbindung von Java an Datenbanken. Sun hat die Bedeutung der Abkürzung JDBC nie öffentlich erklärt. Am geläufigsten ist die Interpretation Java DataBase Connectivity, die von sun bisher unkommentiert blieb.
3 Applet bedeutet ”kleineApplikation“undisteininJavageschriebenesProgrammwelchesaufdemClient-Rechner ausgeführt wird. Applets k önnen in Internetseiten eingebaut werden und laufen als eigenständiges Programm im Browser ab.
4 Cookies sind kleine Datensätze, die auf dem Client-Rechner gespeichert werden.
5 Swing ist ein Paket von Java-Oberflächenkomponenten, das komplett in Java geschrieben ist. Es erm öglicht eine plattform- und browserunabhängige Darstellung dieser Komponenten, so daß es sich f ür die Erstellung eines GUI eignet. Swing ist in der Java 2 Standard Edition (J2SE) enthalten.
6 JavaScript ist eine von netscape entwickelte Skriptsprache, die in HTML-Dokumente eingebettet werden muß.
7 CGI: Common Gateway Interface
8 In der objektorientierten Programmierung werden die aus einer Klasse erzeugten Objekte Instanzen genannt.
9 Threads (dt.: Handlungsfäden) erlauben die (fast) gleichzeitige Ausf ührung von mehreren Prozessen und Teilung von Systemressourcen. Jeder Prozeß erhält dabei eine kurze Ausf ührungszeit, danach bekommt der nächste Prozeß Gelegenheit zur Ausführung. Wurden alle Prozesse bedient, startet wieder der erste Prozeß. Dem Benutzer erscheint die Ausf ührung mehrerer Prozesse aufgrund der K ürze der Intervalle simultan.
10 SQL: Structured Query Language. Standarddatenbanksprache f ür relationale Datenbanksysteme.