Deift University of Technology
Ship Hydromechanics Laboratory
Library
Mekelweg 2, 2628 CD Delft
The Netherlands
Phone: +31 15 2786873 - Fax: +31 15 2781836
Dienstintegration an Bord von Schiffen
mit Hilfe von CORBA
Carsten Zerbst
Februar 2004 -
Berich24
Dienstintegration
an Bord von
Schiffen mit Hilfe
von CORBA
Vom Promotionsausschuss der Technischen Universität Hamburg-Harburg
zur Erlangung des akademischen Grades Doktor-Ingenieur
genehmigte Dissertation
von
Carsten Zerbst aus Bad Homburg v.d.H
Gutachter Prof. Dr.-Ing. Dr-Ing. E.h. Dr. h.c. E. Lehmann,
Gutachter Prof. Dr.-Ing. Robert Bronsart
Gutachter Prof. Dr. F. H. Vogt
Mündliche Prüfung: 26. Januar 2004
ISBN 3-89220-624-4
©Arbeitsbereiche Schiffbau der
Technischen Universität Hamburg-Harburg
Lämmersieth 90 D-22305 Hamburg
Vorwort
Die vorliegende Arbeit entstand während meiner Tätigkeitam Arbeitsbereich
«Schiffstechni-sehe Konstruktionen und Berechnungen» der Technischen UniversitätHamburgHarburg.
Mein besonderer Dank gilt Herrn Prof. Dr.-Ing. Dr.-Ing. E.h. Dr. h.c. E. Lehmann, der mit seinem Interesse an interdisziplären Themen diese Arbeit ermöglichte. An dem Arbeitsbereich
ergibt sich unter seiner Leitung ein anregendes Arbeitsumfeld, in dem Mitarbeiter verschie-dener Nationen und Forschungsinteressen zusammengearbeit haben. Diesen möchte ich für viele anregende Diskussionen danken, besonders dem OberingenieurHerrn Dr-Ing. Höft.
Herrn Prof. Dr.-Jng, Bronsart und Herrn Prof. Dr. Vogt möchte ich für die Bereitschaft danken, das Koreferat zu übernehmen.
Diese Arbeit wäre kaum denkbar gewesen ohne die verwendete Software. Hier möchte
ich besonders Frank Pilihofer für sein Tcl-CORBA Binding Combat danken.
Und nicht zuletzt geht mein Dank an meine Eltern und an meine Frau für die langjährige
Unterstützung.
Inhaltsverzeichnis
1 Einleitung
9
2 Konzeption
13
2.1 Infrastruktur und Basisfunktionalitäten 15
2.1.1 Objektermittlung 15
2.1.2 Benachrichtigung 17
2.1.3 Zeitbehandlung 18
2.1.4 Eigenschaften und Konfiguration 18
2.1.5 Datentransport 19 2.1.6 Sicherheit 21 2.2 Sensor 22 2.3 Berechnung 23 2.4 Datenspeicherung 25 2.5 Zusammenfassung 25 3 Systemwahl 29 3.1 Spezifische Kommunikationsschicht 29 3.2 Fremde Protokolle 30 3.3 Middleware 31 3.3.1 0MG CORBA 31 3.3.2 Microsoft DCOM 35
3.3.3 Die Java Plattformen 37
3.4 Ergebnis 38
4 Schnittstellenbeschreibung 41
4.1 Generelle Erwägungen 41
4.2 Eigenschaften und Konfiguration 42
4.2.1 Allgemeine Beschreibung der Eigenschaftsbehandlung 42
4.2.2 Namensschema 45
4.2.3 IDL Beschreibung der Eigenschaftsbehandlung 46
4.3 DATATRAwLER-Objekte und Objektermittlung 47
4.3.1 Namensauflösung 47 4.3.2 Suchdienst 48 4.4 Datentransport 49 4.4.1 Datenpakete 49 4.4.2 Metadaten 51 5
4.4.3 Datenströme
4.4.4 Namensschema
4.4.5 IDL Beschreibung für den Datentransport
53 55 56 4.5 Benachrichtigung 58 4.5.1 Namensschema 58 4.6 Zeitbehandlung 58 4.7 Lebensdauer 59 4.7.1 Netzdienste 59 4.7.2 Serverseitig 59 4.7.3 Klientenseitig 60 4.8 Fehlerbehandlung 60
4.8.1 Allgemeine Beschreibung der Fehlerbehandlung 60
4.8.2 IIJL Beschreibung der Fehlerbehandlung 61
4.9 Sensoren 62
4.9.1 Allgemeine Beschreibung der Sensoren 62
4.9.2 Namensschema 62
4.9.3 IDL Beschreibung der Sensoren 63
4.10 Berechnungsdienste 64
4.10.1 Allgemeine Beschreibung der Berechnungsdienste 64
4.10.2 Namensschema 64
4.10.3 IDL Beschreibung der Berechnungsdienste 64
4.11 Logdienste 65
4.11.1 Allgemeine Beschreibung der Datenspeicherung 65
4.11.2 Namensschenia 66
4.11.3 IDL Beschreibung der Datenspeicherung 66
5 Ausführung 73 5.1 Infrastruktur 73 5.1.1 Namensauflösung 73 5.1.2 Suchdienst 74 5.1.3 Time Service 75 5.1.4 Eventservice 76 5.1.5 Propertyservice 76 5.1.6 COSSclient 76 5.2 DATATRAWLER-Komponenten 76 5.2.1 DataDredge 77 5.2.2 Base Klasse 77 5.2.3 Factory Klasse 78 5.2.4 Stream Klasse 78 5.2.5 Sensor Komponente 79 5.2.6 Berechnungs Komponente 80 5.2.7 Speicherungs Komponente 81 5.3 Sicherheit 82 5.4 zusammenfassung 82 6 Zusammenfassung 85
A DataTrawler IDL 89
B Kennzeichnung der Datenart 99
C Kennzeichnung von Einheiten 103
D NMEA Abbildung 105
E Startskript 107
JrI;'
.L
Einleftung
Schiffe gehören zu den größten technischen Strukturen die zur Zeit erstellt werden. Ihre Stahistruktur ist eine immer wieder imponierende Ingenieursleistung. Neben der sichtbaren
Stahistruktur bestehen sie jedoch noch aus einer weiteren Struktur, in der Informationen
übertragen werden. Die Menge der an Bord anfallenden Daten in ihren verschiedenen Forma-ten ist groß und nimmt weiter zu, ein Ende ist kaum abzusehen. Die ZeiForma-ten, in denen man
mit Logge, Lot und Kompaß auf der Brücke ausgekommen ist, sind lange vorbei. Neben der
Navigation sind die Maschine, Klimatechnik und die Ladung Untersuchungsgegenstand einer
Unzahl von Sensoren. Hinzu kommt auf Passagierschiffen eine große Menge weiterer Dienste wie Telephon, Fernsehen, Radio
Schaut man auf die technische Realisation der Datenübertragung, entdeckt man ein
Wirr-warr von Kabeln, die jeweils nur einem Zweck dienen. An Bord eines Passagierschiffeszum Beispiel ist zur Zeit meistens je ein Kabel für das Lautsprechersystem, Fernsehen, Telephon,
Brandrnelder, Klimatisierung, Türverriegelung etc. verlegt. Im Kabinenbereich kommen so
et-wa 10 - 15 Dienste mit jeweils einem eigenen Kabel zusammen. Diese Kabelmenge ist sowohl bei der Planung, Erstellung wie Wartung ein erheblicher Kostenfaktor.
Aus dem Gebiet der allgemeinen Computertechnik ist spätestens mit demSiegeszug des Internets bekannt, daß sich Information der verschiedensten Art und Weise mit einem
ein-heitlichen Medium transportieren lassen. Wie in Bild 1.1 illustriert, ist dies aktuell bei weitem
nicht der Fall. Jede Art von Information wird mit unterschiedlicherHardware und
unterschied-lichem Protokoll transportiert.
Doch an Bord befinden sich nur unterschiedliche physikalische Medien zum Transport der
Daten, auch die verwendete Art des Protokolls unterscheidet sich erheblich. Die Abfrage und Übertragung der Daten erfolgt bei jedem Gerät jeweils in einem proprietären Protokoll. Eine
kleine Auswahl umfaßt zum Beispiel die Telephonic mit denanlagenspezifischen Protokollen
für die Konifortmerkmale, Industriebusse für die Anlagensteuerung, UHF-Fernsehübertragung, 20 Milliampere Sensorik oder serielle Protokolle auf Zweidraht-Leitungen. Mit einem
gemein-samen Kabel kann der Zugriff zwar physikalisch von einem Punkt erfolgen, allerdings
erfor-dert jede Datenquelle eine eigene Behandlung. Neben der physikalischenIntegration auf einen
gemeinsamen Übertragungsweg ist eine Einigung auf ein einheitliches Protokoll zur Nutzung
aller im Netzwerk vorhandenen Komponenten notwendig.
Ein erstrebenswertes Ziel ist jedoch ein dienstintegriertes Netzwerk. In diesem wären alle
an Bord anfallenden Informationen auf eine einheitliche Art und Weise verfügbar. Dies würde
nicht nur den direkten Zugriff auf die Sensorik umfassen, es wären auch höherwertige Dien-ste wie Weiterverarbeitung und Speicherung möglich. Neben dem leichteren Zugriff und die Integration der anfallenden Informationen winkt der gesparten Aufwand für die Verkabelung.
lo Radar Temperatur L Tankpeilung Bild 1.1: STiittstcflenproblematik
lrrkompatb]e ooer fehlence
SohrrsfeThn
Datenbündelung
Datenweiterverarbeitung, Repräsentation,
Speicherung
Allein aus Kostengründen ist dies natürlich auch im Schiff'oaubereich eine attraktive Vision. Bevor nur ein Kabel zum Träger sämtlicher relevanten Informationen dient, muß ein ein-heitliches Format gefunden werden, mit dem die an Bord anfallenden Daten transportiert wer-den können. Dieses Format muß auf der einen Seite die Möglichkeit bieten, schiffsrelevantc Datentransporte durchzuführen, auf der anderen Seite aber auch den besonderen Anforderun-gen an Bord Rechnung traAnforderun-gen. Ein weiterer Punkt, dem bisher neben der puren Übertragung kaum Beachtung geschenkt wird, ist die Datenintegration. Eine weitere Lehre aus dem Erfolg des Internets ist, daß die Integration von verschiedenen Daten einen erhebliche Mehrwert bieten kann. Während diese Versprechung im Internet nur auf dem kleinsten gemeinsamen
Nenner der Texte gehalten wird, ist im Schiffsbereich eine allgemeine Verfügbarkeit von Daten wie Position oder Geschwindigkeit von besonderem Interesse. Mit der allgemeinen
Verfügbar-keit solcher Daten ließen sich interessante Mehrwertdienste wie ein elektronischen Logbuch, ein Passagierinforrnationssystem oder Dienst zur Planung von Serviceintervallen erstellen
er-stellen.
Der aktuelle Stand der Technik an Bord erinnert jedoch an die Stadt Babel, die Anzahl an unterschiedlichen Formaten und Übertragungstechniken geht in die Hunderte. Es existiert weder ein einheitlicher Standard zum Transport noch zur Integration der Daten, obwohl es in Teilbereichen de facto Standards gibt. Der Transport von Daten geschieht meist auf dedizier-ten Leitungen, Sensoren und Endgeräte müssen jeweils speziell aufeinander abgestimmt sein, generische Lösungen existieren nicht. Für jede Datenquelle oder gewünschte Verarbeitung
müssen entsprechende Konverter geschaffen werden. Das Daten von Hand übertragen werden
ist Alltag. Deshalb sind Anwendungen, die übergreifend mit verschiedenen Daten arbeiten oder sie speichern auch kaum verfügbar; es bilden sich lauter Insellösungen. Diese werden
"ItÇtMtJLI .suw Jrt
zwar mit dem Stempel ,,Integrierte Brücke" angepriesen, sind aber nach außen so zugänglich
wie ein Geldautomat.
Beschäftigt man sich näher mit diesem Gebiet, stellt sich zuerst das Problem eines
einheit-lichen Daterizugriffes. Die Datenquellen an Bord sind von ganz unterschiedlicher Natur, die Bandbreite reicht von einfachen Tastern an Verschlüssen bis hin zu Datenströmen aus Radar und Funk. Diese werden mit den verschiedensten Mitteln übertragen, die die Technik bietet. Von der 20 Milliampere Stromschleife und seriellen Schnittstelle bis hin zu paketvermitteln-den Diensten auf UDP/JP und TCP/IP Basis ist alles anzutreffen. Dabei unterscheiden sich
die Daten nicht nur in ihrem Informationsgehalt, auch die Repräsentation reicht von Boole-schen Variablen über Zeichenketten hin zu Bild- und Tonmaterial. Ein einheitlicher Zugriff aufdiese Daten ist zur Zeit nicht möglich (siehe Bild 1.1).
Neben dem reinen Zugriff auf die Daten von Sensoren gibt es zwei weitere Probleme in diesem Umfeld. Das eine ist die Frage der Weiterverarbeitung der anfallenden Daten. Hier
existiert eine große Anzahl an Lösung für die unterschiedlichen Bereiche,von der Navigation
bis hin zum Ladungsmanagemetit. Die meisten dieser Lösungen könnenjedoch nicht
automa-tisch die Daten von einem Sensor anfordern bzw. es müssen extra proprietäre Lösungen dafür
geschaffen werden. Außerdem lassen sich die Ergebnisse der Berechnungen meistens nur auf
dem Bildschirm betrachten oder auf einem Blatt Papier ausgeben. Des weiteren müssen Daten
für diverse Zwecke an Bord gespeichert werden, sei es nun um der allgemeinen Nachweis-pflicht zu genügen oder um Wartungsintervalle planen zu können. Auch hier fehlt es bislang an Möglichkeiten, übergreifend Daten aufzuzeichnen und später wieder abzurufen.
Die Lösung dieser Probleme ist ein dienstintegriertes Netzwerk. Wesentliches Merkmal eines solchen Netzwerkes ist, daß alle anfallenden Daten mit einheitlichen Methoden übertra-gen werden. Dies trifft sowohl den physikalischen Transport wie auch den Zugriff auf den Inhalt der transportierten Daten. Dies bedeutet, daß auf alle anfallenden Daten transparent, also ohne Ansehen von Hersteller, Einbauort etc. zugegriffen werden kann. Die Konsequenz eines solchen Netzes ist auf der Hardwareseite, daß im einfachsten Fall nur ein Kabel zur Ver-netzung und eines zur Stromversorgung verlegt werden müßte. Auf der Softwareseite benötigt
man eine entsprechende Spezifìkationen, die einen einheitlichen Zugriff auf die unterschied-lichen Dienste gewährleistet. Mit den spezifizierten Schnittstellen kann man dann einheitlich auf alle an Bord anfallenden Daten zugreifen.
Die Anforderungen nach einer durchgehenden Informationskette wird immer dringender.
Für den Ingenieur stehen meist die technischen Möglichkeiten einer solchen Informations-kette im Vordergrund. Dies wären zum Beispiel einfache Systemüberwachung und Datenaus-wertung, Einsparung bei der Verkabelung etc. Eine Motivation für eine durchgehende Infor-mationskette besteht jedoch noch aus anderen Gründen. Ein kleiner Auszug der aktuell im
Schiffsumfeld genannten Normen umfaßt die DIN/ISO 900X (Qualitätsmanagement [13]), ISO
14001 (Umweltmanagement [12]) und nicht zuletzt den ISM Code, diean Bord berücksichtigt
werden müssen [9].
Hallay und Priem [Il] konstatierten schon Anfang der '90 Jahre:
Für eine ökologische Un rnehmenspolitik sind daher entsprech ende Informati-onssystenw nötig, die dazu dienen alle ökologisch wichtigen Infonnationen zu sammeln, sie unter ökologischen und ökonomischem Aspekten zu bewerten und
leitu ng
An diesen Anforderungen hat sich seitdem nichts geändert. Ganz im Gegenteil, der poli-tische Druck auf die Reeder ist eher größer geworden und wird sie zu einer größeren Trans-parenz zwingen. In diesen Normen werden Anforderungen an die Führung eines Schiffes in Bezug auf Sicherheit, Nachvollziehbarkeit und Umweltschutz gestellt, sie bieten jedoch kei-ne Aussage über die technische Durchführung. Es ist jedoch klar, daß eikei-ne Schiffsführung entsprechend diesen Anforderungen kaum möglich ist, wenn nicht weite Bereiche der Da-tenaufbereitung und -aufzeichnung automatisiert werden. Einer übergreifenden Automation dieser Aufgabe stehtjedoch wieder das Fehlen geeigneter Schnittstellen entgegen. Neben der Vereinfachung bei dem Nachweis eines ökologischen Betriebes kann man davon ausgehen, daß ein dienstintegriertes Netzwerk die an Bord verlegte Kabelmenge wesentlich verringert
[38], was ein erwünschter Effekt wäre.
In dieser Arbeit wurde das Problem eines dienstintegrierten Netzwerkes für den Bord-gebrauch näher untersucht. Das Problem wird dabei in mehreren aufeinander aufbauende Schritten angegangen und eine Lösung vorgeschlagen. Diese Lösung mit dem Projekttitel
DATATRAWLER stellt ein Netzwerk dar, welches transparent den Zugriff auf Datenquellen,
Pro-grammen zur Weiterverarbeitung und Speicherung ermöglicht.
Basis der Betrachtung ist das Kapitel 2, in dem die Anwendungsfälle einer solchen Lösung
beschrieben werden. Diese beschreiben ein System, in dem beliebig viele Komponenten eines Schiffes miteinander kommunizieren können. Aus den möglichen Anwendungsfälle leiten
sich drei wesentliche Komponenten her; die für das Schiffsumfeld von wesentlicher Bedeutung sind: Sensoren, Rechen- und Speicherkomponenten. Mit ihnen lassen sich weiter Bereiche des Bordgebrauches abdecken.
Aus den gewünschten Anwendungsfälle ergeben sich logisch eine Reihe von Anforde-rungen an eine prospektive ImplementieAnforde-rungen eines solchen Systems. Um dieses System zu entwickeln, sind verschiedene Wege und zugrundeliegende Technologien anwendbar. In Kapitel 3 werden die aktuell verfügbaren Möglichkeiten mit ihren Basisprinzipien, Vor- und Nachteilen vorgestellt. Auf Grund der Anforderung wird hier als Softwarebasis C0RBA der
0MG verwendet. Dies ist eine plattform- und sprachübergreifende Middleware, für die eine Vielzahl von freien und kommerziellen Implementierungen existiert.
Unter Verwendung von CORBA und dem dazugehörenden Umfeld wird in Kapitel 4 die Spezifikation für ein dienstintegriertes System entwickelt. Es bietet eine Lösung für die oben angedeuteten Anforderungen mit der eine großzügige Vernetzung des Schiffes erstellt werden
kann. Die Spezifikation besteht dabei aus mehreren Teilen. Die Infrastruktur von
DATATRAW-LER besteht größtenteils aus Standardkomponenten aus dem CORBA-Umfeld. Ihre Verwen-dung in diesem speziellen Umfeld wird explizit beschrieben, damit möglichst wenig Raum
für eine implementierungsspezifische Interpretation des Regeiwerkes bleibt. Hinzu kommt die
Beschreibung der eigentlichen Schnittstellen für die in Kapitel 2 geforderten Komponenten. Neben der reinen Beschreibung der Schnittstellen wurde eine ausführliche textliche
Darstel-lung des geforderten Verhaltens entwickelt.
Um die Spezifikation von DATATRAWLER bezüglich der Implementierbarkeit und
Verwen-dung zu testen, wurde eine prototypische Implementation durchgeführt. Hierzu wurden Kom-ponenten unterschiedlicher Komplexität auf Basis der Spezifikation entwickelt die Bedeutung für den Bordbetrieb haben. Die Ausführung der einzelnen Komponenten, die Beschreibung
der Leistungsfähigkeit des Gesamtsystems enthält Kapitel 5.
Das letzten Kapitel enthält die Zusammenfassung der Arbeit und eine Aussicht auf wei-tere mögliche Schritte mit dem Ziel eines dienstintegrierten Netzwerkes entworfen.
Konzeption
Begeben wir uns an Bord des hypothetischen Schiffes «MS DataTrawier». Sie verfügt über ein
dienstintegriertes Netzwerk, welches die an Bord befindlichen Komponenten vereint. Dieses Netzwerk ist nicht auf einzelne Bereiche wie Navigation oder Raumüberwachung beschränkt, sondern steht übergreifend in allen Bereichen zur Verfügung.
Rundgang
Die Brücke wird durch einige wenige Großbildschirme in den Pulten beherrscht. Auf
je-dem können die an Bord anfallende Information dargestellt werden, dabei wird durch Filter die Informationsfiut auf wesentliche Details beschränkt. In den Pulten herrscht
nicht das übliche Kabelgewirr, statt dessen liegt nur je ein Kabel für Daten und Strom-versorgung mit entsprechender Redundanz.
Der Serviceingenieur braucht für normale Routineuntersuchungen seinen Arbeitsplatz
nicht zu verlassen. Den aktuellen Zustand der Systeme kann er jederzeit abrufen oder die Aufzeichnungen der letzten Zeit einsehen. Werden Grenzparameter überschritten, wird er sofort alarmiert und kann von jedem Punkt des Schiffes die aktuellen Daten abfordern. Ein Passagier auf der «MS DataTrawier» sieht natürlich nichts von DATATRAWLER. Auf seiner Kabine befinden sich die üblichen Geräte und Dienste, die in der gehobenen Klasse verlangt werden. Die sind Fernseher, Radio, Telephon, Computer mit E-Mail und Inter-netanschluß. Im bordeigenen Netz kann er jederzeit Daten wie Geschwindigkeit, Position
oder den aktuellen Seekarteausschnitt abrufen, aber auch das Abendprogramm oder
In-formationen über das nächste Landziel. Dennoch ist seine Kabine mit nur einem Kabel an das Bordnetz angeschlossen, alle Dienste werden einheitlich über DATATRAWLER trans-portiert. Soll ein weiterer Dienst in seiner Kabine angeboten werden, zum Beispiel Video on Demand, braucht kein weiteres Kabel gezogen werden.
Der Zahlrneister hat einen permanenten Überblick über die an Bord befindlichen
Wa-ren. Sowohl das Warenwirtschaftssystem wie die Kassensystem sind an DATATRAwLER angeschlossen und lassen sich so abfragen.
Der Reeder ist mit der Entscheidung für die Dienstintegration zufrieden. Nicht nur die gesunkenen Baukosten sind von Interesse, auch der direkte Zugriff auf alle relevanten Daten ist von Bedeutung. Die nach ISO 9001 oder 14000 geforderte Datenspeicherung
geschieht mittels DATATRAWLER automatisch und selbst Basel II [2] läßt sich ohne Pro-bleme erfüllen.
Die Vision einer Dienstintegration an Bord von Schiffen ist ohne Frage sehr attraktiv. Die
Gründe sind verschiedenartig, es reizen gesparte Kabelkilometer und Wartungsarbeit,größere
Schiffssicherheit durch einen besseren Überblick über das Bordgeschehen oder die ansonsten
nicht möglichen Mehrwertdienst für die interne Buchhaltung oder den Kunden. Erst durch 13
die Dienstintegration werden einige Dienste wie automatisches Logbuch,
Schiffsinformations-system etc. sinnvoll möglich.
Das Szenario eines solchen Netzwerkes besteht aus vielen Puzzlestücken, die notwendig, um das Ziel der Dienstintegration zu erreichen. In einem integrierten Netzwerk sind die im Netz vorhandenen Instanzen der unterschiedlichen Komponenten unabhängig von Ort, Her-steller usw. zu benutzen. Eine Komponenten ist dabei die Summe aus ein oder mehreren
Klassen, die jeweils der Erfüllung eines Zweckes (z.B. Abfrage der aktuellen Geschwindigkeit)
dienen. Jede dieser Komponenten kann durch ein oder mehrere Objekte realisiert sein, die sich durch bestimmte Eigenschaften unterscheiden können. Für diesen ersten Entwurf einer übergreifenden Vernetzung werden neben den für die Infrastruktur benötigten Komponenten drei schiffsspezifische Komponenten berücksichtigt: Sensoren, Berechnungsprogramme und
Speicherungsdienste. Beispiele für diese sind: Taster von Lukenverschlüssen
- Nautische Geräte mit NMEA Schnittstelle
Datenströme aus der Bordüberwachung, Radar und Funk
Berechnungsprogramme für Tankinhalt und Medieneigenschaften
Berechnungsprogramme für Ladungsverhalten, Metazentrische Höhe
- Datenspeicherung für ein elektronisches Logbuch
Das Szenario des dienstintegrierten Netzwerkes wird in Form von einzelnen Anwendungs-fällen ( Use Case) entwickelt. Die Usecases beschreiben jeweils, welche Möglichkeiten die
Komponenten dem Anwender bieten, sie sind keine Beschreibung der einzelner Fähigkeit, wie
zum Beispiel die Genauigkeit einer Geschwindigkeitsmessung. Der Schwerpunkt liegt in der Art, wie mit den Komponenten gearbeitet wird, welche Möglichkeiten des Zugriffs
notwen-dig sind und wie die Interaktionen mit anderen Komponenten erfolgt. Für die verschiedenen Komponenten werden verschiedene Anwendungsfällen entwickelt, deren Gesamtheit die
Fä-higkeiten von DATATRAWLER beschreiben.
Grundlage für das Arbeiten mit den Komponenten ist eine gemeinsame Basisarchitek-tur. Diese Basisarchitektur stellt das gemeinsame Netzwerk, über das Klienten und Server verbunden werden. Im Rahmen des Netzwerkes muß der Zugriff auf einzelne Komponenten möglich sein. Die Betrachtung des Netzwerkes kann entsprechend Bild 3.1 in die rein physi-kalische Übertragung und dem darauf verwendeten Protokoll bis hin zur Anwendungsschicht unterteilt werden. Wesentlich für die Anwendung in diesem Kontext ist die gemeinsame
An-wendungsschicht, sie ermöglicht die Interoperabiltät zwischen den Objekten im Netzwerk. Die
Ausführung dieser Schicht muß mehreren Aspekten entsprechen. Hintergedanke dabei muß sein, daß die Aufwendungen zur Integration bestehender Anwendungen oder zur Erzeugung von neuen Anwendungen möglichst gering sein sollen.
Das heißt aus Sicht der beteiligten Firmen minimale Änderung gegenüber dem von ver-wendeten Stand der Technik. Und der ist sehr weit gefächert, im aktuellen Bordgebrauch sind Geräte auf der Basis von einfachen Kontrollerbausteinen über Industrierechner mit x86-Architektur bis hin zu Unix-Workstation. Das zu verwendende Protokoll muß sowohl auf
2,..,irifrastruktur und
sichergestellt werden, daß die Hersteller von Klient wie Server nicht auf eine bestimmte Pro-grammiersprache festgelegt werden, damit die bisherigen Erfahrungen und Quelltext weiter-verwendet werden kann. Neben der reinen Verfügbarkeit für möglichst alle bisher verwen-deten Geräte dürfen die Anforderungen an den Speicherbedarf und Rechenleistung nicht zu groß sein. Wird die Meßlatte für den Einstieg in die Dienstintegration schon durch die Wahl des verwendeten Protokolls und seine Folgen zu hoch gelegt, wird sich noch lange keine Anwendung an Bord ergeben.
Jenseits des Basisprotokolls bestehen die Anforderungen aus zwei wesentlich Teilberei-che. Der erste betrifft die Anforderungen an die allgemein verfügbare Netzinfrastruktur und das Verhalten von DATATRAWLER eigenen Komponenten in diesem Umfe]d. Er ist in den Kapitel 2.1.1 his 2.1.3 abgehandelt. Der zweite Bereich enthält die spezifischen Fähigkeiten,
die DATATRAWLER-Objekte im allgemeinen ausmachen sowie die spezifischen Fähigkeiten der betrachteten Komponente. Dieser Teilbereich ist in dem Kapitel 2.1.5 bis 2.4 enthalten.
In der kompletten ,Arbeit wird ein Punkt nicht oder nur am Rande behandelt: die ver-wendete Hardware. Sie hat auf das verver-wendete Konzept nur marginalen Einfluß hat. Es wird im Folgenden deshalb nur angenommen, daß eine beliebige geartete Verbindung (siehe Bild 3.1) zwischen den Komponenten und Kiienten vorhanden ist. Ob die Vernetzung auf Basis
von Ethernet, - ATM oder gar Token Ring durchgeführt wird, ist eher eine Frage der
Ko-sten, denn von konzeptioneller Bedeutung. Die genaueren Anforderungen an die Hardware ergeben sich unter anderem aus dem verwendeten Basissystem (siehe Kapitel Kapitel 3), der Anzahl und Art der integrierten Komponenten und nicht zuletzt aus den Anforderungen der beteiligten Klassifikationsgesellschaft und wird deshalb hier nicht behandelt.
2.1
nfrastruktur und Basisfunktionalitäten
Bevor mit den drei schiffsspezifischen Komponenten gearbeitet werden kann, ist eine In-frastruktur notwendig, die das Arbeiten in dienstintegrierten Netzwerken überhaupt erst
er-möglicht oder wesentlich erleichtert. Diese Dienste betreffen vor allem die Objektermittlung (Kapitel 2.1.1), Benachrichtigung von Kiienten über Zustandsänderungen (Kapitel 2.1.2) und ein allgemeines Zeitnormal (Kapitel 2.1.3). Des weiteren gibt es Reihe von Punkten, die alle
DATATRAWLER-Objekte gemein haben sollen. Dies betrifft einmal ein Konzept zum Abfragen und Ändern der Konfiguration (Kapitel 2.1.4) wie natürlich den Datentransport (Kapitel 2.1.5).
2.1.1 Objektermittlung
Bevor ein Klient Zugriff auf das eine Komponente realisierende Objekte in einem Netzwerk
hat, muß eine Referenz auf dieses ermittelt werden. Die Ermittlung der Referenz für ein Objekt
kann dabei abhängig von der Anwendung auf zwei verschieden Weisen geschehen:
> Ermittlung einer Referenz für ein Objekt bekannten Namens
- Ermittlung einer Referenz für ein Objekt mit bestimmten Eigenschaften
Diese Probleme findet man in jedem Netz, zu ihrer Lösung sind meistens zwei verschiedene Dienste vorhanden. Am bekanntesten dürften die vergleichbaren Dienste des Internets sein, hier dient zum Beispiel der Nameserver zur Namensaufiösung [21, 221 von Rechnern und
Anbieter wie Yahoo oder Lycos bieten ihre Dienste als Suchmaschinenan für Dokumente auf
o
Klient fract nach Referenz DataTrawler Namens-auflösungfragt nach Zeit
Bild 2.1: Usecase-Dïagramrn der Infrastruktur
fragt nach Referenz
trägt Namen und Referenz ein
trägt Eigenschaften und Referenz ein
fragt nach Zeit
Die Namensauflösung dient dazu, zu einem Namen die Referenz eines Objektes zu
ermit-teln. Vorausgesetzt, der Name des Objektes setzt sich mit Hilfe eines Namensschematas aus den Informationen über Typ, Position, Hersteller... zusammen, kann man bei dem Dienst zur Namensauflösung (Narneserver) sofort die Referenz zu der gewünschten Komponente erhal-ten. Voraussetzung für die Namensauflosung ist ein einheitliches Schema, welches im Sinne der Übersichtlichkeit gut strukturiert sein muß. Der Namensdienst muß in der DATATRAw-LER-Infrastruktur zur Verfügung stehen und die Referenzen auf Objekte entsprechend dem
gewählten Namensschema speichern. Klienten können dort die Referenz zu einem Objekte mit
bekannten Namen auflösen. Des weiteren sind administrative Möglichkeiten zur Überprüfung
der gespeicherten Referenzen oder Löschen von Eintragen beim Namensdierist notwendig. Als Basisdaten für das DATATRAWLER-Namensschema werden daher folgende vorgeschla-gen:
Art des Gerätes Position des Gerätes im Schiff
Hersteller eindeutige Identifikation
Modell des Gerätes
Neben der Namensauflösung soll eine Möglichkeit vorhanden sein, Geräte anhand
ein-zelner Merkmale wie ihres Dienstes oder Position, Typ oder Hersteller finden zu können. Diese
Suchmaschine muß für jedes Objekt ein Satz von Eigenschaften speichern, anhand deren es
bei einer späteren Suche ermittelt werden kann. Damit diese Suche eine große Bandbreite von
Objekten abdeckt, ist die Speicherung eines bekannten Mindestsatz an Eigenschaften notwen-dig. Diese werden später bei den einzelnen Komponenten näher zu beschreiben sein. Wegen
der Ähnlichkeit mit dem Namensschema sind zumindestens die dort beschriebenen Basisdaten
auch für jedes Objekt in der Suchmaschine zu hinterlegen.
2.1. Jpfrastruktur und BassfunktionaIithten - -
-Da jedoch kaum abzusehen ist, ob die gewählten Eigenschaften jedes Gerät eindeutig beschreiben, muß ein Anbieter in der Lage sein, weitere Eigenschaften in der Suchmaschine für seine Objekte ablegen zu können. Dies ermöglichen ihm, einen technischen Mehrwert anzubieten, ohne die Funktionalität für generische Werkzeuge einzuschränken. Ein Use Case Diagramm mit den eben beschriebenen Diensten ist in Bild 2.1 enthalten.
Das Anmelden mit Namen oder Eigenschaften sowie Referenz und Eigenschaften muß ein einfacher Prozeß sein, da auch Embedded Devices in Betracht kommen, sind zu auf-wendige Verfahren nicht praktikabel. Die Identifikation von Komponenten muß anhand von
verschiedenen Kriterien durchführbar sein.
2.1.2 Benachrichtigung
Betrachtet man den Datenfluß zwischen Server und Klient, gibt es drei grundsätzliche
Lösun-gen:
- der Klient fragt Daten an und bekommt sie vom Server
der Klient meldet sich beim Server an und bekommt irgendwann Daten zugeschickt
- eine dritte Komponente vermittelt die Daten zwischen Server und Klient
Der erste Weg besticht durch seine Einfachheit, außerdem kann so ein Klient gewährleisten,
daß er die Daten dann bekommt wenn er sie braucht. Dieser Weg ist deshalb zu realisieren. Der
Nachteil dieser Lösung wird jedoch bei einer Vielzahl von Klienten sichtbar. Obwohl sie alle identische Daten abfragen, sind sie alle getrennt zu bedienen,was die Last auf der Serverseite
steigert. Die Klienten ihrerseits müssen regelmäßig beim Server anfragen ( Polling), um auf dem neusten Stand zu bleiben. Dies ist besonders auffällig bei Sensoren, deren Wert sich nur selten ändert, deren Änderung aber im Ereignisfall aber schnell bekannt sein muß. Hier
muß mit hoher Rate abgefragt werden, obwohl eventuell nie eine Änderung eintritt. Ein prominentes Beispiel für solche Sensoren sind Brand- oder Einbruchsmelder.
Der zweite Weg hat diesen Nachteil nicht, liegen neue Daten beim Server an, kann er alle
Klienten mit einem Mal versorgen. Allerdings kann die Zeit zwischen dem Schicken zweier Daten sehr lang sein. Neu angemeldete Klienten blieben solange ohne Daten. Zweitens muß sich der Server dann nicht nur um die Verwaltung der eigentlichen Daten kümmern, auch
die Klienten müssen verwaltet werden. Fehlermeldungen durch das Verschicken von Daten an
nicht mehr existenten Klienten müssen interpretiert werden etc. Dadurch wird
Implementie-rung des Servers vergrößert.
Als Ausweg bietet sich der dritte Weg an. Eine drittes Objekt wird zwischen dem Server und den Klienten geschaltet und verteilt Daten vom Server an die Klienten. Der Server ist
von der Verwaltung der Klienten entlastet und muß neue Daten nur noch einmal an das
Verteiler-Objekt übermitteln. Durch diesen Weg wird das - Polling vermieden. Um sowohl die Möglichkeit zu haben, sofort Daten bei einem Server abzufragen, aber auch Polling zu
vermeiden, sollen bei DATATRAWLER der ersten und dritten Weg zu den Daten unterstützt
werden (siehe Bild 2.2).
Hierfür muß die Infrastruktur eine Möglichkeit anbieten, die die Daten für den Serveran
eine Vielzahl von Klienten verteilt. Des weiteren sind auch hier wieder administrative Dinge wie An- und Abmelden von Klient und das Öffnen und Schließen der Verteiler notwendig.
Th D ataT ra w e r fragt Daten ab fragt Referenz von Ereigniskana vermittelt Daten meldet sich an/ab
Bild 2.2: Usecase-Diarmm für die Benachrichtigung
versorgt mit Daten
2.1.3 Zeitbehandlung
Für einige Dienste ist die korrekte Zeitbehandlung von Bedeutung, sei es bei der
Datenspeicher-ung oder zur Synchronisieren mit anderen Diensten. Hierfür ist es notwendig, ein Zeitnormal zur Verfügung zu haben. Damit können auch Dienste auf Basis von Hardware ohne RTC
mit genauer Zeit arbeiten und zweitens können alle Dienste auf einer gemeinsamen Zeitbasis
arbeiten (siehe Bild 2.1).
Die Infrastruktur muß deshalb eine Komponente enthalten, bei der die aktuelle Zeit mit
hoher Genauigkeit abgefragt werden kann, um sie in in DATATRAWLER-Komponenten
verwen-den zu können.
2.1.4 Eigenschaften und Konfiguration
Nachdem ein Objekt mit Hilfe der im Kapitel 2.1. 1 beschriebenen Techniken gefunden wurde.
muß ein Klient ermitteln können, welche näheren Eigenschaften es hat oder es gegebenfalls den Wünschen des Anwenders anzupassen. Um die Möglichkeit zu haben, mit Objekten zu arbeiten, deren Eigenschaften nicht a priori bekannt sind, müssen es möglich sein die aktuelle
Konfiguration des Objektes zu ermitteln und die Konfiguration des Objekte zu ändeim. Für alle DATATRAWLER-Objekte muß daher ein einheitlicher Mechanismus vorhanden
sein, mit dem Eigenschaften abgefragt und gegebenfalls auch geändert werden können. Ne-ben dem einheitlichen Transport von Konfigurationsattributen verschiedener Natur (Zeichen-ketten, Boolesche oder numerische Werte) stellt sich das Problem, was passiert, wenn unter-schiedlich Klienten eine Komponente in verschiedenen Konfigurationen benötigen. Beispiels-weise wenn unterschiedliche Klienten die Ausgabe der Schiffsgeschwindigkeit in Knoten, in rn/s oder km/h erwarten. Hier sollte ein einheitliche Lösung von Konfigurationskonflikten für alle Geräteklassen gefunden werden. Dabei ist zu bedenken, daß Komponenten möglicherwei-se zehn oder zwanzig Parameter bieten, so daß nicht einfach für jede mögliche Kombination
ein Objekt zur Verfügung gestellt werden kann.
Eine mögliche Lösung ist das Factory Pattern. Dieses Entwurfsmuster sieht eine Objekt (die Factory) vor, deren einzige Aufgabe es ist, weitere Objekte zu erzeugen. Diese, von der Factory erzeugten, Objekte können den Ansprüchen des Klienten entsprechend konliguriert werden. Da jedes Objekte nur einem oder wenigen Klienten zur Verfügung steht, kann dies
,sflt.,,çflNflPtIc,* Konzeption
A
Klient
t
fragt nach Standardkomponente
und Standarkonfiguration,
fragt nach neuer Komponente
Bild 2.3: Usecase-Diagramm der Erstellung und Konfiguration
ohne Konflikte geschehen. Die eigentlichen Aufgaben wie Meßwert abfragen etc. werden dann durch die konfigurierbaren Objektevorgenommen. Das Use Case Diagramm hierzu ist
in Bild 2.3 enthalten (siehe auch [48, 15]).
Soll zum Beispiel die Windgeschwindigkeit abgefragt werden, so wird bei der entspre-chenden Factory ein Objekt angefragt. Dieses Objekt repräsentiert den Sensor im Netz und kann entsprechend den Anforderungen konfiguriertwerden. Hier würde sich die Verwendung unterschiedlicher Maßeinheiten (Knoten, m/s, km/h) oder Mittelungsverfahren (keine Mitte-lung, über die letzten 10, 30, 60 ... Sekunden) anbieten.
Damit bei Standardaufgaben nicht mehrere Objekte mit der gleichen Konfiguration er-zeugt werden müssen, wird das Entwurfsmuster noch erweitert. Die Factory bietet neben der Erzeugung konfigurierbarer Objekte eine Standard-Objekt an. Diese läßt sich von den
Klien-ten nicht verändern. ist ein Klient mit der Konfiguration des Standard-Objektes einverstanden,
kann er seine Anfragen bei diesem bearbeiten lassen, ansonsten muß er bei der Factory ein
neues Objekt erzeugen lassen.
Mit dieser Aufteilung läßt sich auf der einen Seite eine Komponente exakt an die
Bedürf-nisse des Klienten anpassen. ist eine Komponente durch ihre Implementierung hingegen auf eine Konfiguration beschränkt, kann die Erstellung weitere Komponenten durch die Factory-Komponente unterbunden werden.
2.1.5 Datentransport
Alle Anwendungen in dienstintegrierten Netzen basieren auf Daten über das Schiff und seine Umgebung, dem Datentransport kommt daher eine zentrale Rolle zu. Es gilt, einen Wegzu
finden, in dem Daten beliebiger Art transportiert können, ohne das dadurch ein Wirrwar
spezifischer Schnittstellen entsteht. Dies würde der idee des integrierten Netzes widersprechen.
Bei dem Daten an Bord, kann aus technischen Gründen zwischen zwei verschiedenen Arten unterschieden werden, einmal einzelne Datensätze, zweitens die Datenströme. Die
Da-tensätze fallen bei den meisten Sensoren an, sie sind Bestandsaufnahmen einzelner Parameter.
Beispiel für solche Daten sind Position, Kurs, Verriegelungsstatus. Bei den Datenströme hin-erzeugt konfiguriert, J' löscht Komponente verweistauf Konfiguration Standard-konfiguration Standard-komponen
j
r-DataTrawlerServer (lin icast) Nachricht L._..[Hrrachnichc 2 i- 4racrict 3 j Nac rict 4
Einfache übertragung eines Packetes,
Unterscheidung nicht möglich,
nur an Interessierte Klienten
Server (MuUicast weiterer Rechner KlientA
L
weiterer RechnerBild 2.4: Unicast, Multicast und Broadcast als Übertragungsniethoden
Mehrfache Übertragung jedes Packetes
Unterscheidung möglich,
nur an Interessierte Klienten
weiterer Rechner
j
gegen handelt es sich um die kontinuierliche Aufnahme von Werten, von denen ein Schnapç-schuß meist keinen Aussage enthält. Beispiel hierfür sind Ton- oder Vìdeoübertragung. Sie unterscheiden sich auch im Datenvolumen erheblich von den einzelnen Datensätzen.
Aus technischen Gründen verbietet sich die Übertragung beider Datenarten mit den glei-chen Transportmechanismen, hier läßt sich auch eine Unterscheidung in den Schnittstellen schwerlich umgehen. Ein Großteil der Daten, die an Bord übertragen werden, bestehen aus wenigen Variablen, die eine feste Struktur haben. Beispiele hierfür sind NMEA-Pakete, Meß-werte für Temperatur oder Druck etc. Bei Daten dieser Art besteht weniger das Problem in
der Menge der transportierten Daten, sondern in der Menge der verschiedenen Inhalte. Hier ist wünschenswert, daß diese Daten in einer Struktur vorliegen, die allen Komponenten be-kannt ist und sich leicht erstellen, transportieren und entziffernläßt. Die verwendete Struktur muß dabei so flexibel sein, daß auch das Auftreten neuer Datentypen keine großes Probleme
Server
(Broadcast)
Einfache Ùbertragung eines Packetes,
Unterscheidung nicht möglich,
.NachricbO
1-KlientC KlientD
an alle Rechner
darstellen darf. Dabei sollten die Daten möglichst in ihrem originalen Format transportiert
werden, es also nicht nötig sein, zum Beispiel alle Gleitzahlen in eine Darstellung als Zeichen-kette umzuwandeln.
Neben einer einheitlichen Struktur zum Transport der Daten selber müssen die Meta-daten vorhanden sein. Dies ermöglicht die Erstellung generischer Klienten, Diagnose- und Speicherungskomponenten. Dank der Metadaten können sie mit Datensätzen beliebiger
Auf-bau arbeiten, zum Beispiel zur Anzeige oder Speicherung.
Anders ist hingegen die Lage bei den Datenströmen. Sie enthalten im allgemeinen
AV-Daten mit einem großen Bandbreitenanspruch, ihr Format ist durch wenige Standards wie
MPEG oder WAV festgelegt. Während bei den Datensätzen eine möglichst einfache
Wei-terverarbeitung von Interesse ist, beschränkt man sich bei den Datenströmen meist auf das
Aufnehmen, Abspielen und Abspeichern.
Zu der Übertragung von Datenströmen ist der Aufbau einer dedizierten Verbindung not-wendig. Für dieses Verbindungen sind zur Zeit drei verschiedenen Methoden (siehe Bild 2.4)
üblich:
Unicast Verbindungen mit TCP- oder UDP-Paketen. Diese Verbindung ist vergleichbar mit einer Telephonverbindung. Bei der Unicast Verbindung wird vom Server für jeden Kli-ent eine spezielle Verbindung geöffnet. Gleiche Daten werden für jeden KliKli-ent einzeln
gesendet, eine Unterscheidung der Klienten ist möglich. [41, 40]
Multicast Verbindungen mit UDP-Paketen. Diese Verbindung ist vergleichbar mit einer Te-lephonkonferenz, nur bestimmte Partner nehmen daran teil. Bei der Multicast Verbin-dung können sich mehrere Klienten an einen Multicast Server hängen. Gleiche Daten werden nur ein einziges Mal gesendet, eine Unterscheidung der Klienten innerhalb der
Multicast-Gruppe ist nicht möglich. [47]
Broadcast Verbindungen mit UDP-Paketen. Diese Verbindung ist vergleichbar mit einem Me-gaphon, alle Netzteilnehmer sind betroffen. Bei der Broadcast Verbindung werden Daten vom Server an alle Rechner im Netz gesendet. Eine Unterscheidung der Rechner ist nicht möglich, eine Eingrenzung auf bestimmte Rechner ebenfalls nicht. [23]
Die beste Art des gewählten Datentransport ist in hohem Maße von der Natur der zu trans-portierenden Daten und deren Verwendung abhängig, jede der drei Methoden ihre Vor- und
Nachteile. Sowohl die gewählte Basisarchitektur wie auch die Schnittstellen der Komponenten
sollten daher alle drei Arten gleichermaßen unterstützen. Die endgültige Wahl der
unterstüt-zen Transportai-t wird erst bei der Implementierung fallen.
2.1.6 Sicherheit
Bei den Vorteilen und Möglichkeiten dienstintegrierter Netzwerke ergibt sich leider auch ein neues Problem, die Sicherheit der zur Verfügung stehenden Daten und Dienste. Sicherheit in
verteilten Netzwerken kann ganz unterschiedliche Aspekte betreffen, Beispiele wären die
ein-deutige Kennzeichnung der Anwender urn Zugriffsrechte vergeben zu können, die Integrität der übertragenen Daten gegenüber Änderungen durch Dritte, der Schutz der übertragenen Da-ten vor unerlaubtem Zugriff Dritter, eine garantierte Verfügbarkeit der Netzwerkverbindung und der Komponenten selber.
-Ebenso unterschiedlich wie diese Aspekte sind die betroffenen Bereiche, zum Beispiel ist
die Verfügbarkeit unter anderem ein Problem der verwendeten Hardware und der Kabelver-legung, während für Schutz der übertragenen Daten sowohl der physikalischen Zugang zum
Übertragungsweg (Kabel, Switch) wie auch eine Verschlüsselung der Daten in Frage kommt.
Hier die Maximalforderung eines in allen Aspekten ultimativ sicheren Netzwerkes zu stellen, würde dem Problem nicht gerecht werden. Gerade beim Einstieg in die Dienstintegra-tion darf die Einstiegshürde durch zu hohe Anforderungen in Bezug auf die Sicherheit nicht zu hoch gelegt werden. Ein Teilbereich kann bei der Betrachtung sowieso abgetrennt wer-den, an die Verfügbarkeit des Netzwerks und der Komponenten vor einem Bordeinsatz von den Klassifikationsgesellschaften entsprechende Forderungen gestellt. Außerdem haben die einschlägigen Anbieter von Software für den Bordgebrauch ihrerseits Erfahrung im Entwurf zuverlässiger Software gemacht)
Gegenüber der feindlichen" Umgebung des Internets bietet die Bordvernetzung einige Voraussetzungen, die die Sicherheit positiv beeinflussen. Es handelt sich um ein abgeschlos senes Netzwerk mit gut kontrollierten (wenn überhaupt) Schnittstellen nach außen. Dabei bezieht sich das abgeschlossen nicht nur auf die räumliche Ausdehnung, auch der
physikali-sche Zugang für Dritte ist im Allgemeinen stark erschwert. Das Abhören von Daten ist deshalb
in viel geringerem Maß ein Problem als im Internet, wo die Datenverbindung potentiell über mehrere unbekannte Zwischenstationen läuft. Gleichermaßen ist die Änderung der übertrage-nen Daten zwar kein ausgeschlossenes, allerdings ein wenig wahrscheinliches Szenario.
Anders stellt es sich hingegen bei der Authentifizierung der Nutzer dar. Der Normalfall
wird zwar, wie heute, der anonyme Zugriff auf die Komponenten sein, in einigen Fälle ist eine Benutzerauthentifizierung jedoch notwendig. Der Grund kann zum Beispiel in der Verwaltung
wesentlicher Eigenschaften einer Komponente liegen, aber auch die Abrechnung bestimmter
Dienste bei Passagieren (z.B. Video on Demand) ist denkbar.
2.2 Sensor
Mit dem Sensor wird die erste schiffsspezifischen Komponenten vorgestellt. Bei einem Sensor handelt es sich um ein Gerät, welches als Datenquelle dient. An Bord gibt es mehrere Hundert
bis Tausend verschiedener Sensoren. die unterschiedlich komplexe Werte aufnehmen. Dies reicht von einfachen Tastern für Verriegelungen über Sensoren für Temperatur, Druck his hin zu so komplexen Geräten wie Radar oder Flächen-Echolot. Für eine sinnvolle Vernetzung müssen alle Sensoren eine Möglichkeit im Netz anbieten, die aktuellen Werte auszulesen und gegebenenfalls ihre Eigenschaften entsprechend 2.1.4 zu konfigurieren. Dabei können
Sensoren ihre Daten sowohl in Form einzelner Datenpakete oder als Stream (S. 19 ff.) abgeben.
Für die Sensoren müssen wie im Usecase-Diagramm 2.5 abgebildet mindestens folgende
Operationen möglich sein:
)
Größe des aktuellen Wertes abfragen Benachrichtigungen entsprechendKapi-tel 2.1.2 anzufordern
)e Konfiguration abfragen und ande
Informationen über die
aufgenomme-nen Daten ermitteln
Dies ist übrigens auch ein Grund, diese nicht durch dic Wahl des Basissystems in eine für sie neue Umgebung zu zwingen, bisher gemachte Erfahrungen wären dort mit großer Wahrscheinlichkeit wertlos.
2.3
Berechnung
Serrsor-Klient +
fragt nach Referenz
DataTrawler
fragt nach Sensor
nd Sfandarkonfiguration
fragt nach Daten, fragt nach Ereigniskanal
konfiguriert, löscht
Bild 2.5: TJsecase-Diagrarnrn für die Sensorkomponente Sensor
leitet Daten an Klient weiter
erzeugt
fragt nach Referenz
trägt Namen und Referenz ein
trägt Standardeigensohaften und Referenz ein
erzeugt Ereigniskanal, sendet Daten
(eigniskanal
Bild 2.6: Kombinationsmöglichkeit von Sensor- und Berechnii.ngskornponente
Die nächste Komponente dient der Berechnung, mit ihr werden auf Basis von Einga-bedaten unterschiedlich komplexe Berechnungen oder Umwandlungen durchgeführt und das
Resultat ausgeben. Solche Komponente werden an Bord schon in großer Mengeverwendet, sie
sind jedoch meistens in proprietären Programmen eingebettet. Ein Beispiel hierfür ist das
Pro-gramm tames [si] des Bundesamtes für Seeschiffahrt und Hydrographie. Dies berechnet auf
Geschwindigkeit und
Wird-sensor Winkel zum Schiff
Geschwindigkeit und Kurs über Grund
Berechnungs- Wiodgeschwirndigkeit
dienst und -winkel über Grund
2. Konzeption
fragt nach Referenz
trägt Namen und Referenz ein
fragt nach Berechnungsdienst und Standarkonfiguration
leitet Daten an Klient weiter
Bild 2.7: Usecase-Diagrarnm für die Berechnungskornponenîe
fragt nach Referenz
trägt Standardeigenschaften und Referenz ein
verbindet mit Ereigniskanal, sendet Daten
Cchmaschi)
Basis von Peilwert, Druck und Temperatur das Volumen und die Masse der Ladung in Tanks.
Intern geschieht dies durch die Berechnung der Vo]umina des Tanks unter Berechnung der La-ge, Tankschrumpfung und Peilungskorrektur durch die Temperatur und Dichte des Ladegutes. Obwohl alle diese Werte in elektronische Form vorliegen, müssen sie von den entsprechenden
Anzeigen abgelesen werden und durch den Benutzer neu eingegeben werden, da mangels
In-tegration kein Zugriff auf diese Daten möglich ist. Ähnlich Probleme gibt es an Bord in großer
Menge, allein aus dem Ladungsbereich wäre es zum Beispiel Ladungsrechner zur Ermittlung der Metazentrischen Höhe, Berechnung der Stauposition von Containern, Tankberechnungen für Inhalt, Be- und Entladevorgänge, Inertbegasung, Klimaführung bei Kühliadung usw.
Damit es möglich wird, einen durchgängigen Datenfluß vom Sensor bis hin zu dem gewünschten Ausgangsergebnis zu ermöglichen, muß man auf Berechnungsdienste wie auf einen Filter zurückgreifen können. Eine Beispielanwendung für ein vernetztes System ist in
Bild 2.6 vorgeschlagen. Berechnungsdienst müssen somit sowohl Datenquelle wie -senke
dar-stellen, Ein- und Ausgang werden dabei in der Regeln unterschiedliche Datenformate haben. Genauso wie bei den Sensoren soll nicht nur die einmalige Übertragen von Datenpaket mög-lich sein, sondern auch eine Verknüpfung mit der Benachrichtigung S. 17).
Entsprechend dem Usecase-Diagramm in Bild 2.7 muß ein Berechnungskomponente
fol-Berechnungs-Kflent
fragt nach Berechnung, fragte nach Ereigniskanal, verbindet mit Ereigniskanal
konfiguriert, löscht
erzeugt
e
gende Möglichkeiten bieten:
Eingabe der benötigten Daten
Ausgabe der berechneten Daten oder Fehlermeldung
) Abfrage der benötigten Daten und Ein-heiten
Lesen der Daten aus einem Ereignis-kanal
Schreiben der Daten in einen
Ereignis-kan al
Entsprechendes gilt natürlich auch für eine Streamvariante der Berechnungskomponente, mit ihr ließen sich zum Beispiel Formatumwandlung, Datenreduktion durch geringere
Auflö-sung oder Kompressionsverfahren realisieren.
2.4
Datenspeicherung
Die dritte DATATRAwLER-Komponente dient der Datenspeicherung. Sie ist für
unterschied-lichen Zwecken notwendig. Kurzfristige ( 10 Minuten - I Stunde) Speicherung von Ge-schwindigkeit, Ruderlage und Radarbildern kann für den Fall einer Havarie durchgeführt werden. Mittel- und langfristige Speicherung (wenige Stunden bis mehrere Jahre) können für
allgemeine Nachweispflichten wie ein Logbuch oder zur Planung von Serviceintervallen ge-nutzt werden. Die Datenspeicherung ist damit ein logisches Ende der Kette vom Sensor über Berechnungskomponente bis hin zur Datenspeicherung.
Die Schnittstellen der Datenspeicherungs-Komponente müssen folgende Methoden
an-bieten:
i- Daten speichern Daten abrufen
Daten speichern aus einem Ereignis- ' Daten löschen (optional)
kanal
Dabei kann der Punkt der Datenabfrage unterschiedliche komplex gestaltet sein, von der Ausgabe aller gespeicherten Daten bis hin zur Datenbank gestützten Abfrage mittels Abfrage-sprache sind diverse Lösungen denkbar. Ebenso natürlich für das Löschen von Daten, was in einigen Anwendungsfällen überhaupt nicht gewünscht sein kann.
2.5
Zusammenfassung
Um das Ziel der Dienstintegration zu erreichen, gibt es eine Reihe von Anforderungen, die
Ver-wendete Basisarchitektur, die realisierte Infrastruktur und durch die im Netzwerk verfügbaren Komponenten zu erfüllen sind.
Die Basisarchitektur muß auf einer Vielzahl von Betriebssystemen, Programmiersprachen
und Hardware verfügbar sein. Der dafür betriebene Aufwand darf insbesondere bei Geräten
am unteren Ende der Leistungsfähigkeit keine zu große Einstiegshürde bieten.
Mit der Basisarchitektur ist eine Infrastruktur zu realisieren, die eine Reihe von Diensten für das Zusammenspiel von Klienten und Server anbietet. Unter diesen sind zwei Dienste, die zur Ermittlung von Objekten im Netzwerk dienen. Der eine dient zur Auflösung von Namen entsprechend eines noch zu spezifierenden Namensschema basierend auf den Objekteigen-schaften von Seite 16. Der andere soll eine freie Suche von Objekten anhand von bestimmten Objekteigenschaften ermöglichen. Ein weiterer Dienst der Infrastruktur dient der Verteilung
rrIW,flt4en2taYjrM
A
Speicherdienst-Klient
fragt nach Referenz
DataTrawler
r
speichert. sucht und löscht Daten, verbindet mit Ereigrriskanal,
f öst non Ereignokanat, abrrrelden,
löscht
erzeugt Ereigniskanafi, sendet Datan
BHd 2.8:Usecase-Diagramm für die Speicherungs-Komponente
fragt nach Referenz
trägt Standardeigenschahen und Referenz ein
Suchmaschine
von Daten an Klienten, so daß sich die Aufgabe von Datenquellen auf die Erstellung der Da-ten beschränken kann. Ein gemeinsames Zeitnormal im Netzwerk dient dazu, mit möglichst geringem Aufwand für die Administration Zeitunterschiede zwischen den Objekten auf ein Minimum zu reduzieren. Zumindestens optional sollte eine Möglichkeit vorhanden sein, daß Server den zu einer Anfrage gehörende Benutzer eindeutig identifiziert zu können. Für die Verwaltung von Benutzern, Rollen und Gruppen ist ein entsprechendes Werkzeug zur
Verfü-gung zu stellen.
Die Infrastruktur stellt nur die Hülle dar, in der drei verschiedene Arten von
Komponenten-Instanzen ihre Dienste anbieten. Betrachtet werden Sensoren, Berechnungskomponenten und Datenspeicherung. Ihnen gemein sind die Anforderungen an die Konfiguration und den
Da-tentransport. Bei alle DATATRAWLER-Objekte muß die Konfiguration auf einheitliche Art und
Weise abgefragt und gegebenenfalls auch geändert werden können. Um Konflikte zwischen den Anforderungen verschiedener Klienten zu verhindern, ist eine Factory vorgesehen, bei dem die Klienten ein für sie erstelltes und konfigurierbares Objekt anfordern können. Um die Anzahl der Objekte zu reduzieren, kann darüberhinaus noch ein Objekt mit
Standardkonfigu-ration angeboten werden.
Neben der Konfiguration soll auch die Art des Datentransports allen Komponenten ge-mein sein. Entsprechend der transportieren Daten sind zwei verschiedene Transportarten
not-o
ragt nach Log und Standarkorrtiguration2.5.
wendige, einzelne Datensätze und Datenströme. Für die einzelnen Datensätze wird ein
Trans-portbehälter gefordert, der in einem einfachen und leicht zu lesenden Aufbau die jeweiligen Daten enthält. Darüber hinaus muß eine Anwendung jederzeit Metadaten über die
empfange-nen Daten abfragen könempfange-nen. In einigen bestimmten Fällen wie der Ton- oder Filmübertragung
muß die Datenübertragung technisch vollkommen anders gehandhabt werden. Statt einzelner Datensätze werden kontinuierliche Datenströme verwendet. Hier existieren drei konkurrie-rende Verbindungsmöglichkeiten, die jeweils in bestimmten Anwendungsfä]len ihre Vorteile
ausspielen können. Deshalb muß die Spezifikation der DATATRAWLER-Schnittstellen so
gehal-ten werden, daß alle drei Möglichkeigehal-ten für den Transport von Dagehal-tenströmen zur Auswahl
stehen.
Auf der Basis dieses Kapitels werden zunächst die zur Auswahl stehenden Basistechno-logien evaluiert und dann mit den Mitteln der gewählten Basistechnologie die Schnittstellen spezifiziert, mit denen sich eine dienstintegriertes Netz entsprechend den hier aufgestellten Forderungen aufbauen läßt.
1-L
Systemwahl
Bisher wurde bei der Beschreibung der Anforderungen nicht darauf eingegangen, wie diese zu realisieren sind. Da die Art der gewählten Realisation sowohl darüberentscheidet, welche der geforderten Komponenten bereits zur Verfügung stehen und in welcher Form die genaue Beschreibung der Schnittstellen vorgenommen werden muß, ist dies vor ihr zu behandeln.
Bisher wurde pauschal davon ausgegangen, daß dem System eine Technik unterliegt, die den Zugriff auf Objekte im Netzwerk erlaubt. Um dies zu realisieren, können verschiedene
Wege begangen werden:
Erstellung einer spezifischen Kommunikationsschicht fürden Bordgebrauch
Verwendung bereits existierender Protokolle aus anderen Bereichen
> Verwendung bereits vorhandener Standards fürverteilte Objekte
Der gewählte Weg entscheidet als Basistechnologie wesentlich über den Aufwand für die
Realisation von DATATRAWLER. Je nach gewählter Lösung sind sowohl unterschiedlich große
Bereiche selber zu implementieren als auch technischeEinschränkungen hinzunehmen. Dabei
darf der Punkt geeigneter Entwicklungswerkzeuge wie auch Dokumentation nicht vergessen
werden. In Bild 3.1 ist das OSI-Schichtenmodell-Modell mit dem unterschiedlichen
Entwick-lungsaufwand je nach dem gewählten Ansatz abgebildet.
3.1
Spezifische Kommunikationsschicht
Die Implementierung einer spezifischen Kommunikationsschicht, die Low-Level Probleme wie
Unabhängigkeit von unterschiedlicher Hardware, Fehlermeldungen etc., gutmütig behandelt, die einen sinnvolle Leistung in Bezug auf Datenmenge und Ansprechzeit zeigt und plattform-übergreifend verfügbar ist, ist eine nicht triviale Aufgabe. Dieser Ansatz wurde im MiTS Projekt [45] versucht, welches sich jedoch nicht durchsetzen konnte.
Ein weiteres Beispiel für ein spezifisches Protokoll ist die Marine Event Record (MER) Lösung von Procom [16]. Dies ist eine Black-Box, in der an Bord anfallende Daten für den
Havariefall gespeichert werden. Der MER soll in Zukunft zu einer Lösung für das
Schiffsma-nagement ausgebaut werden. Die Daten von Sensoren wie NMEA-Geräten oder Radar werden
bei dieser Lösung in einem ,,Konzentrator" in das MER-Protokoll umgewandelt. Dieser Kon-zentrator ist nur als Haibrücke ( Brücke) ausgelegt, also nur in der Lage, externe Signale in das eigene Format umzuwandeln. Ein Möglichkeit von der MER-Seite auf externe Ger-äte zuzugreifen gibt es nicht. Das MER-Protokoll basiert auf UDP-Paketen und spezifiziert
Application Layer Presentation Layer
Session Layer
Transport Layer
Network Layer
Logical Link Layer
Physical Layer
Zu erstellen
Vom Betriebssystem bereitgestellt
Bild 3.1: Vergleich der Lösung im OSI-Modell
neben der Möglichkeit zur Datenübertragung einfache Administrationsaufgaben wie
Anmel-den/Abmelden von Geräte etc. Uni die Möglichkeiten dieses Protokolls auszuloten, wurde eine
Implementierung [52] entsprechend der Spezifikation von Procom durchgeführt. An diesem
Protokoll zeichnen sich eine Reihe von Problemen.
Das MER-Protokoll spezifiziert C-Strukturen, die in Paket verpackt und geschickt werden.
Dies ergibt mehrere Problemen, so ist das Alignment der Paketinhalte normalerweise durch
den Compiler optimiert. Um funktionsfbhige MER-Pakete zuerzielen, muß dem Compiler
ex-plizit das Alignment vorgegeben werden. Zweitens sieht das Protokoll keine Umwandlung für
Little/Big Endian Prozessorarchitekturen ( Byteorder) vor, es wird einfach das Little Endian
Format angenommen. Damit ist die Verbindung zwischen Maschinen verschiedener Prozes-sorarchitekturen erschwert. Da das Protokoll auf UDP-Paketen basiert, ist der Transport von Daten nicht garantiert, wie er es bei TCP/IP ist. Hier müßte auf dem Application Layer des OSI Modells sichergestellt werden, daß die Datenübertragung sichergestellt ist. Eine solche Möglichkeit ist jedoch nicht vorgesehen worden.
Nicht zuletzt sind in dem MER-Protokoll keineanderen Dienste vorgesehen, außer denen,
die zum Speichern und Abrufen von Daten auf dem Server nötig sind. Es sind keine höher-wertigen Administrationsmöglichkeiten vorgesehen,keine mehrfachen Server etc. PRO-COM hat mit dem MER als eine der ersten Firmen eine lauffähige Lösung für Black-Box Syste-me an Bord von Schiffen geschaffen, sie stellt sich im Sinne einer Systemlösung nichtals ausbaufähig dar.
3.2
Fremde Protokolle
Die zweite Möglichkeit, ein Netzwerk für den Bordgebrauch zu entwickeln, ist die Verwendung
fremder Protokolle, zum Beispiel aus dem Bereich der Fertigung oder Telekommunikation. Dazu müßte man spezifizieren, wie Daten und Objekte aus dem Schiffsumfeld auf solche aus
der Fertigung oder Telekommunikation abzubilden sind. Hierbei besteht aber die Gefahr, daß
man nicht für alle schiffsspezifischen Daten ein Äquivalent in dem jeweiligen Protokoll findet.
Zu erstellen Von der Middleware
bereitgestellt
Vom Betriebssystem
bereitgestellt
t'Lc Systernwahl
OSI Modell Spezifische Korn- Middleware
munlkationsschicht (Java RMI,
3.3. Middleware
Dann wäre das Protokoll außerhalb seiner Spezifikation zu betreiben oder zu erweitern, was im Allgemeinen keine elegante Lösung darstellt.
3.3
Middleware
Da die Problematik der Kommunikation verteilter Komponenten nicht nur im Schiffsbereich
vorhanden ist, existieren verschiedene Möglichkeiten, die einen Grundstock für verteilte Rech-nersysteme bieten. Dies sind aktuell CORBA der 0MG, COM/DCOM von Microsoft und die im
Javaumfeld zur Verfügung stehenden Lösungen von Sun Microsystems. Die grundlegende Architektur dieser drei wird im Folgenden kurz vorgestellt.
3.3.1 0MG CORBA
Die Object Management Group ( 0MO) wurde 1989 als gemeinnütziger Verein von
Software-herstellern gegründet, um eine Standard für verteilte Objekte zu schaffen [26]. Die 0MO selber
stellt keine Implementierung her, ihre alleinige Aufgabe ist es, Spezifikationen zu schreiben und zu publizieren. Anders als zum Beispiel die ISO hat sie aber wesentlich kürzere Entwick-lungszeiten. Die Entwicklung der Spezifikation erfolgt durch Firmen oder im Rahmen von Forschungsprojekten, über ihre Annahme als Spezifikation wird dann gemeinsam von den Mitgliedern bestimmt. Einige der 0MG Spezifikationen sind inzwischen auch von der ISO als Norm anerkannt worden.
Das Basismodel der 0MG für verteilte Objekte ist die Object Management Architecture
(OMA), eine Model zur Kommunikation verteilter Objekte. Es unterteilt Objekte entsprechend Bild 3.2 in vier verschiedenen Kategorien:
CüRBAservicesTM Die Services sind Basisdienste, die bei verteilten Objekten benötigt werden.
Beispiele sind der Name Server, mit dem ein Server anhand seines Namens gefunden werden kann oder der Time Service, der zur Synchronisierung von Rechnern im Netz
benutzt werden kann. Ihre Spezifikation steht in [32] zur Verfügung, Implementierungen
sind in Form kommerzieller und freier Software zu finden.
I
¿
¿
CORBA Servìces
'INTERNET INTER ORB PROTOCOL
DL Stubs
Bild 3.3: Grundlegender Aufbau von CORBA
Eingabe Argumente
o
io
Ausgabe Argumente Rückgabewerte ORB SchnittstelleKommunikation über GIOP/IIOP
Server
'f c<etMft.aiewfl,w.n 3. 5ystemwahl
CORBAfacilitestm Die Facilities sollten dem Anwendungsentwickler eine Lösung für Drucken
oder Internationalisierung bieten. In diesem Bereich hat es jedoch keine wesentlichen
Entwicklungen gegeben.
CORBAdomainTh' Die Domains sind bieten eine Lösungen für besondere Industriezweige an, zum Beispiel für die Telekommunikation oder das Bankwesen an.
Anwendungsobjekte Anwendungsobjekte sind alle Objekte, die nicht in eine der anderen
Gruppen fallen.
Das Bindeglied zwischen den Objekten aller Kategorien ist der der Objekt Request Broker ORBJ. Erverrnittelt Objektaufrufe von der Klientanwendung an das gewünschten Objekt.
Da-bei übersetzt er wenn nötig zwischen verschiedenen Rechnerarchitekturen, Betriebssystemen und Programmiersprachen.
Die OMA ist die Sichtweise, die die 0MG für das Problem verteilter Objekte entwickelt hat, mit der Common Objekt Request Broker Architecture (CORBA) wird auch eine Lösung angebo-ten. Sie besteht aus einer Spezifikation des ORBs, seiner Schnittstelle, dem Netzwerkprotokoll
und einer Definitionssprache für die Schnittstellen der Objekte. Um Server und Klienten
mit-tels CORBA zu verbinden, ist auf beiden Seiten ein ORB notwendig, der die eigentlich Kommu-nikation abwickelt. Diese findet zwischen dem Server- und Klientseitigen ORB mit Hilfe eines
von der 0MG genormten Netzwerkprotokolls1 statt. ORBs sind sowohl kommerziell wie auch als freie Implementierung für eine große Anzahl von Betriebssystemen und Programmierspra-chen verfügbar, die dank des genormten Netzwerkprotokolls untereinander ohne Ansehen des
Herstellers kommunizieren können.
I Klient DL Skeleton Object Adapter (BOA, POA)
rwrI.-r*Rranwr,zTz'niaon4nr,n,eat.
A
Benutzer (Principal)
Klient
Bild 34: Posirion des CORBA Security Service
Server
L
Object Request Broker
Implementation des Security Service
J
/
Damit die beiden ORBs miteinander kommunizieren können, müssen sie über eine Be-schreibung des Objektes mit seinen Methoden und Attribute verfügen. Diese BeBe-schreibung geschieht in Form einer speziellen Sprache, der Interface Definition Language . Dies ist eine C++ ähnliche Sprache, die zur Definition der Schnittstellen dient. Mit ihr lassen sich Objekte mit Attributen und Methode, Datenstrukturen und Fehlermeldungen definieren.
Der Aufbau von CORBA Anwendungen ist in Bild 3.3 dargestellt. Auf der Klientseite dienen sogenannte Stubs als Schnittstelle, die automatisch aus der IDL-Datei erzeugt werden. Die Stubs verhalten sich für den Programmierer wie ein normales, lokales Objekt und bieten
alle in der IDL beschriebene Methoden. Ein Anwendungsprogrammierer muß sich bei CORBA
nicht um die unterliegenden Details der Netzwerktechnik wie Öffnen von Sockets, Binding etc., kümmern. Auf der Serverseite werden vom IDL-Compiler virtuelle Funktionen erstellt, die Skeletons. Diese werden durch die reale Implementation überladen. Weder auf der
Klient-noch auf der Serverseite muß man sich Gedanken um Typumwandlung, Adressauflösung oder
ähnliches machen, dies ist die Aufgabe des Object Request Brokers. Dieser hat die Aufgabe,
die Anfragen der Klienten bzw. Antworten der Server über das Netz an den jeweiligen Partner
zu übermitteln. Er läßt sich in gewissen Maßen auch konfigurieren und stellt entsprechende Schnittstellen zur Verfügung.
Neben der einfachen Koppelung von Klient und Server werden in der Konzeption eine Reihe von Diensten gefordert. Diese können durch die CORBA Services abgedeckt werden. Für die einfache Namensauflösung aus Kapitel 2.1.1 ist der Name Service [28] vorgesehen, der zum Lieferumfang vieler ORBs gehört. Zur Suche von Objekten anhand bekannter Eigen-schaften kann der Trading Service [31] herangezogen werden. Basierend auf gespeicherten Objektreferenzen und dazugehörenden Eigenschaften lassen sich mit Hilfe einer einfachen Abfragesprache passende Objekte ermitteln. Die in Kapitel 2.1.2 geforderte Möglichkeit, Ku-enten beim Vorliegen neuer Daten zu Benachrichtigen, kann durch den Event Service [27] abgedeckt werden. Er bietet das Versenden von Nachrichten an viele Empthnger an. Für das
netzweite Zeitnormal existiert mit dem Time Service [30] eine Spezifikation, die die
Möglich-keit hochauflösender Zeitangaben bietet.
Sicherheitsrelevante Themen werden im CORBA Security Service (CORBAsec [34]) behan-delt. Es ist der umfangreichste CORBA Service, dessen ganzer Umfang nur in Ansätzen
CSI Level O CSI Level 2 Klient verwendet Klient-,Ì\ Principal Klient O
Klient-Í\
Principal +AZugri?tsrethte,Gruppen etc.
überträgt
Principal /\ Principal
verwendet
CORBA-Objekt
Bild 3.5: Verschiedene CSI-Level des CORBA Security Service
Klient-,/\ Principal Khent-Principal + Zugriffsrechte, Gruppen OtC, überträgt CORBA-Oblekt i verwendet r CORBA-Objekt verwendet p, CORBA-Objekt CORBA-Objekt CORBA-Objekt CORBA-Objekt COHBA-Objekt 1verwendet CoRBA-0bJekt
CORBA-Oblekt
Datenfiuß zwischen Klient und Server eingeklinkt. Die Spezifikation beschreibt die Möglich-keiten zum Schutz einzelner Anwendungen, zur Administration sowie von drei verschiedene Sicherheitsstufen, die das Zusammenspiel von CORBA Objekten im Sicherheitskontext
be-schreiben. Die weiteren Kapitel des CORBA Security Service sind dann an den Entwicklervon
ORB und Security Service gerichtet.
Der Benutzer als Auslöser aller Aktivitäten wird bei CORBAsec durch eine eigene Klas-se, dem CORBA::Principal repräsentiert. Ein Objekt dieser Klasse enthält wesentlichen Daten
über den Benutzer wie Name, verwendete Authentifizierungmethode oder Rechner des
fi-entprogrammes. Die drei Sicherheitsstufen oder Common Secure Interoperabi]ity (CSI) Level unterscheiden sich wie in Bild 3.5 zu sehen sowohl in ihrem Funktionsurn fang wie in der
tech-nischen Durchführung. Im Level O und i wird dem Server nur der Principal übermittelt, im Level 2 können neben der Authentifizierung noch Zugriffsdaten für die Authorisierung oder administrative Daten wie Rollen und Gruppen übermittelt werden. Des weiteren
unterschei-den sich die Level bei der Delegation. Verwendet ein Objekt weitere Objekte, dann wird diesen
bei Level I und 2 der ursprünglich Principal übermittelt. Damit haben sie die selben Authen-tifìzierung als wenn sie direkt vom ursprüngliche Principal aufgerufen würden. Beim Level O hingegen wird der Principal jeweils nur einen Schritt weit übermittelt. Wie im Bild 3.5 zu sehen, wird das über Delegation verwendete Objekte mit einem Principal angesprochen, welches dem Principal des Server-Objektes, nicht dem aufrufenden Benutzer entspricht. Bei Level O wird der Secure Socket Layer (SSL) zur Authentifizierung und Verschlüsselung des
Netzverkehrs verwendet, beim Layer I und 2 kommt das SECIIOP Protokoll zur Verwendung. CS Level i überträgt überträgt verwendet CORBA-Objekt I Klient
fy1jçidieware
Anwendung
In-Process Server (DLL)
Bild 3.6; Mögliche Komponentenposition bei COM/DCOM
DCOM
Netzwerk
Netzwerk Anwendung
Während bei den anderen Services die Implementation wie bei einem normalen CORBA-Server erfolgen kann, ist der Security Security entsprechend Bild 3.4 direkt im Object Request
Broker verankert. Der Aufwand ist erheblich und deshalb sind wesentlich weniger Implemen-tationen als bei den anderen Services zu finden. Die größte Verbreitung haben die Imple-mentationen des Levels O gefunden, sie bieten neben der Benutzerauthentifizierung auch die Verschlüsselung der Datenübertragung. Security Service Implementationen für den Level I und 2 sind in geringer Anzahl verfügbar, allerdings sind die Anforderungen an die
Infrastruk-mr (GSS [181, Kerberos [19] oder SESAM [49]) erheblich.
CORBA hat sich in einigen Bereichen als die führende Technologie für verteilte Objekte
durchsetzen können. Dies ist vor allem durch die Unabhängigkeit von einzelnen Herstellern und Plattformen bedingt, selbst die Koppelung von Mainframes mit PCs ist problemlos mög-lich Für die meisten zur Zeit verwendeten Programmiersprachen existieren sowohl
kommer-zielle wie freie ORB-Implementierungen, es stehen auch eine ganze Reihe von Implementatio-nen der CORBA Services zur Verfügung.
3.3.2 Microsoft DCOM
Das Distributed Component Object Model (DCOM) wurde von Microsoft auf Basis seines
Com-ponent Object Model (COM) geschaffen, damit dies auch in verteilten Umgebungen
angewen-det werden kann. COM ist in erster Linie als Hilfe bei der Entwicklung im Desktop-Bereich entwickelt worden. Es ermöglicht, schnell Anwendungen mit GUI aus fertigen Komponenten
zusammenzusetzen. Eine Komponente bei COM besteht aus eine Reihe von Schnittstellen mit
Methoden und Attributen. Wie bei CORBA werden ihre Schnittstellen in einer IDL-Datei be-schrieben, wobei das Format von CORBA IDL und COM IDL nicht identisch ist. Anders als bei CORBA, dessen Fokus primär auf dem Netzwerkverkehr liegt, können die Komponenten wie in Bild 3.6 gezeigt entweder in der Anwendung selber laufen, in einer Anwendung auf dem selben Rechner oder bei DCOM auf einem weiteren Rechner. Es steht also weniger der Gedanke verteilter Objekte im Vordergrund, sondern die möglichst einfache Nutzung von
Komponenten. Damit wird zum Beispiel das Einbetten von Tabellen in eine Textverarbeitung realisiert.
COM
