-
HINTERGRUND DER ERFINDUNG
-
1. Gegenstand der Erfindung
-
Die
vorliegende Erfindung betrifft ein Verfahren zur Roboter-Teleübertragung
und ein Teleübertragungssystem
für autonome
Roboteragenten.
-
In
aktueller Praktik hat ein Roboter eine physikalische Architektur
(Körper,
Sensoren, Betätiger) und
ein Steuerprogramm, das auf einem Computer oder einer elektronischen
Sonderzweck-Vorrichtung ausgeführt
ist, das dem Roboter seine funktionellen Eigenschaften verleiht.
Der Roboter ist autonom genannt, wenn er diese Steuerprogramme ohne menschliches
Eingreifen ausführt
und wenn er seine Steuerprogramme anpasst, um an seine Umgebung und
Aufgabenstellung maximal angepasst zu sein. Das Steuerprogramm ist
generell mit einem spezifischen physikalischen Körper verknüpft, insbesondere wenn das
Steuerprogramm durch Anpassung, Lernmechanismen oder andere Mittel
zum Individualisieren des Roboters spezialisiert ist.
-
2. Technischer Hintergrund
-
Es
gibt einige relevante Konzepte und Mechanismen, welche als Hintergrund
vorliegender Erfindung agieren.
-
Es
gab auf dem Gebiet der ferngesteuerten Roboter signifikante Entwicklungsarbeit,
wobei ein Mensch einen Roboter beabstandet steuern kann. In diesem
Fall sind die Sinneszustände
des Roboters extrahiert und über
ein Datenübertragungssystem
zu einem anderen physikalischen Ort zum Interpretieren durch einen
menschlichen Operator gesendet. Der menschliche Operator sendet
dann wieder über
das Datenübertragungssystem
Steueranweisungen zum Roboter. Ein Beispiel eines solchen Standes
der Technik ist in
WO-A9852109 angegeben.
Teleübertragung
erfordert eine Roboterarchitektur, in welcher sensorische und betätigende
Zustände
für externe Prozesse
zugänglich
gemacht sind. In diesem Fall von Teleübertragung ist der Roboter
nicht autonom, weil er unter der Kontrolle des Menschen bleibt. Dementsprechend
ist in den ferngesteuerten Robotern das Steuerprogramm nicht durch
den Roboter selbst auf lokalen Computer-Ressourcen ohne menschliches
Eingreifen ausgeführt.
-
Ein
anderer relevanter Bereich mit einem bemerkenswerten Stand der Technik
ist der von den netzmobilen Programmen. Das sind Computerprogramme,
die zwischen Hostvorrichtungen quer durch ein Netzwerk übertragen
und dann in einer lokalen Vorrichtung ausgeführt sein können. Ein Java-Applet (kleines
Programm) ist beispielsweise ein übertragbares Computerprogramm,
das in einer Hostvorrichtung (typischerweise einem Web-Browser)
ausgeführt
ist. Jedoch ist ein netzmobiles Programm wie ein Java-Applet, das
eine Taste oder eine Bildabbildung umsetzt nicht autonom: es ist
nach Bedarf herunter geladen, reagiert auf Betätigungen des Benutzers und
ist dann aus dem Speicher gelöscht,
wenn der Benutzer fortfährt.
Außerdem
ist ein netzmobiles Programm nicht langlebig, d.h. das netzmobile
Programm hat keine definierte Lebenszeit, welche mehr als einen
einzelnen Aufruf andauert und im Falle der mobilen Programme ist
es nicht notwendig dessen interne Zustände einzustellen.
-
Ein
dritter relevanter Bereich des Standes der Technik befasst sich
mit Software-Agenten.
Software-Agenten sind Systeme, die eine Autonomität und Dauerhaftigkeit
aufweisen und daher einige Eigenschaften von teleübertragbaren
Agenten aufbringen. Verschiedene Vorschläge sind für die Software-Agenten gemacht
worden und verschiedene Experimente sind ausgeführt worden.
-
Es
gibt zwei bedeutsame Unterschiede hierbei. Erstens ist die Mobilität keine
notwendige Eigenschaft der Software-Agenten. Viele Software-Agenten
sind gar nicht zwischen Hostvorrichtungen übertragen. Andere können das
was wir Pseudo-Mobilität nennen
aufweisen: sie machen den Gebrauch von Daten, die von entfernten
Ressourcen bezogen sind, aber sind selbst nicht übertragen. Die „Spinnen" („spider") oder „Laufketten" („crawler"), die zum Indizieren
des World Wide Web benutzt sind, sind Beispiele von pseudomobilen
Programmen: sie machen den Gebrauch von fernen Daten, aber trotz
deren Namengebung – mit
deren Andeutung einer Bewegung – spielt
die Übertragung
von einem Host zum anderen hinsichtlich der Ausführung keine Rolle in deren normaler
Betriebsweise. Eine kleinere Anzahl von Agenten kann wirklich mobil
sein, aber es ist klar, dass die Mobilität kein zwingender Teil der
Definition eines Software-Agenten ist.
-
Der
zweite und wesentlich wichtigerer Unterschied ist, dass die Software-Agenten
typischerweise nicht gebunden sind. Sie arbeiten innerhalb eines
Informationsraums, welcher durch gespeicherte Daten, nicht durch
die in Realzeit von Sensoren oder Betätigern erhaltenen Daten definiert
ist.
-
KURZBESCHREIBUNG DER ERFINDUNG
-
Die
vorliegende Erfindung beabsichtigt das Abtrennen funktioneller Fähigkeiten
und daher der Verhaltensidentität
des Roboters von seiner physikalischen Ausgestaltung in einer solchen
Weise, dass es über
ein solches Datenübertragungsnetzwerk
wie das Internet in verschiedene Roboterkörper gesendet und heruntergeladen
(materialisiert) oder extrahiert (dematerialisiert) sein kann. Solch
eine Eigenschaft ist Mittleragent-Teleübertragung
genannt. Die verhaltensbedingte Identität eines Roboters ist Agent genannt
und die physikalische Installation, in welcher ein Agent untergebracht
sein kann, ist als eine Hilfsvorrichtung des Roboterkörpers genannt.
Ein fernübertragbarer
Roboter-Agent ist ein Agent, welcher sowohl in einem Roboterkörper untergebracht
sein kann als auch über
ein Datenübertragungsnetz
wandern kann.
-
Roboterfernübertragung
weist einen breiten Anwendungsbereich auf. Physikalische Roboterkörper, die über das
Internet verbunden sind werden erwartet in Zukunft verbreitet zu
sein und Personen werden Agenten haben, welche diese Roboteraufbaustrukturen
betreiben können,
aber nicht an einen einzelnen physikalischen Roboter gebunden sind. Solche
Agenten können
Aufgaben in der physikalischen Welt ausführen oder mit anderen beherbergten
Agenten in vielen verschiedenen physikalischen Orten interagieren,
ohne der Notwendigkeit sich physikalisch von einem Ort zum nächsten zu
bewegen.
-
Zum
Beispiel sind die „Haustier-Roboter", welche fähig sind,
sich autonom zu bewegen und Grundtöne und Aussehen verleihende
Vorrichtungen (solche wie der als ein Hund ausgebildeter miniaturisierter
Aibo-Roboter, der von Sony® Corporation hergestellt
ist) aufweisen, zunehmend auf den Markt gekommen. Basierend auf
der in dieser Anwendung beschriebenen Erfindung könnten sich
solche kleinen mobilen Roboter periodisch mit einem Netzwerk verbinden,
um Agenten herunter zu laden, die als Steuerprogramme für den Roboter
agieren. Unter Anweisung des steuernden Agenten erkundet der Roboter seine
unmittelbare Umgebung. Die Bild- und Tondaten, die er erfasst, sind
verwendet, um dem Agenten zu ermöglichen „zu lernen" (z.B. durch das
Erstellen der Weltkarten oder das Lernen – beim Zusammenwirken mit anderen
Robotern oder Menschen – der Namen
identifizierbarer Gegenstände
wie der Oberflächen
in der Welt). Der Roboter kann sich dann mit einem Netzwerkzugangs-Port verbinden und
den Agenten und sein neuerlich über
die Welt erworbenes Wissen herunterladen. Das eröffnet Möglichkeiten für das Backup,
Wartung, Überwachung
und Aktualisierung der Agenten, ohne der Notwendigkeit für die Benutzer
die Agenten manuell zu speichern oder wiederherzustellen oder neue
Software zu installieren. Außerdem
könnten
Eigentümer
der Haustier-Roboter die Agenten oder Teile von Agenten austauschen
oder Personen könnten
Agenten haben, die an anderen Orten interagieren, wodurch das Unterhaltungspotential
der Haustier-Roboter zunimmt.
-
Eine
andere Anwendung ist im Gesprochenen. Ein Sprachsystem kann als
ein Agent angesehen sein, der einen Sprachgenerator steuert und menschliche
Sprache über
ein Mikrophon erkennt. In Gegensatz zu meisten aktuellen Technologien
erwarten wir zukünftige
Agenten die menschliche Sprache in deren Umgebung kontinuierlich
anzupassen und zu spezialisieren. Das bedeutet, dass deren internen Zustande
sich zum Aufzeichnen neuer Worte, neuer Aussprachen etc. verändern. Durch
die in der vorliegenden Ausführung
beschriebene Erfindung ist es den Personen möglich, einen Sprach-Agenten
zu haben, der an deren Sprache oder die Sprache der Leute, mit denen
die Personen zu interagieren haben, hochangepasst ist. Solch ein
Sprach-Agent kann sich selbst an einer beliebigen Maschine, welche
geeignete Hardware aufweist, an einem Ort installieren, wo ihr Benutzer
physikalisch lokalisiert ist. Es ist für Sprach-Agenten, die in anderen Umgebungen gewesen
sind, auch möglich,
sich in anderen Umgebungen selbst irgendwo zu installieren, wo deren
Expertenwissen am meisten benötigt
ist und als eine Umsetzeinrichtung zu agieren.
-
In
Kürze,
die vorliegende Erfindung wendet sich an gebundene mobile Agenten
und unterscheidet sich von der Teleübertragung darin, dass der Agent
autonom ist, wobei er seine definierten Ziele unabhängig von
einem menschlichen Operator verfolgt. Somit ist entsprechend der
vorliegenden Erfindung das Steuerprogramm durch den Roboter selbst an
lokalen Computer-Ressourcen ohne eines menschlichen Eingreifens
ausgeführt.
-
Die
Agenten nach vorliegender Erfindung unterscheiden sich von den netzmobilen
Standardprogrammen dadurch, dass sie auch dauerhaft sind. Deren
interner Zustand und Aufbaustruktur ist zwischen den Aufrufen beibehalten.
Somit hat ein Agent eine definierte Lebenszeit, welche mehr als
einen einzelnen Aufruf des Agenten andauert. Außerdem müssen autonome Agenten in der
Lage sein, deren eigene Vertretungen und interne Zustände anzupassen,
sowie sie durch eine Reihe nacheinanderfolgender Interaktionen lernen.
-
Die
erfindungsgemäßen Agenten
unterscheiden sich ferner von konventionellen Software-Agenten dadurch,
dass sie notwendigerweise mobil und notwendigerweise gebunden sind.
Dadurch sind die Agenten in der realen Welt untergebracht und müssen die
Welt durch physikalische Vorrichtungen steuern und wahrnehmen. Weil
diese Agenten die Zufälligkeit
abhandeln müssen,
mir der die realen Weltumgebungen behaftet sind, wird es niemals möglich sein,
sie vollständig
zu programmieren und sie in einem statischen Zustand zu haben. Im
Gegenteil, sie passen an und spezialisieren sich notwendigerweise,
um bestimmte Typen von Ausrüstungen
zu handhaben. Diese definierenden Eigenschaften machen spezifische
Anforderungen an das Hilfssystem erforderlich.
-
Spezieller
sind die Ziele der vorliegenden Erfindung durch ein Verfahren zum
Umsetzen eines ersten Systems, das aus einer physikalischen Aufbauanordnung
und dazwischen verbundenen Hardware- und Softwarekomponenten besteht
und ein Serversystem definiert, in zumindest ein zweites System,
das aus einer physikalischen Aufbauanordnung und dazwischen verbundenen
Hardware- und Softwarekomponenten besteht und ein Clientsystem definiert,
wobei jedes von dem ersten und zweiten System zumindest einen Mittleragenten
aufweist, der funktionelle Fähigkeiten definiert,
die die verhaltensbedingte Identität eines Roboters und einer
Hilfsvorrichtung bestimmt, durch die physikalische Aufbauinstallation
ausmachen, in der ein Mittleragent untergebracht sein kann, dadurch
gekennzeichnet, dass die Umsetzung zwischen dem ersten und zweiten
System durch eine Mittleragent-Teleübertragung über ein Datenübertragungsnetzwerk
erreicht ist, wobei jeder Mittleragent durch einen eingrenzbaren
Mittleragentenzustand vertreten ist, der eine Ansammlung von Informationen
aufweist, die während
des Betriebs des Systems, deren Teil sie sind, Änderungen unterliegen, welcher
einen erheblichen Steuereinfluss auf den Betrieb dieses Systems
hat und welcher von den ständigen
Teilen der Hilfsvorrichtung abgetrennt und ausgezeichnet sein kann,
wobei während
der Umsetzung des ersten Systems in das zumindest zweite System
jeder Mittleragent vorübergehend
in eine fortbestehende Vertretung umgesetzt ist, die über das Datenübertragungsnetzwerk übertragen
sein kann, wobei das Herunterladen eines durch das Clientsystem
von dem Serversystem angeforderten Mittleragenten mittels eines
zustandslosen Anforderungs-/Rückantwortprotokolls
und einem Paar von Nachrichten-Token erreicht ist, und das Hochladen eines
im Clientsystem vertretenen Mittleragenten, der zum Serversystem
zu senden ist, auch mittels eines zustandslosen Anforderungs-/Rückantwortprotokolls
und einem Paar von Nachrichten-Token erreicht ist.
-
Entsprechend
einer spezifischen Ausgestaltung ist das zustandslose Anforderungs-/Rückantwortkommunikationsprotokoll,
das zum Herunterladen oder Hochladen eines Mittleragenten verwendet ist,
ein HTTP-Protokoll.
-
Nach
einem Aspekt der vorliegenden Erfindung weist das Herunterladen
eines durch den Client angeforderten Mittleragenten folgende Schritte
auf:
- a) Bereitstellen einer Wartereihe wartender
Mittleragenten, die zum Clientsystem zu liefern sind, in dem Serversystem,
- b) Ermöglichen
dem Clientsystem eine BEKOMME-NÄCHSTEN-MITTLERAGENTEN-Anforderung
an das Serversystem zu übertragen,
- c) Vorhalten eines ersten wartenden Mittleragenten, der zum
Clientsystem als Rückantwort
auf die durch das Clientsystem übertragene
BEKOMME-NÄCHSTEN-MITTLERAGENTEN-Anforderung
zu senden ist,
- d) Nachprüfen,
ob der erste wartende Mittleragent bereits in dem Clientsystem vertreten
ist und Ignorieren dieses Mittleragenten, wenn die Antwort Ja ist,
- e) Installieren des ersten wartenden Mittleragenten in dem Clientsystem,
wenn dieser Mittleragent noch nicht vertreten ist, und Senden eines
MITTLERAGENT-VERTRETEN-Signals zum Serversystem, um anzuzeigen,
dass der Mittleragent empfangen worden ist, wobei der empfangene Mittleragent
aus der Wartereihe nach dem Erhalt des MITTLERAGENT-VERTRETEN-Signals durch
das Serversystem entfernt wird,
- f) Wiederholen der Schritte b) bis e) zum Erhalt aller angeforderten,
hintereinander wartenden Mittleragenten, die von dem Serversystem
zum Clientsystem gesendet werden, bis das Serversystem einen „keine-Mittleragenten-mehr"-Token aussendet.
-
Nach
einem anderen Aspekt der vorliegenden Erfindung weist das Hochladen
eines in dem Clientsystem vertretenen Mittleragenten folgende Schritte
auf:
- a) Bereitstellen einer Wartereihe wartender
Mittleragenten, die zum Serversystem zu liefern sind, in dem Clientsystem,
- b) Ermöglichen
dem Clientsystem eine IST-MITTLERAGENT-VERTRETEN-Anforderung an das Serversystem für den ersten
wartenden Mittleragenten zu übertragen,
- c) Löschen
eines ersten wartenden Mittleragenten aus der Wartereihe in dem
Clientsystem, wenn die Antwort auf die IST-MITTLERAGENT-VERTRETEN-Anforderung „Ja" ist,
- d) Senden des ersten wartenden Mittleragenten zu dem Serversystem
mit einem MITTLERAGENTEN-HOCHLADEN-Signal und Löschen aus der Wartereihe in
dem Clientsystem, wenn die Antwort von dem Server auf die IST-MITTLERAGENT-VERTRETEN-Anforderung „Nein" ist,
- e) Wiederholen der Schritte b) bis d) für jeden nächsten, im Clientsystem wartenden
Mittleragenten, bis alle wartenden Mittleragenten aus der Wartereihe
im Clientsystem wartender Mittleragenten gelöscht sind.
-
Entsprechend
einer möglichen
Ausgestaltung arbeitet ein Serversystem mit einer Vielzahl von Clientsystemen
zusammen.
-
In
einer spezifischen Ausgestaltung ist das Serversystem ein passives
System, das lediglich auf die durch die Clientsysteme gesendete
Nachrichten ohne eine Verbindung einzuleiten reagiert.
-
Die
vorliegende Erfindung betrifft auch ein autonomes System aufweisend
zumindest einen Mittleragenten, der funktionelle Fähigkeiten
definiert, die die verhaltensbedingte Identität eines Roboters und einer
Hilfsvorrichtung bestimmt durch die physikalische Aufbauinstallation
ausmachen, in der ein Mittleragent untergebracht sein kann, wobei
die Hilfsvorrichtung Hardwarekomponenten, Softwarekomponenten, die
den generellen Betrieb der Hardware der Vorrichtung betreffen, Softwarekomponenten,
die mit der Instandhaltung der Mittleragentenumgebung und jener
Teile der Mittleragentenimplementierung, die nicht verändert werden,
zusammenhängen,
und Softwarekomponenten, die mit dem Lesen und Schreiben eines eingrenzbaren
Mittleragentenzustands zusammenhängen,
der eine Ansammlung von Informationen aufweist, die während des
Betriebs des Systems, deren Teil sie sind, Änderungen unterliegen, welcher
einen erheblichen Steuereinfluss auf den Betrieb dieses Systems
hat und welcher von den ständigen
Teilen der Hilfsvorrichtung abgetrennt und ausgezeichnet sein kann,
aufweist, wobei das anonyme System ferner Extrahiermittel zum Extrahieren
des Zustands des eingrenzbaren Mittleragentenzustands und zu seinem
Umformen in eine Vertretung, welcher quer durch das Netzwerk übertragen
sein kann, und Einfügemittel
zum Einfügen
eines empfangenen übertragenen
Zustands in die Hilfsvorrichtung auf eine solche Art und Weise aufweist,
um den empfangenen Mittleragenten in dieser Hilfsvorrichtung zu
beherbergen.
-
Spezieller
enthält
der Mittleragentenzustand Daten, die in den Berechnungen verwendet
sein können,
die durch den Code ausgeführt
sind, der in der Mittleragent-Kernimplementierung
definiert ist, als auch den Code und Daten, die die Konfiguration
des Hardwaresubstrats vertreten.
-
Entsprechend
einer spezifischen Ausgestaltung weisen die Extrahiermittel Mittel
zum Lesen der Teile des Hilfsvorrichtungsspeichers, in welchen Schlüsselelemente
des Mittleragentenzustands definiert sind, und Mittel zum Umsetzen
der darin gefundenen Daten in einen Text- oder Binärdatenstrom, der
für die Übertragung
geeignet ist, auf.
-
Entsprechend
einem anderen Aspekt weisen die Einfügemittel Mittel zum Interpretieren
der empfangenen übertragenen
Daten und Mittel zum auf eine solche Art und Weise Aktualisieren
des Speichers der Zielhilfsvorrichtung, um den Mittleragenten in
dieser Vorrichtung zu beherbergen, auf.
-
Das
autonome System nach Erfindung bildet entweder ein Serversystem,
das zumindest mit einem Clientsystem zusammenarbeitet, oder ein
Clientsystem, das zumindest mit einem Serversystem zusammenarbeitet.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Weitere
Merkmale und Vorteile der vorliegenden Erfindung werden durch untenfolgend
in bezug auf die beigefügten
Zeichnungen gemachte Beschreibung verdeutlicht, in welchen:
-
1 ein
Diagramm ist, das die Architektur eines erfindungsgemäßen autonomen
Systems darstellt,
-
2 ein
Flussdiagramm ist, das die allgemeinen Schritte des Hochladens eines
Agenten darstellt, der in dem Clientsystem nach einem Aspekt des
erfindungsgemäßen robotischen
Teleübertragungs-Verfahrens
vorhanden ist, und
-
3 ein
Flussdiagramm ist, das die allgemeinen Schritte zum Herunterladen
eines Agenten, der in dem Clientsystem nach einem anderen Aspekt des
erfindungsgemäßen robotischen
Teleübertragungs-Verfahrens
vorhanden ist.
-
DETAILBESCHREIBUNG DER BEVORZUGTEN AUSGESTALTUNGEN
-
1. Mittleragenten-Architektur
-
Um
die Agenten teleübertragbar
zu machen, müssen
zwei Bedingungen zutreffen:
- (1) Ausgehend von
einem kompletten System, das aus untereinander verbundenen Hardware- und
Software-Komponenten besteht, muss es möglich sein, die Software-Elemente
(Steuerprogramme und Daten) zu identifizieren, welche den Zustand
des Mittleragenten mit seinen ganzen gelernten Verhaltensweisen
und Informationen definieren.
- (2) Es muss möglich
sein, den kompletten Zustand in eine Form zu übersetzten, welche ausgeschrieben
und dann wiedergelesen sein kann. Das Wiedereinlesen des Agentenzustands
in eine geeignete Host-Hardware/Software-Vorrichtung muss ein komplettes
System produzieren, welches – im
Rahmen der durch die Vorrichtung auferlegten Einschränkungen – funktionell
dem System äquivalent
ist, von dem der Mittleragent extrahiert worden ist.
-
1.1 Der Zustand des Agenten
-
Man
betrachte eine Hostvorrichtung, die wir D nennen. Eine solche Vorrichtung
kann beides haben, Hardware-Komponenten H und Software-Komponenten
S. Wenn eine Agentenvertretung oder ein Zustand A der Vorrichtung
D hinzugefügt
ist, bildet das Ganze ein komplettes System Σ.
-
Man
betrachte nun ein Netzwerk, das zwei identische Vorrichtungen D1
und D2 und eine Agentenvertretung A1 aufweist. Die Zusammensetzung der
Vorrichtung D1 und der Agentenvertretung A1 bildet ein komplettes
System Σ1.
Wenn wir mm die Agentenbeschreibung A1 in die Vorrichtung D1 übertragen,
wird das resultierende System Σ2
funktionell dem System Σ1 äquivalent
sein. (Es ist keine Anforderung der vorliegenden Erfindung, dass
Agenten nur zwischen identischen Vorrichtungen zu übertragen
sind: die Vorrichtungen D1 und D2 können auch nicht identisch sein,
welche die nichtäquivalente
Systeme Σ1
und Σ2 produzieren;
das Beispiel ist lediglich zum Darstellen des Faktes angegeben,
dass die Agentenvertretung eine übertragbare
Komponente ist, welche mit einer Hilfsvorrichtung zusammen genommen
ein einfaches System bildet).
-
Hieraus
folgt, dass die komplette Agentenvertretung die minimale Einheit
ist, welche zwischen zwei identischen Vorrichtungen in einer Weise übertragen
sein kann, um äquivalente
Systeme zu produzieren. Informell gesprochen, besteht die Agenten-Vertretung aus allem
in dem kompletten System Σ1
Vorhandenen, das in der Zielvorrichtung D2 nicht vorhanden ist und
was zu D2 übertragen
sein muss, um Σ2
zu produzieren.
-
Die
Agentenvertretung ist auch eine Einheit des Austauschs. Zu diesem
Zweck sprechen wir von dem Zustand eines Agenten. Wie früher konstatiert, sind
die Agenten langlebig. Die Interaktion eines Agenten mit der Welt – durch
die Vorrichtung, in der er installiert ist – führt zu Änderungen in den internen Datenaufbaustrukturen
und dem Programmcode des Agenten. Diese Änderungen sind von permanenter oder
halbpermanenter Natur und werden das zukünftige Verhalten des Agenten
bestimmen oder beeinflussen. Sie sind daher verschieden von – beispielsweise – während der
Ausführung
vorübergehend
variablen Bindungen, welche vergessen sind, sobald die Berechnung
abgeschlossen worden ist und von den „permanenten" Teilen eines beliebigen
Hilfssystems, welche unempfindlich gegenüber Modifikationen als ein
Ergebnis der Ausführung
sind.
-
Nebenbei
ist anzumerken, dass die Hardware-Komponente einer Vorrichtung nicht
zwingend unveränderlich
ist. Man stelle sich eine Vorrichtung vor, die ein Feld von Sensoren
aufweist, die in einer spezifischen Konfiguration angeordnet sind.
Als Ergebnis von Lern- oder Optimierungsmechanismen kann ein Agent
die Konfiguration einstellen, um besser die Wahrnehmungen von der
Welt zu erfassen. Diese neue Konfiguration ist ein notwendiger Teil
des ganzen Systems und ist benötigt,
um eine effektivere Funktion zu ermöglichen, aber kann nicht über ein Netzwerk übertragen
werden. Stattdessen braucht man eine Vertretung dieser Konfiguration
zu übertragen,
um die Vervielfältigung
der Konfiguration auf andere Vorrichtungen zu ermöglichen.
Die Agenten-Vertretung kann daher Details der erforderlichen Konfigurationen
der unterlegten Hardware- und Software-Aufbaustruktur aufweisen – der Vorrichtung – als auch
des eigenen „Wissens" des Agenten – der Daten
und Algorithmen, die für
diesen Agenten einzigartig und im Verlauf seiner Berechnungen benutzt sind.
-
Zusammengefasst
ist der Agentenzustand oder eine Vertretung eine Ansammlung von
Informationen, welche:
- – während des Betriebs eines Systems,
dessen Teil sie ist, einer Änderung
unterliegen,
- – bedeutenden
Steuereinfluss auf den Betrieb dieses Systems haben,
- – von
den „permanenten" Teilen des Systems
isoliert und differenziert sein können,
- – einer
geeigneten Hilfsvorrichtung hinzugefügt sein können, um ein neues vollständiges System zu
bilden.
-
1.2 Extrahier- und Eintragungsprozesse
-
Bei
einem gegebenen isolierbaren Agentenzustand brauchen wir als Nächstes:
- – eine
Möglichkeit,
diesen Zustand zu extrahieren und in eine Vertretung umzuformen,
welche quer durch das Netzwerk übertragen
sein kann,
- – eine
Möglichkeit,
den übertragenen
Zustand in eine Zielvorrichtung wiedereinzutragen.
-
Im
praktischen Einsatz können
die durch diese Anforderungen aufgeworfenen technischen Herausforderungen
relativ einfach erfüllt
sein. Eine Extrahierkomponente kann aufgebaut sein, die relevanten
Teile des Speichers der Hostvorrichtung zu lesen – d.h. der
Teile, in welchen die Schlüsselelemente des
Agentenzustands definiert sind – und
die darin gefundenen Daten in einen für eine Übertragung geeigneten Text-
oder Binärstrom
umzusetzen. Andererseits kann eine Eintragungskomponente die übertragenen
Daten interpretieren und sie zum Aktualisieren des Speichers der
Zielvorrichtung auf eine solche Weise verwenden, um den Agenten
in dieser Vorrichtung zu „beherbergen".
-
Es
gibt keine Anforderungen an die für die Datenübertragung best geeignete Form.
Der Agentenzustand kann in Form eines direkten Speicherauszugs oder
als gegliederter Text in einem solchen Format wie XML oder als ein
vorgangsmäßiges „Rezept", welches zum Wiederherstellen
des Agenten ausgeführt
sein könnte, übertragen
sein. Der Schlüsselpunkt
hierbei ist nicht wie das Extrahieren und Eintragen auszuführen ist,
sondern dass es verfügbare Komponenten
geben sollte, um es zu tun. Ohne solche Komponenten kann das System
nicht arbeiten.
-
1.3 Die Architektur
-
1 summiert
die erforderlichen Komponenten des Systems 1. Die Hilfsvorrichtung 2 ist
aus beidem zusammengebaut, der Hardware- (Komponente 21)
und den Software-Komponenten 22, 23, 24.
Innerhalb der Software-Komponente sind spezialisierte Unterteile 22 zuständig für den allgemeinen Betreib
der Vorrichtung, spezialisierte Unterteile 23 zuständig für die Wartung
der Agentenumgebung und derjenigen Teile der Agentenausführung, die
sich nicht ändern,
und spezialisierte Unterteile 24 zuständig für das Lesen und Schreiben des
Agentenzustands. Der Agentenzustand selbst 3 wird als Minimum
die Daten enthalten, die in den Berechnungen genutzt sein können, die
durch Code ausgeführt
sind, der in der Agenten-Kernanwendung definiert ist. Er kann auch
Code enthalten (zum Beispiel Fragmente des Programmcodes, der durch
generische Programmierung aufgebaut ist oder Spezialanwendungs-Code,
der für
diesen Agenten durch seinen Besitzer ausgewählt oder entwickelt worden
ist) und Daten, welche die Einstellungen des Hardware-Substrats
darstellen. In 1 repräsentiert der Pfeil 5 den
Eintragungs-/Extrahierprozess zwischen dem Agentenzustand 3 und
der Hilfsvorrichtung 2, wobei die Pfeile 4 den Übertragungsprozess
zwischen dem ganzen System 1 und einem anderen ähnlichen
System darstellt.
-
Nachdem
die wesentlichen Elemente der Vorrichtungsarchitektur somit hervorgehoben
worden sind, wird nun der Mechanismus der Teleübertragung und der Eigenschaften
des Teleübertragungs-Netzwerkes
beschrieben.
-
2. Der Teleübertragungs-Mechanismus
-
In
diesem Abschnitt wird die zum Unterstützen der Übertragung der intelligenten
Agenten zwischen den Servern entworfene Architektur betrachtet.
-
2.1 Anforderungen
-
In
allgemeine Worten gefasst sind die Anforderungen an die Übertragung
eines Agenten die gleichen wie die Anforderungen an die Übertragung
beliebiger anderer Datenbestandteile. Die Techniken für die Übertragung
von Daten mit Hilfe der Fehler- Korrekturprotokolle
sind gut verstanden und vorhandene Lösungen haben sich als außerordentlich
stabil erwiesen.
-
Die
Situation ist dennoch kompliziert, wenn die übertragenen Agenten langlebig
sein müssen. Folglich
ist das Verwalten einer Welt von langlebigen Agenten eine Konsistenz-Wartungsaufgabe.
Die Aufgabe der Kommunikationsprotokolle ist im wesentlichen sicherzustellen,
dass der Gesamtzustand des Netzwerkes (und der Agenten, die es nutzen)
konsistent bleibt. Die zwei Hauptprobleme, die zu vermeiden sind,
sind der Datenverlust und die Zusammenhanglosigkeit (Inkohärenz).
-
Datenverlust
im Zusammenhang mit den Agenten rührt von der Vorstellung von
einem Agenten als einer Einheit, die eine bestimmte Art von permanenter
oder halbpermanenter Existenz hat. Wenn ein Agent einfach ein Computerprogramm
wäre, das zum
Ausführen
einer Verarbeitungsaufgabe an einen entfernten Ort ausgesendet und
dann sich überlassen
worden ist, würde
das Problem hiervon, was besser als ein „Agentenverlust" zu bezeichnen ist,
nicht aufkommen. Als eine autonome Einheit jedoch ist ein Agent
das Ergebnis seiner eigenen Berechnungen. Er beherbergt die Information,
die er integriert hat und die Vertretungen, die er aufgebaut hat.
Außerdem
sind die betrachteten Arten von Agenten nach einer einzelnen Verwendung
nicht gelöscht,
sondern setzen fort, sich von Hostvorrichtung zu Hostvorrichtung
zu bewegen. Wenn ein Agent einen Host verlässt, sind die den Agenten vertretende
Daten von diesem Host gelöscht.
Es ist daher äußerst wichtig
sicherzustellen, dass der Agent an dem nächsten Ziel erfolgreich empfangen
worden ist, bevor er von dem Quellhost gelöscht ist.
-
Die
Zusammenhanglosigkeit ist das Gegenteil des Agentenverlustes. In
diesem Fall ist ein Agent zu einem neuen Zielhost übertragen,
aber nicht von dem Quellhost gelöscht.
Es gibt nun zwei existierende Kopien des Agenten, von welchen eine
fortsetzt, sich zu entwickeln und zu lernen und eine andere, welche
einen „Schnappschuss" eines früheren Zustands
des Agenten darstellt. Sofern keine Schritte unternommen sind, es
zu verhindern, kann die Existenz zweier Kopien des gleichen Agenten
zu Konflikten führen,
die schwierig zu beheben sind.
-
Die
vorgeschlagene Architektur nach vorliegender Erfindung adressiert
diese zwei Hauptprobleme, wobei sie versucht soweit wie möglich sicherzustellen,
dass die Agenten weder verloren noch dupliziert sind, wobei sie
extrem einfach ist.
-
2.2 Stabile Übertragungen mit Hilfe zustandsloser Protokolle
-
Das
System besteht aus einer Anzahl von Hostvorrichtungen (Computer),
die in der Lage sind, miteinander über einen Kommunikationskanal
(d.h. ein Netzwerk) zu kommunizieren. Die Agenten bestehen aus fortbestehenden
Vertretungen, die über
das Netzwerk übertragen
sein können.
Die Form der Vertretungen ist nicht wichtig, aber jede muss eine „vollständige" Agentendefinition
bilden, die ausreicht, das Ausführen
des Agenten auf einer Zielplattform zu ermöglichen.
-
Die
Hosts auf dem Netzwerk stehen in einer Client-Server-Beziehung zueinander.
Die Beziehung kann fest sein, wodurch der Client immer ein Client und
der Server immer ein Server ist, aber auch eine Peer-to-peer-Netzwerkschema
kann vorgeschlagen sein, in welcher jede Maschine beides sein kann,
Client und Server. Jede Übertragung
ist durch den Client initiiert und besteht aus einer Anfrage, auf
welche der Server eine Rückantwort
liefert. Ein Vokabular aus vier Nachrichten-Token bildet die Basis
des Teleübertragungs-Mechanismus.
-
2.3 Herunterladen der Agenten
-
Um
während
der Agentenübertragung
die Datenintegrität
zu gewährleisten,
können
zwei mögliche
Betrachtungen herangezogen sein. Eine würde sein, ein Protokoll zu
definieren, das eine Art von Dreischritt-Austausch entsprechend
folgender Punkte verwirklicht:
- 1. der Client
sendet eine Anforderung,
- 2. der Server sendet eine Rückantwort,
- 3. der Client bestätigt
den Empfang der Rückantwort.
-
Im
Falle von Herunterladen eines Agenten würde der Client einen Agenten
anfordern, der Server würde
ihn zurückliefern
und der Client würde
den Empfang bestätigen,
woraufhin der Server den von dem Agenten benutzten Speicher verwerfen
könnte.
-
Eine
solche Herangehensweise ist komplizierter als es zu sein braucht,
da sie die Implementierung eines Dreischritt-Protokolls erfordert.
Außerdem bedeuten
Kommunikationsfehler an einem beliebigen Punkt, das System in einem
inkonsistenten Zustand zu lassen. Wie es sich nun herausstellt kann die
gleiche Wirkung entsprechend einer bevorzugten Ausführung der
Erfindung mit Hilfe eines einfachen zustandslosen Anforderungs-/Rückantwort-Protokolls
(solchen wie http) und einpaar Nachrichten-Token sicher erreicht sein.
-
Der
Client kann die Aufgabe des Abrufs beliebiger wartender Agenten
mit Hilfe des in 2 gezeigten Algorithmus (dargestellt
in Pseudo-Code) implementieren.
-
Eine
Reihe wartender Agenten, die an das Clientsystem zu liefern sind,
ist anfänglich
im Serversystem bereitgestellt worden.
-
Nach
dem Start (Schritt 101) überträgt das Clientsystem eine BEKOMME-NÄCHSTEN-MITTLERAGENTEN-Anforderung
zum Serversystem (Schritt 102). Wenn ein Agent in dem Serversystem verfügbar ist
(die Antwort zur Frage im Schritt 103 ist Ja), ist ein
erster wartender Agent an das Clientsystem gesendet und eine Rückantwort
auf den BEKOMME-NÄCHSTEN-MITTLERAGENTEN-Report durch
das Clientsystem (Schritt 104) übertragen.
-
Es
ist dann bestimmt, ob der erste wartende Agent bereits in dem Clientsystem
(Schritt 105) vorhanden ist. Wenn die Antwort ist „Ja", wird dieser Agent
ignoriert (schritt 106).
-
Wenn
die Antwort auf die Frage im Schritt 105 „Nein" ist, wird der erste
wartende Agent in dem Clientsystem (Schritt 107) installiert
und ein MITTLERAGENT-VERTRETEN-Signal
ist an den Server (Schritt 108) gesendet, um anzuzeigen,
dass der Mittleragent empfangen worden ist, wobei der empfangene
Agent mit dem Empfang des MITTLERAGENT-VERTRETEN-Signals durch den
Server aus der Wartereihe entfernt ist.
-
Die
gleichen Schritte sind für
alle angeforderten, nacheinander wartenden, vom Serversystem an das
Clientsystem gesendete Agenten wiederholt, bis das Serversystem
einen „KEINE-MITTLERAGENT-MEHR"-Token (Schritt 109)
sendet, wenn die Rückantwort
auf die Abfrage im Schritt 103 „Nein" ist. Nach dem Ende der wiederholten
Sequenz gelangt die Bekomme-Mittleragenten-Prozedur an das Ende (Schritt 110).
-
Somit
reagiert der Server auf die BEKOMME-NÄCHSTEN-MITTLERAGENTEN-Nachricht (Schritt 102)
mit einer Rückgabe
des ersten Agenten, der auf die Auslieferung an den Client (Schritt 104) wartet.
Wenn es keine Agenten mehr zum Senden gibt, sendet er den „KEINE-MITTLERAGENT-MEHR"-Token (Schritte 104 und 109)
zurück.
-
Das
Ausliefern eines Agenten bewirkt kein Löschen oder sogar kein Entfernen
des Agenten aus der Wartereihe. Tatsächlich verbleibt der Agent
in der Wartereihe und wenn der Client ein anderes BEKOMME-NÄCHSTEN-MITTLERAGENTEN-Signal sendet
wird er ein zweites mal heruntergeladen. Der Agent ist nur gelöscht, wenn
der Client explizit ein AGENT-VERTRETEN-Signal (Schritt 108)
sendet, um anzuzeigen, dass er den Agenten erhalten hat.
-
Das
System ist stabil, weil es kein Löschen des Agenten bewirken
und keine inkorrekte Installation bewirken kann.
- – Wenn ein
Fehler den Server daran hindert, die BEKOMME-NÄCHSTEN-MITTLERAGENTEN-Anforderung zu empfangen,
veraltet die Client-Anforderung
einfach und der Client versucht es wieder.
- – Wenn
ein Fehler den Client daran hindert, den Agenten zu empfangen, ist
die Client-Anforderung einfach ausprobiert und der Client versucht
es wieder.
- – Wenn
ein Fehler den Server daran hindert, das MITTLERAGENT-VERTRETEN-Signal
zu empfangen, ist der Agent nicht aus der Wartereihe entfernt und
der Server reagiert durch das erneute Senden davon, wenn es ein nächstes mal
BEKOMME-NÄCHSTEN-MITTLERAGENTEN-Anforderung
empfangt. Jedoch, wenn der Client eine zweite Kopie des Agenten
empfangt, ist die zweite Kopie (Schritt 106) ignoriert
und eine neue AGENT-VERTRETEN-Anfrage
ist gesendet, die dem Server eine zweite Chance einräumt zu erkennen,
dass der Agent empfangen worden ist und ihn zu löschen.
- – Es
gibt keine Unbestimmtheit darüber,
ob der Server den Agenten gelöscht
oder nicht gelöscht hat.
Sobald der Client einen neuen Agenten als Reaktion auf seine BEKOMME-NÄCHSTEN-MITTLERAGENTEN-Anforderung
empfangt, weiß er,
dass seine letzte MITTLERAGENT-VERTRETEN-Anforderung erfolgreich empfangen war
und dass der Server nicht länger mit
dem vorhergehenden Agenten befasst ist. Man vergleiche das mit dem
Fall bei dem Drei-Schritt-Protokoll, bei dem der Client keine Möglichkeit
hat zu prüfen,
ob oder nicht der Server seine Informationen empfangen hat – ohne zum
Protokoll einen weiteren Schritt hinzuzufügen (oder vielleicht mehrere).
-
Das
Drei-Schritt-Protokoll könnte
gleichsam stabil gemacht sein – aber
nur durch Mechanismen, ähnlich
zu jenen, die oben vorgeschlagen worden sind. Bei zwischenliegenden
Anforderungen und mit Hilfe des zustandslosen Protokolls kann ein
sicheres System für
die Agenten-Übertragung
mit Hilfe des „serienmäßigen" Kommunikationsprotokolls
wie HTTP bereitgestellt sein.
-
2.4 Hochladen der Agenten
-
Das
Protokoll zum Hochladen der Agenten ist im wesentlichen das gleiche.
Der Client hält
eine Liste von hochzuladenden Agenten (bezeichnet als „Abreise-Lounge") vor und durchsetzt
die MITTLERAGENTEN-HOCHLADEN-Anforderungen mit IST-MITTLERAGENT-VERTRETEN-Anforderungen.
Der Algorithmus ist in 3 gezeigt.
-
Eine
Wartereihe wartender, an den Server zu liefernder Agenten ist im
Clientsystem vorgesehen.
-
Nachdem
Start (Schritt 201) ist der Agent zum ersten in der Abreise-Lounge
wartenden Agenten (Schritt 202) gesetzt.
-
Das
Clientsystem überträgt für den ersten wartenden
Agenten eine IST-MITTLERAGENT-VERTRETEN-Anforderung
an das Serversystem (Schritt 203).
-
Wenn
die Abreise-Lounge leer ist (die Antwort auf die Frage in Schritt 204 ist „Ja"), gelangt die Agenten-Anwende-Prozedur
zu einem Ende (Schritt 208).
-
Wenn
die Abreise-Lounge nicht leer ist (die Antwort auf die Frage in
Schritt 204 ist „Nein"), wird nachgeprüft, ob die
Antwort von dem Serversystem auf die IST-MITTLERAGENT-VERTRETEN-Anforderung „Ja" oder „Nein" ist (Schritt 205).
-
Wenn
die Antwort im Schritt 205 ist „Ja", wird der erste wartende Agent aus
der Wartereihe im Clientsystem (Schritt 207) gelöscht.
-
Wenn
die Antwort im Schritt 205 „Nein" ist, wird der erste wartende Agent
an das Serversystem mit einem MITTLERAGENTEN-HOCHLADEN-Signal (Schritt 206)
gesendet und dann der erste wartende Agent aus der Wartereihe im
Clientsystem (Schritt 207) gelöscht.
-
Der
gleiche Prozess wird wiederholt, solange die Abreise-Lounge nicht
leer ist.
-
Der
Server reagiert auf eine MITTLERAGENTEN-HOCHLADEN-Anfrage (Schritt 203)
mit dem Empfang und Speichern des Agenten, vorausgesetzt, dass der
Agent nicht bereits vorhanden ist. Er reagiert auf die IST-MITTLERAGENT-VERTRETEN-Anforderung durch
Signal „Ja" oder „Nein", das davon abhängt, ob
der Agent vorhanden oder nicht vorhanden ist (Schritt 205).
Abermals, der Algorithmus ist stabil.
- – Wenn der
Client keine Rückantwort
auf IST-MITTLERAGENT-VERTRETEN erhalten hat, veraltet die Client-Anforderung
einfach und der Client versucht es wieder.
- – Wenn
der Server keinen mit MITTLERAGENTEN-HOCHLADEN gesendeten Agenten
empfangen hat, wird er auf die nächste
IST-MITTLERAGENT- VERTRETEN-Anforderung „Nein" antworten und der
Agent wird erneut hochgeladen.
- – Weil
der Client immer vor dem Senden überprüft, um zu
sehen, ob der Agent vorhanden ist, kann der Aufwand einer vollständigen Agentenübertragung
vermieden sein, wenn sie nicht benötigt ist. Weil ein Agent nicht
erneut übertragen wird,
wenn er bereits vorhanden ist, kommt ein Fall, bei dem der Server
eine zweite Kopie empfängt
niemals vor.
- – Wenn
ein Client einen neuen Agenten überträgt, „weiß" der Server, dass
der Client den vorhergehenden Agenten gelöscht hat und dass der Server nun
verantwortlich für
die Verwaltung dieses Agenten ist.
-
Es
ist anzumerken, dass die Abreise-Lounge als eine Wartereihe mit
den an das Listen-Ende
hinzugefügten
neuen zu übertragenden
Agenten implementiert sein muss. Nur wenn Agenten in strikter Anordnung
hochgeladen sind, kann der Server annehmen, dass der erfolgreiche
Empfang eines neuen Agenten anzeigt, dass der Client nicht länger den vorhergehenden
Agenten verwaltet.
-
2.5 Passive Server
-
Im
einfachsten Model ist der Server gänzlich passiv. Er initiiert
niemals eine Verbindung, sondern reagiert nur auf die von den Clients
gesendete Nachrichten. Es gibt einige Vorteile dieser Vorgehensweise.
Erstens eliminiert es die Notwendigkeit, jegliche Serversoftware
auf dem Client laufen zu lassen, wodurch die Umsetzung vereinfacht
und die Last an dem Client reduziert ist. Zweitens ermöglicht es
den Server die Agenten an die Clients zu liefern ohne den Ort oder
sogar von der Existenz eines Clients zu wissen. Das vereinfacht
die Aufgabe des Servers, weil er keine vielfachen Clients zu verfolgen
braucht (die Clients stehen gewöhnlich
in einer Viele-zu-Einem-Beziehung
zum Server). Es vereinfacht auch die Aufgabe der Unterstützung mobiler
Clients, die sich mit dem Netzwerk periodisch, möglicherweise jedes Mal von
einem verschiedenen Ort verbinden. Schließlich macht es für den Server
einfach, eine Agenten-Routenplanung als einen Dienst an beliebige
Clients anzubieten, einschließlich
der Clients, die in den Server nicht spezifisch „konfiguriert" worden sind.
-
Obwohl
die Einfachheit der Betrachtungsweise viel Empfehlenswertes aufweist,
könnte
in der Praktik sogar ein System, in welchem der Server manchmal
zum Initiieren der Übertragungen
erforderlich war, ohne allzu große Schwierigkeiten angepasst
sein.
-
2.6 Server- und Clientfehler
-
Der
oben hervorgehobene Transfermechanismus bietet einen allgemeinen
guten Schutz gegen den während
einer Übertragung
vorkommenden Agentenverlust oder eine Zusammenhanglosigkeit. Eine
erstere Gefahr stellt die Möglichkeit
eines Server- oder Clientfehlers dar. Wenn ein Client ausfällt, kann
das System in einem zusammenhanglosen Zustand gelassen sein, weil
der Client keine Aufzeichnung über
jegliche vorhandene Agenten hat, während der Server diese Agenten
als im Client lokalisierte markiert hat.
-
Eine
Lösung
besteht in einem Quittierungsüberwachungs-Mechanismus,
mit dem ein Client seinen Zustand beim Starten dem Server mitteilen
kann. Der Client meldet die Anzahl und die Identität der Agenten,
die er hat, an den Server und der Server überprüft es gegen sein eigenes Model
des Netzwerkzustands. Im Fall, das sie nicht übereinstimmen, können Reparaturmaßnahmen
getroffen sein. Eine typische Reparatur kann sein, auf dem Server
den Flag für
den Agenten-Ort zum „Server" anstelle „Client" für diejenigen
Clients zu setzen, von welchen der Client keine Aufzeichnung hat.
Diese Agenten werden dann durch den Client wieder herunter geladen sein.
-
Ein
Absturz des Servers ist ernsthafter dadurch, dass er eine größere Anzahl
von Agenten einbezieht. Wiederherstellung ist auch durch die Tatsache
kompliziert, dass der Server keine Verbindungen initiieren kann.
Das Beste was er machen kann, ist alle Agenten als auf dem Server
vorhanden zu markieren und zu versuchen sie herunterzuladen, wenn der
Client das nächste
mal eine BEKOMME-NACHSTEN-MITTLERAGENTEN-Anforerung
sendet. Die Agenten, die bereits auf dem Client vorhanden sind, werden
abgewiesen sein, was es dem Server ermöglicht, seine Datenbank richtig
zu aktualisieren. Abhängig
von dem Zeitablauf des Absturzes kann es jedoch in Wirklichkeit
schlechter sein. Man betrachte den Fall des Agenten A, der anfänglich zum
Client C1 gesendet worden ist, dann zum Server zurückkehrte und
zum Client C2 durchpassierte. Wenn der Server ausgefallen und wiederhergestellt
ist, zeigt seine Datenbank – inkorrekt – dass der
Agent A in dem Client C1 sein soll. Er bietet daher den Agenten
dem Client C1 an, der ihn akzeptiert, weil in der Tat nicht vorhanden
ist. Das resultiert darin, dass es nun zwei Kopien von A im Netzwerk
gibt und das Ganze zusammenhanglos ist. Um dieses Problem zu überwinden,
kann es notwendig sein, an die Aufgaben einzigartige ID's zuzuweisen (wobei
eine Aufgabe die Übertragung und
Ausführung
eines Agenten auf einem Client ist) und die Clients zum Beibehalten
der Übertragungsprotokolle
zu bringen. Ein Übertragungsversuch
ist dann ein Tupel <A,
T> und ein Client
kann eine beliebige Agentenausführung
zurückweisen,
welche seine eigenen Aufzeichnungen als bereits stattgefunden anzeigen
und läuft
bis zur Fertigstellung. Mit der Abweisung der Übertragung durch den Client
C1 könnte der
Server seine Datenbank aktualisieren und versuchen den Agenten dem
Client C2 anzubieten. C1 würde
auch die Übertragung
abweisen, aber dieses mal aus einem anderen Grund – weil der
Agent vorhanden ist. Nach dem Empfang dieser Rückweisung wird der Server nun
wissen, wo der Agent sein soll und seine Datenbank ist wieder bezüglich dieses Agenten
korrekt.
-
2.7 Erweiterungen des Basismechanismus
-
Es
werden nun einige von den Wegen betrachtet, wie diese Vorgehensweise
erweitert sein kann. Wir werden insbesondere das Erweitern des Protokolls
für eine
größere Sicherheit,
der Möglichkeit
für eine
Peer-to-Peer-Routenplanung und eine „blinde Routenplanung" -Technik betrachten,
welche es den Agenten ermöglicht,
sich durch ein Netzwerk zu bewegen, dessen Topologie und Eigenschaften unbekannt
sind.
-
2.7.1 Fehlerprüfung
-
Eine
oben nicht diskutierte Eigenschaft ist jede Art einer Verifizierung
der übertragenen
Agentendaten (außer
der grundsätzlichen
Fehlerprüfung, die
durch die darunter liegende Transportprotokolle vorgesehen ist).
Die interessierende Frage hier ist nicht so sehr wie man die Korrektheit
des übertragenen
Agenten überprüft (im einfachsten
Fall sollten die Prüfsummen
entsprechend untersucht sein, um eine Verfälschung in der Übertragung
zu erfassen), sondern wie eine Verfälschung, wenn sie auftritt
zu handhaben ist.
-
Wenn
ein Server feststellt, dass ein Agent verfälscht worden ist, sollte er
nicht einfach den Agenten installieren und dem Client mitteilen,
dass der Agent empfangen worden ist. Zur gleichen Zeit kann er nicht
melden, dass der Agent nicht empfangen worden ist, worauf dann der
Client einfach versuchen wird, den Agenten wieder zu laden. Wenn
der Agent auf dem Client verfälscht
worden ist, anstatt bei der Übertragung,
könnte
das zu einer unendlichen Schleife führen und alle anderen ausgehenden Agenten
von diesem Client blockieren.
-
Eine
zweckmäßige Antwort
des Servers auf die IST-MITTLERAGENT-VERTRETEN-Anfrage ist ein „beschädigter_Agent"-Token. Der Client
kann dann in der Lage sein, den Agenten lokal zu rekonstruieren
oder zu reparieren, bevor er versucht ihn erneut zu senden. Wenn
das missglückt,
kann er den Agenten abbrechen und ein WIEDERHERSTELLE_AGENTEN_VON_BACKUP-Signal
zum Server senden, was in einem Neuerzeugen des Agenten auf dem
Server und dann erneuter Übertragung
zum Client resultieren würde.
-
Die
Situation, wenn der Client einen defekten Agenten von dem Server
empfängt
ist analog: er hat keine Mittel, einen Agenten sogleich abzuweisen, sondern
kann daran scheitern ihn zu installieren und ein Signal zum Server
auszusenden, welches ihn zur Korrektur aufruft – den Fehler zu melden, die
lokale Kopie des Agenten zu verifizieren, eine Kopie von dem Backup
zu erneuern, etc..
-
Die
Architektur muss daher in einer solchen Art und Weise aufgebaut
sein, um die Beschädigungen
der Agenten so bald wie möglich
zu erfassen versuchen und deren Ausbreitung zu verhindern. Aus diesem
Grund sind Kontrollen an beiden, dem Client und dem Server, zweckdienlich.
-
2.7.2 Peer-to-Peer-Routenplannung
-
Das
soweit diskutierte Model setzt eine Stern-Topologie mit einem einzelnen
Server voraus. Alle Agenten passieren durch den Server durch: ein Agent
auf seinem Weg von Client A zum Client B ist durch den Client A
zum Server übertragen
und dort gelassen, bis der Client B ihn aufruft.
-
Das
ist akzeptabel für
kleine Netzwerke, verursacht aber einen Flaschenhals. Der Ausfall
des zentralen Servers kann die Agenten gestrandet belassen und mit
der wachsenden Anzahl von Clients wird die Last an dem Server wachsen.
-
Eine
Vorgehensweise ist eine direkte Routenplanung zwischen den Clients
zu ermöglichen.
In diesem Fall würde
jeder Host beides sein, Client und Server. Wenn ein Host eine Anfrage
von einem anderen Host empfängt,
agiert er als Server; wenn er seine eigene Anfrage machen muss,
agiert er als Client.
-
Ein
Problem mit dieser Vorgehensweise ist dass sie erfordert, dass der
Clienthost den Ort des Hosts kennt, mit dem er zu kommunizieren
wünscht. Wir
setzen Agenten-Transport-Hosts
als notwendigen Fluss voraus – ein
gegebener lokaler Agenten-Host kann nicht immer die gleiche IP haben
oder sogar auf dem gleichen Computer ablaufen. Die Client-Hosts,
welche auf die Dienste anderer Clients zugreifen wollen, werden
offensichtlich Hilfe benötigen, sie
zu lokalisieren. Dafür
ist ein Domain-Namensdienst-(DNS)-System
erforderlich, der in der Lage ist, Client-Orte dynamisch quer über das
Netzwerk zu verbreiten.
-
2.8 Speichern-und-Fortsenden-Routenplanung
-
Eine
alternative Lösung
des Problems der Erzeugung einer skalierbaren Lösung für große Netzwerke ist ein Netzwerk
von Servern zu verwenden. Der Client lädt die Agenten zu seinem eigenen
direkten „Eltern"-Server. Dieser Server übernimmt
dann die Verantwortung für
die Routenplanung der Agenten weiter zu den anderen Servern, die
näher zu
deren letztendlichem Zielort sind. Wie das Standard-Internet-Routenplanen kann
das System durch das Ermöglichen
der Auswahl alternativer Routen für die Agenten durch die zwischenliegenden
Server basierend auf der Serververfügbarkeit ausfalltolerant gemacht
sein.
-
2.9 Dienst-basierende Routenplanung
-
Das
früher
beschriebene System involviert das Verwenden der Clientmaschinen,
welche durch Namen identifiziert sind. Einzelne Agenten sind von einer
Maschine zur anderen durch das Spezifizieren des Namens des Zielhosts
und alle Zielhosts sind angenommen, der Agentensteuerung bekannt
zu sein.
-
Eine
andere interessante Möglichkeit
ist die Route der Agenten durch Dienste zu bestimmen. Die Agenten-Aufgaben-Beschreibung
könnte
die Art der Ressourcen spezifizieren, die sie erfordert (und die Reihenfolge,
in welcher sie benötigt
sind, wo zutreffend) und der Server könnte die Verantwortung für das Routenplanen
des Agenten zu den Hosts übernehmen,
die jene Dienste bereitstellen können.
-
Das
schafft die Möglichkeit,
dass die „Dienste-Tabelle" – die Liste der die Dienste
bereitstellender Server – auch
dynamisch aufgebaut sein kann. Die Clientmaschinen machen deren
Verfügbarkeit
und die Dienste, die sie an die Server bereitstellen, bekannt, was
die verfügbaren
Ressourcen ausfindig macht und einen Lastenausgleich ausführt, wobei
die Aufgaben unter den verfügbaren
Clients verteilt werden. Es gibt sogar einen Spielraum für eine Art
Parallelität
mit den Agenten, die konfiguriert sind, an Unteraufgaben zu arbeiten
und die unter verschiedenen Clients verteilt sind.
-
Eine
weitere Fortführung
dieser Idee ist, den Eigentümern
lokaler Ressourcen zu ermöglichen,
für die
Benutzung dieser Ressourcen bezahlt zu werden. Der Netzwerk-Server sollte „Angebote" für die Kosten
der Bereitstellung spezifischer Typen von Diensten akzeptieren.
Die an dem Server ankommende Agenten würden dann zu den Clientmaschinen
entsprechend dem Pegel und dem Preis des angebotenen Dienstes durchgeleitet
sein. Der Server würde
für die
Gewährleistung
zuständig
sein, dass verschiedene, durch den Eigentümer des Agenten spezifizierte
Einschränkungen – die Ausführungsgeschwindigkeit,
das Gesamtbudget etc. – erfüllt sind.
-
3.5 Die Ausführung
-
Der
Vorschlag beschreibt ein System, in welchem ein Netzwerk von Clients
und Servern mobile ungebundene Agenten austauscht. Die Clientvorrichtungen
stellen die Gebundenheit durch die Mittel der Hardware her – die Sensoren,
Betätiger – durch
welche die Agenten die reale Welt wahrnehmen und interagieren können.
-
Die
Implementierung eines gebundenen mobilen Agentensystems ist auf
den Clientvorrichtungen basiert, die mit lenkbaren digitalen Kameras
ausgerüstet
sind, durch welche die Agenten Szenen aus der realen Welt wahrnehmen
können.
Jede Clientvorrichtung (eine Computerstation und verknüpfte Peripheriegeräte) ist
an zwei Kameras angeschlossen. Die Softwarekomponente ist durch
eine Agentenverwaltungs-Umgebung
bereitgestellt, die in der allgemeinen LISP-Programmiersprache implementiert
ist. Diese Umgebung bietet die Basisausführung der Agenten (d.h. den „festen" Agenten-Code), die
zum Steuern der Kamera, Interpretieren zurückgelieferter Bilder und zum
Interagieren mit anderen Agenten erforderlich ist. Zusätzlich legt
die Umgebung die Agenten-Interaktionen fest, ordnet den Zugriff
auf die Kameras und verwaltet die Kommunikation mit dem Server (einschließlich der
Einfügungs-
und Extrahierfunktionen, die im Abschnitt 1.2 diskutiert worden sind,
um die Agenten in und aus einer übertragbaren Form
zu konvertieren).
-
In
diesem Beispiel gibt es im Netzwerk drei Clientvorrichtungen und
einen Server. Der Server pflegt eine Datenbank von Agenten, in welcher
die Information über
den Agenten-Name, Erzeuger, einzigartige ID, Zieladresse, gegenwärtiger Aufenthaltsort – instandgehalten
ist. Jede Agentenaufzeichnung weist ebenso die vollständige fortbestehende,
durch den Client gesendete Beschreibung des Agenten auf. Die Kommunikation
zwischen dem Client und Server findet unter Verwendung des HTTP/1.1-Protokols
statt. Der Client ruft die CGI-(Common Gateway Interface/Allgemeine
Gateway-Schnittstelle)-Skripte auf dem Server auf, was den Server
veranlasst, Informationen zu empfangen oder zurück zusenden und seine Datenbank
zu aktualisieren.
-
Die
Agenten auf der Clientvorrichtung verwickeln einander in Interaktionen,
die wir „Ratespiel" nennen. Jeder Agent
erkennt eine einfache Szene (mittels der Kameras) und analysiert
das Bild, um die augenblicklichen Gegenstände zu identifizieren. Dann
versucht ein Agent die Aufmerksamkeit der anderen Agenten auf ein
spezifisches Objekt durch das Übertragen
eines Verknüpfungsausdrucks
(d.h. einer kurzen, aus einem oder mehreren Worten bestehenden Folge)
zu richten, der das interessierende Objekt einzigzutreffend identifiziert.
Der andere Agent zeigt dann das Objekt an, das er denkt beabsichtigt
gewesen ist. Wenn er das Objekt korrekt identifiziert hat, war das
Spiel erfolgreich.
-
Das
System ist für
die Experimente in der Entwicklung der Kommunikation, insbesondere
in der Ausbildung gemeinsamer (universeller) Sprachen und konzeptioneller
Aufbaustrukturen verwendet worden. Als Ergebnis des Erfolgs oder
des Fehlschlags können
die Agenten neue Worte lernen oder die Aufbaustruktur verfeinern,
die sie zum Interpretieren und Kategorisieren der Bilder verwenden,
die sie sehen. Die auf diese Weise gebildeten Vokabulare und Klassifizierungs-Aufbaustrukturen
begründen das
einzigartige „Wissen" eines Agenten, d.h.
den Agentenzustand. Die Teleübertragung
der Agenten besteht aus den Übertragungen
dieses Zustands zwischen den verschiedenen Maschinen des Netzwerkes.
Durch das Bewegen von Platz zu Platz quer über das Netzwerk können die
Agenten ihre zu verschiedenen Szenen, die von jedem der Clients
sichtbar sind, gelernte Aufbaustrukturen anwenden.
-
Die
vorliegende Erfindung ermöglicht
somit den autonomen Roboter-Agenten über ein Datenübertragungsnetz
teleübertragen
als auch gesichert, instandgehalten, aktualisiert oder auf anderen
physikalischen Seiten verwendet zu sein.