Fernsteuerung von Sensoren in komplexen, weitflächigen Laboratorien

Transkript

1 Forschungszentrum Karlsruhe Institut für Prozessdatenverarbeitung und Elektronik Diplomarbeit Fernsteuerung von Sensoren in komplexen, weitflächigen Laboratorien vorgelegt von Stephan Bender Bearbeitungszeitraum: 10. September Februar 2008 Gutachter: Betreuer: Prof. Dr. Holger Vogelsang, HS Karlsruhe M. Sc. Michael Sutter

2

3 Zusammenfassung Neuere Forschungsprojekte erzeugen immer größere und komplexere Datenmengen. Innerhalb des Pierre Auger Projekts fallen beispielsweise pro Nacht mehrere GB an Daten an. Für die Auswertung solcher Datenmengen werden enorme Rechenkapazitäten benötigt. Eine Möglichkeit diese Rechenleistung bereit zu stellen bietet das Grid-Computing. In einem Grid wird die Rechenleistung durch den massiv parallelen Einsatz von Computern, welche als Ressource bezeichnet werden, erbracht. Weiterhin ermöglicht es die kooperative Nutzung der enthaltenen Ressourcen. Werden kurzfristig zusätzliche Ressourcen benötigt, können diese dynamisch hinzugefügt werden. Die aus dieser Dynamik resultierende Skalierbarkeit ermöglicht eine optimale Anpassung an die unterschiedlichen Anforderungen von Projekten. Eine wichtige Grundfunktionalität eines Grids ist die Bereitstellung von geeigneten Sicherheitsmechanismen. Dies ist bei einer kooperativen Nutzung zwingend notwendig. Andernfalls kann die Integrität der Daten und der Schutz vor Fremdzugriff nicht gewährleistet werden. Eine weitere Herausforderung ist die steigende Anzahl der Sensoren und Detektoren in neueren Forschungsprojekten. Das bereits erwähnte Pierre Auger Projekt setzt z.b. auf einem Areal von 3000 km Wassertanks und 24 Teleskope zur Datenaufnahme ein. Damit solche komplexen Forschungssysteme betrieben werden können bedarf es einer Technologie, welche den Zugriff auf die einzelnen Sensoren und Detektoren von einem zentralen Punkt aus ermöglicht. Für diese Herausforderung besteht bereits eine Lösungsmöglichkeit, welche auf bestehende Grid-Technologien aufsetzt. Diese bietet einen zentralen Kontrollraum der für den Zugriff auf Sensoren und die Datenaufnahme verwendet werden kann. Diese Lösungsmöglichkeit wird auf ihre Eignung für das Pierre Auger Projekt überprüft. iii

4

5 Selbstständigkeitserklärung Ich versichere, dass ich diese Arbeit selbstständig verfasst und keine anderen als die angegebenen Hilfsmittel verwendet habe. (Stephan Bender) Karlsruhe, den 29. Februar 2008 v

6

7 Danksagung An dieser Stelle möchte ich mich bei allen für ihren fachlichen Rat, ihre Unterstützung und Motivation bedanken, die zum Gelingen dieser Diplomarbeit beigetragen haben. Insbesondere möchte ich mich bei folgenden Personen bedanken: Herrn Prof. Dr. Vogelsang danke ich für die Unterstützung und Betreuung der Diplomarbeit von Seiten der Hochschule Karlsruhe Technik und Wirtschaft. Bei Herrn Sutter bedanke ich mich für die Betreuung und Motivation während der Diplomarbeit, innerhalb des Forschungszentrum Karlsruhe. Bei Herrn Kopmann bedanke ich mich für die Unterstützung und den fachlichen Rat im Bereich des Pbusprotokolls. Desweiteren möchte ich mich bei den Mitarbeitern des GRIDCC-Projekts für die schnelle Unterstützung bei Herausforderungen mit der GRIDCC-Middleware bedanken. vii

8

9 Inhaltsverzeichnis 1 Vorwort Forschungszentrum Karlsruhe Motivation Zielsetzung Einführung Pierre Auger Projekt Auger Crate Grid Grid Enabled Remote Instrumentation with Distributed Control and Computation Virtual Control Room Instrument-Element Run Control and Monitoring System Java Native Interface Analyse 23 4 Durchführung Installation Implementierung Basisimplementierung des Pbuswrapper Einführung der Abstraktionsschicht Ergebnisse Installation Auslesen der Versionsnummer des Auger Crate Auslesen von Zeitstempeln aus dem Auger Crate Security Diskussion 49 7 Ausblick 53 Literaturverzeichnis 59 ix

10

11 1 Vorwort Zuerst erfolgt eine kurze Einführung in die Organisation des Forschungszentrum Karlsruhe und die Eingliederung der Abteilung in der die Diplomarbeit durchgeführt wurde. Danach wird die Motivation der Arbeit beschrieben und in der Zielsetzung mit konkreten Zielen ausgearbeitet. 1.1 Forschungszentrum Karlsruhe Das Forschungszentrum Karlsruhe ist eines der größten Forschungszentren in Deutschland. Aufgegliedert ist es in insgesamt 22 Institute mit ca Mitarbeitern. Neben 14 weiteren Forschungszentren in Deutschland ist es Teil der Hermann von Helmholtz- Gemeinschaft. Der Schwerpunkt des Forschungszentrum Karlsruhe zielt, neben der Stilllegung von Nuklearanlagen, in drei Bereiche: Energie Schlüsseltechnologien Struktur der Materie Das Institut für Prozessdatenverarbeitung und Elektronik (IPE), in welchem diese Diplomarbeit durchgeführt wurde, ist im Bereich der Hard- und Softwareentwicklung tätig. Die Hardwareabteilung entwickelt hauptsächlich Systeme zur Erfassung von Messdaten mit Datenraten von mehreren hundert GB/s. Von der Softwareabteilung werden Algorithmen und Methoden zur Auswertung dieser Datenmengen bereit gestellt. Ein Projekt in welchem eine Hardware des Instituts zum Einsatz kommt ist das Pierre Auger Projekt [1] (siehe Pierre Auger Projekt Seite 5). Dieses ist im Bereich Struktur 1

12 1 Vorwort der Materie angesiedelt. Ziel ist es mit Detektoren die Herkunft höchstenergetischer kosmischer Teilchen zu bestimmen, welche eine extrem hohe Strahlungsenergie von bis zu ev 1 besitzen. Der GZK-Cutoff, benannt nach Greisen, Zatsepin und Kuz min [3][4], sieht Teilchen mit einer Strahlungsenergie von maximal ev vor. Teilchen mit einer höheren Strahlungsenergie treten, nach dem GZK-Cutoff, mit der im Weltraum vorherrschenden Hintergrundstrahlung in Interaktion und existieren deshalb nur kurze Zeit. Durch diese Interaktion werden die Teilchen stark abgebremst. Eine Ankunft von Teilchen mit dieser Strahlungsenergie in der Erdatmosphäre wäre somit nicht möglich. Die bisher gemessenen Daten über höchstenergetische kosmische Teilchen wiederlegen jedoch einen solchen GZK-Cutoff [5]. 1.2 Motivation Das Pierre Auger Projekt erforscht die Herkunft von höchstenergetischen kosmischen Teilchen. Diese kosmischen Teilchen werden auf bisher unbekannte Weise extrem stark beschleunigt und erreichen die Erde durch den Weltraum. Ein Beispiel verdeutlicht die Energiegrößen mit denen sich das Pierre Auger Projekt beschäftigt. In Bern wird derzeit der leistungsfähigste Teilchenbeschleuniger der Welt durch das CERN errichtet. Die geplante Fertigstellung des Large Hadron Collider [6] genannten Teilchenbeschleunigers erfolgt Der Large Hadron Collider soll Strahlungsenergien von bis zu ev erreichen. Die kosmischen Teilchen mit denen sich das Pierre Auger Projekt beschäftigt weisen Strahlungsenergien von bis zu ev auf. Die Energie der kosmischen Teilchen liegt damit ca mal Höher als die im Large Hadron Collider erzeugbaren. Teilchen mit diesen enormen Energien waren in der Theorie, die bis zur ersten Messung eines solchen Teilchens verbreitet war, in dieser Form nicht möglich. Die Erforschung der höchstenergetischen kosmischen Teilchen liefert somit wichtige Erkenntnisse für die Grundlagen der Teilchenphysik. Die Messung der kosmischen Teilchen durch das Pierre Auger Projekt erfolgt mit zwei Observatorien. Eines deckt ein Messgebiet auf der Südhalbkugel, ein weiteres ein Gebiet auf der Nordhalbkugel der Erde ab. Die Messung auf der Südhalbkugel erfolgt in der Pampa Amarilla, in Argentinien. Das Observatorium befindet sich derzeit noch im Aufbau, ist allerdings teilweise schon in Betrieb und erstreckt sich über ein Gebiet von 3000 km 2. Das Observatorium für das Messgebiet auf der Nordhalbkugel soll in Colorado, USA, errichtet werden, befindet sich derzeit aber noch in der Planung. Für die Messung der kosmischen Teilchen macht man sich einen Effekt zunutze der Auftritt, wenn diese in die Erdatmosphäre eindringen. Beim Eintritt interagieren die kosmischen Teilchen mit Luftmolekülen und übertragen ihre Strahlungsenergie an die Luftmoleküle. Die Luftmoleküle interagieren danach mit weiteren Luftmolekülen, was zu einer Kettenreaktion führt. Diese Kettenreaktion ist als Leuchtspur detektierbar. 1 Für die Messung von Strahlungsenergie wird in der Physik die Einheit Elektronenvolt (ev) [2] verwendet. 2

13 1.3 Zielsetzung Im folgenden wird dieser Vorgang als Luftschauer [7] bezeichnet. Diese Luftschauer beginnen in der Erdatmosphäre und bewegen sich auf die Erdoberfläche zu. Die Messung der kosmischen Teilchen kann anhand der erzeugten Leuchtspur vorgenommen werden. Die Intensität der Leuchtspur lässt dabei Rückschlüsse auf die Strahlungsenergie zu. Das Pierre Auger Projekt misst Teilchen mit zwei voneinander unabhängigen Detektorsystemen. Ein Detektorsystem besteht aus Wassertanks und misst Cherenkov- Strahlung [8] die bei der Interaktion der Teilchen des Luftschauers mit Wasser entsteht. Die Wassertanks werden als Surfacedetektor (SD) bezeichnet. Das zweite Detektorsystem misst die Leuchtspuren in der erdnahen Atmosphäre und wird als Fluoreszenzdetektor (FD) bezeichnet. Die beiden Detektorsysteme generieren eine große Menge von Daten, die im Nachhinein ausgewertet werden müssen. Die Auswertung soll zukünftig durch den Einsatz von Grid-Technologie in möglichst kurzer Zeit erfolgen. Aufgrund der großen Detektorfläche muss der Zugriff auf die Detektoren mit geeigneten Maßnahmen, z.b. Sicherung der Kommunikation vor Fremdzugriff, durchgeführt werden. Einen Ansatz zur Lösung dieser Herausforderungen bietet die Grid-Technologie. Das Projekt, Grid enabled Remote Instrumentation with Distributed Control and Computation (GRIDCC), stellt die geforderte Funktionalität zur Verfügung. 1.3 Zielsetzung Das Projekt GRIDCC stellt mit seiner GRIDCC-Middleware eine Software zur Verfügung, welche den Remote-Zugriff auf und Datenaustausch mit der Messtechnik erlaubt. Die Verwendung der GRIDCC-Middleware mit einer bereits existierenden Hardware soll evaluiert werden. Die Hardware entstammt dem Pierre Auger Projekt und stellt spezielle Anforderungen, die bisher nicht mit der GRIDCC-Middleware getestet worden sind. Eine Anforderung begründet sich z.b. darin, dass der Zugriff auf das Auger Crate nicht direkt über HTTP sondern über einen Treiber erfolgt. Hierfür muss zuerst die Kommunikation zwischen GRIDCC und Auger Crate hergestellt werden. Zwischen der GRIDCC-Middleware und dem Auger Crate soll eine Verbindung hergestellt werden. Diese Verbindung muss gegen Fremdzugriff abgesichert werden, was den Einsatz geeigneter Sicherheitsmechanismen erfordert. Im Rahmen der Diplomarbeit soll getestet werden welche Sicherheitsmechanismen genutzt werden können. Die räumliche Ausdehnung und die Anzahl der Detektoren machen einen Remote- Zugriff notwendig. Mit der GRIDCC-Middleware soll eine Möglichkeit geschaffen werden ein Auger Crate von einem zentralen Campus aus zu steuern. Als langfristiges Ziel 3

14 1 Vorwort ist angedacht die Steuerung aller Auger Crates von einem zentralen Campus vorzunehmen. Desweiteren müssen die Messdaten des Auger Crate zur Verarbeitung ausgelesen werden. Zwischen GRIDCC-Middleware und Auger Crate soll deshalb eine Möglichkeit zum Datenaustausch geschaffen werden. 4

15 2 Einführung Dieses Kapitel enthält einen Überblick über die in der Diplomarbeit eingesetzten Technologien. Zuerst erfolgt eine Beschreibung des Pierre Auger Projekts und des als anzusprechende Hardware verwendeten Auger Crate. Anschließend folgt eine Einführung in die Grid-Technologie allgemein und spezifischer anhand der verwendeten Software des GRIDCC-Projekts. 2.1 Pierre Auger Projekt Das Pierre Auger Projekt erforscht den Ursprung höchstenergetischer kosmischer Teilchen. Die extrem stark beschleunigten kosmischen Teilchen erreichen die Atmospähre der Erde auf direktem Weg. Die Strahlungsenergie dieser kosmischen Teilchen übertrifft dabei alles bisher bekannte oder erzeugbare um ein Vielfaches. Durch die Messung dieser kosmischen Teilchen erhoffen sich die Forscher deren Ursprung zu lokalisieren. Der mögliche Standort des Ursprungs soll mit Hilfe von statistischen Verfahren bestimmt werden. Statistische Verfahren benötigen allerdings die Messdaten sehr vieler kosmischer Teilchen, damit eine hohe Genauigkeit erreicht werden kann. Im Durchschnitt trifft pro Woche ein kosmisches Teilchen mit einer Strahlungsenergie von ev auf ein Gebiet von einem km 2. Ein kosmisches Teilchen mit einer Strahlungsenergie von ev tritt im selben Gebiet nur ein mal pro Jahrhundert auf. Damit möglichst viele kosmische Teilchen gemessen werden können, werden deshalb zwei extrem große Observatorien aufgebaut. Das Observatorium in der Pampa Amarilla soll ein Gebiet von 3000 km 2 abdecken (siehe Abbildung 2.1). 5

16 2 Einführung Der Eintritt in die Erdatmosphäre und die damit verbundene Interaktion mit Luftmolekülen bremst die kosmischen Teilchen stark ab. Eine direkte Messung der Teilchen wäre deshalb nur außerhalb der Erdatmosphäre möglich. Die benötigte große Detektorfläche ist außerhalb der Atmosphäre allerdings nicht zu realisieren. Die Messung der Teilchen muss also indirekt innerhalb der Erdatmosphäre erfolgen. Pierre Victor Auger [7], der Namensgeber des Projekts, wies kosmische Teilchen erstmals 1938 nach. Das Pierre Auger Projekt misst innerhalb der Erdatmosphäre mit zwei verschiedenen Detektorsystemen, dem Surfacedetektor und dem Fluoreszenzdetektor. Die Surfacedetektoren dienen der bodennahen Erfassung von Luftschauern. Insgesamt befinden befinden sich 1600 Surfacedetektoren auf der Erdoberfläche mit jeweils Metern Abstand zueinander (siehe rote Punkte auf Abbildung 2.1). Als Surfacedetektor wird ein Wassertank gefüllt mit Litern hochreinem Wasser und der Messelektronik zur Detektion von Luftschauern bezeichnet. Treffen Teile eines Luftschauers einen Surfacedetektor entsteht durch die Interaktion mit dem Wasser Cherenkov-Strahlung. Die Messelektronik innerhalb des Wassertanks registriert diese Cherenkov-Strahlung. Rückschlüsse auf das kosmische Teilchen können durch die Intensität der Cherenkov-Strahlung und der Anzahl vom Luftschauer betroffener Wassertanks gezogen werden. Abbildung 2.1: Diese Abbildung zeigt die räumliche Ausdehnung des Messgebiets. Die Wassertanks (Surfacedetektor) sind durch einen roten Punkt repräsentiert. Die grünen Linien geben den Sichtbereich der Teleskope (Fluoreszenzdetektor) an. Die Teleskope sind in einem 30 Winkel zur Erde ausgerichtet. 6

17 2.1 Pierre Auger Projekt Die Fluoreszenzdetektoren erfassen ihre Daten in der erdnahen Atmosphäre. In der Pampa Amarilla werden vier Gebäuden mit jeweils sechs Fluoreszenzdetektoren eingesetzt (siehe grüne Linien in Abbildung 2.1). Als Fluoreszenzdetektor wird ein Teleskop bezeichnet, das ausgerichtet auf die erdnahe Atmosphäre, Leuchtspuren misst, welche durch ein kosmisches Teichen ausgelöst werden können. Die geringe Intensität der Leuchtspuren erfordert eine hochempfindliche Elektronik. Bedingt durch die hohe Empfindlichkeit der Teleskope ist jedoch eine Messung nur während dunkler Nächte mit diesem System möglich. Am Tag oder bei Vollmond könnte ein Einsatz die Teleskope beschädigen. Die stark eingeschränkten Einsatzmöglichkeiten werden für eine deutlich höhere Genauigkeit bei der Messung in Kauf genommen. Rückschlüsse auf die Strahlungsenergie kosmischer Teilchen wird durch die Intensität der Leuchtspur getroffen. Die Datenaufnahme bei der Messung einer Leuchtspur erfolgt mit dem Auger Crate, einer speziell hierfür entwickelten Hardware. Zusätzlich zu den Messdaten wird der zugehörige aktuelle Zeitstempel erfasst. Anhand dieser Zeitstempel kann später festgestellt werden ob die Teleskope eine Leuchtspur, die durch ein kosmisches Teilchen oder z.b. durch Wetterleuchten ausgelöst wurde, erfasst haben Auger Crate Das Auger Crate ist eine am Institut für Prozessdatenverarbeitung und Elektronik entwickelte Hardware zur Erfassung von Messdaten. Das primäre Einsatzgebiet ist die Aufnahme von Messdaten im Pierre Auger Projekt. Durch eine allgemeine Gestaltung der Hardware ist jedoch eine Nutzung in anderen Projekten möglich. Innerhalb des Pierre Auger Projekts wird jeder Fluoreszenzdetektor an ein eigenes Auger Crate angeschlossen. Das Auger Crate kann mit First-Level-Triggern (FLT) und Second-Level-Triggern (SLT) bestückt werden. Die First-Level-Trigger sind für die Aufnahme der Daten zuständig. Eine Logik in den First-Level-Triggern entscheidet, ob die aktuellen Messdaten einem Event zugeordnet werden können. Messdaten, welche keinem Event zuzuordnen sind, werden direkt verworfen. Der Second-Level-Trigger speichert Statusinformationen über das Auger Crate und die eingebauten First-Level- Trigger. Im Vollausbau, was 20 verbauten First-Level-Triggern und einem Second- Level-Trigger entspricht, liegt der maximale Eingangsdatenstrom bei 9,6 GB/s. Der maximale Eingangsdatenstrom ist jedoch eine Peakdatenrate und kann höchstens über eine Zeit von 300 µs aufrecht erhalten werden. Zum Speichern von Daten verwendet das Auger Crate 32 Bit Register. Der Zugriff auf größere oder kleinere Speicherbereiche muss mit Software nachgebildet werden. Adressierbar sind die Daten wie ein zusammenhängender Speicherblock. Sollte das Auger Crate nicht voll bestückt sein, kann der entsprechende Speicherbereich nicht genutzt 7

18 2 Einführung werden. Ein Verschieben der Adressen dahinterliegender Register erfolgt nicht. Im Vollausbau können maximal 64 Events in den Speicher aufgenommen werden, wobei ein Event eine detektierte Leuchtspur darstellt. Diese Eventdaten werden nach der Aufnahme zur weiteren Bearbeitung an einen zentralen Campus gesendet. Der Second-Level-Trigger speichert Informationen über den Zustand des Auger Crate, z.b. ob es sich im Aufnahmemodus befindet. Weitere Register des Second-Level-Trigger liefern Informationen welche Speicherbereiche Eventdaten beinhalten, so dass diese ausgelesen werden können. Das Auger Crate ist über eine Firewire oder MicroEnable Schnittstelle mit einem Rechner verbunden, welcher als Mirror-PC bezeichnet wird. Die Kommunikation mit dem Auger Crate erfolgt immer über den Mirror-PC. Auf dem Mirror-PC läuft dazu ein sogenannter Pbusdaemon, welcher Aufrufe entgegen nimmt und auf dem Auger Crate die entsprechenden Operationen ausführt. Abbildung 2.2 zeigt die Kommunikation der einzelnen Komponenten. Abbildung 2.2: Auf einem PC mit installiertem Pbusprotokoll kann eine FEshell zum Absetzen von Kommandos an das Auger Crate benutzt werden. Der Zugriff auf das Auger Crate erfolgt über den Mirror-PC und dem dort laufenden Pbusdaemon. Der Pbusdaemon nimmt Anfragen entgegen und führt sie auf dem Auger Crate aus. Pbusprotokoll Das Pbusprotokoll stellt die Funktionen für den Zugriff auf das Auger Crate durch Software bereit. Funktionsaufrufe werden vom Pbusprotokoll zunächst an den Mirror-PC weiter geleitet. Der Pbusdaemon auf dem Mirror-PC nimmt den Funktionsaufruf entgegen und führt die entsprechende Operation auf dem Auger Crate aus. Zum leichteren Verständnis wird die Verbindung im Folgenden so betrachtet, als würde das Pbusprotokoll direkt auf das Auger Crate zugreifen. 8

19 2.1 Pierre Auger Projekt Die zentrale Klasse innerhalb des Pbusprotokolls heißt Pbus. Sie stellt Funktionen für das Herstellen und Schließen von Verbindungen mit dem Auger Crate bereit. Weitere Funktionen der Pbus Klasse ermöglichen den Zugriff auf die Daten der Register. Abbildung 2.3: Die Abbildung deutet die Klassenhierarchie innerhalb des Auger Crate betreffend der Registerklassen an. Die Registerklassen erben alle von der Klasse Pbus. Innerhalb des Pbusprotokolls gibt es eine logische Abstraktionsschicht. In dieser werden Hardwareelemente des Auger Crate, wie z.b. First-Level-Trigger und Second-Level- Trigger, als Objekte abgebildet. Diese Implementierung erlaubt den Zugriff auf Daten über eine logische Struktur. Die zentrale Klasse dafür heißt Subrack. Ein Subrack Objekt hat Einträge auf Objekte, welche First-Level-Trigger bzw. Second-Level-Trigger abbilden. In den Klassen der First- bzw. Second-Level-Trigger Objekten existieren Einträge auf weitere Objekte, welche die Register repräsentieren. Register werden durch viele Klassen abgebildet (Siehe Abbildung 2.3). Als Attribute besitzen diese eine Bezeichnung und die physische Speicheradresse an der sie sich befinden. Je nach Klasse kommen spezifische Attribute hinzu, wie z.b. eine Längenangabe, falls ein physisches Register für die adressierten Daten nicht ausreicht. Änderungen an der Hardware erfordern evtl. das Anpassen der Speicheradressen bei der Initialisierung einzelner Registerobjekte. Pbusdaemon Wie bereits erwähnt nimmt der Pbusdaemon die Aufrufe des Pbusprotokolls entgegen und leitet diese an das entsprechende Auger Crate weiter. Hierfür läuft der Pbusdaemon auf dem jeweiligen Mirror-PC eines Auger Crates. Die Aufrufe des Pbusprotokolls erreichen den Pbusdaemon über Netzwerk. Die Ausführung der Operationen erfolgen über die Firewire oder MicroEnable Schnittstelle zum Auger Crate. Danach werden die 9

20 2 Einführung Rückgabewerte der Operationen, z.b. der Wert eines Registers, an das Pbusprotokoll weiter geleitet. FEshell Die FEshell ist ein Programm, das eine Kommandozeile zur Kommunikation eines Benutzers mit dem Auger Crate zur Verfügung stellt. Als Standardwerkzeug wird die FEshell auch von vorhandener Software des Pierre Auger Projekts verwendet. Aus der FEshell können Kommandos ausgeführt werden, welche Statusinfos anzeigen oder das Auger Crate steuern. Die Kommandos werden mit Hilfe von Pbusprotokoll und Pbusdaemon ausgeführt. In dieser Diplomarbeit wird die FEshell hauptsächlich zum Verifizieren der Ergebnisse eingesetzt. Abbildung 2.4: Die Abbildung zeigt die FEshell mit der auf das Auger Crate zugegriffen werden kann. Verwendet wurde das Kommando read, das zu der gegebenen Speicheradresse deren Inhalt zurückliefert. 2.2 Grid Die Idee des Grid Computing [9] leitet sich aus dem Stromnetz (engl. power grid) ab. Ziel ist es, das Verwenden von Rechenleistung und Speicherplatz so einfach zu machen, wie das Einstecken eines Steckers in die Steckdose. Die Kraftwerke des Stromnetzes werden im Grid Computing durch Rechenzentren ersetzt. Wobei dies nur eine Verbildlichung der Technologie darstellt. In ein Grid können auch Rechner hinzugefügt werden, die nicht zu einem Rechenzentrum gehören. Die einzelnen Rechner werden als Ressourcen bezeichnet. Die weitere Unterteilung erfolgt nach der Aufgabe, welche der jeweilige Rechner übernimmt. Ressourcen, welche zur Ausführung von Algorithmen oder anderer Funktionalität verwendet werden, bezeichnet man als Computing-Element (CE). Zur Datenspeicherung eingesetzte Ressourcen werden Storage-Element (SE) genannt. Ressourcen, welche Daten erzeugen bzw. erfassen, wie z.b. Messinstrumente, werden als Instrument-Element (IE) bezeichnet. Die Kommunikation zwischen den Ressourcen erledigt eine sogenannte Grid-Middleware. Die Grid-Middleware abstrahiert die technischen Details, die örtlichen Gegebenheiten und die Komplexität der Ressourcen. Dies ermöglicht die transparente Nutzung 10

21 2.2 Grid des Grids ohne das Wissen des Benutzers. Eine Aufgabe wird von einem Benutzer an das Grid abgegeben und ohne weiteres Zutun ausgeführt. Die Ergebnisse des Programms werden an den Benutzer zurückgegeben. Verschiedene Services in einem Grid sorgen für den automatisierten Ablauf. Ein besonders wichtiger Service innerhalb des Grid ist für Security zuständig. Die vielen unterschiedlichen Benutzer innerhalb eines gemeinsamen Grids erfordern eine Absicherung der Authentizität des Benutzers und eine Verschlüsselung sensibler Daten. Die Nutzung eines Grids bietet theoretisch unendlich viele Ressourcen. Die Möglichkeit Ressourcen dynamisch hinzuzufügen oder zu entnehmen bietet eine große Flexibilität. In einigen Firmen wird eine Grid-Middleware auf Arbeitsplatzrechner installiert. Die Grid-Middleware stellt die Ressourcen des Arbeitsplatzrechners im Grid zur Verfügung, sobald der Benutzer den Arbeitsplatz verlässt. Kehrt der Benutzer wieder zurück, wird der Arbeitsplatzrechner wieder aus dem Grid entnommen. Prinzipiell ist jede Hardware für den Einsatz in einem Grid geeignet. Sie muss allerdings die Vorraussetzungen für das Betreiben der Grid-Middleware erfüllen. Vorraussetzungen können z.b. bestimmte Leistungsmerkmale oder installierte Softwarepakete wie eine Java Virtual Machine sein. Die Flexibilität im Einsatz der Hardware bietet einen großen Kostenvorteil. Im Gegensatz zu Supercomputern ist für ein Grid, das eine hohe Rechenleistung erbringen kann, keine teure Spezialhardware notwendig. Die laufenden Kosten eines Grids sind ebenfalls geringer. Das dynamische Hinzufügen bzw. Entnehmen von Ressourcen ermöglicht es unbenutzte Teile des Grids herunterzufahren und damit Kosten einzusparen. Eine hohe Rechenleistung wird durch die massive Parallelisierung erreicht. Heutige Grid-Middlewares sind von der eigentlichen Idee noch weit entfernt. Zusätzliche Services im Netzwerk erleichtern dem Benutzer zwar die Verwendung des Grids an einigen Stellen. Ein komplett automatisierter Ablauf ist jedoch noch nicht möglich. z.b. muss die Suche nach verfügbaren Ressourcen bei den meisten Grid-Middlewares vom Benutzer angestoßen werden. Der Suchvorgang wird dann z.b. durch einen zentralen Informationsdienst unterstützt. Eine weitere große Herausforderung stellt die räumliche Verteilung der Ressourcen dar. Die in Projekten anfallenden Datenmengen werden immer größer. Damit Berechnungen auf den Computing-Elements durchgeführt werden können, müssen diese lokal auf die Daten zugreifen können. Das Kopieren der Daten bildet einen Flaschenhals, der die Ausführung erheblich verzögern kann. Es existieren Ansätze diesen Flaschenhals zu umgehen. Die Ausführung der Berechnungen soll dazu auf Ressourcen verlagert werden, auf denen die Daten bereits vorhanden sind. Die Herausforderung ist damit nur teilweise gelöst. Ressourcen sind nicht immer oder nicht in ausreichender Menge dort verfügbar wo die Daten bereits vorgehalten werden. 11

22 2 Einführung Aktuell entwickeln mehrere Projekte parallel Grid-Middlewares, die jedoch teils unterschiedliche Schwerpunkte fokussieren. Die Globus-Alliance [10] und das glite-projekt [11] arbeiten an einer effizienten Nutzung von Rechenleistung in Form von Computing- Elements und Speicherplatz in Form von Storage-Elements. Das GRIDCC-Projekt arbeitet an der Einbindung von Instrument-Elements, wie z.b. Messsystemen als Grid- Ressource. Ziel dieses Projektes ist die Steuerung und der Datenzugriff auf diese Ressourcen von jedem beliebigen Punkt aus dem Netzwerk. 2.3 Grid Enabled Remote Instrumentation with Distributed Control and Computation GRIDCC ist ein im September 2004 gestartetes Projekt der Europäischen-Gemeinschaft. An der Durchführung des Projektes sind folgende Organisationen beteiligt: Istituto Nazionale di Fisica Nucleare, Legnaro, Italy [12] Brunel University, Uxbridge, United Kingdom [13] International Business Machine (IBM), Haifa, Israel [14] Imperial College of London, London, United Kingdom [15] Greek Research and Technology Network S.A., Athens, Greece [16] Institute of Accelerating Systems and Applications, Athens, Greece [17] Consorzio Nazionale Interuniversitario per le Telecomunicazioni, Italy [18] Istituto di Metodologie per l Analisi Ambientale - CNR, Potenza, Italy [19] Human-Computer Interaction Lab at Università degli Studi di Udine, Udine, Italy [20] Sincrotrone Trieste S.C.P.A., Trieste, Italy [21] In Projekten wie glite oder dem der Globus-Alliance existiert derzeit kein Ansatz Messinstrumente in ein Grid einzubinden. Die Kommunikation zwischen Computing- Elements und Messinstrumenten gewinnt jedoch zunehmend an Bedeutung. Der Trend zu Forschungsprojekten mit immer größerer räumlicher Ausdehnung und gleichzeitig immer mehr Messeinrichtungen nimmt zu. Die räumliche Ausdehnung macht einen Remotezugriff zur Steuerung und Überwachung immer notwendiger. Gleichzeitig entstehen immer mehr Szenarien bei denen für die Berechnung ein direkter Zugriff auf die Messinstrumente erforderlich ist. Das GRIDCC-Projekt will genau diese Szenarien bedienen. Ein Beispiel ist das Pierre Auger Projekt zur Messung von höchstenergetischer kosmischer Teilchen. Zur Messung der Teilchen werden allein 1600 Surfacedetektoren eingesetzt. Für die Messung der Luftschauer in der erdnahen Atmosphäre kommen nochmals 24 Fluoreszenzdetektoren hinzu. 12

23 2.3 Grid Enabled Remote Instrumentation with Distributed Control and Computation Die Anbindung der Messinstrumente ist ein zentraler Punkt innerhalb des GRIDCC- Projekts. Der Zugriff beinhaltet die Fernsteuerung der Messinstrumente und die Möglichkeit, die erfassten Daten auszulesen. Entwicklern wird die Möglichkeit gegeben für die Messinstrumente eine Remotekonfiguration und automatisierte Zugriffe auf die Daten zu implementieren. Die Computing-Elements können sich die benötigten Daten von den Messinstrumenten holen. Ein weiterer zentraler Punkt des GRIDCC-Projekts macht sich einen Grundsatz der Grid-Idee zu Nutze. Innerhalb eines Grids wird eine gesicherte Kommunikation durch Authentifizierung und Verschlüsselung vorrausgesetzt. Auf Basis der Authentifizierung kann eine Zugriffsberechtigung für Elemente aufgesetzt werden. Messeinrichtungen könnten so für andere Forschungsgruppen zeitweise verfügbar gemacht werden. Eine Nutzung der Messinstrumente durch mehrere unabhängige Forschungsgruppen wird dadurch ermöglicht. Damit kann die Finanzierung sehr teurer Messinstrumente, durch Aufteilung der Kosten zwischen den involvierten Forschungsgruppen, erleichtert werden [22]. Bereits während der Entwicklungsphase wird das GRIDCC-Framework in mehreren großen Forschungsprojekten eingesetzt. Dadurch kann dessen Anwendbarkeit getestet werden [23]. Abbildung 2.5: Das GRIDCC-Framework unterteilt sich in 8 Bereiche, wobei Bereich 1, der Virtual Control Room und Bereich 8, das Instrument Element, die wichtigsten Komponenten des GRIDCC-Frameworks bilden (Die Abbildung entstammt aus [24]). 13

24 2 Einführung Abbildung 2.5 zeigt den Aufbau des GRIDCC-Frameworks [24]. Die einzelnen Punkte stellen jeweils Module dar. Der Virtual Control Room bildet das Basismodul und kann bei Bedarf mit den Modulen 2 bis 8 erweitert werden. Die gezeigten Bereiche haben folgende Aufgabe: 1 Virtual Control Room Der Virtual Control Room dient als zentrale Anlaufstelle für die Benutzer. Die Bedienung der Grid-Ressourcen, die Benutzer- Anmeldung und Benutzer-Verwaltung wird mit einer grafischen Oberfläche unterstützt. Nach der Benutzeranmeldung gelangt man auf die Startseite und kann von dort aus auf weitere installierte Module zugreifen. 2 Existing Grid Infrastructures Der Bereich Existing Grid Infrastructures ermöglicht die Anbindung an bestehende Grid-Ressourcen. Computing-Elements werden für die Berechnung von Aufgaben verwendet. Storage-Elements dienen der Datenhaltung. 3 Execution Services Workflows stellen verkettete Anweisungsfolgen dar. Dabei wird z.b. eine Aufgabe berechnet und das Ergebnis als Eingabe für folgende Berechnungen verwendet. Die Execution Services ermöglichen die Ausführung der Workflows. Darunter fällt z.b. das Reservieren entsprechender Ressourcen und das Sicherstellen einer ordnungsgemäßen Ausführung. 4 Global Problem Solver In einem Grid können Probleme auftreten, welche lokal nicht gelöst werden können. Fällt z.b. ein Computing-Element aus, auf dem eine Berechnung durchgeführt wird, muss eine Alternative gefunden werden, so dass das Ergebnis ermittelt werden kann. Der Global Problem Solver sendet in diesem Fall die Berechnung an ein anderes verfügbares Computing-Element. 5 Security Service Der Security Service stellt Funktionalität im Bereich Sicherheit bereit. In einem Grid muss bekannt sein, welcher Benutzer auf welche Ressourcen zugreifen darf. Dafür ist es notwendig sowohl Ressourcen als auch Benutzer identifizieren zu können. Ein weiterer Punkt ist die Sicherheit der Kommunikation, welche häufig über das Internet erfolgt. Eine Verschlüsselung ist erforderlich damit sensible Daten geschützt werden können. 6 Information Service Damit Virtual Control Room und Execution Service auf Ressourcen zugreifen können, müssen sie wissen wo sich diese befinden. Der Information Service dient als Register bei dem sich verfügbare Ressourcen anmelden. 7 Monitoring Service Der Monitoring Service ist in der Softwareversion 2.5 des GRIDCC-Framework noch nicht implementiert. Der Monitoring Service soll Funktionen für das Einstellen und Auslesen von Monitoringdaten zur Verfügung stellen. 8 Instrument Element Das Instrument-Element stellt die Neuerung zwischen GRIDCC und anderen Grid-Middlewares dar. Der Zugriff, die Fernsteuerung und das Auslesen von Daten eines Instruments wird durch das Instrument-Element ermöglicht. 14

25 2.3 Grid Enabled Remote Instrumentation with Distributed Control and Computation Virtual Control Room Der Virtual Control Room ist die zentrale Anlaufstelle für die Bedienung des GRIDCC. In der Basisinstallation ist der Virtual Control Room enthalten. Das Modul verfügt über eine Benutzerverwaltung und bietet Zugriff auf weitere Module, welche in die grafische Oberfläche des Virtual Control Room eingebunden werden können, wie z.b. das Instrument-Element. Für den Zugriff auf den Virtual Control Room müssen sich Benutzer mit einem Benutzernamen und einem Passwort authentifizieren. Ein Administrator kann Zugriffsberechtigungen festlegen und Benutzer erstellen oder löschen. Der Virtual Control Room ist modular aufgebaut und kann mit den Modulen 2-8 aus Abbildung 2.5 erweitert werden. Von hier aus kontrollieren die Benutzer die Workflows und geben Befehle an die Instrumente Instrument-Element Die Einbindung des Instrument-Element ermöglicht den Zugriff auf Instrumente aus einem Grid [25]. Ein Benutzer kann ein Instrument über das Grid ansprechen und dessen Statusinformationen auslesen oder es steuern. Diese Funktionalität stellt einen Remote-Zugriff auf die Instrumente dar. Die Administration komplexer Messsysteme kann somit erleichtert werden. Einzelne Instrumente können z.b. ein oder aus geschaltet werden. Der Zugriff kann aber auch in Aufgaben eingebaut werden, welche ein Benutzer auf das Grid schickt. Während der Ausführung können Computing-Elements die Messdaten dann selbstständig aus den Instrumenten auslesen, welche für die Aufgaben verwendet werden. Instrumente können dabei sowohl Sensoren und Detektoren als auch Aktoren sein. Die Einsatzgebiete des Instrument-Element können also sehr unterschiedlich sein. Die Anforderungen an das Instrument-Element wurden durch die Einbindung in verschiedene Projekte zusammengestellt [26]. Das Instrument-Element muss bis zu Instrumente handhaben können. Die gleiche Anzahl an Nachrichten muss innerhalb einer Sekunde aufgenommen werden können. Nur dann ist eine sinnvolle Fehlerbehandlung und ein Monitoring durchführbar. Bei einer geringeren Leistungsfähigkeit könnte es z.b. vorkommen, dass Fehlermeldungen von einzelnen Instrumenten nicht, oder zu spät empfangen werden. In Projekten an denen mehrere Personen arbeiten, wollen diese evtl. auch gleichzeitig auf ein Instrument zugreifen, um dessen Parameter zu ändern. Das Instrument-Element muss die Zugriffe autorisieren und umsetzen. Aktionen die sich gegenseitig beeinträchtigen müssen abgefangen werden. Spezielle Szenarios stellen Echtzeitanforderungen an das Instrument-Element. Eine Maximalzeit bis zur Antwort auf eine Anfrage muss dabei zwingend eingehalten werden. Trotz dieser Anforderungen darf das Instrument-Element keine hohen Soft- oder Hardware-Ressourcen benötigen. 15

26 2 Einführung Abbildung 2.6: Das Schaubild zeigt den Aufbau des Instrument-Elements mit seinen intern agierenden Services (Die Abbildung entstammt aus [25]). Wie in der Abbildung 2.6 zu sehen ist, werden für die Kommunikation der Instrumente mit anderen Grid-Ressourcen und Benutzern mehrere Services bereit gestellt. Diese Sammlung aus Services wird unter der Bezeichnung Instrument-Element zusammengefasst. Zentrale Schnittstelle für den Zugriff auf das Instrument-Element stellt der Virtual-Instrument-Grid-Service (VIGS) dar. Der Virtual-Instrument-Grid-Service hält eine Web-Service-Schnittstelle bereit, über die Kommandos und Datenanfragen empfangen werden. Nach einem Sicherheitscheck über Authentizität, Autorität und Verschlüsselung durch den Access-Control-Manager, wird der Zugriff freigegeben und kann ausgeführt werden. Damit die Zugriffe an das richtige Instrument geleitet werden können, stellt der Ressource-Service Funktionen zum Suchen und Registrieren von Ressourcen bereit. Eine Ressource bezeichnet in diesem Kontext eine beliebige Hard- oder Softwarekomponente, die über das Netzwerk angesprochen werden kann. Der Information-and-Monitoring-Service (IMS) stellt eine Message-Queue dar. Die Vermittlung von Nachrichten erfolgt über ein publish/subscribe System. Status- und Fehlermeldungen von Instrumenten werden vom Information-and-Monitoring-Service entgegen genommen und in verschiedene Gruppen geordnet. Diese Gruppen können abonniert werden. Wird eine neue Nachricht in eine abonnierte Gruppe eingetragen, wird der Abonnent benachrichtigt. Der Problem-Solver abonniert die Fehler- und Warnmeldungen des Information-and-Monitoring-Service, damit im Fehlerfall Gegenmaßnahmen eingeleitet werden können. Hierzu stellt der Problem-Solver Funktionen bereit, 16

27 2.3 Grid Enabled Remote Instrumentation with Distributed Control and Computation mit denen er versucht wieder in einen stabilen Zustand zu gelangen. Ist das nicht möglich, reicht er die Fehler und Warnungen an den Virtual Control Room und damit an die Benutzern weiter. Der eigentliche Hauptservice des Instrument-Element ist der Instrument-Manager (IM). Ein Instrument-Manager verwaltet ein einzelnes oder eine Gruppe von Instrumenten. Innerhalb eines Instrument-Element können viele Instrument-Manager verfügbar sein. Ein hierarchischer Aufbau ist ebenfalls möglich. Der Instrument-Manager steuert dann einen oder mehrere andere Instrument-Manager. Der Instrument-Manager ist zuständig für die Umsetzung der Zugriffe aus dem Grid auf die Protokolle der Instrumente. Für die Kommunikation und Steuerung der Instrumente stehen mehrere Komponenten bereit. Der Instrument-Manager beinhaltet einen Data-Collector, einen Informationand-Monitoring-Service-Proxy und den Control-Manager. Der Data-Collector und der Information-and-Monitoring-Service-Proxy stellen Proxys für die globalen Services Data-Mover und Information-and-Monitoring-Service bereit. Fordert ein Computing-Element Daten beim Data-Mover an, leitet der Data-Mover die Anfrage an die entsprechenden Data-Collectors der Instrument-Manager weiter. Der Information-and- Monitoring-Service-Proxy schreibt seine Daten in die Message-Queue des Informationand-Monitoring-Service. Der Control-Manager ist nochmals in Teilbereiche untergliedert. Er besteht aus einer Zustandsmaschine, einem Event-Processor, einem Input- Manager und einem Ressource-Manager. Werden Daten von einem Instrument-Manager gefordert, wird die Anfrage an den Data-Collector weiter geleitet. Der Data-Collector gibt danach die geforderten Daten zurück. Kommandos, welche an den Instrument-Manager geschickt werden, damit bestimmte Aktionen ausgelöst werden können, verarbeitet dieser im Control-Manager. Der Control-Manager wiederum nimmt die Kommandos über den Input-Manager entgegen. Im Event-Processor werden Aktionen zu den Kommandos definiert. Ein im Control-Manager definierter Zustandsautomat bestimmt, welche Kommandos im aktuellen Zustand zulässig sind. Anhand des Kommandos und dem aktuellen Zustand des Zustandsautomaten wird überprüft, ob die im Event-Processor definierte Aktion ausgeführt wird. Mit einer Aktion kann der Zustand des Zustandsautomaten verändert, oder auf ein Instrument zugegriffen werden oder beides. Eine Veränderung des Zustandes verändert gleichzeitig die dann zulässigen Kommandos. Nach der Durchführung erhält der Benutzer im Virtual Control Room eine Rückmeldung, ob die Aktion erfolgreich war oder nicht (siehe Abbildung 2.7). Das Sequenzdiagramm (siehe Abbildung 2.7) zeigt den Ablauf einer typischen Interaktion zwischen Benutzer und Instrument. In diesem Beispiel sendet der Benutzer aus dem Virtual Control Room ein Kommando zur Zustandsänderung, wobei beim Zustandsübergang auch der Betriebsmodus des Instruments geändert werden soll. Im Hintergrund sendet der Virtual Control Room die Nachricht über den Virtual- Instrument-Grid-Service des Instrument-Element an den Input-Manager des zustän- 17

28 2 Einführung Abbildung 2.7: Das Sequenzdiagramm stellt den Ablauf einer Benutzerinteraktion mit einem Instrument dar. (Die Abbildung entstammt ursprünglich aus [25]) digen Instrument-Manager. Der Input-Manager leitet das Kommando an den Event- Processor weiter, welcher den aktuellen Zustand des Zustandsautomaten prüft. Anhand des aktuellen Zustandes wird entschieden, ob die Aktion ausgeführt werden darf. Wenn die Bedingungen erfüllt sind, wird das Kommando an den Ressource-Proxy gesendet. Der Ressource-Proxy führt das Kommando auf dem Instrument aus, um dessen Betriebsmodus zu ändern. Danach bestätigt der Ressource-Proxy die Aktion beim Event-Processor. Der Event-Processor ändert den Zustand des Zustandsautomaten und meldet dem Input-Manager den Erfolg oder Misserfolg der Aktion. Der Input-Manager sendet dann eine Benachrichtigung zurück an das Virtual Control Room, die dem Benutzer angezeigt wird. 18

29 2.3 Grid Enabled Remote Instrumentation with Distributed Control and Computation Das CERN stellt mit dem Run Control and Monitoring System (RCMS) ein Framework für die Programmierung von Instrument-Managern bereit. Das Framework gibt einen Rahmen für den Instrument-Manager vor, so dass nur der Zustandsautomat, die Aktionen des Event-Processors und das Protokoll für die Kommunikation mit den einzelnen Instrumenten implementiert werden müssen Run Control and Monitoring System Das Run Control and Monitoring System ermöglicht das Betreiben von einem oder mehreren Instrument-Managern (siehe Abbildung 2.6). Die Services Information-and- Monitoring-Service-Proxy und Data-Collector übernimmt das Run Control and Monitoring System ebenfalls. Die Logik des Control-Managers muss selbst implementiert werden und wird dann vom Run Control and Monitoring System eingebunden. In einem Tomcat betrieben können damit Instrumente gesteuert werden. Mit einem Webbrowser kann auf das Run Control and Monitoring System zugegriffen werden, das zur weiteren Bedienung eine Authentifizierung via Username und Passwort erfordert. Eingeloggt wird eine Ansicht über die verfügbaren Instrument-Manager Implementierungen angeboten (Siehe Abbildung 2.8). Für die Implementierung des Control-Managers wird eine API bereitgestellt. Hauptbestandteil des Control-Managers ist der Zustandsautomat und die Ereignisbehandlung. In einer Klasse werden alle Zustände und Zustandsübergänge des Zustandsautomaten festgelegt. Jeder Zustandsübergang erfolgt aus einem Ursprungszustand in einen Folgezustand. Ein Zustandsübergang wird an ein Kommando gebunden, durch das er ausgelöst wird. Aktionen, die beim Betreten oder Verlassen eines Zustandes ausgeführt werden, sind ebenfalls in dieser Klasse definiert. Dazu werden Informationen zum Zustand und der auszuführenden Aktion benötigt. Die Funktionalität wird in Klassen hinterlegt, welche von der Klasse UserActions oder UserStateNotificationHandler erben. Die Ereignisbehandlung ruft die im Zustandsautomaten definierte Funktionalität auf. Die übersetzten Dateien des Control-Manager müssen als Java-Archiv in einem Verzeichnis des Tomcat-Servers abgelegt werden. In einer Datenbank wird eine Konfiguration für den Control-Manager gespeichert, damit dieser angesprochen werden kann. Die Konfiguration beinhaltet Angaben über den Namen des Control-Managers, einen Ressource-Identifier, unter welcher der Control-Manager zu erreichen ist, eine Liste der zugriffsberechtigten Benutzer und den Pfad zu dem Java-Archiv. Der Control-Manager steht jetzt im Run Control and Monitoring System zur Verfügung. Das Run Control and Monitoring System erstellt für den definierten Zustandsautomaten eine grafische Benutzungsoberfläche (siehe Abbildung 2.9). Auf dieser wird der aktuelle Zustand des Zustandsautomaten angezeigt. Über die dargestellten Buttons können Kommandos an den Instrument-Manager gesendet werden, der dann die dazu 19

30 2 Einführung Abbildung 2.8: Ansicht der verfügbaren Instrument-Manager nach dem Einloggen in das Run Control and Monitoring System. Der Auger Crate- Instrument-Manager wurde in dieser Diplomarbeit erstellt. Die restlichen Instrument-Manager sind Beispiele, die für die Einarbeitung in das Framework benötigt wurden. definierten Aktionen ausführt. Das Run Control and Monitoring System zeigt nur die Buttons an, zu denen im aktuellen Zustand Aktionen definiert sind. Die Tabelle Global Parameters in Abbildung 2.9 zeigen die Werte der Function-Manager-Parameter an. 2.4 Java Native Interface Das Java Native Interface (JNI) bildet eine Brücke zwischen hardwareunabhängigem Java-Code und hardwarenahem Code. Besonders performancekritische Operationen können über das Java Native Interface als hardwarenaher Code ausgeführt werden. Die spezifischere Gestaltung des hardwarenahen Codes ermöglicht eine schnellere Ausführung des Programms. 20

31 2.4 Java Native Interface Abbildung 2.9: Gezeigt wird eine Instrument-Manager-Oberfläche im Run Control and Monitoring System. Das Run Control and Monitoring System erstellt die Oberfläche selbstständig aus den Informationen des Zustandsautomaten und der definierten Parameter. Ein weiterer Anwendungsfall liegt in der Verwendung von existierendem Programmcode. Der Zugriff auf vorhandenen Code erspart die doppelte Implementierung der selben Logik. Änderungen der Logik müssen nur in einem Quellcode vorgenommen und getestet werden. Besonders betriebssystemnahe Funktionalitäten wie z.b. der Zugriff auf die grafische Benutzungsoberfläche können ebenfalls über das Java Native Interface abgebildet werden. Das Standard Widget Toolkit ist beispielsweise auf diese Art realisiert. Ein Aufruf von Java-Code aus nativem Code ist ebenfalls möglich. Sofern der native Code nicht auf allen Betriebssystemen verfügbar ist, verliert Java durch die Verwendung des Java Native Interface allerdings seine Plattformunabhängigkeit. Bevor Methoden nativ ausgeführt werden können, muss der entsprechende native Programmcode bekannt gemacht werden. Ein Methodenkopf wird mit dem Schlüsselwort nativ gekennzeichnet. Abgeschlossen wird der Methodenkopf mit einem Semikolon und verbleibt somit ohne Implementierung. Die Funktionalität der Methode wird danach nativ implementiert. Wird eine solche Methode aus dem Java-Programm aufgerufen, wird die Ausführung bei der entsprechenden nativen Methode fortgesetzt und kehrt nach deren Ausführung zum Java-Programm zurück. Primitive Werte können wie gewohnt als Parameter und Rückgabewerte übergeben werden. Bei Arrays oder Objekten muss aus dem nativen Code in den Adressraum des Java-Programms gegriffen werden. Die entsprechenden Daten werden direkt aus dem Adressraum des Java-Programms gelesen oder hinein geschrieben. 21

32 2 Einführung Abbildung 2.10: Das Java Native Interface ermöglicht den Zugriff von Java auf native Programmieresprachen, hier C++, und umgekehrt. 22

33 3 Analyse Der zentrale Punkt dieser Diplomarbeit behandelt die Evaluation einer Kommunikation zwischen Auger Crate und der GRIDCC-Middleware. Damit diese Aufgabenstellung gelöst werden kann, ist eine umfangreiche Einarbeitung sowohl in das GRIDCC-Projekt als auch in das Pierre Auger Projekt notwendig. Die Einarbeitung in das Projekt GRIDCC zeigt, dass sich die Software aus zwei großen Teilbereichen zusammensetzt. Ein Teil ist modular aufgebaut mit der Basiskomponente Virtual Control Room. Der Virtual Control Room ist die zentrale Kontrollinstanz. Ein Webinterface bietet Zugriff auf die Funktionen des Virtual Control Room. Weitere Module können in den Virtual Control Room integriert werden (siehe Abbildung 2.5). Zusätzliche Funktionalitäten, welche durch neue Module geliefert werden, werden darüber zugänglich gemacht. Für die Einbindung von Hardware, im Fall dieser Diplomarbeit des Auger Crates, in den Virtual Control Room wird das Modul Instrument-Element benötigt. Die Integration erweitert das Basismodul mit den Instrument-Element-Services. Über das Instrument-Element erfolgt der Zugriff auf die Instrument-Manager, welche auf die Hardware zugreifen. Instrument-Manager sind in den zweiten großen Teilbereich der GRIDCC-Middleware dem Run Control and Monitoring System ausgelagert. Das Run Control and Monitoring System liefert ein Gerüst für die Implementierung von Instrument-Managern. Die spezifischen Eigenschaften wie z.b. die Zustandsmaschine und die Ereignisbehandlung werden hier implementiert. In der Ereignisbehandlung werden die Methoden zum Zugriff auf das Auger Crate implementiert. Die Zustandsmaschine hingegen legt das Verhalten der Software fest. So sind nur bestimmte Aktionen pro Zustand zulässig. 23

34 3 Analyse Mit den Methoden der Ereignisbehandlung können z.b. Zugriffe auf das Auger Crate implementiert werden. Dazu muss der Aufbau einer Kommunikation mit dem Auger Crate bekannt sein. Der Zugriff auf das Auger Crate erfolgt über das Pbusprotokoll und den Pbusdaemon. Die Kommunikation zwischen Pbusprotokoll und Pbusdaemon sowie Pbusdaemon und Auger Crate erfolgt im Hintergrund. Eine Einarbeitung für die Nutzung des Auger Crate ist hauptsächlich im Bereich des Pbusprotokolls erforderlich. Die Analyse zeigt, dass das GRIDCC-Framework und das Pbusprotokoll in unterschiedlichen Programmiersprachen implementiert sind. Ein direkter Zugriff ist somit nicht möglich. Das Pbusprotokoll kann jedoch in einer Umgebung mit dem GRIDCC- Framework installiert werden. Die GRIDCC-Middleware muss also nur lokal auf das Pbusprotokoll zugreifen. Für die Lösung dieser Herausforderung wurden zwei Ansätze herausgearbeitet. Der erste Ansatz sieht eine Implementierung des Pbusprotokolls in Java vor. Dabei wird die Funktionalität des Pbusprotokolls einfach in Java nachgebildet. Diese Lösung erlaubt einen direkten Zugriff aus der GRIDCC-Middleware, bringt jedoch zahlreiche Herausforderungen mit sich. Die genauen Implementierungsdetails des Pbusprotokolls müssen erarbeitet werden. Zudem muss das in Java implementierte Pbusprotokoll ausführlich auf Fehler getestet werden. Bei Änderungen im Pbusprotokoll muss sowohl die Java, als auch die C++ Implementierung, des Pbusprotokolls angepasst werden. Somit würde sich sich der Implementierungsaufwand verdoppeln. Der zweite Ansatz sieht die Verwendung des Java Native Interface vor. Das Java Native Interface bietet die Möglichkeit, aus Java auf native Funktionalitäten zuzugreifen. Ein Vorteil ist, dass mit dem Java Native Interface auf den bereits vorhandenen Programmcode des Pbusprotokolls zugegriffen wird. Ein weiterer Vorteil ist, dass die Implementierung mit dem Java Native Interface weniger Programmieraufwand erfordert. In Java werden nur die Methodensignaturen der Methoden des Pbusprotokolls bereit gestellt. Im nativen Teil des Java Native Interface werden dann die Methoden des Pbusprotokolls aufgerufen. Die Funktionalität verbleibt im Pbusprotokoll. Dadurch ist die benötigte Kenntnis über das Pbusprotokolls ebenfalls geringer. Es reicht aus, zu wissen welche Funktionalität eine Methode bietet und wie deren Methodensignatur ist. Die genaue Kenntnis der Implementierungsdetails wird nicht benötigt. Im Gegensatz zum ersten Ansatz muss das Java Native Interface nur bei Änderungen angepasst werden, welche die Methodensignatur verwendeter Methoden verändern. Im Gegensatz zum Nachbau des Pbusprotokolls wird allerdings eine Einarbeitung in das Java Native Interface benötigt. Die Vorteile des Ansatzes mit der Verwendung von Java Native Interface überwiegen deutlich. Sowohl der Implementierungs- als auch Einarbeitungsaufwand ist geringer. Die Entscheidung fällt daher auf den Ansatz mit Java Native Interface. 24

35 Java Native Interface Pbusprotokoll in Java Kenntnis des Pbusprotokolls Ja Ja Kenntnis der Implementierungsdetails Nein Ja Kenntnis über Java Native Interface Ja Nein Programmieraufwand Moderat Hoch Änderungen Nur bei Änderung der Immer Methodensignatur Testen Nur Java Native Interface Testen der kompletten (Funktionen des Funktionalität Pbusprotokolls sind bereits getestet) Tabelle 3.1: Die Tabelle zeigt in einem Vergleich die Unterschiede zwischen der Nachimplementierung des Pbusprotokolls in Java und der Verwendung des Java Native Interface. 25

36 3 Analyse 26

37 4 Durchführung In diesem Kapitel werden die notwendigen Schritte, für die Kommunikation des Auger- Crate mit der GRIDCC-Middleware behandelt. Im ersten Abschnitt wird die Architektur des Aufbaus nach der Installation beschrieben. Abschnitt 2 beschreibt die Implementierung des benötigten Control-Managers und des Java Native Interface. 4.1 Installation Die Installation der benötigten Software wird aus Architektursicht beschrieben. Dabei wird aufgezeigt, an welchen Orten welche Software benötigt wird. Die Installation der GRIDCC-Middleware wird auf einem Rechner mit Linux Betriebssystem vorgenommen. Die GRIDCC-Middleware bietet eine Web-Oberfläche und erfordert dafür einen Apache Tomcat Webserver. Der modulare Aufbau der GRIDCC- Middleware ermöglicht es, Funktionalität nach Bedarf hinzuzufügen. Die verfügbaren Module werden in Abbildung 2.5 gezeigt. Das Basismodul Virtual Control Room bringt die Funktionalität als zentrale Kontrollinstanz. Dazu gehören unter anderem eine grafische Benutzungsoberfläche und eine Benutzerverwaltung. Für die Diplomarbeit muss der Virtual Control Room mit den Modulen 5 und 8 erweitert werden. Das Instrument-Element ist notwendig für die Einbindung des Auger Crate als Instrument. Das Security-Modul erlaubt eine Absicherung über Authentifikation und Verschlüsselung. 27

38 4 Durchführung Das Security-Modul ermöglicht eine Signierung und Verschlüsselung von Nachrichten. Nachrichten werden generell signiert. Anhand der Signierung kann der Absender authentifiziert werden. Eine Verschlüsselung der Nachricht findet nicht in allen Fällen statt. Bei Nachrichten, die zeitlich kritische Vorgaben haben, z.b. bei Realtime, kann auf eine Verschlüsselung verzichtet werden, da diese aufwändig ist. Für Nachrichten welche keine sensiblen Daten, wie z.b. Passwörter enthalten, ist eine Verschlüsselung auch nicht zwingend notwendig. Der Zusatzaufwand der Ver- und Entschlüsselung entfällt bei diesen Nachrichten und ermöglicht dadurch eine höhere Performance. Bei Nachrichten welche sensible Daten enthalten, ist eine Verschlüsselung unabdingbar. Ohne Verschlüsselung wäre der Schutz der Daten nicht gewährleistet. Während der Installation dieses Moduls traten Probleme auf, die später genauer erklärt werden. Das Run Control and Monitoring System stellt eine Umgebung für den Betrieb von Instrument-Managern bereit und wird ebenfalls in einem Webserver betrieben. Für die Diplomarbeit reicht es aus, wenn das Run Control and Monitoring System und der Virtual Control Room auf einem Webserver betrieben werden. Im produktiven Einsatz werden das Run Control and Monitoring System und der Virtual Control Room in verschiedenen Webservern auf verschiedenen Rechnern betrieben. Sicherheitstechnisch wird Kommunikation zwischen dem Virtual Control Room und dem Run Control and Monitoring System deshalb betrachtet als wäre es eine externe Kommunikation. Damit das Run Control and Monitoring System aus dem Virtual Control Room angesprochen werden kann, wird es im Virtual Control Room bekannt gemacht. Als Instrument wird ein Auger Crate verwendet. Für die Kommunikation zwischen Auger Crate und dem Run Control and Monitoring System ist ein Treiber notwendig. Abbildung 4.1: In der Abbildung ist der Aufbau der installierten Software zu sehen. Die Softwarekomponenten befinden sich auf einem Rechner mit Linux Betriebssystem. Die Kommunikation des Systems mit dem Auger Crate erfolgt über das Netzwerk. (Der Mirror-PC mit Pbusdaemon wird zum einfacheren Verständnis ausgeblendet.) 28

39 4.2 Implementierung Hierfür wird das Pbusprotokoll verwendet. Die Implementierung des Pbusprotokolls erfolgt mit C++, die des Run Control and Monitoring System in Java. Für die Überwindung dieser Grenze muss eine Schnittstelle geschaffen werden, welche die Kommunikation des Run Control and Monitoring System mit dem Pbusprotokoll ermöglicht. Das Erstellen dieser Schnittstelle wird im Abschnitt Implementierung beschrieben. Probleme traten während der Installation des Security-Moduls (siehe Abbildung 2.5) auf. Das Security Modul benötigt die zusätzlich installierte Software MyProxy. My- Proxy ist ein Server, der Zertifikate in einer sicheren Umgebung speichern kann. Auf Basis der Zertifikate können Tickets ausgestellt werden, welche der Signierung oder Verschlüsselung von Nachrichten dienen. Beim Registrieren eines Benutzers im Virtual Control Room wird der Benutzer aufgefordert sein persönliches Zertifikat hochzuladen. Das Security Modul sollte das Zertifikat im MyProxy Server ablegen. Das Ablegen des Zertifikats bricht jedoch ab und beendet den Registrierungsvorgang. Nach einer Problemanalyse mit den Entwicklern des GRIDCC-Projekts stellte sich heraus, dass diese Funktionalität erst noch implementiert werden muss und aus diesem Grund nicht verwendet werden kann. Die einzig mögliche Security ist somit die Authentifizierung des Benutzers via Username und Passwort beim Anmelden am Virtual Control Room. Die Kommunikationswege bleiben ungeschützt. Sobald diese Funktionalität in der GRIDCC-Middleware zur Verfügung steht, kann die Absicherung der Kommunikationswege nachgerüstet werden. 4.2 Implementierung Die GRIDCC-Middleware ist in der Programmiersprache Java gehalten. Der Pbusdaemon und das Pbusprotokoll sind schon bedingt durch die direkte Kommunikation mit dem Auger Crate in einer hardwarenahen Sprache, in diesem Fall C++, implementiert. Für die Kommunikation zwischen beiden Systemen wird eine Verbindung benötigt (siehe Abbildung 4.2). Diese Verbindung soll durch den Einsatz des Java Native Interface realisiert werden Basisimplementierung des Pbuswrapper Die Basisimplementierung des Pbuswrappers erlaubt den grundlegenden Zugriff auf das Auger Crate. Der Auf- und Abbau der Verbindung zum Auger Crate sowie ein Lesen und Schreiben einzelner Register ist damit möglich. Die passende Implementierung des Instrument-Manager ermöglicht die Nutzung der Funktionalität im Run Control and Monitoring System bzw. im Virtual Control Room. 29

40 4 Durchführung Abbildung 4.2: Verschiedene Programmiersprachen zwischen GRIDCC (Java) und Auger Crate (C++) machen es notwendig eine Schnittstelle für die Kommunikation beider Systeme zu schaffen. Für das Testen der Funktionalität wird der Use Case Versionsnummer auslesen implementiert. In diesem Use Case wird auf das Auger Crate zugegriffen und das Register für Versionsinformationen ausgelesen. Die Versionsinformationen müssen danach in ein menschenlesbares Format gewandelt und angezeigt werden. Für die Anzeige der Daten werden diese in einen Function-Manager-Parameter, im folgenden Parameter genannt, geschrieben. Der Parameter dient zur Übergabe der Daten an andere Module des GRIDCC-Frameworks. Die restlichen Schritte zur Anzeige übernimmt das Run Control and Monitoring System bzw. der Virtual Control Room, abhängig davon über welche Oberfläche der Instrument-Manager aufgerufen wird. Pbuswrapper Der Pbuswrapper bietet Wrappermethoden für den Zugriff aus Java auf die Methoden des Pbusprotokolls. Das Pbusprotokoll baut seine Funktionalität aus einfachen read- /write-zugriffen auf, d.h. alle Methoden, auch komplexere, können auf read- und write- Zugriffe abgebildet werden. Diese Zugiffsart ermöglicht eine schlanke Implementierung des Pbuswrappers für eine einfache Kommunikation mit dem Auger Crate, so dass nur folgende 4 Methoden benötigt werden: init Stellt die Verbindung mit dem Pbus-Daemon her read Liest ein Speicherwort aus der angegebenen Speicheradresse aus write Schreibt ein Speicherwort an die angegebene Speicheradresse 30

41 4.2 Implementierung free Schließt die Verbindung mit dem Pbus-Daemon Für die Implementierung wird eine Java-Klasse, die den Java-Teil des Java Native Interface bildet, erstellt [27][28]. Die Java-Klasse enthält die oben beschriebenen Methoden. Diese werden als native gekennzeichnet, welches das Schlüsselwort für Java Native Interface-Methoden ist. Beispielhaft wird hier ein Template für eine native Methode gezeigt. p u b l i c n a t i v e rueckgabewert methodenname ( Type parameter ) ; Solche Methoden dürfen keine Funktionalität enthalten, da sie nativ implementiert werden. Im Fall des Pbuswrappers ist die native Programmiersprache C++. Mit Hilfe des Java-Compilers wird für die Implementierung in C++ eine Headerdatei aus dem Quellcode der Java-Klasse erzeugt. Das Kommando javah -jni -classpath build-pfad paketname.klassenname erstellt die Headerdatei aus der Java-Klasse. Bei der Generierung der Header-Datei werden Methoden mit folgender Signierung erzeugt: JNIEXPORT rueckgabewert JNICALL Java paketname Klassenname methodenname ( JNIEnv, j o b j e c t, parameter ) ; Diese Signatur soll gewährleisten, dass auch in der Programmiersprache C keine Methodennamen, bzw. in C Funktionsnamen genannt, doppelt vergeben werden. Notwendig wird das auf Grund des prozeduralen Programmierparadigma. Dieses bindet Funktionen nicht an eine Klasse, weshalb alle Funktionen von überall aufgerufen werden können. Die Unterscheidung der aufzurufenden Funktion erfolgt nur anhand des Funktionsnamens. Der nativen Methode wird zusätzlich zur Übergabe der definierten Parameter ein Zeiger auf den Speicherbereich des Java-Programms übergeben und eine Referenz auf das aufrufende Objekt. Dieser Schritt ermöglicht eine objektorientierte Programmierung zwischen Java und der nativen Sprache, sowie die Übergabe von komplexen Datentypen. In den nativen Methoden kann auf die Speicherbereiche des Java-Programms zugegriffen werden, um dort Daten zu speichern. Die Verwendung dieser Pointer und damit die Implementierung der Funktionalität erfolgt in einer C++-Datei, welche die erzeugte Header-Datei einbindet. Für den Pbuswrapper wird nur zum Auslesen eines Strings bei der Übergabe in der init- Methode der Speicherbereich des Javaprogramms benötigt. Notwendig wird das durch die unterschiedliche Repräsentation eines Strings in Java und C++. Zeichen werden mit dem Universal Transformation Format (UTF) in eine Bitfolge gewandelt. UTF- 16 verwendet 16 Bit für die Kodierung von Zeichen, UTF-8 verwendet 8 Bit. Java verwendet standardmäßig UTF-16 für die Zeichenkodierung, C++ hingegen UTF-8. Mit der Funktion 31

42 4 Durchführung const char c Z e i c h e n k e t t e = env >GetStringUTFChars ( javazeichenkette, i s c o p y ) ; wird ein UTF-16-String in einen UTF-8-String überführt. Der Parameter iscopy bestimmt, ob eine lokale Kopie des Strings erstellt wird oder nicht. Der übergebene String in der init-methode wird nicht verändert, wodurch keine Kopie benötigt wird. Da die Strings im Speicherbereich des Java-Programms angelegt werden, muss die Laufzeitumgebung wissen, wenn diese nicht mehr benötigt werden. Erst danach kann der belegte Speicher von der Laufzeitumgebung wieder freigegeben werden. Der folgende Aufruf zeigt beispielhaft das Freigeben eines Strings. env >ReleaseStringUTFChars ( javazeichenkette, c Z e i c h e n k e t t e ) ; Aus Header- und C++-Datei wird eine shared Library erzeugt. Für den Zugriff aus Java muss diese im Programmcode über System. loadlibrary ( Library ) ; geladen werden. Das Erstellen der shared Library benötigt Java Native Interface- Header-Dateien und Bibliotheken des Pbusprotokolls. Zum Übersetzen der shared Library muss ein C++ Compiler verwendet werden. Auf Linux-Systemen steht dafür standardmäßig der g++ Compiler zur Verfügung. Im Fall von g++ sieht das Kommando zum Übersetzen folgendermaßen aus: g++ -shared -I$JAVA_HOME/include -I$JAVA_HOME/include/linux Pbuswrapper.cpp -o libpbuswrapper.so -LPfadzuLibrarys -llibrarys Mit der Option -shared erstellt der Compiler eine shared Library. Die beiden Optionen -I geben die Position der Java Native Interface-Header-Dateien an, die im Java Developement Kit zu finden sind, wobei $JAVA HOME den Pfad des Installationsverzeichnisses des Java Developement Kits spezifiziert. Der Name der Ausgabedatei wird über -o angegeben. Das Verzeichnis für weitere Librarys wird mit -L angegeben und die daraus zu verwendenden Librarys mit -l. Während des Aufrufs in Java mittels System.loadLibrary() ist zu beachten, dass dort der Dateiname der shared Library ohne lib und.so steht diese Strings werden automatisch hinzugefügt. Control-Manager Der Control-Manager bildet den auf das Instrument zugeschnittenen Part des Instrument-Element. Die Methoden zur Steuerung und Kommunikation mit dem Instrument werden im Control-Manager implementiert. Für den Fall des Auger Crate sind folgende Klassen implementiert worden: AugerCrateFunctionManager Dient der Instanzierung des Control-Managers. Function-Manager wird in diesem Kontext synonym verwendet. 32

43 4.2 Implementierung AugerCrateEventHandler Implementiert die Funktionalität zur Kommunikation mit dem Auger Crate. StateMachineDefinition Definiert den Zustandsautomaten (Siehe Abbildung 4.3). AugerCrateParameters Definiert Parameter, welche über den Data-Collector im Grid verfügbar gemacht werden. Abbildung 4.3: Der Zustandsautomat des Control-Managers für das Auger Crate besteht aus 2 stabilen Zuständen und 4 Übergangszuständen. Die Aktionen setinit, setread, setwrite und setstop sind für den Benutzer nicht sichtbar und werden durch die Programmlogik ausgelöst. Der Zustandsautomat in einem Control-Manager setzt sich aus stabilen Zuständen und Übergangszuständen zusammen. Als stabil werden Zustände bezeichnet, in denen ein System dauerhaft verbleiben kann. Übergangszustände werden nur vorübergehend eingenommen, z.b. bis eine bestimmte Aktion ausgeführt ist. Der Zustandsautomat im Fall des Auger Crate besteht aus zwei stabilen Zuständen und vier Übergangszuständen. Stabile Zustände sind off und on. Übergangszustände sind goingon, goingoff, read und write. Der Zustand off erlaubt nur die 33

44 4 Durchführung Eingabe des Kommandos connect, welches in den Zustand goingon überführt. Im Zustand goingon wird die Verbindung über den Pbuswrapper zum Pbusprotokoll hergestellt. Nach erfolgreichem Verbindungsaufbau sendet der AugerCrateEventHandler das Kommando setinit an den Zustandsautomaten. Der Übergang in den Zustand on wird damit ausgelöst. Sollten Fehler während des Verbindungsaufbaus aufgetreten sein, wird der Übergang in den Zustand off mit dem Kommando setstop ausgeführt. Im Zustand on können Daten aus dem Auger Crate gelesen, bzw. in das Auger Crate geschrieben werden. Das Kommando disconnect löst das Trennen der Verbindung aus und endet im Zustand off. Die möglichen Übergänge werden in der StateMachineDefinition wie folgt implementiert: addtransition (Kommando, aktuellerzustand, Folgezustand ) ; Einige Kommandos werden nur für die interne Kommunikation verwendet und sollen vom Benutzer nicht gesehen werden. Hierzu beschreibt man diese Kommandos, im folgenden Beispielcode als Input bezeichnet, als unsichtbar. Das hat zur Folge, dass diese in der grafischen Oberfläche, die der Virtual Control Room bzw. das Run Control and Monitoring System bereit stellt, nicht angezeigt werden. Input. s e t V i s u a l i z a b l e ( f a l s e ) ; Dieses Vorgehen wird z.b. bei Übergangszuständen verwendet, bei denen die Programmlogik das Kommando ausführt, sobald eine bestimmte Aufgabe abgeschlossen ist. Integration des Instrument-Managers in den Virtual Control Room In der verwendeten Version des GRIDCC-Frameworks werden die Instrument-Manager, bzw. das Run Control and Monitoring System auf dem sie betrieben werden, in einer Java-Datei konfiguriert. Dazu wird in der Datei $VCR_HOME/projects/mceinstruments/src/org/gridcc/mce /mceinstruments/services/is/mcetestinformationservice.java (wobei $VCR HOME dem Installationsverzeichnis des Apache Tomcat Servers entspricht) ein Ressource-Item definiert. Das Ressource-Item enthält Informationen über die Art des Elements, in diesem Fall ein Instrument-Element, den Pfad zu der Ressource, sowie eine textuelle Beschreibung. In späteren Versionen des GRIDCC ist ein grafisches Tool geplant, das diesen Vorgang unterstützt. Die Quelldateien müssen danach mit der neuen Klasse compiliert werden. Nach dem Compilieren muss der Tomcat Server neu gestartet werden. 34

45 4.2 Implementierung Eingeloggt im Virtual Control Room stehen nun alle auf dem Run Control and Monitoring System verfügbaren Instrument-Manager zur Verwendung bereit. Der Virtual Control Room erzeugt für den Instrument-Manager eine grafische Oberfläche (siehe Abbildung 4.4), zur Bedienung dessen. Die im Virtual Control Room generierte Oberfläche des Instrument-Manager ist in die Bereiche Control, Commands und Monitoring unterteilt. Zusätzlich werden im oberen Bereich Informationen über das verwendete Run Control and Monitoring System angezeigt, auf dem der Control-Manager betrieben wird. Abbildung 4.4: Die Abbildung zeigt die generierte Ansicht auf das Instrument-Control des Auger Crate im Virtual Control Room. Im Bereich Control werden Informationen über den Zustandsautomaten angezeigt. Im Bereich Monitoring erfolgt eine Übersicht über die Parameter und ihre aktuellen Werte. Im Bereich Control befindet sich die grafische Abbildung des Zustandsautomaten für das Instrument. Die letzten Zustandswechsel, sowie die Information, ob diese geglückt oder fehlgeschlagen sind, werden im Textfeld Command History angezeigt. Der Teilbereich Status listet den aktuellen Zustand, sowie mögliche Zustandsübergänge und Ar- 35

46 4 Durchführung gumente für diesen auf. Aufforderungen zum Zustandswechsel werden mit dem Popup- Menü bei Choose Trans... angegeben. Der Bereich Commands bietet die Möglichkeit mit Command Parametern eine Aktion ohne Zustandswechsel auszuführen. Diese werden hier jedoch nicht verwendet. Im Bereich Monitoring werden die Namen der Parameter und deren aktuelle Werte angezeigt. Der Button Set erlaubt das Setzen der Parameter auf einen eingegebenen Wert. Im unteren Bereich steht die Möglichkeit zur Verfügung mit Add Time Chart, Add Bar Chart und Add Scatter Plot die Anzeige zu erweitern. Time Chart erlaubt das Anzeigen des Werteverlauf eines Parameters über die Zeit. Security Die Einbindung von Securitymechanismen entfällt aufgrund der, während der Installation aufgetretenen, Probleme (siehe Abschnitt Installation auf Seite 29) Einführung der Abstraktionsschicht Mit der Einführung einer Abstraktionsschicht soll der Speicherzugriff transparent erfolgen. Der Zugriff über die Abstraktionsschicht ermöglicht die Einführung von logischen Registern. Der Benutzer kann zukünftig mit einer Bezeichnung auf Speicherbereiche des Auger Crate zugreifen. Für einen Test der Funktionalität wird der Use Case Eventschleife implementiert. Die Eventschleife greift über die neu implementierte Funktionalität auf das Auger Crate zu. Innerhalb des Use Case werden Daten des Auger Crate überprüft. Weisen die überprüften Daten spezielle Informationen auf, werden bestimmte Zeitstempel aus dem Auger Crate zur Anzeige im Run Control and Monitoring System bzw. Virtual Control Room ausgelesen (siehe Abbildung 4.6). Welche Daten auf welche Informationen überprüft werden, wird in den folgenden zwei Abschnitten beschrieben. Pbuswrapper Der Pbuswrapper wird durch die Einführung von logischen Registern auf eine logisch höhere Abstraktionsschicht gebracht. Logische Register bieten die Möglichkeit über eine Bezeichnung, anstelle der physikalischen Adresse, auf Daten zuzugreifen. Die Einführung von Längenangaben in logischen Registern erweitert einen einzelnen Lese- oder Schreibzugriff auch auf mehrere physische Register. Längenangaben mit einem Wert größer eins adressieren das Register und die jeweils Folgenden. Bei einem Lesezugriff auf ein logisches Register mit einer Längenangabe größer eins, wird die vorhandene Funktionalität zum Lesen eines einzelnen Registers verwendet. Die betroffenen Register werden nacheinander gelesen und dann als Array an das aufrufende Programm zurückgegeben. Bei Schreibzugriffen wird anstelle eines einzelnen Wertes ein Array mit 36

47 4.2 Implementierung Werten übergeben. Zuerst wird überprüft, ob das übergebene Array mit der Länge des logischen Registers übereinstimmt. Das Schreiben nach dieser Prüfung erfolgt ebenfalls einzeln wie beim Lesezugriff. Bestimmte Register der Hardware sollen nur lesoder schreibbar sein. Logische Register enthalten hierfür zusätzlich Angaben über Lesund Schreibbarkeit. Durch die Einführung der logischen Register gewinnt der Pbuswrapper an Flexibilität. Register, welche in einer neuen Hardwareversion des Auger Crate an einer anderen Speicheradresse liegen, können trotzdem noch über das gleiche logische Register angesprochen werden. Lediglich die Adressinformationen des logischen Registers müssen angepasst werden. Im Pbusprotokoll befinden sich bereits alle Attribute der logischen Register, wie z.b. Bezeichnungen mit den zugehörigen Registeradressen, Längenangaben und Attributen der Les- bzw. Schreibbarkeit. Die Attribute sind im Pbusprotokoll in Objekte verschiedener Klassen gekapselt. Die Basisklasse für Register ist Pbus. Pbus selbst besitzt keine Angaben über die Bezeichnung, die Speicheradresse, an der das Register liegt, eine Längenangabe oder Lese- und Schreibattribute. Von Pbus leiten sich vier Hauptklassen, SltRegister, SltRegisterVector, FltRegister und FltRegisterVector (siehe Abbildung 2.3) ab. Diese vier Hauptklassen besitzen die oben aufgezählten Attribute mit einer Ausnahme. Die Klassen SltRegister und FltRegister besitzen keine Längenangabe als Attribut. Sie adressieren jedoch immer ein einzelnes physisches Register. Damit ist deren Länge immer eins. Von diesen vier Klassen leiten sich weitere Klassen ab. Die abgeleiteten Klassen stellen zusätzliche Methoden zur Interpretation der Daten die sie beinhalten bereit. Für die Umsetzung der logischen Register in die Speicheradresse werden 2 Möglichkeiten betrachtet. Eine Möglichkeit ist, das gesuchte logische Register unter den Objekten der oben beschriebenen Klassen zu suchen. Die zweite Möglichkeit sieht eine Liste vor, in die Initial alle oben genannten Attribute kopiert werden. Als Index für die Liste dient die Bezeichnung des logischen Registers. Wird ein logisches Register gelesen, wird dessen Bezeichnung als Index auf die Liste angewendet. Ist in der Liste ein Eintrag unter dieser Bezeichnung vorhanden, erfolgt der Lesezugriff auf den Speicherbereich, den die Attribute in der Liste angeben (siehe Abbildung 4.5). Ist die Bezeichnung unbekannt, wird eine RegisterNotFoundException geworfen, welche an das aufrufende Programm durchgereicht wird. Der Programmierer kann sich dann entscheiden, wie weiter verfahren wird. Der Vorteil von Methode 1 ist der Zugriff auf das eigentliche Objekt. Falls für nachfolgende Versionen des Pbuswrapper ein Zugriff auf die Methoden zur Interpretation 37

48 4 Durchführung Abbildung 4.5: Die Abbildung zeigt den Vorgang beim Zugriff auf die Liste der logischen Register. Die Ausgabe der physischen Adresse direkt. Ein iteratives Durchlaufen ist nicht notwendig. der Daten gewünscht wird, lässt sich dieser einfacher implementieren. Bei Verwendung von Methode 2 werden Attribute, welche nicht in allen oben genannten Klassen stehen, abstrahiert. Einzige Ausnahme bildet das Längenattribut, das zwar in den Klassen SltRegister, FltRegister und deren Unterklassen nicht vorkommt, aber als eins angenommen werden kann. Diese Daten werden in eine Liste eingetragen. Als Schlüssel der Liste dient die Bezeichnung des logischen Registers. Methode 2 bietet dadurch einen Geschwindigkeitsvorteil. Der Suchaufwand für die Attribute des logischen Registers sinkt mit Methode 2 auf O(1) anstatt O(n), was bei Methode 1 der Fall wäre. Die Abstraktion von weiteren Attributen und Methoden in Methode 2 verringert außerdem die Komplexität der Aufrufe. Anstatt die Bezeichnung des gesuchten logischen Registers mit den Bezeichnungen jedes einzelnen Objekts zu vergleichen, wird diese einfach als Index für die Liste angesetzt und liefert sofort ein Ergebnis. Der Nachteil der Initialisierung der Liste in Methode 2, was bereits vor dem ersten Zugriff erfolgt, gleicht sich mit dem ersten Zugriff bereits nahezu aus. Für die Initialisierung der Liste müssen alle Objekte der oben genannten Klassen durchlaufen und die Attribute extrahiert werden. Aufgrund der einfacheren und schnelleren Zugriffsvariante wurde Methode 2 verwendet. Control-Manager Im Kontext des Pierre Auger Projekts spricht man bei einer gemessenen Leuchtspur von einem Event. Wird ein Event detektiert, speichert das Auger Crate die dazu er- 38

49 4.2 Implementierung fassten Messdaten. Bei einem Luftschauer entstehen mehrere Leuchtspuren und somit auch mehrere Events. In speziellen Registern wird vermerkt, welche Speicherbereiche Messdaten eines Events beinhalten. Dadurch werden die Messdaten vor Überschreiben geschützt. Zusätzlich wird zu jedem Event ein Zeitstempel erfasst. Der Zeitstempel enthält das aktuelle Datum und die Uhrzeit mit einer Auflösungsgenauigkeit von bis zu 50 Nanosekunden. Anhand der Zeitstempel kann festgestellt werden, ob es sich um einen Luftschauer handelt der durch kosmische Strahlung ausgelöst wurde, oder z.b. um Wetterleuchten. Für das Auslesen der Zeitstempel eines Auger Crate wird eine Eventschleife implementiert. Das Auger Crate muss zyklisch auf neu eingetretene Events überprüft werden, da es selbst keine Möglichkeit besitzt auf den Pbusdaemon zuzugreifen und dies somit nicht nach außen mitteilen kann. Erfährt die Eventschleife durch pollen von einem oder mehreren neuen Events, wird deren Zeitstempel ausgelesen. Abbildung 4.6: Die Abbildung zeigt den zyklischen Ablauf der Eventschleife. Die Überprüfung auf neue Events erfolgt über das logische Register Pageevents, das sich aus zwei physischen Registern zusammensetzt. Jedes Bit dieser zwei Register, bzw. zusammen 64 Bit steht für einen Speicherbereich der ein Event beinhaltet. Wird ein neues Event in einen Speicherbereich geschrieben, wird das zugehörige Bit gekippt. 39

50 4 Durchführung Die Eventschleife speichert jeweils den Wert dieses logischen Registers und vergleicht ihn beim nächsten Durchlauf mit dem dann Aktuellen. Eine XOR Operation auf beide Werte liefert die Stellen an denen neue Events gespeichert wurden. Die Zeitstempel der entsprechenden Events werden ausgelesen und in einem Vektor gespeichert. Der Vektor kann dann zur weiteren Verarbeitung, z.b. Anzeige in der Benutzeroberfläche, verwendet werden. Die Eventschleife ist in einen eigenen Thread ausgelagert, damit die restliche Funktionalität nicht blockiert wird. Der Thread wird gestartet wenn der Zustandsautomat den Zustand on erreicht. Das Verlassen des Zustandes führt zu einem Stoppen der Eventschleife (siehe Abbildung 4.7). Abbildung 4.7: Die Eventschleife wird beim Betreten des Zustands on gestartet und beim Verlassen wieder beendet. 40

51 5 Ergebnisse Im folgenden Kapitel werden die Ergebnisse der Diplomarbeit präsentiert. Der Erfolg der Installation wird anhand der erfolgreichen Einbindung des Auger Crate belegt. Die Ergebnisse der Implementierung werden anhand von zwei praktischen Anwendungsfällen sichergestellt, welche die Funktionalitäten von Pbuswrapper und Control-Manager nutzen. 5.1 Installation Wie in Abbildung 4.4 zu sehen ist, ist die Steuerung des Auger Crate aus dem Virtual Control Room möglich. Bei einer fehlerhaften Installation des Virtual Control Room oder des Instrument-Moduls (Modul 8 aus Abbildung 2.5) wäre die Steuerung nicht möglich. Das Security-Modul (Modul 3 aus Abbildung 2.5) wurde installiert gibt jedoch bei der Verwendung Fehler aus. Die Fehler treten auf, da die erforderliche Funktionalität in der aktuellen Version des GRIDCC noch nicht implementiert ist. Sie wird jedoch in späteren Versionen des GRIDCC integriert sein. Das Benutzen der Funktionalität ist jedoch im Rahmen dieser Diplomarbeit nicht mehr möglich. Die korrekte Installation des Pbusprotokolls wird mit dem Einsatz der FEshell überprüft. 41

52 5 Ergebnisse 5.2 Auslesen der Versionsnummer des Auger Crate Zur Evaluation wurde die Versionsnummer des Auger Crate mit einem einfachen read ausgelesen, welche in einem Register des Auger Crate gespeichert ist. Mit diesem praktischen Anwendungsfall soll der korrekte Verbindungsaufbau bzw. Verbindungsabbau und die Datenübertragung zwischen dem Auger Crate und dem Control-Manager sichergestellt werden. Die Logik zur Interpretation der Versionsnummer wurde aus dem Pbusprotokoll nachimplementiert. Initial startet die Zustandsmaschine des Instrument-Managers im Zustand off. Das Senden des Kommandos on überführt den Zustandsautomaten in den Zustand goingon. Das Kommando kann durch einen Klick auf den Button on, im Virtual Control Room bzw. im Run Control and Monitoring System, ausgelöst werden. Der Zustand goingon bleibt so lange erhalten, bis der Verbindungsaufbau beendet oder fehlgeschlagen ist. Danach geht der Zustandsautomat automatisch in den Zustand on, bzw. off im Fehlerfall, über. Im Zustand on erfolgt mit Klick auf getversion (siehe Abbildung 5.1) das Auslesen der Versionsnummer. Die Versionsnummer wird durch die interne Logik im Pbuswrapper aufbereitet und dann im Feld Version angezeigt (siehe Abbildung 5.1). Zur Verifikation des Use Case Version auslesen, werden die Ausgaben des Run Control and Monitoring System (siehe Abbildung 5.1) und Virtual Control Room (siehe Abbildung 5.2) mit der Ausgabe der FEshell (siehe Abbildung 5.3) verglichen. Während Abbildung 5.1: Die Abbildung zeigt einen Ausschnitt des Instrument-Manager für das Auger Crate im Run Control and Monitoring System nach dem Auslesen der Versionsnummer. Zu beachten ist das Feld Version in der Tabelle Global Parameters, welches den Wert 2.5 anzeigt. dem Auslesen der Versionsnummer traten keinerlei Fehler auf. Die Kommunikation 42

53 5.3 Auslesen von Zeitstempeln aus dem Auger Crate Abbildung 5.2: Die Abbildung zeigt einen Ausschnitt des Instrument-Manager für das Auger Crate im Virtual Control Room nach dem Auslesen der Versionsnummer. Zu beachten ist das Feld Version im Abschnitt Monitoring,welches Version 2.5 anzeigt. zwischen Run Control and Monitoring System bzw. Virtual Control Room und Auger Crate ist somit sichergestellt. 5.3 Auslesen von Zeitstempeln aus dem Auger Crate Bei der Erfassung von Leuchtspuren speichert das Auger Crate zu den Eventdaten zusätzlich den Zeitstempel des Auftretens. Die Entscheidung, ob die Eventdaten einem kosmischen Teilchen oder einem Luftschauer zuzuordnen sind, kann anhand dieser Zeit- 43

54 5 Ergebnisse Abbildung 5.3: Die Abbildung zeigt die Konsolenausgabe der FEshell nach Eingabe des Befehls sltstatus zur Ausgabe des Status. Zu Beachten ist die ausgegebene Versionsnummer (2.5) im rechten oberen Bereich. stempel getroffen werden. Das Auslesen von Zeitstempeln ist somit ein wichtiger Use Case, der im Umfeld des Pierre Auger Projekts benötigt wird. Die Verifikation der erweiterten Funktionalität mit der Verwendung logischer Register soll mit einer Eventschleife erfolgen, welche diese Zeitstempel ausliest. Die Eventschleife pollt zyklisch auf Veränderungen im logischen Register PageStatus. In diesem wird vermerkt, ob und wo neue Eventdaten gespeichert wurden. Die Eventschleife liest bei aufgetretenen neuen Events die zugehörigen Zeitstempel aus dem Auger Crate aus. Jeder Zeitstempel besteht aus zwei 32 Bit Registern. Durch die Einführung logischer Register ist das Auslesen beider physischer Register mit nur einem Aufruf aus dem Control-Manager möglich. Der Control-Manager speichert die ausgelesenen Zeitstempel in einem Menschen-lesbaren Format. In der grafischen Oberfläche des Virtual Control Room (siehe Abbildung 5.5), wird die Anzahl der ausgelesenen Zeitstempel im Feld Number of Timestamps und jeweils der zuletzt erfasste Zeitstempel im Feld Last Timestamp ausgegeben. Das Ergebnis wurde auch hier mit Hilfe der FEshell verifiziert. Zu beachten ist, dass die Zeitstempel in der FEshell nicht interpretiert ausgegeben werden. Für die Verifikation der Ausgaben zwischen Run Control and Monitoring System (siehe Abbildung 5.4) bzw. Virtual Control Room (siehe Abbildung 5.5) und FEshell (siehe Abbildung 5.6) muss folgende Umrechnung stattfinden. Die in der FEshell ausgegebenen Werte entsprechen den seit 1. Januar 1980 vergangenen Sekunden. Zusätzlich zeigt der Wert, in der Spalte 100µs, den gemessenen Millisekunden-Wert in 100µs Schritten. Die Spalte 50ns zeigt den gemessenen Nanosekunden-Wert in 50ns Schritten. 44

55 5.3 Auslesen von Zeitstempeln aus dem Auger Crate Die Ausgabe der Zeitstempel im Run Control and Monitoring System und dem Virtual Control Room erfolgt mit einem Java Date Objekt. Zusätzlich werden die Werte für 100µs und 50ns übernommen und im Ausgabefeld angehängt. Das Java Date Objekt errechnet sich durch die seit 1. Januar 1970 vergangenen Millisekunden. Für die Umrechnung von Sekunden auf Millisekunden, muss die Ausgabe der FEshell mit 1000 multipliziert werden. Danach wird die Anzahl der vergangenen Millisekunden zwischen 1. Januar 1970 und 1. Januar 1980 addiert. Die Zeitausgaben in der FEshell berücksichtigen keine Schaltsekunden [29]. Für die korrekte Ausgabe im Run Control and Monitoring System bzw. im Virtual Control Room wurden diese jedoch addiert. Für den Vergleich müssen also die Schaltsekunden auf die Zeitangabe der FEshell addiert werden. Seit 1. Januar 1980 waren das 14 Schaltsekunden. Abbildung 5.4: Die Abbildung zeigt den Instrument-Manager im Betrieb mit laufender Eventschleife im Run Control and Monitoring System. In Number of Timestamps wird die Anzahl der seit dem Start aufgetretenen Ereignisse ausgegeben und Last Timestamp zeigt den Wert des letzten Zeitstempels an. 45

56 5 Ergebnisse Abbildung 5.5: Die Abbildung zeigt den Instrument-Manager im Betrieb mit laufender Eventschleife im Virtual Control Room. In Number of Timestamps wird die Anzahl der seit dem Start aufgetretenen Ereignisse ausgegeben und Last Timestamp zeigt den Wert des letzten Zeitstempels an. Mit dieser Vorgehensweise wurde die Verwendung von logischen Registern zur Abstraktion der Speicheradresse und der Größe des benötigten Speicherbereichs erfolgreich verifiziert. In einem 24 Stunden Test wurde die Langzeit-Lauffähigkeit der Software getestet. Die Zeitdauer von 24 Stunden ist mehr als ausreichend, da die Teleskope nur in der Nacht Daten erfassen und sich danach in einem Standby-Zustand befinden. Während des Tests wurden alle gemessenen Events richtig erfasst und es traten keinerlei Fehler auf, was mit der FEshell verifiziert wurde. Die Langzeit-Einsetzbarkeit ist damit gewährleistet. 46

57 5.4 Security Abbildung 5.6: Die Abbildung zeigt einen Ausschnitt der FEshell nach Aufruf des Befehls times zur Abfrage der Zeitstempel von erfassten Events. Zu sehen sind 5 Zeitstempel und die aktuelle Zeit unter Act. Der Eintrag unter pg mit dem Index 5 ist der Aktuellste. Die Umrechnung der Zeitstempel in ein menschenlesbares Format wird auf Seite 45 erläutert. 5.4 Security Durch geeignete Sicherheitsmechanismen sollten die Kommunikationsverbindungen geschützt werden. Kommunikationsverbindungen bestehen zwischen Benutzer und Virtual Control Room, Virtual Control Room und Run Control and Monitoring System sowie Run Control and Monitoring System und Auger Crate. Das Run Control and Monitoring System kann in einen gesicherten Netzwerkbereich mit dem Auger Crate verlegt werden. Eine zusätzliche Absicherung der Kommunikationsverbindung ist daher nicht notwendig. Die Kommunikationsverbindung zwischen Benutzer und Virtual Control Room bzw. Virtual Control Room und Run Control and Monitoring System sollte mit dem Security-Modul (Modul 3 aus Abbildung 2.5) des GRIDCC erfolgen. Die beschriebenen Fehler beim Verwenden dieses Moduls machten eine Absicherung der Kommunikationsverbindungen auf diesem Wege unmöglich. Nach eingehender Kommunikation mit den Entwicklern des GRIDCC-Projekts stellte sich heraus, dass diese Funktionalität erst in zukünftigen Versionen dieses Moduls implementiert wird. Die Absicherung der Kommunikationsverbindungen kann somit nachgeholt werden, jedoch 47

58 5 Ergebnisse aus zeitlichen Gründen nicht mehr in dieser Diplomarbeit. Die Kommunikationsverbindung zwischen Virtual Control Room und Benutzer wird standardmäßig bereits durch einen Userlogin abgesichert. Dadurch wird sichergestellt, dass nur authentifizierte User Zugriff auf den Virtual Control Room bekommen. Der Admin kann die Benutzerverwaltung so konfigurieren, dass er neue Useranträge autorisieren muss, bevor diese sich anmelden können. Zusätzlich ist es möglich mit einem Serverzertifikat diese Verbindung durch die Verwendung von HTTPS zu verschlüsseln. Abbildung 5.7: Die Abbildung zeigt die Startseite des Virtual Control Room. In der rechten Hälfte befindet sich der Bereich für den Userlogin. 48

59 6 Diskussion Das GRIDCC-Projekt bringt mit dem Instrument-Element ein neues Element in die Grid-Umgebung ein. Der Bedarf der Einbindung in aktuellen Forschungsprojekten wird durch die größer werdende Komplexität und die steigende Anzahl der Messinstrumente immer deutlicher. Innerhalb des Forschungszentrum Karlsruhe wird an mehreren großen Projekten geforscht, die einen zentralen Zugriff auf ihre Messinstrumente benötigen. In den meisten Projekten wird zudem bereits Grid-Technologie für die Berechnung und Speicherung von Daten verwendet. Mit dem Einsatz der GRIDCC-Middleware wurde die Einsatzfähigkeit bzgl. des Auger Crate getestet. Die Kommunikation zwischen GRIDCC und dem Auger Crate ist nicht ohne weiteres möglich. Aufgrund unterschiedlicher Implementierungssprachen ist eine zusätzliche Software notwendig. Sie soll die Lücke in Form fehlender Zugriffmöglichkeiten schließen. Zwei Möglichkeiten standen dabei zur Auswahl. Das Pbusprotokoll kann in Java neu implementiert, oder mit dem Java Native Interface in Java verfügbar gemacht werden. Parallel zur Einarbeitung in das komplexe Pbusprotokoll erfolgte die Erfassung der Vor- und Nachteile beider Varianten. Aufgrund des geringeren Entwicklungsaufwandes und der besseren Wartbarkeit fiel die Entscheidung zu Gunsten des Java Native Interface aus. Die Kapselung der Pbusprotokoll Methoden in Wrappermethoden ergab zugleich den Namen Pbuswrapper für das Java Native Interface. Für die Übergabe von Arrays und Objekten, sowie dem Erzeugen von Exceptions wurde eine tiefere Einarbeitung in das Java Native Interface notwendig. Probleme bei der Verwendung sind vor allem beim Debuggen aufgetreten. Das Debuggen des Java-Codes 49

60 6 Diskussion mit einem Java-Debugger verläuft noch problemlos. Sind Fehler im aufgerufenen C++ Code enthalten, liefert der Debugger nur noch ungenaue Fehlermeldungen. Ein Zugriff auf die Werte der Variablen zur Laufzeit, wie es in einigen Debuggern angeboten wird, ist nicht möglich. Das Programmieren des C++ Codes musste deshalb mit besonderer Vorsicht vonstatten gehen. Im Vordergrund der Diplomarbeit stand die Kommunikation zwischen der GRIDCC- Middleware und dem Auger Crate. Im Gegenzug wurde die Funktionalität des Pbuswrapper auf die benötigten Methoden eingeschränkt. Diese Einschränkung bringt gleichzeitig einen Vorteil mit sich. Der Pbuswrapper kann durch seine allgemeine Implementierung auch in anderen Projekten verwendet werden, welche auf das Auger Crate oder eine baugleiche Hardware zugreifen. In einem weiteren Schritt wurde der Zugriff auf die Daten des Auger Crate mit logischen Registern realisiert. Die Einführung von logischen Registern bringt eine Abstrahierung der Hardware mit sich. Ändert sich die Hardware des Auger Crate müssen die Daten im Pbusprotokoll entsprechend angepasst werden. Eine Änderung im Pbuswrapper ist nicht notwendig, da die Attribute der logischen Register zur Laufzeit aus dem Pbusprotokoll gelesen werden. Die logischen Register im Pbuswrapper sind somit automatisch auf dem aktuellsten Stand. Die Entscheidung eine eigene Liste der logischen Register im Pbuswrapper zu halten, wurde aufgrund eines einfacheren und schnelleren Zugriffs getroffen. In der Liste werden nur Bezeichnung, Speicheradresse, Länge, Lesbarkeit und Schreibbarkeit gehalten. Die Abstraktion von weiteren spezifischen Details erlaubt eine höhere Wiederverwendbarkeit. Die Evaluation der Funktionalität wurde an Hand von zwei Use Cases durchgeführt. Der erste Use Case erlaubt das Auslesen der Version des im Auger Crate verbauten Second Level Triggers. Mit diesem Use Case wurde die korrekte Verwendung von Zugriffen auf einzelne Register des Auger Crate sicher gestellt. Der zweite Use Case implementiert Funktionalität zum zyklischen Auslesen von Zeitstempeln aus dem Auger Crate. Das Auslesen der Zeitstempel erfolgt mit dem Einsatz von logischen Registern, welche den Zugriff auf mehrere physische Register mit einem Aufruf erlauben. Die Funktionalität zur Interpretation der Daten beim Auslesen der Version wurde im Pbuswrapper implementiert. Damit wird die Möglichkeit zur Erweiterung des Pbuswrapper angedeutet. Bei der Implementierung von Erweiterungen muss jedoch eine Entscheidung gefällt werden. Soll der Pbuswrapper weiterhin generisch nutzbar sein, oder wird auch projektspezifische Logik implementiert. Die beiden getesteten Use Cases bieten eine erste praktische Funktionalität. Das Auslesen der Versionsnummer ist ein grundlegender Anwendungsfall. Das Auger Crate existiert in verschiedenen Versionen, in denen sich die Hardware ändert. Abhängig davon existieren bestimmte Funktionalitäten erst ab einer bestimmten Versionsnummer. 50

61 Vor der Benutzung dieser Funktionalität muss also die Versionsnummer überprüft werden, damit keine Fehler erzeugt werden, falls sie nicht verfügbar ist. Dadurch ist der Use Case auch für andere Projekte relevant. Das Auslesen von Zeitstempeln stellt einen projektspezifischen Use Case dar. Innerhalb des Pierre Auger Projekts spielt dieser jedoch eine wichtige Rolle. An Hand der Zeitstempel kann entschieden werden, ob es sich bei den Events um einen Luftschauer oder z.b. Wetterleuchten gehandelt hat. Dieser Use Case bezieht die Verwendung von logischen Registern mit ein, damit eine Abstraktion der physischen Speicheradressen erreicht werden kann. 51

62 6 Diskussion 52

63 7 Ausblick Der Virtual Control Room bietet mit dem Instrument-Element die Möglichkeit ein Zeitdiagramm zu erstellen. Dieses zeigt den Verlauf eines Variablenwertes über die Zeit an (siehe Abbildung 7.1). Mit dieser Funktionalität lässt sich z.b. feststellen, zu welchem Zeitpunkt wieviele Events gemessen wurden. Diese Funktion stellt nur eine bereits standardmäßig implementierte Funktionalität der grafischen Datenauswertung bereit. Abbildung 7.1: Das Zeitdiagramm zeigt die Anzahl der gemessenen Events über die Zeit an. Künftig soll die grafische Datenauswertung für die Zeitstempel erweitert werden. Die Zeitstempel sollen mit den in den Eventdaten enthaltenen Informationen über die Position eines Events in einer Hexagongrafik angezeigt werden. Die Auswertungsmöglichkeit einer derzeit eigenständigen Softwarelösung soll damit in den Virtual Control Room integriert werden (Siehe Abbildung 7.2). 53

64 7 Ausblick Für die zusätzlich geforderte Funktionalität muss der Zugriff auf das Auger Crate erweitert werden. Speziell der Use Case für das Auslesen der Zeitstempel. Die zu jedem Zeitstempel gespeicherten Eventinformationen müssen ausgelesen werden. Daraus resultiert eine komplexe Datenaufnahme inklusive der Speicherung von großen Datenmengen. Abbildung 7.2: Das Programm FDEyeDisplay ermöglicht die grafische Auswertung von Eventinformationen. Im linken oberen Bildbereich bildet eine Hexagongrafik den Verlauf einer Leuchtspur in der Atmosphäre ab. Jede Farbe steht für einen anderen gemessenen Zeitwert. Weiterhin ist innerhalb des Institut für Prozessdatenverarbeitung und Elektronik eine Überarbeitung des Pbusprotokolls in Planung. Das Pbusprotokoll soll eine neue Klassenstruktur bekommen und komplett neu implementiert werden. Durch die damit einhergehende Änderung des Pbusprotokolls sind evtl. Anpassungen im Pbuswrapper notwendig. Aktuell findet im Rahmen des GRIDCC-Projekts eine Überarbeitung des Instrument- Elements statt. Unter anderem finden Anpassungen in den Instrument-Managern statt, 54