Roboterfernsteuerung in offener Netzwerkumgebung
©2000
Diplomarbeit
142 Seiten
Zusammenfassung
Inhaltsangabe:Zusammenfassung:
Aufbauend auf einem Programm zur Steuerung eines Roboters, genannt Robotalk, wird eine Client-Server Architektur entwickelt, die eine dislozierte Kommunikation ermöglicht. Robotalk wurde an der Fachhochschule Hagenberg im Rahmen des Projektes Sprachbasiertes Softwaresystem für Mensch-Maschine Kommunikation entwickelt und befähigt den Benutzer von einem Steuercomputer aus Befehle an einen Roboter zu senden.
In dieser Arbeit wird das komponentenorientierte Programmierparadigma vorgestellt. Unter Verwendung von DCOM (Distributed Component Object Model), das komponentenorientierte Programmierung ermöglicht, wird die Client-Server Architektur realisiert. Für die Robotersteuerung wird der Interpretierer einer benutzerfreundlichen Sprache aus Robotalk in den Client übernommen. Die vom Benutzer eingegebenen Befehle werden über das Netzwerk übertragen und vom Steuercomputer, der die Server Komponente enthält, an den Roboter weitergeleitet.
Es ist beliebig vielen Clients möglich, sich zu dem Server zu verbinden, aber nur einem ist es erlaubt, Befehle zu senden. Alle anderen empfangen die an den Roboter gesendeten Kommandos und können mittels einer Kamera die Bewegung verfolgen. Das Kamerabild wird mit Hilfe eines Browsers in der Benutzerschnittstelle des Client dargestellt.
Der Client, dem es erlaubt ist, Befehle zu senden, kann die Kontrolle abgeben und ein anderer verbundener Client kann diese übernehmen.
Anhand dieser Arbeit wird die Entwicklung von global einsetzbaren Komponenten mit DCOM gezeigt. Dabei werden unter anderem die Definition von den Schnittstellen zu solchen Komponenten, die Wiederverwendungsaspekte komponentenorientierter Software und Parallelen und Unterschiede zu objektorientierter Programmierung behandelt.
Inhaltsverzeichnis:Inhaltsverzeichnis:
1.Einführung7
1.1Ziel der Arbeit7
1.2Basis der Arbeit7
1.2.1Basissystem8
1.2.2Robotersteuerung im Basissystem9
1.3Lösungsverfahren: die Client-Server Architektur14
1.4Kapitelbeschreibung18
2.Kommunikationstechnologie der Client-Server Architektur20
2.1Einführung: Komponentenorientierte Programmierung20
2.2DCOM: ein Modell für komponentenorientierte Programmierung24
2.2.1DCOM Architektur26
2.2.2Teile eines Interfaces31
2.2.3Entwurf von Interfaces35
2.2.4Fernaktivierung von Komponenten36
2.2.5Parallele Benutzung von Komponenten: Apartments40
2.2.6Dislozierte Kommunikation über Interfaces: […]
Aufbauend auf einem Programm zur Steuerung eines Roboters, genannt Robotalk, wird eine Client-Server Architektur entwickelt, die eine dislozierte Kommunikation ermöglicht. Robotalk wurde an der Fachhochschule Hagenberg im Rahmen des Projektes Sprachbasiertes Softwaresystem für Mensch-Maschine Kommunikation entwickelt und befähigt den Benutzer von einem Steuercomputer aus Befehle an einen Roboter zu senden.
In dieser Arbeit wird das komponentenorientierte Programmierparadigma vorgestellt. Unter Verwendung von DCOM (Distributed Component Object Model), das komponentenorientierte Programmierung ermöglicht, wird die Client-Server Architektur realisiert. Für die Robotersteuerung wird der Interpretierer einer benutzerfreundlichen Sprache aus Robotalk in den Client übernommen. Die vom Benutzer eingegebenen Befehle werden über das Netzwerk übertragen und vom Steuercomputer, der die Server Komponente enthält, an den Roboter weitergeleitet.
Es ist beliebig vielen Clients möglich, sich zu dem Server zu verbinden, aber nur einem ist es erlaubt, Befehle zu senden. Alle anderen empfangen die an den Roboter gesendeten Kommandos und können mittels einer Kamera die Bewegung verfolgen. Das Kamerabild wird mit Hilfe eines Browsers in der Benutzerschnittstelle des Client dargestellt.
Der Client, dem es erlaubt ist, Befehle zu senden, kann die Kontrolle abgeben und ein anderer verbundener Client kann diese übernehmen.
Anhand dieser Arbeit wird die Entwicklung von global einsetzbaren Komponenten mit DCOM gezeigt. Dabei werden unter anderem die Definition von den Schnittstellen zu solchen Komponenten, die Wiederverwendungsaspekte komponentenorientierter Software und Parallelen und Unterschiede zu objektorientierter Programmierung behandelt.
Inhaltsverzeichnis:Inhaltsverzeichnis:
1.Einführung7
1.1Ziel der Arbeit7
1.2Basis der Arbeit7
1.2.1Basissystem8
1.2.2Robotersteuerung im Basissystem9
1.3Lösungsverfahren: die Client-Server Architektur14
1.4Kapitelbeschreibung18
2.Kommunikationstechnologie der Client-Server Architektur20
2.1Einführung: Komponentenorientierte Programmierung20
2.2DCOM: ein Modell für komponentenorientierte Programmierung24
2.2.1DCOM Architektur26
2.2.2Teile eines Interfaces31
2.2.3Entwurf von Interfaces35
2.2.4Fernaktivierung von Komponenten36
2.2.5Parallele Benutzung von Komponenten: Apartments40
2.2.6Dislozierte Kommunikation über Interfaces: […]
Leseprobe
Inhaltsverzeichnis
ID 5151
Nedbal, Manuel: Roboterfernsteuerung in offener Netzwerkumgebung / Manuel Nedbal -
Hamburg: Diplomica GmbH, 2002
Zugl.: Linz, Universität, Diplom, 2000
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 2 von 141
DANKSAGUNG
Im folgenden möchte ich den Menschen danken, die eine Kooperation zwischen der
Abteilung Systemtechnik und Automation der Kepler Universität Linz und der
Fachhochschule Hagenberg ermöglichten, mich bei dieser Arbeit unterstützten und
somit mithalfen dieses Projekt zu verwirklichen.
· Gerhard Chroust für den Beistand bei der Verfassung und Korrektur der
Diplomschrift, für seine flexible Zeiteinteilung und Geduld bei technischen
Details.
· Withold Jacak, der eine Kooperation zwischen der Fachhochschule
Hagenberg und der Abteilung Systemtechnik und Automation ermöglichte und
bei Fragen und Problemen zur Seite stand.
· Herwig Tlusty für die Verbesserungsvorschläge und kritische Betrachtung der
Diplomschrift und die Koordination mit Gerhard Chroust.
· Dagmar Reinmann für die Koordination der Termine und die Erledigung des
Verwaltungsaufwandes.
· Den Teilnehmern des Projektes ,,Sprachbasiertes Softwaresystem für Mensch-
Maschine Kommunikation", das am Fachhochschulstudiengang Software
Engineering im Wintersemester 1995/1996 bis Sommersemester 1996
entwickelt wurde, danke ich für die gute Dokumentation und saubere
Programmierung des Systems, auf dem diese Arbeit aufbaut (siehe
[FHSS_1996])
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 4 von 141
ZUSAMMENFASSUNG
Aufbauend auf einem Programm zur Steuerung eines Roboters, genannt Robotalk,
wird eine Client Server Architektur entwickelt, die eine dislozierte Kommunikation
ermöglicht. Robotalk wurde an der Fachhochschule Hagenberg im Rahmen des
Projektes ,,Sprachbasiertes Softwaresystem für Mensch-Maschine Kommunikation"
entwickelt und befähigt den Benutzer von einem Steuercomputer aus Befehle an
einen Roboter zu senden.
In dieser Arbeit wird das komponentenorientierte Programmierparadigma vorgestellt.
Unter Verwendung von DCOM (Distributed Component Object Model), das
komponentenorientierte Programmierung ermöglicht, wird die Client Server
Architektur realisiert. Für die Robotersteuerung wird der Interpretierer einer
benutzerfreundlichen Sprache aus Robotalk in den Client übernommen. Die vom
Benutzer eingegebenen Befehle werden über das Netzwerk übertragen und vom
Steuercomputer, der die Server Komponente enthält, an den Roboter weitergeleitet.
Es ist beliebig vielen Clients möglich, sich zu dem Server zu verbinden, aber nur
einem ist es erlaubt, Befehle zu senden. Alle anderen empfangen die an den Roboter
gesendeten Kommandos und können mittels einer Kamera die Bewegung verfolgen.
Das Kamerabild wird mit Hilfe eines Browsers in der Benutzerschnittstelle des Client
dargestellt.
Der Client, dem es erlaubt ist, Befehle zu senden, kann die Kontrolle abgeben und
ein anderer verbundener Client kann diese übernehmen.
Anhand dieser Arbeit wird die Entwicklung von global einsetzbaren Komponenten mit
DCOM gezeigt. Dabei werden unter anderem die Definition von den Schnittstellen zu
solchen Komponenten, die Wiederverwendungsaspekte komponentenorientierter
Software und Parallelen und Unterschiede zu objektorientierter Programmierung
behandelt.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 5 von 141
INHALTSVERZEICHNIS
1 Einführung ... 7
1.1 Ziel der Arbeit ________________________________________________ 7
1.2 Basis der Arbeit ______________________________________________ 7
1.2.1 Basissystem... 8
1.2.2 Robotersteuerung im Basissystem ... 9
1.3 Lösungsverfahren: die Client Server Architektur ________________ 14
1.4 Kapitelbeschreibung _________________________________________ 18
2 Kommunikationstechnologie der Client Server Architektur... 20
2.1 Einführung: Komponentenorientierte Programmierung ____________ 20
2.2 DCOM: ein Modell für komponentenorientierte Programmierung ____ 24
2.2.1 DCOM Architektur... 26
2.2.2 Teile eines Interfaces... 31
2.2.3 Entwurf von Interfaces ... 35
2.2.4 Fernaktivierung von Komponenten ... 36
2.2.5 Parallele Benutzung von Komponenten: Apartments ... 40
2.2.6 Dislozierte Kommunikation über Interfaces: Marshaling ... 45
2.2.7 Sicherheitsmechanismen... 50
2.2.8 Konfiguration des Servers - Der APPID Schlüssel... 59
2.2.9 Konfiguration der Komponenten - Der CLSID Schlüssel ... 61
3 Realisierung der Client Server Architektur mittels DCOM ... 62
3.1 Robotalk Server _____________________________________________ 64
3.1.1 Server Instanzierung... 64
3.1.2 Client Benachrichtigungen... 69
3.1.3 Wiederverwendung... 72
3.1.4 Serielle Kommunikation ... 79
3.2 Robotalk Client______________________________________________ 81
3.2.1 Dialog der Sichtklasse ... 81
3.2.2 Verbindungsdialoge ... 84
3.2.3 Setzen der Kamera URL... 85
3.2.4 Befehlsabarbeitung... 86
3.2.5 Verbindungsaufbau zu einem Robotalk Server... 87
3.3 Robotalk Marshaler __________________________________________ 91
3.3.1 Das Makefile ... 91
3.3.2 RoboInt.idl ... 93
4 Systemdokumentation ... 98
4.1 Server Architektur ___________________________________________ 99
4.2 Server Klassen _____________________________________________ 101
4.2.1 CMainWindow...102
4.2.2 CServer ...102
4.2.3 CFRobo ...104
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 6 von 141
4.2.4 CImpIClassFactory ...106
4.2.5 CORobo...107
4.2.6 CImpIConnectionPointContainer ...110
4.2.7 CImpIShareRobo ...112
4.2.8 COConnectionPoint ...116
4.2.9 COEnumConnections ...119
4.3 Client Klassen _____________________________________________ 121
4.3.1 CORoboSink...122
4.3.2 CImpIRoboSink...123
4.3.3 CServerConnection ...125
5 Schlussfolgerungen ...131
6 Anhang ...134
6.1 Literaturverzeichnis _________________________________________ 134
6.2 Abbildungsverzeichnis ______________________________________ 138
6.3 Glossar ___________________________________________________ 139
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 7 von 141
1 Einführung
1.1 Ziel der Arbeit
Das Ziel dieser Arbeit ist es, mehreren Benutzern auf dislozierten Computern die
Steuerung eines Roboters zu ermöglichen. Es soll eine einfache, leicht erlernbare
Sprache zur Robotersteuerung verwendet werden. Das Zielsystem muss die
Beobachtung der Roboterbewegung unterstützen und die Verfolgung der an den
Roboter gesendeten Befehle. Außerdem sind Eigenschaften wie Modularität,
Erweiterbarkeit, Offenheit und Sicherheit geforderte Kriterien.
Aufbauend auf dem ,,Sprachbasierten Softwaresystem zur Mensch Maschine
Kommunikation", das in einem Projekt des Fachhochschulstudiengangs Software
Engineering an der Fachhochschule in Hagenberg entwickelt wurde, soll das
Zielsystem eine Steuerung von jedem Computer aus, auf dem ein Zugang zum
Internet installiert ist, ermöglichen. Dabei liegt der Schwerpunkt nicht auf der
verwendeten Sprache zur Robotersteuerung, sondern auf der Realisierung einer
möglichst sprachunabhängigen Architektur, sodass das System mit wenig
Änderungsaufwand die Adaptierung auf verschiedene andere Steuerungssprachen
ermöglicht.
Es soll die Sicherheit vor unerlaubtem Zugriff trotz Offenheit des Systems
gewährleistet sein. Da ein offenes System einer großen Anzahl von Benutzern die
Möglichkeit für Attacken bietet, ist diese Eigenschaft von großer Bedeutung.
Wenn mehreren Benutzern die Steuerung des Roboters ermöglicht wird, müssen
auch Nebenläufigkeitsbedingungen beachtet werden. Das erfordert einen
Mechanismus um die Kontrolle über den Roboter zu erlangen und diese wieder
abzugeben. Das Zielsystem muss also zwei unterschiedliche Rollen der Benutzer
unterscheiden können: eine steuernde und eine beobachtende.
1.2 Basis der Arbeit
Das im folgenden Abschnitt beschriebene System bietet einem einzelnen Benutzer
die Möglichkeit der Robotersteuerung. Dieses System stellt die Ausgangsbasis für
das geforderte Zielsystem dar. Die Systemdokumentation kann in [FHSS_1996]
nachgelesen werden.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 8 von 141
1.2.1 Basissystem
Diese Arbeit basiert auf Robotalk, das von dem Fachhochschulstudiengang Software
Engineering im Wintersemester 1995/1996 bis Sommersemester 1996 entwickelt
wurde. Robotalk ist der zentrale Teil des ,,Sprachbasierten Softwaresystems für
Mensch-Maschine Kommunikation". Es handelt sich hierbei um eine Windows
Applikation, die Kommandos von der benutzerfreundlichen Sprache ROCL (Robot
Command Language) übersetzt und über die serielle Schnittstelle des Computers an
den Roboter oder einen Simulator weiterleitet (siehe ,,Abbildung 1:
Roboterkommunikation mit Robotalk").
ROCL ist eine einfache Sprache zur Steuerung von Robotern. Die Implementierung
des ROCL Interpreters ist für einen Roboter des Typs SCARA. Dieser Roboter hat
einen drehbaren Körper, einen abwinkelbaren Arm und eine höhenverstellbare Hand
mit zwei Fingern zum Greifen. Das ROCL Vokabular umfasst die Bezeichner für die
Roboterteile (Achsen, Freiheitsgrade), Zeitwörter für die Bewegung sowie Ziffern und
andere Wörter.
Abbildung 1: Roboterkommunikation mit Robotalk
Mit Robotalk ist es möglich Befehle durch Spracherkennung an den Roboter zu
schicken, oder sie in Form von Zeichenketten einzutippen. Der ROCL Interpreter
analysiert dieses Kommando und übersetzt es, falls es sich um einen gültigen ROCL
Befehl handelt, in eine äquivalente VAL II Befehlskette für den realen Roboter und in
ein Programm für einen virtuellen Roboter eines Simulationsprogramms. Die VAL II
Kommandos werden über die serielle Schnittstelle an den Roboter weitergeleitet,
dessen Antwort interpretiert und textuell oder in Form von Sprachausgabe dem
Benutzer präsentiert. Das Programm RoboTalk befindet sich auf dem
Steuercomputer, an dessen serielle Schnittstelle die Kommandos für den Roboter
weitergeleitet werden.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 9 von 141
1.2.2 Robotersteuerung im Basissystem
Im Laufe der Entwicklung von immer komplexeren Maschinen haben sich auch die
Anforderungen an die Implementierer von Steuerungen gesteigert. Analog zur
Erstellung von Applikationen am Computer, erfordern schwierigere Probleme
abstraktere Beschreibungsmittel. In diesem Fall wurden Compiler mit größerem
Sprachumfang entwickelt, neue Programmierparadigmen, wie objektorientierte,
komponentenorientierte Programmierung erfunden und neue Sprachgenerationen
sind entstanden.
Damit aber die Steuerung von Robotern von einem Computer aus möglich ist,
müssen zuerst Applikationen am Computer existieren, die die Entwicklung von
Robotersprachen zulassen. Die Berechnungen unterliegen bei der Robotersteuerung
Echtzeitbedingungen (siehe auch [WESL_1990], Seite 329), die schnelle Computer
erfordern. Bei [JAIR_1998], Seite 1, wird das Problem der Bahnberechnung einer
Roboterbewegung sogar als NP vollständig identifiziert. Mit der Entwicklung
schnellerer Computer ist die Grundlage für einen größeren Sprachumfang bei
Robotersteuerungssprachen gegeben.
Bereits in [BLJA_1983] wird von den Autoren festgestellt, dass die Entwickler und
Anwender von Robotersystemen zwar mit den Eigenheiten der
Roboterprogrammierung, nicht jedoch mit dem systematischen Konstruieren und
Formulieren von Algorithmen vertraut sind. Dort wird versucht eine Nahtstelle
zwischen dem Informatiker, der mit dem systematischen Konstruieren und
Formulieren von Algorithmen, nicht aber mit den speziellen Problemen und
Anforderungen der Robotertechnologie vertraut ist, und dem Roboterspezialisten zu
bilden. Die komplexen Algorithmen, die eine Bahnplanung der Roboterbewegung in
einer sich dynamisch ändernden Umgebung ermöglichen, sind in [JULI_1999] und
[JAIR_1998] beschrieben. Dadurch wird gezeigt, dass bei der Entwicklung von
Robotersteuerungen Informatiker benötigt werden, die algorithmisches Verständnis
besitzen.
1.2.2.1 Definition von Roboterbegriffen
In diesem Kapitel werden die grundlegenden Begriffe für die Robotersteuerung
erläutert. Sie sind fett gedruckt und aus [BLJA_1983] und [WESL_1990] entnommen.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 10 von 141
Roboter sind und universell einsetzbare Bewegungsautomaten mit mehreren
Achsen, deren Bewegung hinsichtlich Bewegungsfolge und wegen bzw. winkel frei
programmierbar (d.h. ohne mechanischen Eingriff veränderbar) und gegebenenfalls
sensorgeführt sind. Sie sind mit Greifer, Werkzeugen oder anderen Fertigungsmitteln
ausrüstbar und können Handhabungs- und/oder Fertigungsaufgaben ausführen. Eine
Programmierung mit mechanischem Eingriff wäre mittels einfachen Einlegegeräten,
die durch Anbringen von Stoppern für die Endanschläge programmiert werden,
möglich. Roboter können mit Sensoren ausgestattet sein. Hierbei handelt sich um
Peripheriegeräte, die ähnlich den Sinnesorganen physikalische Signale, wie
Lichtwellen, Druck, Position der Armgelenke, oder Bilder der Umgebung (Kamera)
registrieren, in elektrische bzw. digitale Signale umwandeln und an den
Steuerrechner des Roboters senden. Am Ende des Roboterarmes ist ein Greifer,
Werkzeug, oder Fertigungsmittel angebracht, zusammenfassend Effektor genannt.
Effektoren müssen ebenfalls gesteuert werden und können mit Sensoren
ausgestattet sein.
Unter einem Freiheitsgrad versteht man eine unabhängige Bewegungsachse, deren
Bewegung sich nicht aus anderen Bewegungsachsen zusammensetzen lässt. Eine
Bewegungsachse wird durch eine Kombination von Antrieb, Getriebe und Gelenk
des Industrieroboters realisiert. Um einen Effektor in eine beliebige Orientierung zu
bringen, sind sechs Freiheitsgrade notwendig.
Die Kinematik untersucht alle Probleme bezüglich der Geometrie und der
verschiedenartigen Bewegungen des Roboters. Dabei werden die Kräfte, die die
Bewegung verursachen, und die Massen der bewegten Körper außer acht gelassen.
Ein dynamisches Modell des Industrieroboters wird verwendet, um alle Kräfte, wie
Trägheit, Gravitation, Zentrifugal- und Corioliskräfte, die auf den Roboter wirken, zu
berücksichtigen.
1.2.2.2 ROCL Sprachbeschreibung
ROCL ist die Abkürzung für Robot Command Language und stellt eine
Abstraktionsstufe für die benutzerfreundliche Interaktion mit einem Roboter dar.
ROCL wird durch den Interpreter von Robotalk in die Industriesprache VAL II
übersetzt, die direkt an den SCARA Roboter gesendet werden kann.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 11 von 141
1
1
.
.
2
2
.
.
2
2
.
.
2
2
.
.
1
1
B
B
e
e
g
g
r
r
ü
ü
ß
ß
u
u
n
n
g
g
u
u
n
n
d
d
V
V
e
e
r
r
a
a
b
b
s
s
c
c
h
h
i
i
e
e
d
d
u
u
n
n
g
g
Diese Höflichkeitsfloskeln zur Begrüßung und Verabschiedung haben keinen Effekt
auf den Roboter, können aber verwendet werden, um zu testen, ob eine Verbindung
zu SCARA besteht.
Syntax
Beschreibung
HELLO
begrüßt den Roboter
BYE | GOOD.BYE
verabschiedet sich vom Roboter
1
1
.
.
2
2
.
.
2
2
.
.
2
2
.
.
2
2
B
B
e
e
w
w
e
e
g
g
u
u
n
n
g
g
s
s
-
-
K
K
o
o
m
m
m
m
a
a
n
n
d
d
o
o
s
s
Bewegungs - Kommandos steuern den Roboter, den Arm und den Greifer.
Syntax
Beschreibung
OPEN [ HAND | GRIPPER ]
öffnet den Greifer oder den Arm
CLOSE [ HAND | GRIPPER ]
schließt den Greifer oder den Arm
( MOVE | GO ) [Delta] ( LEFT |
RIGHT | FORWARD | BACKWARD
| UP | DOWN )
bewirkt die relative Bewegung vom
aktuellen Punkt in die gewünschte
Richtung entweder um die Standard- oder
eine explizit angegebene Schrittweite
Bsp: move 50 left... bewegt den Greifer
um 50 mm nach links.
( MOVETO | GOTO ) Pos
bewirkt die Bewegung des Effektors zu
einer gespeicherten Position Pos. Pos ist
die Bezeichnung für eine Position, die mit
dem Befehl SET festgelegt worden ist.
Bsp: moveto flasche ... bewegt den
Greifer zu dem bekannten Punkt mit der
Bezeichnung Flasche.
( DRIVE | TURN ) Axe [
DeltaSymbol ] Direction
Axe := BODY | ARM | HAND |
GRIPPER
DeltaSymbol := 1..9, 10..90,
100..500
Direction := LEFT | RIGHT | UP* |
DOWN*
* nur erlaubt mit HAND oder
GRIPPER
bewirkt die Drehung beziehungsweise
Verschiebung einer bestimmten Achse. Der
Scara Roboter hat vier steuerbare Achsen
j1..j4. Die Bezeichnungen sind an die
menschliche Anatomie angelehnt.
1.2.2.3 GelenkIndex Achse
ROCL
Vokabel
j1 Hauptachse
BODY
j2 Mittelachse
ARM
j3
Hubachse GRIPPER | HAND
j4
Greifachse GRIPPER | HAND
Bsp:
drive body left
drive arm 90 right
drive hand up
turn gripper 30 left
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 12 von 141
1
1
.
.
2
2
.
.
2
2
.
.
3
3
.
.
1
1
P
P
r
r
o
o
g
g
r
r
a
a
m
m
m
m
S
S
t
t
e
e
u
u
e
e
r
r
u
u
n
n
g
g
Die Befehle für die Programm Steuerung ermöglichen ein Ausführen, Laden und
Speichern einer Datei, die Roboterbefehle enthält.
Syntax
Beschreibung
( EXECUTE | RUN ) Programm
Program := letter { letter | digit }
bewirkt das Ausführen eines Programms,
das sich bereits im Speicher des
Robotercontrollers befindet.
Bsp: run test ... bewirkt die Ausführung
des Programms mit dem Namen test.
ACHTUNG: Das Programm muss vorher mit
dem Befehl LOAD in den Speicher des
Roboter Controller geladen werden.
LOAD Programm
Programm := letter { letter | digit }
bewirkt das Laden eines Programms in den
Speicher des Roboter Controllers. Danach
kann es dann mit dem ExecuteCommand
ausgeführt werden.
Bsp: load test ... lädt das Programm test
SAVE Pragramm
Programm := letter { letter | digit }
bewirkt das Speichern eines Programms
vom Speicher des Roboter Controllers auf
ein externes Medium.
Bsp: save test ... speichert das Programm
test
1
1
.
.
2
2
.
.
2
2
.
.
3
3
.
.
2
2
Z
Z
u
u
s
s
t
t
a
a
n
n
d
d
s
s
v
v
e
e
r
r
ä
ä
n
n
d
d
e
e
r
r
u
u
n
n
g
g
Die Befehle für die Zustandsveränderung bewirken eine Konfiguration des Roboters,
mit denen der Benutzer die Geschwindigkeit, Schrittweite und Punkte im Raum vor
der Ausführung von Bewegungen definieren kann.
Syntax
Beschreibung
[ NEW | CHANGE ] ( DELTA |
STEP ) [TO] ( SMALL | MEDIUM |
BIG | Deltasymbol )
oder
( SMALL | MEDIUM | BIG |
Deltasymbol ) ( DELTA | STEP )
Setzt den Wert für die Schrittweite auf ein
neues absolutes Maß. Der Effektor des
Roboters kann in diskreten Schritten
bewegt werden. Um welchen Betrag sich
der Effektor (auch Greifer oder Arm)
bewegen soll, kann man auf folgende Arten
festlegen. Entweder wird der Betrag direkt
als Zahl oder als Synonym SMALL,
MEDIUM oder BIG angegeben.
1.2.2.4 Eingabe Abstand
Winkel
Zahl in mm in Grad
SMALL
5 mm
1.0 Grad
MEDIUM
10 mm
3.0 Grad
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 13 von 141
BIG 100 mm 10.0 Grad
Bsp:
change step to big
30 delta
small step
SET PointIdentifier
PointIdentifier := letter { letter | digit
}
speichert die aktuelle Position des Armes
unter dem Namen PointIdentifier ab. Diese
Position kann später wieder direkt mit dem
MOVETO angefahren werden.
ACHTUNG: Wird ein Name gewählt, der
schon verwendet wurde, wird der Punkt
mit der neuen Position ohne Vorwarnung
überschrieben.
Bsp: set a2
[ CHANGE | NEW ] ( SPEED |
VELOCITY ) [TO] ( SLOW | LOW |
MEDIUM | FAST | HIGH )
oder
( SLOW | LOW | MEDIUM | FAST |
HIGH ) ( SPEED | VELOCITY )
setzt den Wert für die Geschwindigkeit
neu. Die Angabe des neuen Wertes erfolgt
in Prozent der maximal möglichen
Geschwindigkeit.
Eingabe
Geschwindigkeit
SLOW | LOW
5%
MEDIUM
50%
FAST | HIGH
100%
Bsp:
change speed to slow
high speed
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 14 von 141
1.3 Lösungsverfahren: die Client Server Architektur
Eine dislozierte Robotersteuerung impliziert die Notwendigkeit der Kommunikation
zwischen dem Steuercomputer und einem anderen Computer, der räumlich getrennt
ist. Es muss eine Datenübertragung über einen Übertragungsweg von einem Sender
zu einem Empfänger gesandt werden.
Dafür werden adressierte Nachrichtenpakete erstellt, der Übertragungsweg muss
definiert werden, die Übertragung muss gesteuert und kontrolliert werden, vom
Empfänger müssen die empfangenen Pakete kontrolliert und quittiert werden (siehe
auch [SCHR_1989], Seite 15ff.]). Da als Übertragungsweg bei der Zielsetzung
bereits das Internet festgelegt wurde, wird die Paketierung und Adressierung von
dem Internetprotokoll TCP/IP übernommen. Damit auf beiden Computern (Sender
und Empfänger) eine Kontrolle und Steuerung des Informationsflusses möglich wird,
benötigt man auf beiden Computern Komponenten, die das bewerkstelligen: auf der
Sender Seite nennt man die Komponente Client, auf der Empfänger Seite Server.
Es erfolgt eine Dekomposition der im Kapitel ,,Basissystem" beschriebenen Robotalk
Applikation in Teile, die im Server und welche, die im Client Verwendung finden.
Dabei werden Client-seitig der Interpreter für die Sprache ROCL und teilweise die
Implementierung des User - Interface übernommen. Auf der Server Seite werden
Teile für die Kommunikation mit der seriellen Schnittstelle adaptiert.
Um ein System zu entwickeln, das eine Robotersteuerung und -beobachtung von
mehreren räumlich getrennten Computern aus ermöglicht, ist die Kommunikation
zwischen den Client Computern und dem, dessen serielle Schnittstelle mit dem
Roboter verbunden ist (Steuercomputer), nötig. Diese Kommunikation wird durch
eine Client Server Architektur realisiert, wobei die dislozierten Computer die Clients
darstellen, der Steuercomputer den Server (siehe Abbildung 2: Client Server
Architektur).
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 15 von 141
Abbildung 2: Client Server Architektur
Die Steuerung des Roboters wird, im Unterschied zu der in ,,Abbildung 1:
Roboterkommunikation mit Robotalk" dargestellten, von einem anderen Computer als
vom Steuercomputer aus möglich. Der Robotalk - Server auf dem Steuercomputer
empfängt die Befehle der Robotalk - Clients und leitet sie über die serielle
Schnittstelle an den Roboter weiter.
Das Client Server System ist so konstruiert, dass ein Client eine Verbindung über
das Internet zu dem Server herstellen kann und nach dem Verbindungsaufbau die
Kommunikation mit dem Roboter erfolgen kann als wäre der Robotalk - Client auf
dem Steuercomputer gestartet worden.
Die Anforderung, dass das Zielsystem mehrere Clients verwalten können soll und
eine Beobachtung der Steuerung möglich sein muss, verlangt von dem Server die
Fähigkeit Nachrichten verschicken und selbst als Sender fungieren zu können. Diese
Nachrichten können zum Beispiel einen Robotalk - Client davon informieren, dass
bereits ein anderer Client verbunden ist, oder die von einem Client gesendeten
Kommandos an einen anderen zum Zwecke der Beobachtung der Steuerung
weiterleiten.
Der Robotalk - Client ist eine interaktive Anwendung, mit deren Hilfe der Benutzer
ROCL Befehle eingeben kann. Wie in [STAR_1996], Seite 157, beschrieben, sollten
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 16 von 141
interaktive Systeme Antwortzeiten von maximal 5 Sekunden aufweisen. Da die
Rückmeldung des Roboters länger dauern kann, ist es nicht möglich diese
Antwortzeit immer zu garantieren. Deshalb enthält der Server einen Job, der im
Hintergrund auf die Antwort des Roboters wartet. Der Server wird nach dem Start
des Jobs selbst aktiv und schickt an die Clients die Benachrichtigung, dass der
Befehl an den Roboter delegiert wurde.
Abbildung 3: Client Server Kommunikation
Daraus ergibt sich ein Kommunikationsfluss wie er in ,,Abbildung 3: Client Server
Kommunikation" dargestellt wird. Im Schritt 1 verschickt der ,,Client Computer 1" ein
Roboter - Kommando. Danach startet der Robotalk - Server einen Job und sendet
sofort (Schritt 2) die Rückmeldung an den Client, dass er den Befehl empfangen hat.
In Schritt 3 und 4 wird der Befehl an den SCARA - Roboter delegiert und auf eine
Rückmeldung gewartet. Trifft diese ein (Schritt 5), informiert die serielle Schnittstelle
den Robotalk - Server davon (Schritt 6) und dieser schickt die Rückmeldung an die
zu ihm verbundenen Clients.
Bei der Realisierung einer derartigen Client Server Architektur, die Faktoren
Sicherheit, Modularität, Erweiterbarkeit und Offenheit nicht unbeachtet lässt, stehen
als gängige Technologien DCOM (Distributed Component Object Model) und
CORBA (Common Object Request Broker Architecture) zur Auswahl. Beide
vereinfachen die Netzwerkprogrammierung, ermöglichen komponentenorientierte
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 17 von 141
Programmierung und haben sich als Standards etabliert. Beide Programmiermodelle
stellen eine Client Server Architektur zur Verfügung, in der ein Client Dienste eines
Servers über Methodenaufrufe nutzen kann, wobei Computergrenzen keine
Limitierung bedeuten. Unter Verwendung von DCOM werden die Client und Server
Teile entwickelt. Als Entwicklungsumgebung kommt Microsoft Visual C++ Version 6.0
auf Windows NT 4.0, Service Pack 5, zum Einsatz.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 18 von 141
1.4 Kapitelbeschreibung
In Kapitel ,,2 Kommunikationstechnologie der Client Server Architektur" werden
zuerst die Grundbegriffe komponentenorientierter Programmierung, die in dieser
Arbeit als Kommunikationstechnologie eingesetzt wird, beschrieben. Dabei wird
erläutert, welche grundlegenden Eigenschaften diese Programmiermethode aufweist
und die verwendeten Termini dieser Technologie eingeführt.
Das darin enthaltene Kapitel ,,2.2 DCOM: ein Modell für komponentenorientierte
Programmierung" startet mit einer Beschreibung des DCOM Modells und einer
Begriffsdefinition. Danach wird die DCOM Architektur vorgestellt. Dort wird die
Entwicklung von Schnittstellen zwischen Komponenten behandelt. Hier befindet sich
auch die Erklärung der essentiellen Techniken, die für das Verständnis von dem
Kapitel ,,3 Realisierung der Client Server Architektur mittels DCOM" wichtig sind.
Dieser Abschnitt ist prägnant und kurz gehalten und beschränkt sich hauptsächlich
auf die für die realisierte Architektur nötigen Techniken. Für weiterführende Literatur
sind Quellenverweise vorhanden.
Im Kapitel ,,3 Realisierung der Client Server Architektur mittels DCOM" ist die Client
Server Architektur des Zielsystems erklärt. Zuerst werden im Überblick die
benötigten implementierungsspezifischen Vorgehensweisen erklärt. Im Unterschied
zu Kapitel 2 wird in diesem Abschnitt die Architektur des aus der Zielsetzung
entstandenen Systems beschrieben, nicht die Architektur der Technologie, die für die
Realisierung verwendet wird.
Die Komponente, die die Schnittstellen des Systems enthält und eine Paketierung für
die Datenübertragung über das Netzwerk ermöglicht, wird im Kapitel ,,3.3 Robotalk "
beschrieben. Hier befinden sich auch die Definitionen der Schnittstellen zwischen
Client und Server und eine Beschreibung der Funktionalität der
Schnittstellenmethoden.
Im Kapitel ,,4 Systemdokumentation" sind die wesentlichen Klassenbeschreibungen
des Servers und des Clients zu finden. Es werden nur die Klassen, die für das
Verständnis der Client Server Architektur nötig sind beschrieben. Der Quellcode ist
dokumentiert und kann als Informationsquelle benutzt werden.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 19 von 141
Das abschließende Kapitel ,,5 Schlussfolgerungen ", stellt die Unterschiede zwischen
komponentenorientierter und objektorientierter Programmierung dar und enthält auch
eine Abschlussbemerkung, die das Gebiet der Informatik und das der
Robotersteuerung zu verknüpfen versucht.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 20 von 141
2 Kommunikationstechnologie der Client Server
Architektur
2.1 Einführung: Komponentenorientierte Programmierung
In [TUCS_1997] wird die komponentenorientierte Programmierung als die natürliche
Erweiterung der objektorientierten Programmierung auf dem Gebiet der unabhängig
erweiterbaren Systeme beschrieben. Die bekanntesten Beispiele für Modelle, die
komponentenorientierte Programmierung ermöglichen, sind bei den
Dokumentenmodellen OLE, OpenDoc, JavaBeans, Netscape ONE und bei den
Objektmodellen SOM/CORBA, COM, DCOM, Java's virtual machine.
Interface: bei komponentenorientierter Programmierung ist ein Interface eine
benannte Ansammlung von abstrakten Methoden, die die Schnittstelle zu einem
binären Objekt darstellen und dessen Funktionalität repräsentieren. Das binäre
Objekt enthält die Implementierung nach der Übersetzung des Quellcodes in
Maschinencode.
Eine Komponente besteht aus einem Interface und einer Implementierung. Jede
Implementierung hat genau ein Interface, aber ein Interface kann mehrere
Implementierungen benutzen. Eine Komponente ist weder durch eine spezifische
Applikation (wie zum Beispiel Compiler, Linker,...) noch durch eine
Implementierungstechnologie festgelegt. Um die Kommunikation mit Komponenten
zu ermöglichen, benötigt man Interfaces, die als eine Stelle gesehen werden können,
die den Zugang zu den Diensten einer Komponente ermöglicht.
Durch die komponentenorientierte Programmierung können Applikationen in
Komponenten unterteilt werden, diese räumlich verteilt entwickelt und danach
zusammengesetzt werden. Dazu werden Standards für die Interaktion von
unabhängig voneinander entwickelten Komponenten benötigt. Diese Standards
erlauben bei einer Zusammensetzung eines komponentenbasierten Systems die
Entscheidung, welche Teile zusammengesetzt werden können und welche nicht. Die
zusammenzusetzenden Komponenten müssen kompatibel zueinander sein. Bei der
Unterteilung von Software in Komponenten und der Komposition der entwickelten
Komponenten sollten die folgenden Kriterien berücksichtigt werden:
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 21 von 141
· Komponenten, deren Interaktivität höher ist, sollten möglichst nahe
beisammen sein.
· Einige Komponenten können nur auf bestimmten Computern oder an
bestimmten Orten laufen.
· Kleinere Komponenten erhöhen die Flexibilität bei der Entwicklung, aber auch
die Netzwerkkommunikation.
· Größere Komponenten vermindern die Netzwerkkommunikation, aber auch
die Flexibilität bei der Entwicklung.
Außerdem können Charakteristika von Komponenten (wie Zeitverhalten, benötigte
Ressourcen, Anforderungen an die Umgebung, Fehlertoleranz, Grad der Verteilung),
die nicht Teil der Schnittstelle einer Komponente sind, die Auswahl bei der
Komposition beeinflussen. Es ist bei der komponentenorientierten Programmierung
möglich auf solche Charakteristika Rücksicht zu nehmen. Da die Implementierung
nach der Entwicklung in Maschinencode übersetzt wird, kann der Entwickler mehrere
Objekte erzeugen, die verschiedene Charakteristika aufweisen, aber dasselbe
Interface benutzen.
Abbildung 4: Auswahl von Implementierungen
Ein Interface kann also für mehrere Implementierungsarten benutzt werden, wobei
bei der Entwicklung des Quellcodes auf bestimmte Charakteristika in
unterschiedlicher Weise Rücksicht genommen werden kann. Maschinencode 1
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 22 von 141
könnte zum Beispiel für ein Unix Betriebssystem kompiliert worden sein,
Maschinencode 2 für Windows. Das Interface kann dann, abhängig von dem
Betriebssystem auf dem die Komponente ihre Dienste anbieten soll, für die Variante
1 oder 2 benutzt werden.
Will ein Client die Dienste einer Komponente verwenden, stellt er eine Anfrage, ob
ein bestimmtes Interface von der Komponente zur Verfügung gestellt wird. Ist das der
Fall, erhält der Client eine Referenz darauf (siehe Abbildung 5: Interface Referenzen
des Clients). Das zum Einsatz kommende Modell der komponentenorientierten
Programmierung (CORBA, COM, Java's virtual machine,...) muss dann die Kontrolle
des Datenflusses bei einem Methodenaufruf des Clients übernehmen. Außerdem
muss das Modell die Aktivierung der Komponente unterstützen, falls diese noch nicht
gestartet wurde, damit eine Befragung erfolgen kann.
Abbildung 5: Interface Referenzen des Clients
Dadurch werden aus der Sicht des Clients zwei verschiedene Lebenszyklen
unterschieden: der Lebenszyklus der Referenz auf das Interface und der der
Komponente. Ersterer ist kürzer, da nur solange eine Komponente existiert, eine
Referenz auf ein Interface existieren kann. Würde die Referenz auf das Interface
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 23 von 141
noch existieren, die Komponente aber nicht, würde jeder Methodenaufruf des Clients
scheitern, da die Implementierung nicht mehr vorhanden ist.
Die Implementierung des Clients kann die Referenz auf das Interface nach Erhalt
benutzen, um Methodenaufrufe auszuführen. Wird der Client beendet, oder die
Interface Referenz nicht mehr benötigt, muss diese freigegeben werden.
Bei den Methodenaufrufen obliegt es wieder dem verwendeten Modell für die
komponentenorientierte Programmierung, dass die Komponente freigegeben wird,
wenn keine Referenzen auf ein Interface mehr existieren.
Wie das DCOM Modell diese Aufgaben löst, wird im nächsten Abschnitt erklärt.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 24 von 141
2.2 DCOM: ein Modell für komponentenorientierte Programmierung
Für eine Beschreibung des DCOM Modells sind zuerst einige Begriffsdefinitionen
nötig:
COM: COM (Component Object Model) ist eine Ansammlung von Funktionen, die
den Programmierer bei der Implementierung komponentenorientierter Software
unterstützen. Diese Funktionssammlung wird auch COM Bibliothek genannt.
DCOM: das Distributed Component Object Model ist nach [SIRO_1999] die Summe
der Teile
· COM
· Fernaktivierung
· Marshaling
· Sicherheit
Die Fernaktivierung ist die Grundlage für die dislozierte Kommunikation der
Komponenten, da mit diesem Mechanismus die Aktivierung von Komponenten, die
sich auf anderen Computern befinden, erreicht wird (siehe ,,2.2.4 Fernaktivierung von
Komponenten").
Marshaling ermöglicht die dislozierte Kommunikation nach der Fernaktivierung. Es
können dadurch Interfaceaufrufe von Clients von räumlich getrennten Computern
aus erfolgen (siehe ,,2.2.6 Dislozierte Kommunikation über Interfaces: Marshaling").
Mit Marshaling wird in DCOM die Kontrolle des Datenflusses vom Client zur
Komponente und umgekehrt realisiert.
Das DCOM - Sicherheitskonzept bietet eine Authentisierung und Autorisierung auf
verschiedenen Ebenen und garantiert, dass kein unbefugter Zugriff auf
Komponenten erfolgen kann (siehe ,,2.2.7 Sicherheitsmechanismen").
Objektklasse: ist bei komponentenorientierter Programmierung eine benannte,
konkrete Implementierung von einem oder mehreren Interface(s). In ,,Abbildung 4:
Auswahl von Implementierungen" stellen Quellcode 1 und Quellcode 2 Objektklassen
dar.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 25 von 141
Ein Prozess im Sinne der Programmausführung ist ein Rahmen für Software, der
einer Applikation alle benötigten Ressourcen zur Verfügung stellt, die für die
Programmausführung benötigt werden.
COM Server: ein Prozess, der mindestens eine Objektklasse und mindestens ein
Interface dafür enthält und einem COM Client die Nutzung seiner Methoden erlaubt.
COM Client: ein Prozess, der die von einem COM Server zur Verfügung gestellten
Interfaces benutzt.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 26 von 141
2.2.1 DCOM Architektur
Dieser Abschnitt beinhaltet die grundlegende Kommunikationstechnik, die bei DCOM
Interfaceaufrufen verwendet wird. Es werden Aufrufe im gleichen, in verschiedenem
Prozessraum und über das Netzwerk hinweg erklärt. Wie Interfaces definiert werden
und welche Teile sie enthalten, wird im nächsten Kapitel ,,2.2.2 Teile eines Interfaces"
erläutert.
DCOM ist, wie im vorigen Kapitel definiert, eine Erweiterung des Component Object
Models (COM). Ein Client, der eine Schnittstellenmethode einer Komponente aufruft,
muss sich nicht mehr um den erhöhten Kommunikationsaufwand kümmern, wenn
sich der COM Server auf einem anderen Computer befindet.
Abbildung 6: Prozessinterne Interfaceaufrufe
Abbildung 6 zeigt, dass ein Interfaceaufruf, bei dem sich der COM Client und COM
Server im selben Prozess befinden, ohne zusätzliche Mechanismen erfolgen kann.
Dieser Interfaceaufruf erfolgt wie ein Methodenaufruf zum Beispiel bei der
objektorientierten Programmierung.
Befinden sich der COM Client und COM Server in verschiedenen Prozessen (siehe
Abbildung 6), erkennt das die COM Bibliothek (in der Abbildung als COM run-time
bezeichnet) und leitet den Interfaceaufruf über LPC (Local Procedure Call) an den
anderen Prozess weiter. LPC ist eine Methode, wie zwei Prozesse unter Windows,
miteinander kommunizieren können. Es werden also von dem DCOM Modell die
Betriebssystemfunktionen für die Interprozesskommunikation benutzt.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 27 von 141
Abbildung 7: Interprozesskommunikation mit DCOM
Falls sich der COM Server auf einem anderen Computer als der COM Client
befindet, ersetzt DCOM die lokale Interprozesskommunikation durch ein
Netzwerkprotokoll und weder bei der Client noch bei der Server Komponente sind
Änderungen nötig (siehe Abbildung 3).
Auf welcher Stufe der Netzwerkprotokollhierarchie DCOM bei der Kommunikation
über Computergrenzen hinweg zu finden ist, wird in Abbildung 9 dargestellt.
Abbildung 8: Netzwerkkommunikation mit DCOM
DCOM könnte, wie in [MSJ_1998] beschrieben, als Netzwerkprotokoll höherer Ebene
bezeichnet werden, da es COM Komponenten befähigt über Netzwerke miteinander
zu kommunizieren. Die Schichten der Netzwerkprotokolle können, wie in Abbildung 9
ersichtlich, aus dem Ethernet Protokoll auf unterster Ebene und DCOM auf höchster
bestehen.
Im folgenden wird DCOM als Netzwerkprotokoll in eine bestehende Hierarchie
eingegliedert. Es wird veranschaulicht, dass bei der Übertragung der Daten über das
Netzwerk, anstatt wie bei der Interprozesskommunikation die
Betriebssystemfunktionen, die bestehenden Netzwerkprotokolle verwendet und für
eigene Zwecke adaptiert werden.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 28 von 141
Da das RPC Protokoll bereits Funktionsaufrufe über Computergrenzen hinweg
unterstützt, bedarf es nur mehr einer Erweiterung dieses Protokolls, um die
Kommunikation mit Komponenten zu erlangen.
Dazwischen können zum Beispiel das Internet Protocol (IP), User Datagram Protocol
(UDP) und Remote Procedure Calls (RPC) liegen. Abbildung 9 zeigt aber nur eine
mögliche Konfiguration, denn unter RPC können viele Protokolle durch die hier
gezeigten ersetzt werden.
DCOM wählt automatisch das beste unter
der RPC Schicht liegende Protokoll für den
COM Client und den COM Server. Ein
Paket, das über das Netzwerk übertragen
wird, besteht aus seiner Kennung (Header)
und den aktuellen Daten. Jedes Protokoll
betrachtet das direkt darüber liegende als
Teil seiner Daten und somit enthält jedes
übertragene Paket den Header und die
Daten jedes Protokolls in der Hierarchie
(siehe auch [SCHR_1989] Seite 55).
Abbildung 9: Protokollhierarchie
Die Ausnahme dieser Regel bildet DCOM, weil es Teile der RPC Struktur für ihre
eigenen Zwecke benutzt. Deshalb wird das DCOM Netzwerkprotokoll auch oft Object
RPC (ORPC) genannt, um die starke Zusammengehörigkeit zu RPC hervorzuheben.
Diese Protokollhierarchie kann man auch auf das OSI (Open Systems
Interconnection) sieben Schichten Modell (siehe [SCHR_1989], Seite 51ff.)
übertragen. Abbildung 10 zeigt wie die Protokollhierarchie unter Windows aussehen
könnte, wobei zu beachten ist, dass bei anderen Betriebssystemen die Schichtung
anders ausfallen kann.
In dieser Abbildung sind auf der linken Seite die Schichten des OSI Modells genannt,
auf der rechten Seite die Ausprägungen auf einem Computer, auf dem Windows
installiert ist und eine Ethernet Netzwerkkarte enthält.
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 29 von 141
Abbildung 10: ISO/OSI 7 Schichten Modell
Das DCOM Modell greift also entweder überhaupt nicht in die Kommunikation von
Client und Server ein oder benutzt Betriebssystemfunktionen oder ein
Netzwerkprotokoll. Der Client kann dadurch Interfacemethoden aufrufen, wobei
DCOM die Art der Kommunikation (im selben Prozess, über Prozessgrenzen oder
über Computergrenzen) vor ihm verbirgt. Die Interfaces von COM Servern stellen
einen Zugang zu den Binärobjekten dar, diese wiederum enthalten die
Implementierung in kompilierter Form.
Aus dieser Architektur des DCOM Modells ergeben sich folgende Vorteile:
a) Wiederverwendung: Die entwickelten Komponenten stellen Bausteine in
binärer Form mit einem Interface dar, die in späteren Anwendungen
wiederverwendet werden können.
b) Ortsunabhängigkeit: Die Verteilung von Applikationen auf mehrere Computer
wird ermöglicht.
c) Sprachunabhängigkeit: Die Entwicklung der Komponenten eines Systems
kann in verschiedenen Sprachen, mit verschiedenen Hilfsmitteln erfolgen, da
Interfaces Zugang zu binären Objekten zur Verfügung stellen.
Programmiersprachen, die eine Definition von Interfaces für Komponenten
Roboterfernsteuerung in offener Netzwerkumgebung
Manuel
Nedbal
Seite 30 von 141
erlauben sind zum Beispiel Java, Microsoft Visual C++
®
, Microsoft Visual
Basic
®
, Delphi, PowerBuilder, Micro Focus COBOL). Es wäre möglich einen
COM Server in Java und den COM Client in Delphi zu implementieren. Nach
der Übersetzung sind beide Teile in Maschinencode vorhanden und
kommunizieren über ein standardisiertes Interface.
d) Existierendes Verbindungsmanagement: Netzwerkverbindungen sind im
allgemeinen fehleranfälliger als rechnerinterne Kommunikation. DCOM
verwaltet die Verbindungen zu Komponenten, indem die Anzahl der Clients,
die zu einem Server verbunden sind, gespeichert wird. Diese Anzahl der
Verbindungen wird in einem Zähler abgelegt, der bei jeder eröffneten
Verbindung erhöht, bei geschlossener erniedrigt wird. Erreicht dieser Zähler
Null, kann sich die Komponente selbst freigeben. Um festzustellen, ob eine
Verbindung abgebrochen ist, benutzt DCOM einen effizienten Mechanismus,
der in bestimmten Zeitintervallen die Verbindung zwischen COM Client und
COM Server testet. Sollte dabei ein Fehler auftreten, wird der Zähler erniedrigt
und die Komponente bei Bedarf aus dem Speicher des Computers entfernt.
Der Referenzzähler entspricht üblicherweise der Anzahl der Referenzen auf
Interfaces (siehe Kapitel 2.1, ,,Abbildung 5: Interface Referenzen des Clients").
e) Skalierbarkeit: Die Anzahl der Komponenten eines DCOM Systems ist
ebenso wenig beschränkt wie die Anzahl und Dislokation der Computer auf
denen Teile des Systems ausgeführt werden.
f) Gleichzeitigkeit (Symmetric Multiprocessing): Mit DCOM ist es möglich
mehrere eintreffende Client Anfragen am Server gleichzeitig zu bearbeiten.
Multiprocessing bedeutet, dass mehrere Jobs gleichzeitig aktiv sind, denen
nach vordefinierten Zeiteinheiten die Benutzung des Prozessors oder der
Prozessoren eines Computers gestattet wird um ihre Aufgaben abzuarbeiten.
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2000
- ISBN (eBook)
- 9783832451516
- ISBN (Paperback)
- 9783838651514
- DOI
- 10.3239/9783832451516
- Dateigröße
- 7.1 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Johannes Kepler Universität Linz – Informatik
- Erscheinungsdatum
- 2002 (März)
- Schlagworte
- programmierung server client komponente
