[go: up one dir, main page]

DE69808633T2 - Ablaufsteuerung für ein softwaresystem - Google Patents

Ablaufsteuerung für ein softwaresystem

Info

Publication number
DE69808633T2
DE69808633T2 DE69808633T DE69808633T DE69808633T2 DE 69808633 T2 DE69808633 T2 DE 69808633T2 DE 69808633 T DE69808633 T DE 69808633T DE 69808633 T DE69808633 T DE 69808633T DE 69808633 T2 DE69808633 T2 DE 69808633T2
Authority
DE
Germany
Prior art keywords
agent
task
agents
data
coordination
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69808633T
Other languages
English (en)
Other versions
DE69808633D1 (de
Inventor
Chi-Hang Lee
Tamajong Ndumu
Sama Nwana
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Application granted granted Critical
Publication of DE69808633D1 publication Critical patent/DE69808633D1/de
Publication of DE69808633T2 publication Critical patent/DE69808633T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G06F8/458—Synchronisation, e.g. post-wait, barriers, locks

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)
  • Stored Programmes (AREA)

Description

  • Die vorliegende Erfindung bezieht sich auf die Ablaufsteuerung bei Software-Systemen und findet Anwendung beispielsweise bei der Ablaufsteuerung von verknüpften Aufgaben einer Gemeinschaft von Software-Agenten.
  • Die Technologie der Software-Agenten hat sich in den letzten Jahren auf verschiedenen Gebieten entwickelt. Ein Software-Agent ist ein Computerprogramm, das als Agent für eine Gruppe, wie z. B. einen Anwender, einen Teil der Einrichtungen oder einen Geschäftsbetrieb, eingesetzt wird. Der Software-Agent verknüpft gewöhnlich Daten mit der Einheit, die er vertritt, er unterliegt einer Liste von Einschränkungen oder Bedingungen, durch die sein Verhalten festgelegt ist, und von größter Bedeutung ist es, dass er ausgestattet ist mit einer Entscheidungs-Software zum Fällen von Entscheidungen für die Einheit im Rahmen oder als Ergebnis von Einschränkungen und Bedingungen. Agenten handeln im Allgemeinen innerhalb eines Systems, und die Entscheidungen, die von einem Agenten gefällt werden, können dazu führen, dass das System aktiv wird. Bei Steuerungs-Software-Systemen führen derartige Entscheidungen zu Steuerungsaktivitäten, wie z. B. die Initiierung eines Verbindungsaufbaus in einem Kommunikationsnetz, das durch das System gesteuert wird.
  • Ein Agent, der innerhalb eines Systems agiert, besitzt im Allgemeinen auch Daten über das System, so dass er im Zusammenhang operieren kann.
  • Bei einer verteilten Umgebung können derartige Agenten kooperieren, um Steuerungsaktivitäten aufeinander abzustimmen und durchzuführen. Üblicherweise bilden derartige Agenten eine Agentenschicht, bei der jeder Agent mit einer Anzahl von externen Systemen (der Domain-Schicht), die sie steuern, überwachen oder verwalten, wie in Fig. 1 gezeigt, kommunizieren.
  • Ein System auf Basis von Agenten kann sehr komplex sein, da die Interaktionen zwischen den Agenten, die Entscheidungsfindungsprozesse individueller Agenten und die Interaktionen zwischen Agenten und den externen Systemen, die sie steuern, berücksichtigt werden müssen.
  • Verschiedene Typen von Agenten-basierenden Systemen werden in vielen Veröffentlichungen beschrieben, wie in denen, die in den Verhandlungen zu der First International Conference und der Second International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology erschienen sind. Diese wurden veröffentlicht von der Practical Application Company Ltd., Blackpool, Lancashire, 1996 bzw. 1997. Ein allgemeiner Übersichtsartikel der Agenten-basierenden Technologie ist erschienen von Hyacinth S. Nwana, "Software Agents: An Overview" in der Zeitschrift Knowledge Engineering Review, Band 11, Nr. 3, Seite 205-244.
  • Es gibt bereits bekannte Arten, um Software-Agenten herzustellen. Als Beispiel seien die folgenden Veröffentlichen genannt, in denen Arrangements für das Herstellen von Agenten beschrieben werden:
  • 1. Agent Building Environment (ABE) von IBM, was im Wesentlichen eine C++-Klassenbibliothek ist [http://www.networking.ibm.com/iag/iagwatsn.htm]. ABE ist ein Tool-Kit, mit dem sich die Konstruktion von Agentenbasierenden Applikationen vereinfachen lässt oder man Hilfe bekommt beim Hinzufügen eines Agenten zu existierenden Applikationen. Dieses Tool-Kit findet Anwendung bei relativ trivialen "Schnittstellen"-Agenten oder unabhängig arbeitenden Agenten. Beispielsweise kann ein Agent hier einer sein, der den Wert von Aktien auf dem Finanzsektor überwacht und seinen Anwender alarmiert (z. B. über Paging), wenn der Wert unter einen bestimmten Schwellenwert fällt. ABE beschreibt weder Einrichtungen für den Aufbau von Systemen mit mehreren Agenten noch Einrichtungen für den Aufbau von mehr als einem Agententyp.
  • 2. SODABOT von dem MIT [http://www.ai.mit.edu/people/sodabot/sodabot.html], Telescript und Odyssey von General Magic [http://www.genmagic.com] und Aglets von IBM [http://www.trl.ibm.co.jp/aglets] sind weitere Beispiele. Diese arbeiten in anderen Umgebungen, wodurch die Konstruktion von "mobilen" Agenten-basierenden Anwendungen vereinfacht wird. Jedoch sind sie auch nicht viel mehr als Sprachen, die vergleichbar sind mit "Java" von Sun Microsystems Inc., und bieten keine speziell weiterentwickelten Arrangements für das Herstellen von Agenten.
  • Vielleicht eher relevant für Ausführungsformen der vorliegenden Erfindung ist die Agenten-Herstellungsoberfläche von der University of Toronto. Von Mihai Barbuceanu und Mark. 5. Fox wird in "The Architecture of an Agent Building Shell", 1996 in Intelligent Agents II, Berlin, Spinger-Verlag, 1037, 235-250, Herausgeber Wooldridge, M., Muller, J. und Tambe, M. dieses beschrieben. Beschrieben wird eine Agenten-Herstellungsoberfläche, "die verschiedene wieder verwendbare Schichten für Sprache und Bearbeitungen in Bezug auf Agenten-Herstellungssysteme bieten: Koordinierung und Kommunikationssprachen, Wissensmanagement auf der Basis von Beschreibungslogik, Gemeinschaftsinformationsverteilung, Organisationsmodellierung und Konfliktmanagement" (Seite 235). Diese Entwicklung schreitet nach wie vor schnell fort und hat noch zu keiner praktischen Ausführungsform geführt, wobei viel Aufwand bezüglich theoretischer Fragestellungen wie Beschreibungslogik, nicht monotone Logik und das Ausdehnen von KQML zum Entwickeln der Sprache "COOL" aufgewendet wurde. Die Entwicklung der vorliegenden Erfindung hebt sich hiervon wesentlich dadurch ab, dass ein Tool-Kit zum Definieren und Erzeugen von realen Agentenbasierenden Steuerungs-Software-Programmen für tatsächliche Applikationen erzeugt wird und sie weit über die allgemein akademische Fragestellung, die der Arbeit aus Toronto zugrunde liegt, hinausgeht.
  • Ein spezielles Problem taucht bei "Gemeinschafts-" Agenten auf. Gemeinschaftsagenten sind eine Gruppe von Agenten, die miteinander kooperieren, um ihre Aktivitäten bei der Bearbeitung einer speziellen Aufgabe zu koordinieren. Eine derartige Kooperation kann notwendig werden, da Wissen, Ressourcen oder Arbeitsleistung über die Umgebung oder über die Agenten in dem System verteilt sind. Das Problem bei Gemeinschaftsagentensystemen ist die Notwendigkeit, ihre Aktivitäten auf problemabhängige und kontextabhängige Art zu koordinieren.
  • Ein Beispiel für Gemeinschaftsagentensysteme, in diesem Fall bei der Verwaltung von Kommunikationsnetzen, wird in der internationalen Patentanmeldung WO95/15635 des gleichen Anmelders beschrieben.
  • Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Software-Modul für ein Software-System für verteilte Steuerung, Überwachung und/oder Verwaltung eines Prozesses oder einer Vorrichtung mit:
  • (i) einer Kommunikationseinrichtung zum Kommunizieren mit anderen gleichartigen Software-Modulen,
  • (ii) einer Koordinierungseinrichtung für das Koordinieren der Zuordnung von Tasks unter Software-Modulen mit den anderen gleichartigen Software-Modulen,
  • (iii) einem Datenspeicher oder Zugriff auf einen Datenspeicher zum Speichern von Task-Definitionen, einschließlich Zeitdaten, die die Task-Ausführungszeit angeben, und
  • (iv) einer Ablaufsteuerungseinrichtung für die Ablaufsteuerung eines Tasks, wobei die Ablaufsteuerungseinrichtung so ausgelegt ist, dass Daten gespeichert werden, die unter der wenigstens einen Task-Definition ausgewählt wurden, einschließlich der Zeitdaten für die jeweilige Task-Definition oder Definitionen, die dem Task entsprechen,
  • geschaffen, wobei die Koordinierungseinrichtung ausgelegt ist, um eine Anfrage, dass ein Task ausgeführt wird, zu empfangen, wobei der Task die Verwendung einer oder mehrerer Ressourcen umfasst, und
  • die Ablaufsteuerungseinrichtung so betrieben werden kann, dass in Abhängigkeit von dem Empfang der Anfrage identifiziert wird, ob dem Modul die oder jede der angeforderten Ressourcen zur Verfügung steht oder nicht, und wenn angenommen wird, dass die oder jede der angeforderten Ressourcen zur Verfügung stehen, den Task zu planen.
  • Diese Ablaufsteuerungseinrichtung kann von dem Software-System zum Zuordnen von Tasks unter mehreren Software-Modulen bei der Steuerung, Überwachung und/oder Verwaltung von einem Prozess oder einer Vorrichtung eingesetzt werden.
  • Die Ablaufsteuerungseinrichtung für ein Software-Modul kann Daten von mehr als einer Task-Definition speichern, wobei die Daten so angeordnet werden, dass die Reihenfolge festgelegt wird, in der das Modul den relevanten Task beim Betrieb des Systems steuert oder ausführt.
  • Vorzugsweise kann die Ablaufsteuerungseinrichtung die Task-Daten zusammen mit einem Zustandsindikator speichern, der aus wenigstens zwei alternativen Zuständen wie "versuchsweise" und "sicher" ausgewählt wird. Der Zustandsindikator kann von der Ablaufsteuerungseinrichtung zum Festlegen der Art der Verwaltung solcher Daten verwendet werden. Beispielsweise kann die Ablaufsteuerungseinrichtung einen Zeitablauf in Bezug auf Task-Daten mit dem Zustand "versuchsweise" festlegen, nach welchem die Daten gelöscht werden oder durch nachfolgende ankommende Daten überschrieben werden können.
  • Besonders vorteilhaft kann die Ablaufsteuerungseinrichtung Ressourcen durch Abspeichern von Daten von mehr als einer Task- Definition überbuchen, wobei das Abspeichern von Daten zeitliche Beschränkungen überlappt.
  • Ausführungsformen der Erfindung beziehen sich außerdem auf eine Software-Herstellungsumgebung für das Herstellen eines Software- Systems für den Einsatz beim Steuern, Überwachen und/oder Verwalten eines Prozesses oder einer Vorrichtung, wobei die Umgebung wenigstens ein Software-Modul, Vorrichtungen für das Aufnehmen von Daten zum Laden einer Kopie des Moduls für die Verwendung in dem Software-System und Vorrichtungen für das Erzeugen des Software-Systems mit wenigstens zwei der geladenen Module umfasst.
  • Jedes geladene Software-Modul umfasst vorzugsweise einen kooperativen Software-Agenten. Es hat daher wenigstens eine Kooperations- oder Koordinierungsstrategie, die beispielsweise als Regel oder Algorithmus vorliegt. Die wenigstens zwei geladenen Module können gemeinsam eine Multiagentengemeinschaft für die Steuerung, Überwachung und/oder Verwaltung des Prozesses bilden.
  • Ausführungsformen der vorliegenden Erfindung können Herstellungsumgebungen für Gemeinschaftsagenten schaffen, mit denen Systementwickler eine Gruppe von Agenten, die in einem System zusammenarbeiten, definieren können, können sie in Beziehung zueinander setzen, auf welche Art sie es auch wollen, können sie mit Koordinierungsmöglichkeiten füllen, die für die Probleme geeignet sind, die mit den Agenten gelöst werden sollen, können Verbindungen von den Agenten zu dem Prozess oder der Vorrichtung herstellen, die mit ihnen kommunizieren müssen, von ihnen gesteuert werden müssen oder beispielsweise aktualisiert werden müssen, und können Software-Code für die Agenten erzeugen.
  • Es ist nicht notwendig, dass alle geladenen Software-Module die gleichen sind. Tatsächlich wird gewöhnlich wenigstens eins von ihnen andere Datensätze enthalten, da sie andere Einheiten darstellen. Vorzugsweise stellt die Software-Herstellungsumgebung mehr als eine Kooperations- oder Koordinierungsstrategie zur Verfügung oder wenigstens den Zugriff darauf. Bei der Verwendung der Umgebung kann der Entwickler dann eine andere Kooperations- oder Koordinierungsstrategie für wenigstens ein Modul laden, das in dem System eingesetzt wird.
  • Besonders bevorzugt ist das Software-Modul in der Lage, mehr als eine Kooperations- oder Koordinierungsstrategie aufzunehmen, so dass seine Kooperation oder Koordinierung in dem System flexibel bleibt. Das bedeutet, es kann gemäß der einen Kooperation oder Koordinierungsstrategie zu einem Zeitpunkt operieren und gemäß einer anderen Kooperation oder Koordinierungsstrategie zu einem anderen Zeitpunkt.
  • Das Software-Modul kann auch oder stattdessen in der Lage sein, gleichzeitig gemäß mehr als einer Kooperations- oder Koordinierungsstrategie zu operieren.
  • Ein Software-System für den Einsatz bei Steuerung, Überwachung und/oder Verwaltung eines Prozesses oder einer Vorrichtung, wie es durch ein System gemäß der Erfindung verwendet wird, kann wenigstens zwei Software-Module umfassen, wobei jedes Modul Daten und/oder Prozessinformation umfasst mit:
  • (i) Organisationsdaten bezüglich einer Modulbeziehung und
  • (ii) ausführbarer Software mit einer Kooperations- oder Koordinierungsstrategie, beispielsweise in Form einer Regel oder eines Algorithmus,
  • wobei im Betrieb ein Modul die ausführbare Software für den Einsatz auswählt, indem mit einem anderen Software-Modul über Task- Zuweisung verhandelt wird, wobei die Auswahl wenigstens teilweise durch die Organisationsdaten festgelegt wird.
  • Zusätzlich können Aspekte der Erfindung visualisiert werden durch ein Visualisierungsarrangement für den Einsatz in einem Software- System zum Steuern, Überwachen oder Verwalten eines Prozesses oder eines Arrangements, wobei das Software-System mehrere Software-Module umfasst mit Vorrichtungen zum Kommunizieren untereinander, wobei das Visualisierungsarrangement Vorrichtungen zum Speichern und Bereitstellen von Anzeigekommunikationsinstanzen bzw. Daten mit Bezug auf ein einzelnes, ausgewähltes Software-Modul, und Einrichtungen zum Speichern und Bereitstellen von Anzeigekommunikationsinstanzen bzw. Daten mit Bezug auf Dinge zwischen wenigstens zwei der besagten Software-Module umfasst.
  • Ein Debug-Arrangement, das es dem Anwender ermöglicht, sich Kommunikationen anzeigen zu lassen, die sich entweder auf ein einzelnes Software-Modul oder eine Gemeinschaft von kommunizierenden Software-Modulen bezieht, oder auf beides, kann einen sehr effektiven Debug-Mechanismus für den Anwender darstellen.
  • Vorzugsweise ist das Visualisierungsarrangement mit Einrichtungen zum Erlangen von Organisationsdaten bezüglich der Software- Module und mit Einrichtungen für das Verarbeiten von Kommunikationsinstanzen oder Daten vor der Anzeige versehen, so dass die Kommunikationsinstanzen oder die darauf bezogenen Daten auf eine Art dargestellt werden können, die durch die Organisationsdaten festgelegt wird.
  • Es ist außerdem von Vorteil, wenn das Visualisierungsarrangement mit Einrichtungen versehen ist, um auf Daten oder ausführbaren Software-Code in einem oder mehreren der Software-Module zuzugreifen, die Daten oder den Code herunter zu laden, die Daten oder den Code für Modifizierungen bereitzuhalten und modifizierte Daten oder Code in das Software-Modul zu laden. Die Daten oder der Code können modifiziert werden durch Editorvorrichtungen in dem Visualisierungsarrangement selbst oder durch separate Editorvorrichtungen.
  • Man sollte beachten, dass es mehrere neue und erfinderische Merkmale der Ausführungsformen der im Folgenden beschriebenen vorliegenden Erfindung gibt, die nicht notwendigerweise alle oben genannt wurden, und wenigstens einige von ihnen unabhängig von anderen Aspekten der besagten Ausführungsformen anwendbar sind.
  • Es sollte außerdem beachtet werden, dass in einer verteilten Umgebung Software-Module in der Praxis nicht selbst Daten oder Software enthalten, wie z. B. Kooperations- oder Koordinierungsstrategien, die oben erwähnt wurden. Sie können stattdessen einfach Zugriff auf sie haben, z. B. zum Laden zu der relevanten Laufzeit. Diese Arrangements sollen durch das Vorangehende mit abgedeckt werden.
  • Ein Agenten-Herstellungssystem, dessen Tool-Kit als "Collaborative Agent Building System", CABS, bekannt ist, wird im Folgenden als Beispiel eine Ausführungsform der vorliegenden Erfindung beschrieben, wobei Bezug genommen wird auf die beigefügten Zeichnungen, bei denen:
  • Fig. 1 ein Agenten-basierendes Steuerungssystem, das mit CABS hergestellt wurde, in Kommunikation mit externer Hardware und/oder Software zeigt,
  • Fig. 2 schematisch die Architektur eines Software-Moduls zeigt, das einen Agenten für verteilte Steuerung, Überwachung und Verwaltung eines Systems darstellt,
  • Fig. 3 eine CABS-Plattform für das Herstellen eines Agenten nach Fig. 2 zeigt,
  • Fig. 4 ein Schichtmodell eines Agenten in Form einer ersten Charakterisierung zeigt,
  • Fig. 5 ein Flussdiagramm mit Schritten bei der Konstruktion eines Agenten unter Verwendung der Plattform aus Fig. 3 zeigt,
  • Fig. 6 mögliche organisatorische Beziehungen zwischen mit CABS hergestellten Software-Agenten zeigt,
  • Fig. 7 Daten zeigt, die unter Verwendung eines Debug-Tools für das Debuggen eines mit CABS hergestellten Agenten-basierenden Steuerungssystems gewonnen wurden,
  • Fig. 8 ein Debug-Szenario zeigt, bei dem das Debug-Tool für das Debuggen eines CABS-Agentensystems verwendet wird,
  • Fig. 9 eine Zusagetabelle für einen Agenten nach Fig. 2 zeigt,
  • Fig. 10 ein Debug-Visualisierungssystem zum Einsatz im Zusammenhang mit dem Agenten-basierenden Steuerungssystem nach Fig. 1 zeigt,
  • Fig. 11 ein Flussdiagramm eines Koordinierungsprozesses für den Einsatz zwischen Agenten in einem System nach Fig. 1 zeigt,
  • Fig. 12 schematisch ein Beispiel eines Bildschirm-basierenden Ausgangssignals eines "Gesellschafts-Tools" des verwendeten Visualisierungssystems zeigt,
  • Fig. 13 schematisch ein GANTT-Diagramm als Beispiel eines "Report-Tools" des verwendeten Visualisierungssystems zeigt,
  • Fig. 14 schematisch ein Beispiel eines Bildschirm-basierenden Ausgangssignals eines "Mikro-Tools" des verwendeten Visualisierungssystems zeigt, und
  • Fig. 15 schematisch ein Beispiel eines Bildschirm-basierenden Ausgangssignals eines "Statistik-Tools" des verwendeten Visualisierungssystems zeigt.
  • In der folgenden Beschreibung wird ein Agenten-basierendes System im Zusammenhang mit einer Umgebung für seine Herstellung beschrieben. Die Planungs- und Ablaufsteuerungsaspekte, die besonderer Gegenstand der vorliegenden Anmeldung sind, werden beispielsweise im Abschnitt 2.5 unter "Planungs- und Ablaufsteuerung 220" beschrieben.
    • 1. EIN AGENTEN-BASIERENDES SYSTEM, DAS MIT DEM CABS-TOOL-KIT HERGESTELLT WURDE
  • Das System nach Fig. 1 ist ein Beispiel eines Agenten-basierenden Systems für den Einsatz bei Kommunikationsaufgaben. Eine CABS- Plattform kann jedoch verwendet werden für die Herstellung fast jeden Agenten-basierenden Systems, wo Software-Agenten sowohl mit anderen Agenten kollaborieren müssen als auch Tasks abarbeiten müssen, die zu einer Ausgabe führen. Die Ausgabe in dem Beispiel in Fig. 1 ist die Steuerung einer Dienstleistung mittels Komponenten eines Kommunikationssystems. Die Ausgabe kann z. B. entweder eine Datenerzeugung oder eine Steuerung eines Produktionsprozesses sein, weitere Beispiele werden in dieser Beschreibung folgen.
  • Das System umfasst eine Gruppe von Klassen (im Sinne der Objektorientierten Technik), die in der Java-Programmiersprache implementiert sind, was es ermöglicht, dass es auf verschiedenen Hardware-Plattformen laufen kann. Java ist eine geeignete Sprache für das Entwickeln von Multi-Agenten-Applikationen, da es Objektorientiert ist und mehrfach vernetzt ist, und jeder Agent kann aus vielen Objekten und verschiedenen Verknüpfungen bestehen. Man hat außerdem den Vorteil, dass es auf verschiedene Betriebssysteme portierbar ist und außerdem eine umfangreiche Gruppe von Klassenbibliotheken bereitstellt, die exzellente Netzkommunikationsmöglichkeiten beinhalten.
  • Die Klassen des Systems können in drei primäre funktionelle Gruppen unterteilt werden - eine Agenten-Komponentenbibliothek, ein Agenten-Herstellungs-Tool und eine Agenten-Visualisierungs-Tool.
  • Die Agenten-Komponentenbibliothek umfasst Java-Klassen, die die "Herstellungsblöcke" der individuellen Agenten bilden. Diese implementieren zusammen die Funktionalität auf "Agenten-Ebene" für einen kooperationsfähigen Agenten. Als Beispiel bei Kommunikationsvorgängen, Bewertung, Agenten-Kooperation und die Fähigkeit, an Ziel orientierten Interaktionen zwischen Agenten teilzunehmen, bietet das System:
  • - eine Leistungsbasierende Agenten-Kommunikationssprache,
  • - Wissensdarstellung und Speicherung mittels Ontologien,
  • - ein asynchrones, Sockel basierendes Nachrichtenübermittlungssystem,
  • - ein Planungs- und Ablaufsteuerungssystem,
  • - ein Event-Modell zusammen mit einer Applikationsprogrammierungsschnittstelle (Applications Programming Interface, API), mit dem es den Programmierern ermöglicht wird, Änderungen im internen Zustand eines Agenten zu überwachen und sein Verhalten extern zu steuern,
  • - eine Koordinierungsmaschine,
  • - eine Bibliothek von vordefinierten Koordinierungsprotokollen;
  • - eine Bibliothek von vordefinierten organisatorischen Beziehungen.
  • Es weist außerdem Hilfsagenten vom bekannten allgemeinen Typ auf, wie Namensserver, Vereinfachungs-(klassifizierte Ordner) und Visualisierungseinrichtungen.
  • Vorzugsweise werden bei Komponenten des Systems Standardtechnologien eingesetzt wo immer möglich, wie z. B. die Kommunikation durch TCP/IP-Sockel unter Verwendung einer Sprache, die auf der Wissensabfragesprache (Knowledge Query Management Language, KQML) basiert.
  • Diese Aspekte werden im Folgenden genauer beschrieben.
  • Im Folgenden werden die Begriffe "Ziel", "Task" und "Job" verwendet. Diese werden wie folgt definiert:
  • ein "Ziel" ist eine logische Beschreibung einer Ressource (Tatsache), von der erwartet wird, dass ein Agent sie produziert;
  • ein "Task" ist eine logische Beschreibung eines Prozesses, der keine oder mehrere Ressourcen verwendet und eine oder mehrere Ressourcen erzeugt, und
  • ein "Job" bezieht sich auf ein Ziel oder einen Task in Abhängigkeit vom Kontext. (Beispielsweise bezieht sich der Ausdruck im Kontext der Visualisierungseinrichtung 140, die unten unter der Überschrift "5. DEBUGGEN UND VISUALISIEREN" beschrieben wird, auf Ziele.)
  • In Fig. 1 umfasst ein Agenten-basierendes System 100, das mit Hilfe der CABS-Plattform aufgebaut wurde, einen Satz von Kommunikationsagenten 105, 110, 115, 120 zum Steuern/Darstellen von Einheiten in einem externen System zusammen mit einem Satz von Infrastrukturagenten 135, 140, 145.
  • Die Agenten des Systems 100 kommunizieren miteinander unter Verwendung eines Netzes, wie z. B. einem lokalen Netz LAN 150. Sie können alternativ kommunizieren, indem sie Kapazitäten in dem externen System selbst nutzen.
  • Außerhalb des Agentensystems 100 gibt es ein Kommunikationssystem 125 mit verschiedenen Komponenten. Innerhalb des externen Systems 125 gibt es dort z. B. ein Terminal 155, eine Software- Applikation für die Authentifizierung 160 und verschiedene Netzwerkverbindungen 165, 170, 175. Eine der Netzwerkverbindungen 175 ist ausgestattet mit einem externen Agenten 180, der von dem Agenten-basierenden System 100 separiert ist, das mit der CABS- Plattform aufgebaut wurde.
  • Die CABS-Agenten 105, 110, 115, 120 haben verschiedene Tasks auszuführen und Ressourcen zu steuern. Die Agenten müssen sowohl miteinander kooperieren als auch Tasks ausführen. Die Tasks umfassen diejenigen, die direkt beim Bereitstellen von Diensten für einen Anwender involviert sind, aber sie können auch Hilfs-Tasks beinhalten.
  • Wenn beispielsweise bei dem gezeigten System der Nutzer Daten auf das Terminal 155 herunterladen möchte, hat der Anwender-Agent 110 den Task, eine Authentifizierungsressource 160 bereitzustellen, der Terminal-Agent 105 den Task, ausreichend Speicherplatz für die Daten bei dem Terminal 155 bereitzustellen, und die Netzwerkagenten 115, 120 den Task, Netzbrandbreite bereitzustellen, um die Daten zu dem Terminal 155 zu übertragen. Die Netzwerkagenten 115, 120 müssen außerdem miteinander kollaborieren, beispielsweise beim Konkurrieren miteinander in Bezug auf Kosten, Zeit und Qualität des Dienstes, um die Netzbandbreite bereitzustellen.
  • Nach einem Abschnitt der Agentenkooperation führen die Agenten 105, 110, 115, 120 die Tasks aus, indem Steuerungsnachrichten an die Komponenten des Systems 125, das durch sie gesteuert wird, ausgegeben werden. Der Terminalagent 105 muss daher das Terminal 155 so Steuern, dass die vereinbarte Speicherkapazität bereitgestellt wird. Der Anwenderagent 110 muss die Authentifizierungsapplikation 160 auslösen. Eine der zwei Netzwerkagenten 120 muss die Bandbreite, auf die man sich bei der Kooperation geeinigt hat, an der jeweiligen Netzwerkverbindung 170 bereitstellen.
  • Bei ihren Aktivitäten haben die Agenten 105, 110, 115, 120 Zugriff auf gemeinsame Ressourcen innerhalb des CABS-Agentensystems 100 einschließlich beispielsweise der Infrastrukturagenten, die oben genannt wurden, eines Namensserveragenten 135, eines Debug-/ Fehleridentifizierungsagenten 140, der hier als Visualisierungseinrichtung bezeichnet wird, und eines Vereinfachungsagenten 145.
  • Der separate Agent 180, der eine Netzwerkverbindung 175 des externen Systems 125 steuert, kann einen Back-up für die Netzwerkagenten 115, 120 des CABS-Systems 100 für den Fall darstellen, dass die Bandbreite durch die Netzwerkverbindungen nicht zur Verfügung steht, die direkt durch die mit CABS aufgebauten Agenten 115, 120 gesteuert werden. In diesem Zusammenhang ist es klar, dass die CABS-Agenten 105, 110, 115, 120 eine gemeinsame Kommunikationssprache mit dem separaten Agenten X 180 sprechen müssen, zusammen mit irgendeiner Art von Koordinierungsprotokoll. Die Kommunikation mit dem externen Agenten 180 beispielsweise zum Anfordern von Kapazitäten bei seiner Verbindung als Back-up-Ressource, kann als ein Task irgendeinem oder mehreren der CABS-Agenten zugeordnet werden.
    • 2. STRUKTUR EINES EINZELNEN AGENTEN, DER MIT DER CABS-PLATTFORM/TOOL-KIT AUFGEBAUT WURDE
  • In Fig. 2 umfasst die interne Struktur eines einzelnen, kooperationsfähigen Agenten, der mit CABS aufgebaut sein kann, für die verteilte Steuerung, Überwachung und Verwaltung von externen Systemen 240:
  • (i) eine Mailbox 200 oder eine Kommunikationsvorrichtung, die die Kommunikation zwischen dem Software-Modul und anderen internen oder anderen Software- oder Hardware-Systemen besorgt;
  • (ii) einen Nachrichtenverwalter 205, der Nachrichten verarbeitet, die von der Mailbox 200 kommen, und sie an weitere Komponenten in dieser Architektur weiterleitet;
  • (iii) eine Koordinierungsmaschine und ein Bewertungssystem 210 zur Entscheidungsfindung bezüglich der Ziele der Agenten, die diese verfolgen sollten, wie sie sie verfolgen sollten, wann sie sie aufgeben sollten etc. und wie die Aktivitäten der Agenten in Bezug auf andere CABS-Agenten in dem System zu koordinieren sind. Die Koordinierungsmaschine und das Bewertungssystem enthalten beide eine Maschine und eine Datenbank von Koordinierungsprozessen 255;
  • (iv) ein Kenntnisstandmodell 215, das das Wissen des Agenten über Fähigkeiten anderer Agenten in den System beschreibt;
  • (v) eine Planungs- und Ablaufsteuerung 220, welche die Tasks organisiert und plant, die der Agent steuert, überwacht oder verwaltet in Abhängigkeit von Entscheidungen durch die Koordinierungsmaschine und das Bewertungssystem 210 und die Ressourcen und Tasks, soweit sie verfügbar sind, um gesteuert, überwacht und/oder durch den Agenten verwaltet zu werden;
  • (vi) eine Ressourcendatenbank 225 mit logischen Beschreibungen der momentan für den Agenten verfügbaren Ressourcen, der eine Schnittstelle zwischen der Datenbank und externen Systemen darstellt, so dass die Datenbank externe Systeme über die Verfügbarkeit oder Ressourcen befragen kann und externe Systeme informieren kann, wenn Ressourcen von dem Agenten nicht länger benötigt werden und externe Systeme auf eigene Initiative Ressourceneinträge in der Datenbank hinzufügen, löschen oder modifizieren können, so dass damit Änderungen bezüglich des Verhaltens des Agenten initiiert werden;
  • (vii) eine Task-Datenbank 230, die logische Beschreibungen von Tasks enthält, soweit verfügbar für Steuerung, Überwachung und/oder Verwaltung durch den Agenten; und
  • (viii) einen Ausführungsmonitor 235, der Tasks externer Systeme startet, stoppt und überwacht, die zur Ausführung oder Beendigung durch den Planungs- und Ablaufsteuerung vorgesehen sind, und der die Koordinierungsmaschine und das Bewertungssystem 210 über erfolgreiche und außerordentliche Terminierungsbedingungen der von ihm überwachten Tasks informiert.
  • Wenn der Agent hergestellt wird, verwendet der Entwickler verschiedene Editierprogramme, die von CABS bereitgestellt werden, um Beschreibungen zu erzeugen, die notwendig sind für die verschiedenen Module der Architektur des Agenten, einschließlich der Koordinierungs- und der Bewertungsmaschine 210, des Kenntnisstandmodells 215, der Ressourcendatenbank 225 und der Task-Datenbank 230.
  • Im Betrieb wird der Agent durch Ereignisse gesteuert, die eine Änderung des Zustands des Agenten herbeiführen. Der Agent lässt ein Ereignismodell ablaufen, das durch die Komponentenbibliothek des Systems bereitgestellt wird, um diese internen Änderungen zu überwachen und sie so über eine API für den Programmierer sichtbar zu machen. Es gibt drei mögliche externe Ereignisquellen (siehe Fig. 2): externe Nachrichten von anderen Agenten in die Mailbox 200 (z. B. Anfragen nach einem Dienst), externe Ereignisse, ausgelöst von dem Ausführungsmonitor 240, der das externe System überwacht (z. B. durch verschiedene Sensoren), und externe Ereignisse, ausgelöst von Änderungen in der Ressourcendatenbank 225. Wenn beispielsweise ein Ereignis eintritt, durch das der Zustand des Agenten geändert wird, wie zum Beispiel der Verlust einer Ressource, ist es notwendig, dass seine Aufzeichnungen entsprechend aktualisiert werden.
  • Eine Änderung des Zustands kann eine Abfolge von Aktivitäten innerhalb und/oder außerhalb des speziellen Agenten bewirken. Zum Beispiel würde der Verlust einer Ressource (z. B. durch Fehler), die für irgendeinen Dienst notwendig ist, es erforderlich machen, dass das Planungs- und Ablaufsteuerungsmodul 220 versucht, eine andere Ressource zu sichern, die den gleichen Job machen könnte. Bei Erfolg können alle Aktivitäten als Ergebnis des Verlusts der Ressource innerhalb des Agenten enthalten sein. Wenn das Planungs- und Ablaufsteuerungsmodul 220 jedoch keine andere lokale Ressource finden kann, wird die Koordinierungsmaschine und das Bewertungssystem 210 aufgerufen, um zu versuchen, entweder die Ressource von einem anderen Agenten zu sichern oder an den Task zu delegieren/abzugeben, der es erforderlich machte, diese Ressource einem anderen Agenten zuzuordnen. In beiden Fällen fordert die Koordinierungsmaschine und das Bewertungssystem 210 die Mailbox 200 über den Nachrichtenverwalter 210 auf, eine Nachricht zu erzeugen und sie an ausgewählte andere Agenten abzuschicken. Auf diese Art wird die Koordinierung von Aktivitäten mit anderen Agenten realisiert.
  • Weitere Einzelheiten der Komponenten der Agentenstruktur zur Unterstützung des obigen Mechanismus werden im Folgenden erläutert.
    • 2.1 Mailbox 200
  • Die Mailbox 200 wird als ein vielfach verknüpftes Model mit Agentenkommunikation über TCP/IP-Sockel implementiert. Eine Verknüpfung zur Ausführung, die Server-Verknüpfung, lauscht fortwährend auf und akzeptiert ankommende TCP- Verbindungsanfragen von anderen Agenten, empfängt irgendwelche ankommenden Nachrichten von diesen Agenten und legt die empfangenen Nachrichten auf einen Eingangsstapel (Schlange). Eine zweite Verknüpfung, die Client-Verknüpfung, öffnet die TCP- Verbindungen mit anderen Agenten zum Ausliefern der Nachrichten. Die Nachrichten, die ausgeliefert werden sollen, werden aus einem Ausgangsstapel (Schlange) geholt. Wenn andere Module des Agenten es erforderlich machen, dass eine Nachricht an einen anderen Agenten ausgeliefert wird, werden diese Nachrichten auf den Ausgangsstapel in der Mailbox gelegt, damit sie später durch die Client- Verknüpfung mitgenommen werden können. Die Nachrichtensprache bei der aktuellen Implementierung ist die KQML- Agentenkommunikationssprache (Tim Finin, Yannis Labrou und James Mayfield, 1997, KQML as an Agent Communication Language, in Bradshaw, J. (Herausgeber), Software Agents, Cambridge Mass., MIT Press, Kapitel 14, Seite 291-316 J.
  • Die Mailbox-Technik ist nahezu Standard und könnte implementiert werden unter Verwendung eines anderen Kommunikationsprotokolls als TCP/IP, wie zum Beispiel Electronic Mail und HyperText Transfer Protokoll HTTP.
    • 2.2 Nachrichtenverwalter 205
  • Der Nachrichtenverwalter 205 fragt kontinuierlich den Eingangsstapel der Mailbox 200 nach neuen ankommenden Nachrichten ab, die er an andere relevante Komponenten des Agenten für die einzelne Verarbeitung weiterleitet. Dieses Modul basiert auf einer Standardtechnik mit einer kontinuierlich laufenden Verknüpfung, die die Mailbox 200 abfragt, und sie hat Zugriff auf Ankopplungsstellen aller größeren Komponenten des Agenten für das Weiterleiten von Nachrichten an sie.
  • In CABS ist das Format von KQML-Nachrichten das folgende:
  • KQML [:Sender :Empfänger :Inhalt]
  • Bei Agentennachrichten einschließlich Agentenkommunikationsvorgängen verwendet man wie üblich zur Koordination in CABS eingesetzte KQML-Routinen, und die Einzelheiten der Kommunikation befinden sich gewöhnlich in dem KQML-Inhaltsfeld. Ein CABS- Agent, der eine Zustandsänderung an andere Agenten weiterleitet (was ein Vorschlag, ein Gegenvorschlag oder eine Zustimmung in dem CABS-Koordinierungsprotokoll sein kann), verwendet die KQML-Routine "achieve". Die empfangenden Agenten antworten unter Verwendung der KQML-Routine "reply", wenn sie einen Gegenvorschlag machen, und "accept", wenn sie einen Vorschlag akzeptieren.
    • 2.3 Koordinierungsmaschine und Bewertungssystem 210
  • In den Fig. 2 und 3 sind die Koordinierungsmaschine und das Bewertungssystem 210 sowie die Planungs- und Ablaufsteuerung 220 beide eindeutig in einem CABS-Agenten, und beide werden im Folgenden im Einzelnen beschrieben. Weiter unten wird nochmals auf sie zurückgegriffen, wenn die Verwendung der CABS-Plattform beschrieben wird, um ein Agentensystem zu entwickeln, und zwar unter den Überschriften "Schritt 4: Agentenkoordinierungsstrategiespezifikation" und unter "Schritt 2: Agentendefinition" in dem Abschnitt mit dem Titel "4. Verwendung der CABS-Plattform zur Entwicklung eines Agentensystems".
  • Die Koordinierung ist außerordentlich wichtig bei CABS, da die Agenten kooperationsfähig sind. Kooperationsfähige Software- Agenten beziehen sich auf die komplexe Klasse von Agenten, die sowohl autonom sind als auch in der Lage sind, mit anderen Agenten zu kooperieren, um Tasks für die durch sie dargestellte Einheiten durchzuführen. Sie müssen unter Umständen verhandeln, um beiderseitig zustimmungsfähige Übereinkommen mit anderen Agenten zu treffen. Ein Agent kann beispielsweise eine Anfrage nach einer Ressource von einem anderen Agenten empfangen. Er antwortet entsprechend der Beziehung zwischen ihnen und entsprechend seiner eigenen speziellen Umstände ("Zustand"), ob diese Ressource zur Verfügung steht. Die Antwort bildet einen Teil eines Interaktionsprozesses zwischen den zwei Agenten, der durch ein "Koordinierungsprotokoll" festgelegt ist. Die Koordinierungsmaschine und das Bewertungssystem 210 erlauben es dem Agenten, mit anderen Agenten mittels eines oder mehrerer anderer Koordinierungsprotokolle zu interagieren, die durch den Entwickler als geeignet für das Gebiet des Agenten ausgewählt werden.
  • Üblicherweise wurden in der Vergangenheit Koordinierungsprotokolle "fest verdrahtet", in der Art, in der individuelle Software- Agenten arbeiten, so dass ihre Änderung ein vollständiges Neuschreiben der gesamten verteilten Applikation erforderlich macht. In einem CABS-System jedoch ist der Agent mit einem oder mehreren Koordinierungsgraphen 255 und einer Maschine 210 für ihre Ausführung versehen. Jeder Graph umfasst eine Gruppe von Bezeichnungen für Knoten zusammen mit einer Gruppe von Bezeichnungen für Bögen, die Übergangsbedingungen von Knoten zu Knoten identifizieren. Der Agent hat außerdem Zugriff auf einen Speicherraum für die ausführbare Form der Knoten und Bögen, die durch die Bezeichnungen identifiziert werden. Dieser Speicherraum kann sich innerhalb oder außerhalb des Agenten befinden. Die Koordinierungsmaschine 210 nutzt Graphbeschreibungen, um dynamisch Koordinierungsprozesse aufzubauen und laufen zu lassen, indem die Prozessschritte zusammengesetzt werden, die durch die Knoten- und Bogenbezeichnungen des Graphen identifiziert werden.
  • Zum Zeitpunkt des Aufbaus eines Agenten wählt der Anwender aus einer Koordinierungsgraphendatenbank 310 die speziellen Koordinierungsgraphen für den Agenten, die in die lokale Koordinierungsgraphendatenbank 255 des Agenten geladen werden. (Die einzige Visualisierungseinrichtung von CABS des Agenten 140 ist versehen mit einem Steuerungs-Tool, wodurch es möglich wird, dass die Anwender die Koordinierungsgraphen des Agenten während der Laufzeit verändern. Dies wird genauer weiter unten beschrieben unter der Überschrift "5. Debuggen und Visualisierung".)
  • Ein besonders wichtiges Merkmal des CABS-Agenten besteht darin, dass seine Koordinierungsmaschine 210 mehr als einen Koordinierungsprozess implementieren kann und damit mehr als ein Koordinierungsprotokoll, und zwar gleichzeitig. Dies erfolgt effektiv durch das Multiplexen der Ausführung der Koordinierungsgraphen in der Koordinierungsgraphendatenbank 255 durch einen Agenten. Die Maschine 210 befasst sich mit dem ersten Knoten jedes Koordinierungsgraphen 255, mit dem sie geladen wurde, geht dann sequenziell zu den zweiten Knoten aller Graphen etc. Damit durchläuft sie die Koordinierungsgraphen 255 im Grunde parallel.
  • CABS stellt somit in der Agentenoberfläche 300 eine Koordinierungsmaschine und ein Bewertungssystem 210 zur Verfügung, wofür die Funktionalität durch Auswahl aus einer Gruppe von Koordinierungsgraphen 310 beim Aufbau des Agenten vorgegeben wird. Wenn einmal jeder Agent in Betrieb gegangen ist, werden die Koordinierungsgraphen durch die Koordinierungsmaschine und das Bewertungssystem 210 verwendet, um spezifizierte Koordinierungsprozessschritte und -protokolle laufen zu lassen.
  • Der Speicherraum mit Prozessschritten, die durch die Bezeichnungen identifiziert werden, muss nicht notwendigerweise selbst in jedem Agenten vorhanden sein. Der Agent kann einfach während der Laufzeit in Übereinstimmung mit seinem/seinen Koordinierungsgraph/en darauf zugreifen.
  • (Im Folgenden wird die Koordinierungsmaschine und das Bewertungssystem 210 auch als Koordinierungs-Software-Modul 210 bezeichnet.)
  • Die Gesamtarchitektur des Koordinierungs-Software-Moduls 210 entspricht einer Turing-Maschine. Eingangsgrößen sind verschiedene variable Zustandswerte, Parameter, Ziele, Ausnahmen und Beschränkungen, und Ausgangsgrößen sind Entscheidungen.
  • In einem Multiagentensystem, bei dem zwei oder mehrere Agenten einen Koordinierungsprozess durchlaufen, wobei sie ihre jeweiligen Koordinierungs-Software-Module 210 verwenden, kann die Gesamtprozessfunktionalität allgemein durch ein "universelles Koordinierungsprotokoll (UCP)" wie folgt dargestellt werden:
    • UCP
  • Dieses UCP ist eine Sequenz der drei Aktivitäten "Vorschlag", "Gegenvorschlag" und "Annahme/Bestätigung" mit den gezeigten möglichen Iterationen. Jede Aktivität wird durch einen "Knoten" dargestellt (dargestellt hier durch eine Prozessbeschreibung auf höherer Ebene), und die Knoten werden durch "Bögen" miteinander verbunden (hier als Pfeile dargestellt), die jeweils eine Übergangsbedingung für den Übergang von Knoten zu Knoten indizieren. Das Koordinierungs-Software-Modul 210 für jeden Agenten muss in der Lage sein, die Rolle dieses Agenten in dem UCP zu unterstützen.
    • 2.3.1 Koordinierungs-Software-Modul 210
  • Das Koordinierungs-Software-Modul 210 ist ausgelegt, um Koordinierungsgraphen zu interpretieren, wenn man sich in einem gegebenen Anfangs-(Problem-) zustand befindet. Der Anfangszustand spezifiziert die Anfangsbedingungen des Problems und die notwendigen Daten.
  • Die Ausführung eines Graphen durch das Koordinierungs-Software- Modul 210 läuft wie folgt ab: Die Maschine wählt den ersten Knoten des Graphen und richtet einen Prozess ein, der durch die Bezeichnung des Knotens identifiziert wird. Dieser Prozess läuft ab durch Aufrufen seiner Routine exec() mit Rückgabe eines der drei möglichen Ergebnisse: FAIL, OK oder WAIT. Wenn exec() ein OK zurückgibt, wird ein Prozess eingerichtet, der durch die Bezeichnung des ersten Bogens identifiziert wird, der von dem Knoten ausgeht, und er wird ausgeführt. Wenn der Test des Bogens erfolgreich ist, wird der Knoten, auf den der Bogen zeigt, als auszuführen eingeplant. Der Graph wird auf diese Art abgearbeitet, bis ein Endknoten erreicht wird, von dem keine weiteren Bögen ausgehen.
  • Das Koordinierungs-Software-Modul 210 durchläuft kontinuierlich die Graphen in dem Sinne, dass es Ereignisse und Ausnahmezustände überwacht, die zu irgendeinem Zeitpunkt auftreten.
  • Wenn ein Test eines Bogens bei einem Knoten fehlschlägt, wird der nächste Bogen von diesem Knoten aus untersucht. Wenn bei einem Knoten von exec() ein FAIL zurückgegeben wird oder alle Bögen, die von dem Knoten ausgehen, fehlschlagen, springt man zurück (durch Aufrufen von backtrack() bei dem Knoten, wodurch alle Änderungen durch exec() rückgängig gemacht werden) zu dem vorherigen Knoten in der Kette.
  • Wenn bei einem Knoten von exec() ein WAIT zurückgegeben wird, dann wird der Knoten in eine Warteschlange gesetzt, bis eine der beiden folgenden Bedingungen eintritt: Entweder wird ein externes Ereignis von der Maschine empfangen (z. B. eine Antwortnachricht wird von einem anderen Agenten empfangen), oder es wird eine von dem Knoten spezifizierte Frist überschritten. In beiden Fällen wird für den Knoten erneut eine Ausführung geplant. Zusammenfassend, die Maschine führt eine Ausführung des Graphen in die Tiefe aus, wobei Rücksprünge erlaubt sind.
  • Andere Attribute der Maschine umfassen:
  • (i) die Fähigkeit, Graphen und Bögen als äquivalent zu behandeln, wenn eine Bogenbezeichnung tatsächlich einen Graphen bezeichnet - dies gibt der Maschine die Möglichkeit, rekursiv zu arbeiten, und
  • (ii) die Fähigkeit, mehrere Instanzen bei demselben Bogen einzurichten und sie parallel abzuarbeiten bei der Verwaltung von Fehlschlägen der Parallelzweige. D. h. wenn ein Zweig eines parallelen Bogens fehlschlägt, betrachtet die Maschine automatisch alle anderen parallel ausgeführten Zweige als fehlgeschlagen.
  • Die genaue Logik der Koordinierungsmaschine 210 ist die Folgende:
  • Die folgenden Codefragmente beschreiben das Grundverhalten eines Knotens. Man beachte, dass beim Definieren eines neuen Knotens nur die Funktionen exec() und backtrack() definiert werden müssen. Die anderen Funktionen unten beschreiben, wie Knoten mit der Maschine und den Bögen interagieren.
  • Das folgende Codefragment beschreibt die Funktionen, die das Verhalten eines Graphen implementieren. Man beachte wiederum, dass ein Anwender diese Funktionen nicht zu implementieren braucht. Um irgendeinen Graph zu beschreiben, muss der Anwender nur ein zweidimensionales Zeichenarray bereitstellen, das die Knoten und Bögen des Graphen auflistet.
  • Im Folgenden wird ein Beispiel einer Graphenbeschreibung wiedergegeben, die abgespeichert ist in der Koordinierungsgraphendatengegeben, und verwendet wird, um einen Koordinierungsprozess einzurichten und auszuführen.
  • Das Array beschreibt einen Graphen mit vier Zuständen s1-s4 und fünf Bögen a1-a5. Vom Knoten s0 können wir den Bogen a1 zum Zustand s1 oder den Bogen a2 zum Zustand s4 oder alternativ Bogen a3 zum Zustand s4 nehmen. Wenn man mehr als einen von einem Knoten aus durchlaufen kann, werden die Bögen in der Reihenfolge untersucht, in der sie in der Graphenbeschreibung vorliegen.
  • Der Code, mit dem ein Anwender einen Knoten definiert, macht es nur erforderlich, ein exec() und ein backtrack() zu implementieren. Für Bögen sollte der Code ein exec() implementieren, der ein Boolesches Ergebnis wahr oder falsch ausgibt.
    • 2.3.2 Koordinierungsmechanismen
  • In Fig. 11 ist gezeigt, wie in CABS-Agenten jeder Koordinierungsmechanismus in Form von einem 14-stufigen Rahmen spezifiziert ist, wo bei jeder Stufe wenigstens ein Zustandsprozess implementiert sein sollte. Der 14-stufige Rahmen kann als "Ausführungszusammenfassung" mit den logischen Einzelheiten der Koordinierungsmaschine 210 nach dem oben angegebenen Code aufgefasst werden. Allgemeine atomare Prozesse für die vierzehn Stufen sind unten aufgeführt. Fig. 11 beschreibt schematisch die unten aufgeführten Stufen.
    • Ressourcenphase
  • In dieser Phase wurde ein Agent A2 durch eine ankommende Nachricht von einem anderen Agenten A1 aktiviert, der beispielsweise Tasks delegieren muss. Die ankommende Nachricht wird an die Koordinierungsmaschine und das Bewertungssystem 210 von A2 abgeschickt, der die Planungs- und Ablaufsteuerung 220 und die verschiedenen Datenbanken 230, 225, 215, 245 zum Aufbauen und Durchführen eines Koordinierungsgraphen als Antwort auf den Agenten A1 aufruft. Bei dieser Ressourcenphase verwendet der Agent A2 die Task-Datenbank 230, um zu sehen, welche Ressourcen ein Task erfordert, sowie die Ressourcen und Verpflichtungsdatenbanken 224, 245, um zu sehen, wo diese Ressourcen zur Verfügung stehen.
    • Erste Stufe
  • Verifizieren der Ressourcenverfügbarkeit und Festlegen von Aktionen bei Situationen mit ausreichenden/nicht ausreichenden Ressourcen;
  • Entscheidung:
  • - wenn Ressourcen vollständig/teilweise ausreichen, gehe zur nächsten Stufe;
  • - wenn Ressourcen überhaupt nicht zur Verfügung stehen, Zurückweisung und Beendigung;
    • Zweite Stufe
  • Provisorische Reservierung von Ressourcen;
    • Delegierungsphase
  • Diese Phase kommt nur ins Spiel, wenn der Agent A2 selbst keine Ressourcen zur Verfügung hat, um damit auf Agenten A1 zu reagieren.
    • Dritte Stufe
  • Bestimmen der Position/Rolle des Agenten in dem gesamten Koordinierungskontext (Kopf - derjenige, der das momentane Ziel vorgibt, oder Untergebener - d. h. derjenige, an den ein Teilziel delegiert wurde) und Unterscheiden der Ebene der Ressourcenverfügbarkeit (teilweise/vollständig ausreichend).
  • - Wenn Ressourcen nur teilweise ausreichen, gehe zur nächsten Stufe (S&sub2;-S&sub3;).
  • - Wenn die Ressourcen nur teilweise ausreichen, ist es notwendig, mit anderen Agenten zu verhandeln, um eine zusätzliche Ressource zu finden. Die Stufen S&sub3; bis S&sub9; betreffen Verhandlungsprozessschritte, die nicht erforderlich sind, wenn die Ressourcen vollständig ausreichen. Wenn Ressourcen vollständig ausreichen und die Rolle des Agenten die des "Kopfes" ist, so gehe zu Stufe dreizehn (S&sub2;-S&sub1;&sub3;).
  • - Ressourcen stehen ausreichend zur Verfügung, aber die Rolle des Agenten ist nicht die des "Kopfes", so gehe zu Stufe zehn (S&sub2;-S&sub1;&sub0;).
    • Vierte Stufe
  • Finde den ersten Satz von Tasks, deren Anforderung an Ressourcen nicht erfüllt werden kann; entferne den ausgewählten Satz (S&sub3;-S&sub4;);
    • Fünfte Stufe
  • Erzeuge einen neuen Vorschlag unter Verwendung jedes Tasks in der ausgewählten Gruppe (S&sub4;-S&sub5;);
    • Sechste Stufe
  • Finde eine Gruppe von Agenten, an die der Vorschlag gerichtet werden kann (S&sub5;-S&sub6;);
    • Verhandlungsphase Siebte Stufe
  • (Hängt ab von der anzuwendenden Koordinierungsstrategie, beispielsweise "mehrmaliges offenes Zweitgebot" oder "Kontraktnetz" - siehe unten.)
  • - Senden des Vorschlags (S&sub6;-S&sub7;);
  • - Durchführen der Annahme-Bearbeitung (S&sub7;-S&sub6;);
  • - (Durchführen der Gegenvorschlag-Bearbeitung) (S&sub7;-S&sub7;);
  • - (Durchführen der Verarbeitung eines modifizierten Vorschlags) (S&sub7;-S&sub6;);
    • Achte Stufe
  • Zusammenfassen der Ergebnisse aus der Verhandlungsphase (S&sub7;- S&sub8;);
    • Neunte Stufe
  • Entscheidung: Auswählen einer Gruppe von Annahmen aus dem Ergebnis (S&sub8;-S&sub9;);
    • Zehnte Stufe
  • Entscheidung:
  • - Wenn es andere Gruppen von Tasks gibt, deren Ressourcenanforderungen nicht erfüllt werden können, gehe zu der dritten Stufe (S&sub9;-S&sub3;);
  • - Wenn es keine anderen Gruppen von Tasks gibt, deren Ressourcenanforderungen nicht erfüllt werden können, und der Agent ein Kopf-Agent ist, gehe zu der dreizehnten Stufe (S&sub9;- S&sub1;&sub2;).
  • - Wenn es keine anderen Gruppen von Tasks gibt, deren Ressourcenanforderungen nicht erfüllt werden können, und der Agent kein Kopf-Agent ist, gehe zur nächsten Stufe (S&sub9;-S&sub1;&sub0;).
    • Elfte Stufe
  • - Sende Annahme und Antworten (S&sub1;&sub0;-S&sub1;&sub1;);
  • - führe Bestätigungsbearbeitung durch (S&sub2;-S&sub1;&sub0;);
  • - falls möglich, führe Bearbeitung des modifizierten Vorschlags durch (S&sub1;&sub1;-S&sub1;&sub0;);
    • Zwölfte Stufe
  • Entscheidung:
  • - Wenn nicht delegiert wurde und Bestätigung empfangen wurde, gehe zur vierzehnten Stufe (S&sub1;&sub1;-S&sub1;&sub3;);
  • - wenn delegiert wurde und Bestätigung empfangen wurde, gehe zur nächsten Stufe (S&sub1;&sub1;-S&sub1;&sub2;);
  • - wenn keine Bestätigung empfangen wurde, Weise zurück und beende (S&sub1;&sub1;-SE);
    • Dreizehnte Stufe
  • Sende Bestätigung (S&sub1;&sub2;-S&sub1;&sub3;);
    • Vierzehnte Stufe
  • Reserviere Ressourcen fest und beende (S&sub1;&sub3;-S&sub1;&sub4;, S&sub1;&sub4;-SE);
    • 2.3.3 Definieren neuer Koordinierungsmechanismen
  • Die Entwicklung der Koordinierungsmaschine ermöglicht eine prinzipiell unendliche Erweiterung auf verschiedene UCP-kompatible Koordinierungsgraphen und sogar auf nicht UCP-kompatible Graphen. Dies wird erreicht durch die Tatsache, dass die Koordinierungsmaschine eine generische und gebietsunabhängige Funktion ist, die jede Graphenbeschreibung interpretiert, die in der vorher beschriebenen Form vorliegt. Dadurch, dass man der Maschine verschiedene Koordinierungsgraphen vorlegt, ergibt sich ein unterschiedliches Verhalten in Bezug auf die Koordinierung. Durch Ändern der implementierten Funktionen (d. h. Programme), identifiziert durch den Knoten und Bogenbezeichnungen eines Graphen, wird sich darüber hinaus dann die Maschine bei der Ausführung dieses Graphen unterschiedlich verhalten, selbst wenn die Gruppe der gegebenen Bezeichnungen unverändert bleibt.
  • Man hat gefunden, dass das UCP und dessen Ableitung, der 14- stufige Rahmen, viele existierende Koordinierungsmechanismen subsumiert. Es wurde außerdem gefunden, dass diese Mechanismen nur in kleineren bestimmten, aber subtilen Aspekten unterschiedlich sind. Nach sorgfältiger Analyse stellte sich heraus, dass durch das Differenzieren des UCP in 14 Stufen die meisten Mechanismen viele der Stufen gemeinsam haben und nur in einer kleinen Anzahl von Stufen unterschiedlich sind. Dies macht es möglich, eine große Anzahl von verschiedenen Mechanismen zu implementieren, indem nur einige wenige neue Funktionen implementiert werden müssen, und es können viele der gemeinsamen Funktionen wieder verwendet werden. Zusätzlich wird es durch die spezifizierenden Mechanismen unter Verwendung eines vereinheitlichten zu Grunde liegenden Rahmens möglich, ein Problem mit einer Mischung aus verschiedenen Mechanismen zu lösen.
  • Bei einem bestimmten Koordinierungsverhalten, um einen neuen UCP-kompatiblen Koordinierungsgraph zu definieren, sollten die folgenden Schritte ausreichen:
  • - Verfeinern des Verhaltens, so dass die Entscheidungsfindung und die Verarbeitung mit dem 14-stufigen Rahmen konform sind;
  • - Absuchen der Bibliothek der Koordinierungseinrichtung und Wiederverwendung existierender implementierter Funktionen, soweit dies möglich ist. Dies wird dann der Fall sein, wenn das funktionelle Verhalten identisch zu dem erforderlichen ist;
  • - Bei den Stufen, bei denen keine implementierten Funktionen wieder verwendet werden können, Implementieren neuer Funktionen, bei denen die folgenden drei Verfahren existieren müssen:
  • - exec: Verifizieren, ob die Funktion anwendbar ist, Ausführen der notwendigen Zustandsänderung, Melden und Aktualisieren bestimmter Datenbanken;
  • - backtrack: Zurücksetzen aller Operationen, die durchgeführt wurden, und Abspeichern des ursprünglichen Zustandes;
  • - Label: Jeder neu implementierten Funktion eine Bezeichnung zuordnen.
    • 2.3.4 Hinzufügen neuer Koordinierungsgraphen bei der Maschine
  • Nachdem ein Speicherraum von implementierten Funktionen definiert worden ist, um es der Maschine zu ermöglichen, einen speziellen Koordinierungsgraphen zu verwenden, sollte eine Beschreibung der Zeichenfolge des Graphen zu der Maschine einfach hinzugefügt werden. (Die Maschine kann mehrere Koordinierungsgraphen in einen vereinheitlichten Graph zusammenfassen, der keine Verdopplung von Zuständen enthält.)
  • Wenn mehr als ein Koordinierungsmechanismus erforderlich ist, um ein spezielles Problem zu lösen, sollten der Maschine in diesem Fall die Graphen vorgelegt werden, die die erforderlichen Koordinierungsprozesse beschreiben. Nach der Zusammenfassung der Graphen ist die Maschine in der Lage, die verschiedenen Mechanismen anzuwenden, die implizit in den vereinheitlichten Graphen enthalten sind, und zwar je nach Fall.
    • 2.4 Kenntnisstanddatenbank 215
  • Die Ressourcen-, Task- und Kenntnisstanddatenbanken 225, 230, 215 dienen zunächst als Informationsspeicherraum und können implementiert werden unter Verwendung konventioneller Datenbanktechnologien, bei denen Speicherung, Auslesen und Abfragemöglichkeiten unterstützt werden. Bei einer Implementierung wird eine Hash-Tabelle (die jeden Datenwert, der gespeichert werden soll, mit einem eindeutigen Schlüssel verknüpft) als Hauptdatenspeicherstruktur für jedes Modul verwendet.
  • Die Kenntnisstanddatenbank 215 speichert ein Kenntnisstandmodell für den Agenten in der Form einer Beziehungstabelle wie in dem folgenden Beispiel ab: das Gebiet bei diesem Beispiel betrifft die Umgebung für das Handeln wie zwischen zwei Geschäften: Das Geschäft 1 und das Geschäft 2. In Fig. 6 hat der Manager-Agent von Geschäft 1 (Agent A1) zwei Assistenten, Agenten B1 und C1; dagegen hat der Manager-Agent von Geschäft 2 (Agent A2) drei Assistenten, nämlich die Agneten B2, C2 und D2.
  • In diesem Szenario weiß A1 notwendigerweise von der Existenz und den Fähigkeiten von B1 und C1, da sie die dazugehörigen Assistenten sind, und ähnlich weiß A2 von B2, C2 und D2. Angenommen, dass A1 Kenntnis von A2 sowie den Größen hat, die A2 erzeugen kann; jedoch hat A2 keine Kenntnis von A1. Außerdem sei angenommen, dass in jedem Geschäft die Assistenten alle einander und ihre Fähigkeiten kennen. Die beiden folgenden Tabellen fassen eine mögliche Instanz des organisatorischen Wissens der Agenten in dem Geschäft 1 und 2 zusammen. Tabelle: Eine Instanz des organisatorischen Wissens der Agenten von Geschäft 1 Tabelle: Eine Instanz des organisatorischen Wissens der Agenten von Geschäft 2
  • Die Tabelle für Geschäft 1 führt die vier organisatorischen Beziehungen ein, die in der gegenwärtigen Implementierung des CABS- Systems verwendet werden. Die Beziehungen übergeordnet und untergeordnet behalten ihre natürliche Interpretation als vertikal strukturierte Beziehungen mit Bedeutung bezüglich Autorität. Gleichgestellt und nebengeordnet sind horizontale Strukturbeziehungen; bei CABS ist ein Mitarbeiter ein anderer Agent in derselben statischen Organisation, der weder über-noch untergeordnet ist. Ebene (Peer-)Beziehungen sind der Normalzustand und beziehen sich auf irgendeinen Agenten, der dem Basisagenten bekannt ist, der weder übergeordnet, untergeordnet noch nebengeordnet ist.
  • Einige der Folgen der verschiedenen organisatorischen Beziehungen für Verhandlung und Koordinierungsstrategien werden unten diskutiert unter der Überschrift "4.4 Schritt 4: Strategiespezifikation für die Agentenkoordinierung 510".
  • Man beachte, dass die organisatorischen Beziehungen nicht von vornherein bidirektional sind. Das bedeutet, obgleich ein Agent X davon ausgehen kann, dass er Y untergeordnet ist, bedeutet dies nicht notwendigerweise, dass Y davon ausgeht, dass er X übergeordnet ist. Man beachte außerdem, dass die Tabelle des Geschäfts 2 keine Beziehung gleicher Ebene für den A2-Agenten enthält. Dieses spiegelt die Tatsache wider, dass der Agent A2 keine Kenntnis von dem Manager von dem Geschäft 1 hat, dem Agenten A1.
  • Man beachte außerdem, dass die Vorstellungen des einen Agenten über einen zweiten nicht konsistent sein müssen mit den Vorstellungen eines dritten Agenten (Daten) bezüglich des zweiten. Beispielsweise geht A1 in der Tabelle zum Geschäft 1 davon aus, dass C2 die Größe 2 mit Kosten von 4 Einheiten innerhalb von 3 Zeiteinheiten herstellen kann. Jedoch glaubt B1 unterschiedlich davon, dass C1 die Größe 2 mit Kosten von 3 Einheiten innerhalb von 5 Zeiteinheiten herstellt. Dies kann in der Praxis eintreten, wenn die Agenten beispielsweise unterschiedliche Dienstebenenabkommen haben.
    • 2.5 Planungs- und Ablaufsteuerung 220
  • Die Rolle der Planungs-/Ablaufsteuerung besteht darin, die durch die Agenten zu bearbeitenden Tasks zu organisieren und zu planen. Die konventionelle Technik für das Planen (z. B. Means-End-Analyse wie bei den SIPE-oder O-PLAN-Organisatoren - siehe Veröffentlichungen in IEEE Expert: "Intelligent systems and their applications", Band 11, Nr. 6, Dezember 1996) und die Ablaufsteuerung (z. B. Job-Shop-Planung) können verwendet werden. Jedoch weist die Planungs- und Ablaufsteuerung 220 des CABS-Agenten zusätzliche, innovative Aspekte auf. Beispielsweise kann er die Möglichkeit des Überbuchens bieten, um eine maximale Ausnutzung der Ressourcen sicherzustellen.
  • Die Implementierung einer Planungs-/Ablaufsteuerung 220 eines CABS-Agenten ist ein partieller und hierarchischer Means-End- Organisator. In Fig. 9 wird die Zusagetabelle (oder Datenbank) 245 aufrechterhalten, die ein zweidimensionales Array ist, deren Zeilen 900 die verfügbaren Prozessoren enthalten und deren Spalten 905 die Zeitpunkte enthalten (unter Verwendung einer ganzzahligen Darstellung der Zeit). Die Basiszeit ("0") in der Tabelle ist die aktuelle Zeit, während die maximale Zeit die aktuelle Zeit plus die maximale, dem Plan vorauslaufende Zeitspanne des Agenten ist.
  • Eingangsgrößen für die Planungs-/Ablaufsteuerung 220 sind Ziele der Form: erzeuge Ressource R bis zur Zeit e bei maximalen Kosten c. Man beachte, dass die Zielsetzung andere Parameter wie zum Beispiel Qualität beinhalten kann. Dies ist abhängig von der Planung, die verwendet wird. Deren Ausgangsgrößen sind:
    • (a) output-tasks
  • - eine Gruppe von Tasks, die notwendig ist, um das Ziel erreichen zu können;
    • (b) output-subgoals
  • - eine Gruppe von Teilzielen, die der Agent mit anderen Agenten aushandeln muss, wenn das oberste Ziel erreicht werden soll.
  • Das Verhalten der Planung ist wie folgt:
  • Wenn (e < aktuelle Zeit oder e > aktuelle Zeit + Vorlauf) gib Fehlermeldung zurück.
  • /* Überprüfung, um sicherzustellen, dass wir uns innerhalb des Zeitraums befinden, der durch die Planung der Agenten abgedeckt wird */
  • Es sei applicable-tasks = Gruppe von Tasks in der Task-Datenbank der Agenten, die die gewünschte Ressource R als eine der ihren haben (erzeugte Größen).
  • /* Man beachte, dass in Abhängigkeit je nach Planungssteuerung die anwendbaren Tasks applicable-tasks nach Kosten, Qualität, Zeit etc. aufgeführt werden können. Das bedeutet, nach Kosten für die Durchführung des Tasks, nach Qualität der Ressourcen, die der Task erzeugt, oder nach der Zeit, die es für die Durchführung des Tasks bedarf. */
  • Für jeden Task in der Gruppe applicable-tasks:
  • versuche, den Task in der Zusagetabelle in einem fortlaufenden Block mit drei Leerstellen zwischen der gewünschten Ablaufzeit e des Tasks und der aktuellen Zeit zu platzieren;
  • wenn nicht genügend Leerstellen für den Task zur Verfügung stehen, gehe zum nächsten Task in der Gruppe applicable-tasks;
  • Wenn task erfolgreich in der Tabelle untergebracht wurde:
  • Füge task zu Gruppe output-tasks hinzu,
  • wobei die Anfangszeit s des Tasks gegeben ist durch die Startposition in der Tabelle.
  • Es sei consumed-resources = Gruppe von Ressourcen, die zur Durchführung des Task erforderlich sind.
  • Für jede Ressource C in consumed-resources:
  • Prüfe Ressourcendatenbank auf C,
  • wenn die Ressourcendatenbank C enthält, ordne C dem Task zu;
  • andernfalls erzeuge ein Teilziel zum Erlangen der Ressource C bis zum Zeitpunkt s sowie mit anderen Einschränkungen wie Qualität, die ähnlich der durch das oberste Ziel geforderten ist.
  • Als nächstes veranlasse rekursiv die Planungssteuerung, das neue Teilziel C zu erreichen und hänge die zwei Ausgangsgrößen der Planungssteuerung jeweils an die Gruppen output-tasks und output- subgoals an.
  • Wenn sich kein Task finden lässt, um die Ressource R innerhalb der Zeit, mit der Ressource und unter anderen Einschränken zu erlangen, hänge das Ziel, R zu erreichen, an die Gruppe output-subgoals und kehre zurück.
  • Die Berechnung der Gesamtkosten für das Erreichen eines Ziels wird als Summe der Kosten für die Durchführung aller Tasks, die für das Ziel erforderlich sind, berechnet.
  • Wenn einmal die Planungssteuerung durchgeführt worden ist, so bucht die Planungssteuerung versuchsweise den organisierten Plan in die Zusagetabelle. Auf Empfang einer Bestätigung der Buchung von der Koordinierungsmaschine wird die Planung fest gebucht, und die Tasks werden für die Ausführung zu ihren geplanten Zeitpunkten vorbereitet. Die Verwendung der versuchsweisen und festen Buchung gibt der Koordinierungsmaschine Zeit zum Delegieren externer Teilziele für das Erreichen eines Ziels und auch die Fähigkeit, Verpflichtungen aufzuheben.
  • Das Verhalten der CABS-Agenten-Ablaufsteuerung bringt die folgenden, besonders nützlichen Konzepte mit sich:
  • - Die Verwendung von versuchsweiser und fester Buchung gibt der Planungssteuerung die Möglichkeit, bereits versuchsweise gebuchte Schlitze doppelt zu buchen (im Prinzip ähnlich dem, was Luftlinien bei der Reservierung machen). Diese Idee verbessert die Chancen des Agenten, mit voller Kapazität zu arbeiten. Der Mechanismus für die Doppelbuchung läuft wie folgt ab: die Planungssteuerung hält eine zweite Kopie der Zusagetabelle, in der nur die fest gebuchten Schlitze und versuchsweise doppelt gebuchten Schlitze enthalten sind. Wenn die Doppelbuchung durch den Agenten zugelassen wird, verwendet die Planungssteuerung diese Tabelle bei der Planung, wenn sie keine freien Schlitze für einen Task unter Verwendung der normalen Zusagetabelle finden kann. Wenn freie Schlitze in der zweiten Tabelle gefunden werden, so werden diese Schlitze als doppelt gebucht markiert. Bei der gegenwärtigen Implementierung wird für den Fall, dass zwei Ziele in demselben Schlitz gebucht sind, das erste Ziel, das bestätigt werden muss, den Schlitzen zugeordnet, und das zweite Ziel wird zurückgewiesen. Andere Auswahlverfahren können implementiert werden, z. B. nach der höchsten Priorität des Ziels oder nach den höchsten Kosten des Ziels etc. Es ist außerdem möglich, den Grad der Doppelbuchung zu steuern, indem die Planungssteuerung einen Bruchteil der Gesamtzahl der Schlitze erhält, die doppelt gebucht werden können.
  • Begrenzen der maximalen Anzahl von parallelen Zweigen auf der Grundlage von verfügbaren Prozessoren.
  • - Die Vorbedingungen eines Tasks können in ihrer Reihenfolge festgelegt werden, z. B. kann ein Task mit drei Vorbedingungen A, B, C die Einschränkung mit sich bringen, dass A vor B und danach C erreicht werden muss. Während dieses ein Merkmal von einigen konventionellen Planungssteuerungen ist, führt bei CABS eine solche Zielreihenfolge zum Vernetzen von Planungssteuerung mit der Koordinierung. Bei konventionellen Agentenbasierenden System steuert die Koordinierungsmaschine die Planungssteuerung, aber bei CABS-Agenten teilen sich die Planungssteuerung 220 und die Koordinierungsmaschine 210 die Steuerung bei der Bearbeitung von der Reihenfolgevorgabe von Zielen. Beispielsweise kann in dem Fall mit A, B und C von oben A durch den Agenten organisiert werden und B ausgelagert werden. Jedoch wird durch die Wahl des Agenten, B zu erreichen, und die Art, auf die dieses erreicht wird (variable Bindungen), sowie die Art, auf die A erreicht wird, C beeinflusst. Damit hängt die letztendliche Entscheidung darüber, mit welchem Agenten die Vereinbarung getroffen wird, von der Planungssteuerung ab und basiert nicht einfach auf einem einzelnen Faktor wie den geringsten Kosten. Derartige Probleme treten üblicherweise auf, wenn Teilziele nicht unabhängig sind; und die Vernetzung von Planungssteuerungen mit der Koordinierung sorgt für einen flexiblen Mechanismus bei der Handhabung solcher Abhängigkeiten.
  • Oben war von "variablen Bindungen" die Rede. Diese stellen ein bekanntes Konzept für die Durchsetzung einer Gleichheitseinschränkung zwischen einer Variablen und einer Tatsache oder einer anderen Variablen dar. Eine Bindung wird verwendet, wenn eine Variable einer Tatsache gleichgesetzt wird. Beispielsweise wenn die Variable "v1" der Tatsache "f1" entspricht, z. B. "v1" muss "f1" sein, ist dies der Fall.
  • CABS-Agenten können es auch ermöglichen, dass eine Optimierung der Ablaufsteuerung an die Zusagetabelle angefügt wird. Bei einer einfachen Implementierung kann ein Algorithmus zur Erfüllung der Einschränkung verwendet werden, um bereits organisierte Aktivitäten neu zu planen, so dass keine der während der Planungssteuerung auferlegten Einschränkungen verletzt wird. Dies ist nützlich bei der Handhabung von Ausnahmezuständen oder beim Erreichen von taktischen Zielen. Die Optimierung kann zu der auf Einschränkungen basierenden Neuablaufsteuerung hinzugefügt werden.
  • Zu den Ausnahmezuständen sei bemerkt, dass ein Ausnahmezustand (unerwarteter Fehler) auftreten kann, wenn die Ausführung eines Tasks die geplante Zeit überschreitet. Wenn es freie Schlitze in der Zusagetabelle gibt, kann die Ablaufsteuerung möglicherweise ihre Aktivitäten neu planen, um den ausgeführten Tasks mehr Zeit zu gewähren. Bei einer einfachen neuen Ablaufplanung versucht die Ablaufsteuerung zur Befriedigung der Einschränkung ein neues Arrangement einzurichten, so dass keine der ursprünglichen Einschränkungen, die durch die Ziele gesetzt wurden, verletzt wird. Für eine optimierende neue Ablaufplanung kann die Planungssteuerung die Verletzung der Einschränkung solange zulassen, bis ein optimales Arrangement gefunden wurde (in diesem Fall bedeutet optimal die Abhängigkeit von Kriterien, die durch den Entwickler entschieden werden). Beispielsweise kann ein Job mit niedrigen Kosten, zu dem die Planungssteuerung bereits verpflichtet ist, fallengelassen werden zu Gunsten der Erweiterung der Verarbeitungszeit eines überfälligen Jobs mit hohen Kosten.
  • Eine Ablaufsteuerung kann auch verwendet werden für taktische Aufgaben. Zum Beispiel kann es taktische Aufgabe eines Agenten sein sicherzustellen, dass Jobs so schnell wie möglich durchgeführt werden. In solch einem Fall kann in der Zusagetabelle 245 in Fig. 9 durch ihn die Verschiebung von Teil-Tasks B und C zwei und eine Zelle nach links durchgeführt werden und ihre Ausführung gestartet werden, wenn der Agent alle ihre erforderlichen Ressourcen hat - eine solche Neuplanung verletzt keine der Einschränkungen, die durch das oberste Ziel gegeben sind.
    • 2.6 Ressourcendatenbank 225
  • Die Ressourcendatenbank 225 speichert die Ressourcendefinitionen.
  • Im allgemeinen ist eine "Variable" eine logische Beschreibung von etwas, während eine "Tatsache" eine spezielle Instanz von diesem Etwas ist, zusammen mit relevanten Daten, die zu der logischen Beschreibung hinzugefügt wurden. Ressourcen sind in diesem Kontext Tatsachen, die es erforderlich machen, dass der Anwender Daten in Bezug auf jede Ressource zum Zweck des Aufbaus der Zusagetabelle bereitstellt. Der Tatsachen-/Variablen-Editor 355 ist vorgesehen, um es dem Anwender zu ermöglichen, die notwendigen Daten unter Verwendung eines Rahmenbasierenden Objektattributwertformalismus zu laden.
  • Eine Ressource ist definiert als ein Objekt mit angefügten Attributwertpaaren. Zum Beispiel kann ein Agent in einem Kommunikationssystem eine Ressource anfordern, um eine Lichtwellenleiter- Netzverbindung von London nach Ipswich aufzubauen, über die Videodaten übertragen werden. Der Bedarf an der Ressource des Agenten kann wie folgt ausgedrückt werden: Ressourcenbeispiel 1:
  • Die speziellen Ressourcen und dazugehörigen Attribute, die ausgewählt wurden, hängen davon ab, wie der Anwender das Gebiet modellieren will.
  • Wenn das "is-variable"-Flag wie in dem Beispiel oben auf "false" steht, dann ist die Ressource tatsächlich eine Tatsache. Andernfalls wird es als Variable behandelt. Das "id"-Feld enthält die eindeutigen Identifizierungen der Ressource. Die folgenden zwei Beispiele betreffen Ressourcenvariablen: Ressourcenbeispiel 2:
  • Man beachte, das "?irgendetwas" eine lokale Variable bezeichnet.
  • Die Ressourcendatenbank 225 enthält außerdem die Ontologiedatenbank 260. Diese speichert die logische Definition jeder Art von Tatsachen - die legalen Attribute, den Bereich der legalen Werte jedes Attributs, jedwede Einschränkung zwischen Attributwerten und jedwede Beziehung zwischen den Attributen der Tatsache und anderer Tatsachen. Agenten müssen dieselbe ontologische Information nutzten, wenn sie einander verstehen sollen.
    • 2.7 Task-Datenbank 230
  • Die Task-Datenbank speichert Task-Definitionen, die beispielsweise von der Planungssteuerung und der Ablaufsteuerung 220 verwendet werden.
  • Die Task-Definition liefert ein Programmgerippe, das umfasst:
  • - eine Sequenz von Aktivitäten
  • - Auswahl (if, then ...)
  • - Iteration (Ausgangsbedingung)
  • Die CABS-Task-Definition (oder Beschreibung) bringt außerdem das Merkmal der "zwangsläufig parallelen" Tasks und "optional parallelen" Tasks mit sich. Wenn eine Task-Beschreibung zwangsläufig parallele Aktivitäten beinhaltet, so muss mehr als eine Aktivität gleichzeitig ausgeführt werden. Dies verhindert, dass sich ein Agent mit nur einer einzigen verfügbaren Ressource um den Task bewirbt.
  • Ein Task kann ein primitiver Task sein, der nur eine Aktivität umfasst, oder er kann eine Gruppe von Sub-Tasks enthalten. Ein Beispiel für letzteres ist ein Task, der eine einfache arithmetische Berechnung wie "ax² + dx + c" ausführen soll. Wenn dieser Task mit der zwangsläufig parallelen Indikation auftritt, werden die drei Werte ax², dx und c gleichzeitig berechnet, gefolgt von der sequenziellen Addition der berechneten Werte. Für einen Task dieser Art wird eine Zerlegung 560 durch den Task-Definitionseditor 335 erzeugt (siehe unten unter der Überschrift "4.5 Schritt 5: Task-Definition"), und ein wesentlicher Aspekt der Task-Beschreibung werden die Schnittstellen zwischen Ausgangsgrößen einer Task-Aktivität und Eingangsgrößen der folgenden Task-Aktivitäten sein.
  • Eine Task-Beschreibung umfasst außerdem Vorbedingungen für den Task, wie zum Beispiel die Ressourcen, die für ihn erforderlich sind, und die Effekte, die durch ihn bewirkt werden (Eingangsgrößen/Ausgangsgrößen), wie lange der Task dauern wird, logische Beschreibung für die tatsächliche Durchführung eines Tasks bei dem externen System 125 und - im Fall von komplexen Tasks - die Zerlegung 560, die oben erwähnt wurde und die eine Liste von Sub-Tasks innerhalb des komplexen Tasks ist.
  • Eine Ausgangsgröße des Tasks ist ein Rückaufruf 555, was dem Befehl entspricht, der über den Ausführungsmonitor 250 an das externe System 125 ausgegeben wird, um eine relevante Funktion auszuführen. Ein Beispiel ist ein Faksimilevorgang. Die logische Beschreibung umfasst eine Variable 550, die das Laden von Papier und das Wählen einer Nummer eines Faksimilegeräts beschreibt. Eine Zerlegung 560 des Tasks listet Sub-Tasks wie das Erfassen des Deckblattes, das gesendet werden soll, oder eines Textblockes in dem korrekten Puffer, das Erfassen eines Wählsignals, das Erfassen des Abhebens und des Beginns der Übertragung oder das Erfassen eines Belegt-Signals, Abspeichern der gewünschten Nummer und Wiederholung nach einem gegebenen Zeitintervall auf. (Dies sind offensichtlich Sub-Tasks, die nicht parallel abgearbeitet werden können oder auf Faksimilegeräte verteilt werden können.) Der Rückaufruf 555 ist in der Realität der Befehl an das Faksimilegerät, den tatsächlichen Faksimilevorgang auszuführen.
  • Tasks und Task-Definitionen werden genauer weiter unten erläutert (unter der Überschrift "4.5 Schritt 5: Task-Definitionen").
    • 2.8 Ausführungsmonitor 250
  • Der Ausführungsmonitor 250 hat Schnittstellen zu dem externen System 125, zu der Planungs- und Ablaufsteuerung 220 und der Koordinierungsmaschine und dem Bewertungssystem 210.
  • Der Ausführungsmonitor 250 erreicht die Ziele eines Agenten, indem er Tasks in dem externen System 125 ausführen lässt. Für jeden Task-Typ in der CABS-Umgebung wird eine benutzerdefinierte Task- Rückaufruffunktion bereitgestellt. Wenn der Ausführungsmonitor 250 entscheidet, dass ein bestimmter Task ausgeführt werden soll, so erfolgt dies durch Aufrufen der entsprechenden Task- Rückaufruffunktionen und ihre Ausgabe an das externe System 125.
  • Um die Konstruktion von CABS zu vereinfachen, wird die tatsächliche Ausführung in diesen Task-Rückaufruffunktionen simuliert. Bei erfolgreicher Beendigung eines Tasks wird dies dem Ausführungsmonitor 250 mitgeteilt. Nichts desto trotz kann auch der Fehlschlag bei einer Ausführung eines Tasks simuliert werden (z. B. es kann zu einem Hardware-Problem bei dem Roboterarm des externen Systems 125 kommen). Diese Umstände werden dem Ausführungsmonitor 250 bei Fehlschlag als Alarm mitgeteilt, und es können damit geeignete korrigierende Aktionen eingeplant werden. Beispielsweise kann der Agentenentwickler einplanen, dass der Agent bei Fehlschlag den Ablauf der Ziele, die erreicht werden sollen, neu plant, indem durch die Koordinierungsmaschine 210 alternative Task- Rückaufruffunktionen ausgelöst werden oder sie an andere Agenten delegiert werden.
  • Darüber hinaus kann der Ausführungsmonitor 250 entscheiden, dass die Zeit, die erforderlich ist, um einen Task auszuführen, die erwartete Dauer überschritten hat, ohne dass der Ausführungsmonitor 250 ein entsprechendes Eingangssignal empfangen hat. Mit demselben Token kann der Agentenentwickler festlegen, welche geeigneten Aktionen in einem solchen Fall ausgeführt werden sollen.
  • Der Ausführungsmonitor 250 hat die folgenden Funktionen bezüglich Vorschlägen, die mit PID und Seq bezeichnet sind:
    • Buchung (reserviert Ressourcen)
  • Book [PID, Level, Seq, AID],
  • wobei
  • - PID (Proposal-ID) als Vorschlags-ID einen speziellen Vorschlag bezeichnet;
  • - Level, Seq &epsi; Z die Ebenennummer und die Sequenznummer des Vorschlags ist;
  • - AID die ID der Aktion bezeichnet, die durch die Funktion zurückgegeben wird.
    • Buchungsrücknahme (löscht die Reservierung von Ressourcen)
  • UnBook [PID, Level, Seq, AID],
  • wobei
  • - PID (Proposal-ID) als Vorschlags-ID einen speziellen Vorschlag bezeichnet;
  • - Level, Seq &epsi; Z die Ebenennummer und die Sequenznummer des Vorschlags ist;
  • - AID die ID der Aktion bezeichnet, die durch die Funktion zurückgegeben wird.
    • Zusage (weist Ressourcen zu)
  • Commit [PID, Level, Seq, AID],
  • wobei
  • - PID (Proposal-ID) als Vorschlags-ID einen speziellen Vorschlag bezeichnet;
  • - Level, Seq &epsi; Z die Ebenennummer und die Sequenznummer des Vorschlags ist;
  • - AID die ID der Aktion bezeichnet, die durch die Funktion zurückgegeben wird.
    • Zusagerücknahme (widerruft die Zuweisung von Ressourcen)
  • Free [PID, Level, Seq, AID],
  • wobei
  • - PID (Proposal-ID) als Vorschlags-ID einen speziellen Vorschlag bezeichnet;
  • - Level, Seq &epsi; Z die Ebenennummer und die Sequenznummer des Vorschlags ist;
  • - AID die ID der Aktion bezeichnet, die durch die Funktion zurückgegeben wird.
  • (Diese Funktion kann nur ausgeführt werden, und zwar nur dann, wenn die Ausführung des Vorschlags noch nicht begonnen hat.)
    • 3. ÜBERBLICK: CABS-PLATTFORM
  • In Fig. 3 werden die Einrichtungen für das Erfassen von Daten zum Laden der Architektur, zum Erzeugen eines Systems mit einer oder mehreren Einheiten gemäß dieser Architektur und für das automatische Aufbauen eines Software-Moduls gemäß dieser Architektur durch die CABS-Plattform bereitgestellt. Diese stellt ein Agenten-Muster 300 bereit, das die Agentenstruktur nach Fig. 2 vorgibt, eine Anwenderschnittstelle 305, die vor allem eine Gruppe von Editoren zum Identifizieren einer Gruppe von Agenten, Auswählen der Funktionalität des Agenten und das Eingeben von Task- und Domain-bezogenen Daten ist, eine Bibliothek von Koordinierungsstrategien 310 und eine Gruppe von standardmäßigen Unterstützungsagenten 315.
  • Die Agentenoberfläche 300 stellt einfach den Rahmen zur Unterstützung einer Agentenstruktur nach Fig. 2 dar, und wird hier in vollem Umfang beschrieben. Die Editoren werden weiter unten beschrieben. Die Koordinierungsstrategien 310 wurden oben beschrieben unter der Überschrift "2.3 Koordinierungsmaschine und Bewertungssystem 210". Einer der Unterstützungsagenten 315 ist besonders wichtig und neu. Dieser wird im Folgenden unter der Überschrift "5. Debuggen und Visualisieren" beschrieben. Er kann auch in anderen Multiagenten- und verteilten Systemen angewendet werden, nicht nur in solchen, die mit dem CABS-System aufgebaut werden.
  • Die Editoren der Nutzerschnittstelle 305 unterstützen und zeichnen Entscheidungen auf, die durch den Entwickler bei der Herstellung eines Agenten getroffen wurden und über eine Konstruktionsschnittstelle 350 eingegeben wurden. Im Einzelnen umfassen sie Folgendes:
  • - Einen Agentendefinitionseditor 320 (auf den Bezug genommen wird unten unter "4.2 Schritt 2: Agentendefinition 500") zum Bereitstellen einer logischen Beschreibung des Agenten, seiner Möglichkeiten und Anfangsressourcen etc.
  • - Einen Organisationseditor 325 (auf den Bezug genommen wird unten unter "4.3 Schritt 3: Agentenorganisation 505") zum Beschreiben der relationalen Verbindungen zwischen Agenten in einem Szenario und auch die Annahmen jedes Agenten über andere Agenten in dem System.
  • - Einen Koordinierungseditor 330 (auf den Bezug genommen wird unten unter "4.4 Schritt 4: Agentenkoordinierungsstrategiespezifizierung 510") zum Auswählen und/oder Beschreiben von Koordinierungsstrategien der Agenten.
  • - Einen Task-Beschreibungseditor 335 (auf den Bezug genommen wird unten unter "4.5 Schritt 5: Tast-Definition 520") zum Beschreiben der Tasks, die die Agenten auf dem Gebiet ausführen können.
  • - Einen Ontologieeditor 340 (auf den Bezug genommen wird unten unter "4.1 Schritt 1: Domain-Untersuchung und Agentenidentifizierung 515") zum Beschreiben einer geeigneten Ontologie für ein Gebiet.
  • - Einen Tatsachen-/Variableneditor 355 (auf den Bezug genommen wird unten unter "4.2 Schritt 2: Agentendefinition 500" und unter "4.5 Schritt 5: Task-Definition 520") zum Beschreiben spezieller Instanzen von Tatsachen und Variablen unter Verwendung der Muster, die durch den Ontologieeditor 340 bereitgestellt werden.
  • - Einen Codegeneratoreditor 360 (auf den Bezug genommen wird unten unter "4.6 Schritt 6: Domain-spezifische Problemlösungscodeerzeugung 525") zum Erzeugen von Code gemäß den Definitionen, die für jeden Agenten gegeben sind.
  • - Einen Task-Zusammenfassungseditor 365 (auf den Bezug genommen wird unten unter "4.5 Schritt 5: Task-Definition 520") zum Beschreiben von Task-Zusammenfassungen bei Tasks, die zusammengesetzt sind aus mehreren Sub-Tasks, die in einer bestimmten Reihenfolge durchgeführt werden müssen.
  • - Einen Einschränkungseditor 370 (auf den Bezug genommen wird unten unter "4.5 Schritt 5: Task-Definition 520") zum Beschreiben der Einschränkungen zwischen (i) den Vorbedingungen und Auswirkungen eines Tasks, (ii) einer oder mehreren Vorbedingungen eines Tasks und (iii) der Auswirkungen eines vorangehenden Tasks und der Vorbedingungen eines nachfolgenden Tasks in einer Task-Zusammenfassungsbeschreibung.
  • Die Ausgangsgröße 100 der CABS-Plattform ist dann eine logische Beschreibung einer Gruppe von Agenten und einer Gruppe von Tasks, die auf einem Gebiet ausgeführt werden müssen, zusammen mit einem ausführbaren Code für jeden Agenten und Grundstrukturen für den ausführbaren Code für jeden Task.
  • CABS stellt ein System von Verfahren plus Umgebung dar, um einen Multiagentensystementwickler auszustatten mit Mitteln zum:
  • - Konfigurieren einer Anzahl von verschiedenen Agenten unterschiedlicher Funktionalität und Verhaltens,
  • - Organisieren von ihnen in beliebiger Weise,
  • - Ausfüllen jedes Agenten mit Kommunikations- und Koordinierungsmöglichkeiten, die in einer von CABS zur Verfügung gestellten Liste ausgewählt werden können,
  • - Versorgen jedes Agenten mit den notwendigen gebietsspezifischen Problemlösungscode und
  • - automatischen Erzeugen der erforderlichen ausführbaren Routinen für die Agenten.
  • Zusätzlich kann die CABS-Plattform dem Entwickler eine Folge von Unterstützungsagenten 315 allgemein bekannten Typs zur Verfügung stellen, wie zum Beispiel Namenserver, Vereinfachungseinrichtungen (klassifizierte Ordner) und Visualisierungen. Vor allem ermöglicht es CABS dem Systementwickler, sich auf gebietsspezifische Analyse zu konzentrieren, ohne dass er sich weiter um Agentenbasierende Fragestellungen kümmern muss.
    • 4. VERWENDUNG DER CABS-PLATTFORM ZUM KONSTRUIEREN EINES AGENTEN-SYSTEMS
  • Die CABS-Plattform basiert auf einem Ansatz zum Konstruieren kooperierender Software-Agenten, wobei angenommen wird, dass die Agenten fünf primäre Gruppen von Eigenschaften oder "Schichten" aufweisen. In den Fig. 4 und 5 macht es dieser Ansatz erforderlich, dass Entwickler die folgenden drei Eingangsgrößen bereitstellen, nämlich wie folgt eine Definitionsschicht 400, eine Organisationsschicht 405 und eine Koordinierungsschicht 410.
  • In einem Schritt "Agentendefinition" 500 mit Bezug auf die Definitionsschicht 400 werden durch Anwendereingaben die Agenten in Bezug auf Bewertung (und Lernen), Ziele, Ressourcen etc. festgelegt.
  • In einem Schritt "Agentenorganisation" 505 mit Bezug auf die Organisationsschicht 405 werden durch Anwendereingaben die Agenten in Form von Beziehungen zu anderen Agenten festgelegt, z. B. zu welchen Organisationen sie gehören, welche Rollen sie in diesen Organisationen spielen, welche anderen Agenten sie kennen, welche Möglichkeiten sie von den anderen Agenten kennen etc. (Eine Organisation ist eine Gruppe von Agenten, die ein gemeinsames Attribut haben, wie z. B. die Zugehörigkeit zu derselben Gesellschaft. Organisationen können virtuell oder real sein. Eine virtuelle Organisation ist eine Gruppe von Agenten, die eine Art von Kooperationsvereinbarung haben.)
  • Bei einem Schritt "Agentenkoordinierung" 510 mit Bezug auf die Koordinierungsschicht 410 werden durch Anwendereingaben die Koordinierung und Verhandlungstechniken für den Agenten festgelegt.
  • Die beiden anderen "Schichten" in jedem Agenten sind in Fig. 4 dargestellt. Es sind dies eine Kommunikationsschicht 415 für die Behandlung technischer Aspekte der Kommunikation von Agenten untereinander und eine Schnittstellenschicht für die Anwendungsprogrammierung (API) 420, die eine Schnittstelle für externe Systeme zum Hinzufügen, Modifizieren oder Löschen von Ressourcen, die dem Agenten zur Verfügung stehen, darstellt. In der Struktur in Fig. 2 ist die Kommunikationsschicht 415 mit der Mailbox 200 und dem Nachrichtenverwalter 205 versehen. Die API-Schicht 420 wird durch die Schnittstellen zwischen dem externen System 240 und der Ressourcendatenbank 225 und dem Ausführungsmonitor 235 bereitgestellt. Diese werden daher beide durch das Agentenmuster 300 in Fig. 3 bereitgestellt.
  • Die Anwendereingaben, die durch den CABS-Ansatz für die Definitionsschicht 400, die Organisationsschicht 405 und die Koordinierungsschicht 410 erforderlich sind, werden als die folgenden sechs Schritte strukturiert:
  • 1. Domain-Untersuchung und Agenten-Identifizierung 515,
  • 2. Agenten-Definition 500,
  • 3. Agenten-Organisation 505,
  • 4. Agenten-Koordinierungsstrategiespezifikation 510,
  • 5. Task-Definition 520, und
  • 6. Domain-spezifische Problemlösungscodeerzeugung 525.
  • In den Fig. 3 und 5 sorgt die CABS-Plattform für Darstellungsprogrammeditoren über die Anwenderschnittstelle 305 zum Unterstützen und Automatisieren der Schritte 1-5. Diese Schritte sollten iterativ durchgeführt werden, bis der Entwickler zufrieden gestellt ist und die endgültige Folge von Agenten genau das Problem wiedergeben, das modelliert wird.
  • Im Folgenden wird die Verwendung der CABS-Plattform zum Ausführen der Schritte 1 -6 genauer erläutert.
    • 4.1 Schritt 1: Gebietsuntersuchung und Agentenidentifizierung 515
  • Die CABS-Plattform wird durch einen Anwender verwendet, der eher Experte für ein Gebiet als für Software-Agenten ist. Dieser erste Schritt wird auf die Weise durchgeführt, die der Experte für das Gebiet als optimal empfindet. Es kann sein, dass der Experte für das Gebiet beispielsweise eine Entscheidung darauf stützt, wo Steuerungsprozesse in dem Gebiet ausgeführt werden müssen. Jedoch besteht der bevorzugte Ansatz darin, die Fähigkeit zur autonomen Entscheidungsfindung als Hauptkriterium zum Identifizieren der Anfangsgruppe von Kandidaten für Agenten auf dem Gebiet zu betonen. Das Maß der Granularität, mit dem der das Gebiet modelliert wird, wird festgelegt durch den Experten für das Gebiet und bestimmt die Grenzen der Agentenkandidaten. Als Anfangspunkt werden Agentenkandidaten für gewöhnlich identifiziert, wo immer es eine Entscheidungsfindungseinheit auf dem Gebiet gibt.
  • Die Anwendereingabe auf dieser Stufe ist einfach eine Listen von Agentenidentifizierungen, die die Gruppe von Agentenkandidaten darstellt, die durch den Experten auf dem Gebiet ausgewählt wurden als diejenigen, die wahrscheinlich ein vernünftiges Modell des Gebietes ergeben und daher auch eine arbeitsfähige Steuerungsstruktur ermöglichen. Das CABS-System ordnet jeder der Identifizierungen eine Kopie der Agentenoberfläche 300 zu, und die Ausgabe nach Schritt 1 ist eine Gruppe von Agentenoberflächen 300.
  • Wenn sich bei einer späteren Stufe herausstellt, dass es zu einem Konflikt kommt, zum Beispiel weil ein Agentenkandidat Entscheidungen zugeordnet in Bezug auf einen Prozess bekommt, den er in der Praxis nicht beeinflussen kann, so kann die Liste der Agentenidentifizierungen verbessert werden, so dass die Gruppe der Agentenkandidaten beispielsweise um einen neuen erweitert wird, und der Konstruktionsprozess wird erneut durchgeführt, um diesen Änderungen Rechnung zu tragen.
  • Es ist kein spezieller Editor für die Agentenidentifizierung notwendig.
  • Eine weitere wichtige Anwendereingabe ist das Vokabular des Gebietes. Dieses wird unter Zuhilfenahme des Ontologieeditors 340 eingegeben. Eine Ontologie oder ein Datenlexikon für ein Gebiet beschreibt alle möglichen Konzepte oder Objekte, die auf diesem Gebiet existieren können. In CABS wird ein Objektattributwertformalismus zum Beschreiben von Gebietsobjekten und Konzepten verwendet. Der Ontologieeditor 340 sorgt einfach für Muster zum Beschreiben dieser Objekte, d. h. (i) die unterschiedlichen Objekttypen, (ii) die Liste von Attributen jedes dieser Objekttypen, (iii) den Typ der Werte, den jedes Attribut annimmt, und (iv) die Default-Werte (falls vorhanden) für jedes Attribut.
  • Dieser Editor sorgt für ein Muster oder ein Formular, so dass das Vokabular des Gebietes beschrieben werden kann, das der Agent steuern soll.
  • Der Ontologieeditor 340 ermöglicht es dem Anwender, eine EINHEIT, ihre ATTRIBUTE, die WERTE der Attribute und typische DEFAULT- Werte zu identifizieren. Ein Beispiel aus einem Kommunikationsnetz sähe wie folgt aus:
    • 4.2 Schritt 2: Agentendefinition 500
  • Für jeden der Agenten, die in Schritt 1 definiert wurden, müssen die folgenden Anwendereingaben über den Agentendefinitionseditor 320 gemacht werden:
  • - Identitäten der Tasks, die der Agent durchführen kann;
  • - die Zahl der Tasks, die der Agent gleichzeitig durchführen kann;
  • - das Zeitintervall, über das der Agent normalerweise seine Ressourcen zuweist (seine Aktivitäten plant); und
  • - die dem Agenten zur Verfügung stehenden Ressourcen.
  • Diese Daten werden an den Planungs- und Ablaufsteuerung 220 weitergeleitet, die oben mit Bezug auf Fig. 2 beschrieben wurden, um sie beim Aufbau einer Zusagetabelle 245 zu verwenden.
  • Dateneinträge bezüglich Task-Identifizierungen, die Zahl der Tasks und der Planungszeitrahmen sind ziemlich unkompliziert, außer dass beim Zeitrahmen verschiedene Faktoren eine Rolle spielen. Beispielsweise kann bei manchen Szenarios ein Agent nur über kürzere Dauer planen und ist daher weniger geeignet, Kundenanforderungen zu erfüllen, kann aber besser auf ökonomische Änderungen der Umstände reagieren.
  • Die Tasks werden auf einer späteren Stufe definiert, was weiter unten unter der Überschrift "4.5 Schritt 5: Task-Definition" diskutiert wird, und auf dieser Stufe ist es lediglich notwendig, die Identifizierungen einzugeben. Jedoch müssen die Ressourcen definiert werden, die dem Agenten zur Verfügung stehen. Da der Kontext, in dem der Agent funktionieren kann, ein beliebiger in einer großen Anzahl von sehr verschiedenen Kontexten sein kann, ist es notwendig, dem Agenten eine Definition der Ressourcen mitzugeben, die ausreicht, damit er ein korrektes logisches Modell der realen physikalischen Ressourcen aufbauen kann, die dem Agenten zur Verfügung stehen, so dass er seine Aktivitäten richtig planen kann. CABS stellt einen Tatsachen-/Variablen-Editor 355 zur Verfügung, der für die Beschreibung der Ressourcen genutzt wird, die dem Agenten zur Verfügung stehen.
  • Allgemein ist eine "Variable" eine logische Beschreibung von irgendetwas, während eine "Tatsache" eine spezielle Instanz von diesem Etwas ist, wobei relevante Daten zu der logischen Beschreibung hinzugefügt werden. Ressourcen sind in diesem Kontext Tatsachen, die es daher erforderlich machen, dass der Anwender Daten mit Bezug auf jede Ressource zur Verfügung stellt, um das logische Modell der realen physikalischen Ressourcen aufbauen zu können. Der Tatsachen-/Variablen-Editor 355 dient dazu, es dem Anwender zu ermöglichen, die notwendigen Daten unter Verwendung eines Rahmenbasierenden Objektattributwertformalismus zu laden.
  • Eine Ressource (oder Tatsache) wird definiert als ein Objekt mit Attributwertpaaren als Anhang. Beispielsweise kann ein Agent in einem Kommunikationssystem eine Ressource anfordern, um eine Lichtwellenleiter-Netzverbindung für Videodaten von London nach Ipswich aufzubauen. Der Ressourcenbedarf des Agenten kann möglicherweise wie folgt ausgedrückt werden: Ressourcenbeispiel 1:
  • Die speziellen Ressourcen und dazugehörigen Attribute, die ausgewählt wurden, hängen davon ab, wie der Anwender das Gebiet modellieren will.
  • Wenn das "is-variable"-Flag wie in dem Beispiel oben auf "false" steht, dann ist die Ressource tatsächlich eine Tatsache. Andernfalls wird es als Variable behandelt. Das "id"-Feld enthält den eindeutigen Identifizierungen der Ressource. Die folgenden zwei Beispiele betreffen Ressourcenvariablen: Ressourcenbeispiel 2:
  • Man beachte, das "?irgendetwas" eine lokale Variable bezeichnet.
  • In Fig. 2 lädt der Tatsachen-/Variablen-Editor 355 die Ressourcendaten in die Ressourcenbank 225 des Agenten, auf die die Planungs-und Ablaufsteuerung 220 Zugriff hat, um eine Zusagetabelle aufbauen und betreiben zu können.
  • Die Ausgangsgröße von Schritt 2 ist daher eine Gruppe von Tatsachen 350 (Ressourcen) und eine Liste von Task-Identifizierungen 535, für die Definitionen im Schritt S angegeben werden müssen, was weiter unten beschrieben wird.
    • 4.3 Schritt 3: Agentenplanung 505
  • Für jeden der im Schritt 1 identifizierten Agenten müssen über den Organisationseditor 325 die folgenden Anwendereingaben gemacht werden:
  • - Identifizieren der anderen Agenten in der Gemeinschaft, die er kennt,
  • - Bestimmen der primären strukturellen Beziehungen, die zwischen ihm und jedem der identifizierten Agenten bestehen,
  • - Identifizieren der Task-Ausgangsgrößen (falls vorhanden), die jeder der identifizierten Agenten erzeugen kann,
  • - Spezifizieren der mittleren Kosten und Zeitdauer (falls bekannt) bei jedem der identifizierten Task-Ausgangsgrößen.
  • Die Dateneingangsgrößen bezüglich Task-Ausgangsgrößen müssen wiederum nur Identifizierungen für die Task-Ausgangsgrößen umfassen, die von dem Agenten unter den Task-Definitionen verstanden werden können, siehe Schritt 5 unten.
  • Der Planungseditor 325 verwendet die Dateneingaben in diesem Schritt (Schritt 3) zum Erzeugen einer Beziehungstabelle, die dann in dem Kenntnisstandmodell 215 des Agenten abgespeichert wird. (Die Beziehungstabelle wurde oben unter der Überschrift "2.4 Kenntnisstanddatenbank 215" beschrieben.)
  • Die Ausgangsgrößen von Schritt 3 sind daher eine Gruppe von Agentenbeziehungen 545, die das CABS-System in dem Kenntnisstandmodell 215 des Agenten abspeichert, und eine Gruppe von Variablen 540, die die Ressourcen (Produkte) beschreiben, von denen der Basisagent glaubt, dass der Zielagent sie erzeugen kann.
    • 4.4 Schritt 4: Agenten-Koordinierungsstrategiespezifikation 510
  • Für jeden der in Schritt 1 oben identifizierten Agenten müssen die Identitäten der UCP-kompatiblen Koordinierungsgraphen über den Koordinierungseditor 330 eingegeben werden, die der Agent ausführen kann, um seine verschiedenen Koordinierungsstrategien zu realisieren. Momentan bietet CABS die folgenden Koordinierungsgraphen in seiner Koordinierungsgraphendatenbank 310, die der Anwender auswählen kann und seinen Agenten zuordnen kann, indem die Koordinierungsgraphendatenbank 255 des Agenten geladen wird:
  • 1. Master-slave (hierarchische Task-Verteilung)
  • 2. Kontraktnetz (beschränktes Kontraktnetz)
  • 3. Mehrmaliges versiegeltes Erstgebot
  • 4. Mehrmaliges offenes Erstgebot (ähnlich einer englischen Auktion)
  • 5. Mehrmaliges versiegeltes Zweitgebot
  • 6. Mehrmaliges offenes Zweitgebot (ähnlich einer Vickery-Auktion)
  • 7. Mehrmaliges offenes Umkehrpreisgebot (ähnlich einer niederländischen Auktion)
  • 8. Einmalige Derivative der letzten fünf Strategien.
  • Client-server- oder Master-slave-Koordinierungen treten auf, wenn ein Master einen Slave dazu aussucht, einen Job durchzuführen. Diese Strategie macht offensichtlich eine vertikale (superior) Beziehung zwischen Slave und Master erforderlich. Die Kontraktnetzstrategie liegt dann vor, wenn ein Agent einen Task ankündigt und Angebote anfordert, um den Task von anderen Agenten ausführen zu lassen. Die Angebote werden kann ausgewertet, und der Kontrakt wird mit dem (den) Gewinneragenten abgeschlossen. Diese Strategie beruht auf keiner organisatorischen Beziehung zwischen den teilnehmenden Agenten. Das beschränkte Kontraktnetz ist ähnlich wie die Kontraktnetzstrategie, außer dass der Auktionator die Agenten auswählt/einschränkt, an die Angebote gesendet werden.
  • Die oben aufgelisteten Koordinierungsprotokolle können einmalig oder mehrmalig durchgeführt werden. Ein einmaliges Verhalten zwischen zwei Agenten bedingt, dass irgendein Agent (beispielsweise) irgendeinen Vorschlag erhält und ihn sofort annimmt. Alternativ kann der Agent eine weitere Runde des Zyklus initiieren, so dass sich eine mehrmalige Durchführung ergibt. Der Schlüsselpunkt ist hier, dass die Beendigungsbedingung für den Agenten, der die Interaktion initiiert hat, erfüllt sein muss, bevor die Interaktion beendet wird.
  • Üblicherweise haben die meisten anderen Agenten-Applikationen Agenten mit einem oder höchstens zwei festen Strategien. CABS- Agenten haben sehr viel mehr, wie es aus der Liste oben hervorgeht. Daher kann beispielsweise ein Agent ein erstes Koordinierungsprotokoll (z. B. die englische Auktion) verwenden, um irgendwelche Antiquitäten zu verkaufen, während gleichzeitig ein zweites Protokoll (z. B. niederländische Auktion) zum Verkaufen von Blumen verwendet wird und zur gleichen Zeit ein drittes Protokoll (das Kontaktnetz) für die Verteilung anderer Tasks verwendet wird.
  • Wenn ein Anwender eine Koordinierungsstrategie wünscht, die nicht durch das CABS-System bereitgestellt wird, so kann der Koordinierungseditor 330 verwendet werden, um einen neuen Koordinierungsgraphen zu der Koordinierungsgraphendatenbank 255 des Agenten hinzuzufügen. Wenn man das UCP als Anfangspunkt nimmt, so können neue Koordinierungsgraphen beispielsweise dadurch erzeugt werden, dass ein neuer Sub-Graph hinzugefügt wird, der neue Knoten zwischen einigen der existierenden Knoten in einem der vordefinierten Graphen einführt, und/oder dass einer oder mehrere der Bögen in einem vordefinierten Graphen modifiziert werden. Alternativ kann ein vollständig neuer Graph erzeugt werden, indem man dem Prozess folgt, der oben unter "2.4.1 Koordinierungs- Software-Modul: Definieren neuer Koordinierungsgraphen" beschrieben wurde. Der Hauptvorteil dieses neuen Ansatzes ist es, dass ein einfacher Kern (das UCP) beibehalten wird, während die Entwicklung und Installation wesentlich komplexerer Koordinierungstechniken vereinfacht wird. Neue Koordinierungsgraphen können aus Primitivroutinen zusammengesetzt werden, die vorhanden sind und auf UCP basieren, soweit sie die Beschränkungen erfüllen, die durch den Koordinierungseditor 330 vorgegeben sind. Der Editor 330 stellt sicher, dass der Konstrukteur eines neuen Protokolls das Folgende durchführt:
  • 1. Beginnen mit dem UCP,
  • 2. Identifizieren der Teile des UCP, wo es notwendig ist, die zusätzliche Komplexität zur Realisierung des neuen Protokolls hinzuzufügen,
  • 3. Definieren und Implementieren des neuen Graphen entweder durch Addieren eines Sub-Graphen oder durch Verfeinern der existierenden Bögen oder Knoten eines vordefinierten Graphen,
  • 4, falls neue Knoten oder Bögen definiert werden müssen, Verwenden von Anwendermustern hierfür, die durch den Editor 330 zur Verfügung gestellt werden.
  • Damit wählt und/oder entwickelt der Anwender bei jedem der in Schritt 1 identifizierten Agenten keine oder mehre Verhandlungs- /Koordinierungsstrategien, die der Agent aufrufen kann, und zwar über den Koordinierungseditor 330.
    • 4.5 Schritt 5: Task-Definition 520
  • Für jeden der in Schritt 2 identifizierten Tasks müssen bei jedem Agenten die folgenden Anwendereingaben über den Task-Beschrei- Beschreibungseditor 335 gemacht werden:
  • 1. Bestimmen der Durchschnittskosten und Dauer bei der Durchführung des Tasks.
  • 2. Ausführliche Liste von Variablen 550 mit allen Einheiten (Ressourcen), die erforderlich sind, bevor der Task durchgeführt werden kann.
  • 3. Ausführliche Liste mit Variablen 550 aller Einheiten (Produkte), die erzeugt werden, wenn der Task durchgeführt wird.
  • 4. Festlegen und Aufzeichnen aller Einschränkungen zwischen den verbrauchten Einheiten (Nr. 2 oben) und den erzeugten Einheiten (Nr. 3 oben) und innerhalb jeder Gruppe.
  • 5. Festlegen, ob der Task durchgeführt werden kann, indem eine Domain-Funktion (primitiver Task) direkt ausgeführt werden kann, oder ob es sich eigentlich um eine Zusammenfassung der Spezifizierung eines Netzes anderer Tasks handelt (d. h. ein Zusammenfassungs-Task).
  • 6. Falls der Task primitiv ist, Bereitstellen der beiden folgenden Funktionen, (a) Durchführen des Tasks (ein Rückaufruf 555) und (b) Berechnen der tatsächlichen Kosten des Tasks, wenn dieser durchgeführt wird. Bei Zusammenfassungs-Tasks muss eine Beschreibung des Zusammenfassungs-Tasks in Form der Task-Komponenten aufgestellt werden.
  • Tasks verbrauchen bestimmte Ressourcen zum Erzeugen ihrer Produkte, wobei jede Durchführung von Tasks ein endliches Zeitintervall beansprucht. Die CABS-Plattform stellt einen Variablen-Editor 355 zur Verfügung, bei dem eine Rahmenbasierende Objektattributwertdarstellung zum Definieren der verbrauchten und erzeugten Einheiten verwendet wird.
  • Die Beschränkungen zwischen und innerhalb der verbrauchten und erzeugten Einheiten dienen zum Beschränken jedes Tasks auf spezielle, wohl definierte Fälle. Zum Beispiel kann ein Task eine spezielle Ressource aufrufen, aber die Ressource kann einer Beschränkung für diesen speziellen Task unterliegen, wie z. B. in Bezug auf Prozesskapazität oder Ausrüstungstyp. Ein Beschränkungseditor 370 wird ebenfalls bereitgestellt, um Beschränkungen zwischen den Variablen zu beschreiben, damit sichergestellt wird, dass die Tasks realistische Variablen verwenden und dass jede Task-Ausgangsgröße der Eingangsgröße für die nächste Stufe gleicht. Dies kann erweitert werden auf das Setzen von Ungleichheiten, zum Beispiel indem man sagt, dass eine Ausgangsgröße beispielsweise nicht ganzzahlig/nicht-ganzzahhg sein soll.
  • Außerdem wird ein Zusammenfassungs-Task-(Plan-) Editor 365 für das Auflisten von Task-Komponenten des Zusammenfassungs-Tasks bereitgestellt. Dieser Editor ermöglicht es, dass Zusammenfassungs- Tasks (i) einfache Aktionen, (ii) mehrere optional parallele Aktionen, (iii) mehrere (zwangsläufig) parallele Aktionen, (iv) bewachte Aktionen (Selektionen) und (v) iterative Aktionen umfasst. Außerdem können diese Aktionen zu einem Netz mit der Möglichkeit, die Variablen an den Endpunkten jeder Verbindung einzuschränken, verbunden sein.
  • Im Folgenden wird ein Beispiel einer Task-Beschreibung angegeben, die unter Verwendung des Task-Beschreibungseditors 335 erzeugt wurde. Der Task beschreibt die Tatsache, dass zur Erzeugung einer Verbindung von A (?Link-141.from) nach B (?Link-141.to) eine Verbindung benötigt wird von A (?Link-131.from) zu einem Ort X (?Link- 131.to) und eine weitere Verbindung von X (?Link-136.from) nach B (?Link-136.to).
  • Die consumed_facts-Liste des Tasks enthält die Ressourcen, die zur Durchführung erforderlich sind, d. h. die Verbindungen von A nach X und von X nach B. Unter produced_facts ist die Ressource aufgelistet, die erzeugt wird, wenn der Task durchgeführt wurde, d. h. die Verbindung von A nach B. Die Einschränkungen spezifizieren die Beziehungen zwischen den verbrauchten und erzeugten Tatsachen. Beispielsweise spezifiziert die Einschränkung "?Link-141.from = ?Link131.from" die Bedingung, dass die Quelle der erzeugten Verbindung die gleiche sein sollte wie die Quelle von einer der erforderlichen Verbindungen. Diese und ähnliche Beschränkungen werden während der Laufzeit durch den Organisator 220 des Agenten durchgesetzt, wodurch sichergestellt wird, dass die Variable ?Link- 141.from zu demselben Token wie ?Link-131.from gehört.
  • Die Anordnung spezifiziert die Reihenfolge, in der die Vorbedingungen geprüft werden sollten. In diesem Fall wird festgestellt, dass der Organisator versuchen sollte, eine Ressource zu bekommen, die die Ressourcenbeschreibung?Link-131 erfüllt, bevor versucht wird, eine Ressource zu bekommen, die die Beschreibung?Link-136 erfüllt.
  • Eine Ressourcenbeschreibung consumed_fact, bei der das Umfangsfeld auf lokal gesetzt ist, ist ein Flag für den Organisator 220, das anzeigt, dass er nur versuchen sollte, die erforderliche Ressource lokal zu bekommen, d. h. die Ressource nicht an einen anderen Agenten auszulagern. Consumed_facts-Einträge mit globalen Umfangsfeldern können an andere Agenten für die Produktion ausgelagert werden. Wenn für produced_fact-Einträge das Umfangsfeld lokal ist, ist dies ein Signal für die Planungssteuerung, diesen Task nicht zu verwenden, wenn sie versucht, speziell dieses zu erreichen. Ein lokales Umfangsfeld zeigt an, dass der Task verwendet werden kann, wenn die Ressource erzeugt werden soll.
  • Im Folgenden wird ein Beispiel einer Task beschrieben:
  • Ein interessanter Aspekt der Definition von Tasks auf diese Art ist es, dass sich ein Optimum damit erreichen lässt. Beispielsweise werden durch Einfügen von Fristablaufbeschränkungen zusammen mit Ressourcendefinitionen inadäquate Ressourcen offensichtlich. Es kann für den Anwender des Systems tatsächlich notwendig werden, die verfügbare Ressource auszuweiten oder zu erweitern.
  • Wenn sich das Agenten-System als Beispiel mit der Verarbeitung von Anrufaufzeichnungsdaten in einem Telekommunikationssystem befasst, so kann der technische Prozess, der dabei eine Rolle spielt, wie folgt auf Tasks abgebildet werden:
  • i) Information im Anrufaufzeichnungszentrum eingegangen,
  • ii) Information nach Priorität sortiert,
  • iii) Information weitergeleitet an entsprechende Ressource/Leute und
  • iv) Ausnahmezustandsverarbeitung, z. B. "Ressource nicht verfügbar".
  • Wenn die Ausnahmezustandsbehandlung zu "Ressource nicht verfügbar" führt, kann es außerordentlich wichtig sein, dass eine weitere Ressource verfügbar gemacht wird. Dies kann der Fall sein, wenn das Anrufaufzeichnungszentrum Fehlererkennung unterstützt. Die Fristabläufe, um Netzkapazität für den Dienst zurückzuholen, können beispielsweise bei bestimmten Kategorien von Kunden nicht verlängerbar sein. Es wäre daher sehr wichtig für den Dienstanbieter, dass das Anrufaufzeichnungszentrum die Ressource zur Verfügung hat, um die Anrufaufzeichnungen innerhalb der Zeitbeschränkung durchführen zu können.
    • 4.6 Schritt 6: Gebietsspezifische Problemlösungscodeerzeugung 525
  • Um einen funktionalen, kooperativen Agenten zu erzeugen, muss das CABS-System realen Code erzeugen. Die Daten, die ein CABS- Agent erfordert, sind von zweierlei Art: Deklarierend und prozedural. Vordefinierte Objekte sorgen für die prozedurale Seite. Die deklarierende Information wird insgesamt über die Editoren und Task- Beschreibungen erfasst. Zur Kompilierungszeit eines Agenten kann aus Gründen, die alle Agenten wie z. B. die Mailbox 200 gemeinsam betreffen, der Codegenerator einfach eine Eins-zu-eins-Kopie des zu der Agentenoberfläche 300 gehörenden Codes machen. Für Informationen wie Task-und Ressourceninformation, die Agentenspezifisch ist, wird dies alles als Datenbank-Datei eins-zu-eins kopiert und bei der Kompilierung mit dem Mailboxcode etc. für jeden Agenten verbunden.
  • Das bedeutet, dass es bei allen definierten Agenten notwendig ist, alle Komponenten des Codes und Datenbanken zu erzeugen, in Ordnern zusammen mit Agentenbeziehungen, Koordinierungsmöglichkeiten und einem optionalen Visualisierungsprogramm eins-zu- eins zu kopieren und zu kompilieren. Effektiv bedeutet dies, eine Instanz der Objekte jedes Agenten einzurichten und dann die Beziehung und Koordinierungsinformation und Standardkomponenten hinzuzufügen.
  • Es ist außerdem notwendig für den Anwender, gebietsspezifischen Code bereitzustellen, um die Funktionalität des Tasks zu implementieren. D. h. der Anwender muss Code für alle Funktionen zum Berechnen von Kosten eines primitiven Tasks und zum Bereitstellen von Rückaufrufen 555 für die Steuerung externer Systeme bereitstellen. Dies erfolgt mittels Codegeneratoreditor 360.
  • Dies ist die einzige Stelle, an der der Entwickler einen ausführbaren Code definieren muss. CABS kann Prototypen für diese Funktionen definieren und stellt außerdem eine API-Bibliothek 380 für den Entwickler bei der Codeerzeugung zur Verfügung.
  • Die Ausgangsgröße von CABS 100 in der Form von Software-Agenten wird über Skripte 390 auf die Anwenderumgebung verteilt. Existierende Systeme können dann mit den Agenten unter Verwendung eines API einer Wrapper-Klasse, definiert durch das System, zum Einkapseln von Code von der Komponentenbibliothek zusammen mit Anwenderdaten verknüpft werden.
    • 5. DEBUGGEN UND VISUALISIEREN
  • Es ist schwierig, irgendein einzelnes Programm zu erzeugen, das keine Mängel oder Fehler aufweist, selbst wenn es ein Programm ist, das mit keinem anderen Programm interagiert. Es ist um Größenordnungen schwieriger, verteilte Software mit mehreren Agenten zu analysieren und zu debuggen. Das Verhalten, das sich bei der weit verteilten Software ergibt, kann sich wesentlich von dem unterscheiden, was erwartet wurde. Außerdem findet die Kommunikation oft auf einer solch hohen Ebene statt, dass es nicht möglich ist, involvierte Daten direkt zu untersuchen. Selbst ein Objektbasierendes System kann so konstruiert sein, dass es dem Programmierer möglich ist, die tatsächlichen Daten zu untersuchen, die in einer Sequenz von Ereignissen involviert sind, aber bei Agenten, die Nachrichtenbasierende Kommunikation verwenden, kann dies dem Programmierer einfach unmöglich sein.
  • Selbstverständlich ist es wichtig, zu analysieren, was falsch läuft, so dass es korrigiert werden kann. Ansätze bei singulären "Agenten"- Anwendungen können verwendet werden, sind aber häufig unzureichend bei der Analyse und beim Debuggen verteilter Software-Systeme. Beispielsweise kann eine Fehleranalyse als "Post mortem"- Vorgang durchgeführt werden, wenn die Daten zum Zeitpunkt des Fehlers gespeichert werden, wodurch sich später eine "Momentaufnahme" der vorherrschenden Umstände ergibt, auf die sich ein Versuch gründen kann, die Ursache des Fehlers herauszufinden. Ein bekannter Debugger, der in der internationalen Patentanmeldung WO93/24882 desselben Anmelders beschrieben wird, zeigt wie solche Daten in einer Ablaufdatei erfasst werden können und später in der Art eines Videos "abgespielt", "wiederholt", "rückgespult", "vorgespult" etc. werden können.
  • Ein solcher Ansatz kann unter bestimmten Umständen bei verteilter Software hilfreich sein, sicher aber nicht immer. Es gibt viele Fehlerklassen, die bei Multiagentensystemen auftreten. Es können strukturelle Fehler auf der Ebene von singulären Agenten innerhalb des Multiagentensystems sein, wie z. B. falsche oder fehlende Kenntnisstandbeziehungen zwischen den Agenten, fehlende Ressourcen, inkorrekt spezifizierte (üblicherweise zu kurze) Zeiten für den Ablauf von Tasks etc. Es können funktionale Fehler sein, d. h. Fehler, die sich auf die Logik der Tasks beziehen, die die Agenten durchführen. Dies kann verschleiert werden durch die Tatsache, dass individuelle Agenten "korrekt" funktionieren, aber das sich ergebende Verhalten des Gesamtaufbaus der verteilten Steuerungsagenten kann sich von dem erwarteten unterscheiden. Dies ist üblicherweise darauf zurückzuführen, was man Koordinierungsfehler nennen kann. In einigen Fällen kann ein solches Verhalten zu inkohärenten Multiagentensystemen führen.
  • Einige Beispiele dieser Art für unerwünschtes Verhalten bei solchen System sind die Folgenden:
  • - Deadlock: Agenten streiten sich um gemeinsame Ressourcen. Ein Agent kann eine vitale gemeinsame Ressource besitzen und aus irgendeinem Grund nicht zurückgeben, vielleicht auf Grund eines Fehlers, beispielsweise auf der Ebene des individuellen Agenten. Aber diese Ressource ist unschätzbar für andere Agenten, die "blockiert" sind, weil sie darauf warten, dass diese Ressource wieder freigegeben wird. Letztendlich bezieht sich Deadlock auf eine Sachlage, bei der weitere Aktionen zwischen zwei oder mehreren Agenten unmöglich werden.
  • - Livelock: Agenten agieren ohne Unterbrechung (interagieren oder tauschen Nachrichten aus), aber es wird kein Fortschritt bei der Lösung des gestellten Problems erzielt. Dies ist im allgemeinen der Fall, wenn die Agenten ihre Aktivitäten über dezentralisiertes Planen koordinieren. Hier können die Agenten undefiniert Planungsabschnitte austauschen, ohne dass sie dadurch notwendigerweise Fortschritte bei den Koordinierungsanstrengungen erzielen, insbesondere wenn es keine strukturellen Prüfungen gibt, um Endlosschleifen bei dem Planungsprozess zu erfassen und zu verhindern.
  • - Chaos: Chaotisches Verhalten ist bei einem verteilten Aufbau immer möglich.
  • Derartige Verhaltensweisen führen zusätzlich zu standardmäßigen "inkorrekten Verhaltensweisen oder Fehlern bei individuellen Agenten häufig zu unkoordinierten Verhaltensmustern. Natürlich sollte ein verteiltes Steuerungssystem normal koordiniert werden. Ein korrekt koordinierter Aufbau nutzt die Möglichkeiten der individuellen Agenten vollständig aus und minimiert Konflikte, Ressourcenstreitigkeiten und Redundanzen. Es ist daher klar, dass Koordinierung eine wünschenswerte Eigenschaft von Agenten-Systemen ist.
  • Wie auch das Debuggen ermöglicht die Visualisierung dem Anwender, das Verhalten des Systems zu bestätigen, zu verstehen, zu Steuern und/oder zu analysieren.
  • Visualisierungen vom unten beschriebenen Typ können Einrichtungen zum Analysieren und Debuggen solcher verteilter Steuerungssoftware bereitstellen, so dass die Verhaltensmuster, die man erzielt, so sind, wie sie sich der Konstrukteur denkt. Die Visualisierungen bilden ein generisches, anpassungsfähiges und skalierbares Visualisierungssystem für die Verwendung zusammen mit einem gebietsunabhängigen Tool-Kit zum Konstruieren von Multiagenten- Anwendungen. Der speziell beschriebene Visualisierer ist generisch in dem Sinne, dass er mit irgendeiner Applikation verwendet werden kann, die unter Verwendung des Tool-Kits entwickelt wurde, und anpassungsfähig in dem Sinne, dass er Baublöcke zum Konstruieren von applikationsspezifischen Visualisierern ermöglicht. Die Skalierbarkeitsbedingung bedeutet, dass die Visualisierung bei Systemen mit einer beliebigen Anzahl von Agenten bei beschränkter Leistungsbeeinträchtigung unterstützt werden sollte. Die Eigenschaft der Verteilung von Multiagenten-Applikationen macht es unbedingt erforderlich, dass der Visualisierer in der Lage sein sollte, entfernte Agenten über ein Großraumnetz zu visualisieren. Für administrative und Debug-Zwecke ist es außerdem wichtig, dass der Visualisierer sowohl online als auch offline funktioniert.
  • Bei Ausführungsformen des erfindungsgemäßen Visualisierers wird ein Arrangement zum Analysieren und Lokalisieren unbeabsichtigter Verhaltensweisen bei verteilten Steuerungssystemen bereitgestellt, wobei das Arrangement eine Folge von Tools umfasst, die alle verschiedene Blickwinkel in Bezug auf die Analyse des verteilten Steuerungssoftware-Systems bieten.
  • Alle unterschiedlichen Tools speichern verschiedene Zustandsdaten. Obgleich kein Tool in der Lage ist, eine vollständige Analyse des verteilten Systems zu bieten, wird dies doch möglich durch die Kombination eines Tools mit einem anderen. Andere Tools bieten oder empfehlen Diagnosen. Wo der Beweis eines Tools den von einem anderen Tool bekräftigt, steigt die Glaubhaftigkeit in diese Diagnose. Es besteht daher eine größere Wahrscheinlichkeit, dass die Diagnose zu einem erfolgreichen Debuggen des Problems führt. Wenn der Beweis widerspricht, kann die Kombination eines Tools mit einem anderen eine Hypothese eliminieren oder andere Diagnosen als möglich suggerieren.
  • Die Tools in der momentanen CABS-Visualisierer-/Debug-Tool- Abfolge umfassen:
  • - Gesellschafts-Tool: Dieses zeigt die Interaktionen (durchgeleitete Nachrichten) zwischen verschiedenen Agenten in der gesamten Gesellschaft. Dies beinhaltet ein videoartiges Tool für die spätere "Post mortem"-Analyse, das für das Aufnehmen von Nachrichten geeignet ist, die zwischen verschiedenen Agenten weitergeleitet werden. Diese Nachrichten werden in einer Datenbank gespeichert, mit der relationale Abfragen für tiefergehende Studien der Interaktionen durchgeführt werden können. Dieses Tool kann zum Analysieren entweder eines einzelnen Agenten oder einer Gesellschaft von Agenten verwendet werden.
  • - Statistik-Tool: Dieses erfasst verschiedene Statistiken bezüglich individueller Agenten (z. B. die Typen und die Anzahl der Nachrichten, die durch Agenten ausgetauscht werden). Beispielsweise beantwortet es Fragen wie "Wie viele Nachrichten wurden von Agent A an Agent B während einer bestimmten Zeit gesendet?" oder "Nenne mir die Zahl der Nachrichten, die Agent A während einer bestimmten Zeit empfangen hat" etc. Das Statistik-Tool bietet zusätzlich zu verschiedenen Graphen Torten- und Balkenvisualisierung individueller Agentenaktivitäten. Mit sowohl dem Video- als auch dem Statistik-Tool kann man die interessierenden Agenten auswählen und ihre aufgezeichneten Agentenzustände genauer studieren. Dieses Tool kann verwendet werden, um entweder einen einzelnen Agenten oder eine Gesellschaft von Agenten zu analysieren.
  • - Mikro-Tool: Dieses zeigt mit einem gewissen Grad an Abstraktion die inneren Vorgänge eines Agenten. Tatsächlich ist der Konstrukteur häufig allein durch Beobachtung des Mikro-Tools in der Lage zu sagen, ob der Agent "tot", "endgültig blockiert" oder "aktiv" ist; alternativ kann festgestellt werden, ob Teile der inneren Vorgänge des Agenten aus irgendeinem Grund fehlerhaft arbeiten.
  • - Report-Tool: Dieses bietet eine GANTT-Darstellung des Gesamt-Tasks, den ein Agent beispielsweise steuert. Üblicherweise listet ein Agent die Hilfe und Dienstleistungen vieler anderer Agenten auf, und dieses Tool erlaubt es dem Konstrukteur, einen speziellen Agenten und einen Task (von möglicherweise vielen Tasks), den der Agent steuert, auszuwählen. Dadurch wird in einer GANTT-Darstellung gezeigt, wie der Task zerlegt wurde (d. h. welches die Sub-Tasks sind), welche Tasks ihm zugeordnet wurden, bis wohin die Ausführung des Tasks erfolgte und was die Zustände der verschiedenen Sub-Tasks sind (z. B. arbeitend, fehlgeschlagen, angehalten oder wartend).
  • - Kontrollmonitor-Tool: Dies ist ein sehr wichtiges administratives Tool, das verwendet wird, um alle Agenten zu stoppen, einige Agenten anzuhalten oder einige der Tasks anzuhalten oder fehlzuleiten, die sie durchführen, um das sich ergebende Ausnahmezustandsverhalten etc. zu studieren. Dies ist auch ein wichtiges Test- und Debug-Tool in dem Sinne, dass bestimmte Agenten von der Gesellschaft etc. angehalten und abgebrochen werden können, so dass spezielle Agenten näher studiert werden können.
  • Der Visualisierer 140 umfasst einen Software-Agenten mit demselben allgemeinen Rahmen wie irgendein anderer der kooperativen Agenten in dem CABS-System. Er hat die Möglichkeit, Daten von anderen Agenten in dem System abzuziehen. Er ist passiv in dem Sinne, dass er nicht mit anderen Agenten verhandelt, aber er registriert sich selbst bei dem Namensserver 135 und visualisiert sich auch selbst.
  • In Fig. 10 umfasst die Gesamtarchitektur des Debug-/Visualisierungs-Softwaremoduls 140 einen zentralen Hub aus einer Mailbox 1000, einem Nachrichtenverwalter 1005, einer Nachrichtenkontextdatenbank 1010 und einer Tool-Startplattform 1015. Der Hub hat eine Gruppe von Tool-Vorgaben 1020 zur Verfügung.
  • Die Mailbox 1000 bietet die Möglichkeit des Nachrichtenaustauschs zwischen Debugger/Visualisierer 140 und anderen Agenten, wobei die übliche Agentenkommunikationssprache verwendet wird, die in diesem Fall KQML ist.
  • Die Tool-Plattform 1015 startet (auf Veranlassung durch den Anwender) Instanzen der verschiedenen Tools in der Tool-Gruppe, nämlich die Instanzen der Gesellschafts-, Statistik-, Mikro-, Report- und Steuerungs-Tools. Es gibt eine große Anzahl von Dimensionen, entlang derer ein Multiagentensystem visualisiert werden kann. Die Entwicklung eines einzigen komplexen Tools, das alle verschiedenen Visualisierungsmoden unterstützt, könnte dazu führen, dass der Visualisierer schwierig zu nutzen ist, unflexibel ist und schwierig zu warten ist: Daher wird eine Folge von Tools verwendet, nämlich die Tool-Gruppe, bei der jedes Tool eine gemeinsame Sicht und Gespür hat und für einen einzigen Visualisierungs-Task ausgelegt ist. Alle Tools werden von dem zentralen Hub gestartet und haben eine gemeinsame Schnittstelle mit dem Hub. Auf diese Art kann der Visualisierer leichter gewartet werden und ist ohne weiteres erweiterbar. Die Gruppe der Tools, die ausgewählt wurden, umfasst solche, die sich als besonders nützlich für das Visualisieren, Steuern und Debuggen eines Multiagentensystems herausgestellt haben.
  • Zunächst sendet der Visualisierer 140 Anfragen an andere Agenten nach Daten, die jene enthalten. Er fragt den Namensserver 135 nach Agentenadressen und verwendet dann diese Adressen. Der Nachrichtenverwalter 205 des empfangenden Agenten leitet in Abhängigkeit davon, wo die interessierenden Daten sich befinden, die empfangene Anfrage korrekt weiter. Daten, die von dem Visualisierer 140 von den anderen Agenten empfangen werden, werden gespeichert, geholt und für eine entsprechende Anzeige verarbeitet.
  • Der Visualisierer 140 kann außerdem Daten in einem Agenten installieren. Er kann daher verwendet werden, um das Verhalten eines Agenten zu modifizieren. Dies wird unten genauer beschrieben.
  • Der Nachrichtenverwalter 1005 des Visualisierers 140 bearbeitet ankommende Nachrichten, die von der Mailbox 1000 empfangen wurden, und liefert sie an Tool-Instanzen aus, die sich für Nachrichten dieses Typs interessieren. Tool-Instanzen zeigen ihr Interesse am Empfang von Nachrichten eines bestimmten Typs dadurch an, dass sie die Nachrichtenkontextdatenbank 1010 verwenden, die von dem Nachrichtenverwalter 1005 bei der Verarbeitung abgefragt wird. Damit wird jede Tool-Instanz, die am Empfang von Reportnachrichten eines bestimmten Typs von einer Gruppe von Agenten interessiert ist, als erstes unter Verwendung der Mailbox 1000 eine Anfrage, an diejenigen Agenten abschicken, dass sie Reportnachrichten an den Debugger/Visualisierer 140 senden mögen, wann immer Ereignisse dieser Art auftreten (unter Verwendung von "if, then" als Steuerungsbefehl), und zweitens werden sie in der Nachrichtenkontextdatenbank 1010 ihr Interesse an dem Empfang von Kopien aller ankommenden Reportnachrichten des gewünschten Typs anzeigen. Dieses Arrangement ermöglicht es einem Anwender des Debuggers/Visualisierers, während der Laufzeit die Gruppe von Ereignissen dynamisch zu setzen, die für die Überwachung interessant sind, und diese Gruppe auch zu jeder Zeit zu ändern.
  • Insbesondere werden reply_with (abgehende Nachricht) und in_reply_to (ankommende Nachricht) von KQML in den Dateien verwendet, um jeder Nachricht eine Identifizierung zuzuordnen, die eindeutig in Bezug auf Tool-Instanzen und Ereignistypen ist. Auf diese Art braucht der Nachrichtenverwalter nicht die Inhalte der Nachricht durchzusehen, um festzustellen, welche Tool-Instanz sie erfordert. Dieses Arrangement ermöglicht es den Anwendern des Visualisierers, die Gruppe der Ereignisse während der Laufzeit festzulegen, die für sie bezüglich Überwachung interessant ist, und die Gruppe auch zu jeder Zeit zu ändern. Außerdem macht die Erweiterung der Tool-Folge um ein neues Tool und/oder die Überwachung eines neuen Ereignistyps keine Modifikation der Basisinfrastruktur notwendig.
  • Der Visualisierer 140 ist kein vollständiger Datenspeicherraum für ein Agenten-System. Er speichert Daten nur über einen bestimmten Zeitraum, z. B. zwei Tage. Wenn der Anwender Daten permanent speichern möchte, so muss er diese z. B. in dem Videotool in dem Gesellschafts-Tool abspeichern. Der Zeitrahmen, innerhalb dessen der Visualisierer 140 Daten hält, wird beeinflusst durch die Größe, Aktivität und Komplexität des CABS-Agenten-Systems, und wenn es z. B. zu viele Agenten gibt, muss der Visualisierer 140 unter Umständen erweitert werden.
  • Der Visualisierer 140 liefert lediglich einen historischen Ablauf; er verzögert die Echtzeitaktivität des Systems. Es ist möglich, dass der Visualisierer 140 Nachrichten in der falschen Reihenfolge empfängt. Um Fehlinterpretationen zu vermeiden, ist der Visualisierer 140 mit einem beschränkten Puffer 1025 ausgestattet, der Nachrichten in ihrer korrekten Zeitabfolge neu organisiert. (Es ist zu beachten, dass die Nachrichten folglich unbedingt einen Zeitstempel zugeordnet bekommen.)
  • In Fig. 12 ist bei einem einfachen implementierten Szenario das Gebiet eine Versorgungskette, bei der die Agenten kooperieren, um als eine Dienstleistung Gegenstände herzustellen und/oder bereitzustellen. Fig. 12 zeigt eine Ansicht der Domain, die durch das Gesellschafts-Tool erzeugt werden kann. In dem Beispiel gibt es fünf Hauptagenten. C, ein Computerhersteller, hat zwei Zulieferer M und U. M stellt Monitore her und kennt C als seinen Abnehmer und U als Nebenlieferanten. U stellt zentrale Prozessoreinheiten (CPUs) her und kennt auf gleiche Weise C als Abnehmer und M als Nebenlieferanten. Sowohl M als auch U haben zwei Zulieferer (X und Y). C kennt einen weiteren Agenten P als Gleichgestellten, der Druckertinte und Tonerkartuschen herstellt. P hat als Zulieferer T, der Druckertinte und Tonerkartuschen herstellt.
  • Nebenlieferanten sind Agenten in derselben Organisation, die keine hierarchische Beziehung untereinander haben, während Gleichgestellte Agenten sind, die zu unterschiedlichen Organisationen gehören.
  • In dem Beispiel bedingt die Herstellung eines Computers eine Basiseinheit (CPU und Monitor) sowie einen geeigneten Drucker.
  • In der Umgebung gibt es drei zusätzliche Unterstützungsagenten: einen Agenten, der als Namensserver (ANS) ein Telefonbuch für die Aufsuche von Agenten-Adressen zur Verfügung stellt, einen Broker- Agenten (PC_Broker), der ein Gelbe-Seiten-Buch zur Verfügung stellt, über das Agenten andere Agenten ausfindig machen, die einen Task ausführen können, und einen Datenbank-Proxy-Agenten (DB), dessen einzige Funktion darin besteht, Nachrichten von Eigentumsdatenbanken auf Anfrage des Visualisierers zu speichern und zu holen. Diese Agenten kommunizieren auch in der allgemeinen Agenten-Kommunikationssprache (ACL). Schließlich gibt es den Visualisierer-Agenten selbst (Visual).
  • Die Verwendung eines der Tools in der Folge macht es erforderlich, dass die Anwender mit einem oder mehreren Namensservern verbunden werden, wenn das Tool gestartet worden ist. Bei einem Multiagentensystem enthalten die Namensserver die Namen und Adressen aller "lebenden" Agenten in der Umgebung. Damit bedeutet die Verbindung mit einem Namensserver das Absenden einer Anfrage an den Namensserver, alle Agenten in der Umgebung sowie alle später zugeschalteten Agenten aufzulisten. In einer Umgebung mit vielen Namensservern kann der Anwender wählen, mit welchem er verbunden werden möchte, wodurch der Visualisierungsaufwand effektiv auf eine Untermenge von interessierenden Agenten eingeschränkt wird.
    • 5.1 Das Gesellschafts-Tool
  • Das Gesellschafts-Tool des Visualisierers sendet drei Arten von Anfragen aus. Gesellschafts-Tool-Nachrichten
  • In Fig. 12 wird es einem Anwender durch das Gesellschafts-Tool ermöglicht, eine Gruppe von Agenten auszuwählen und (a) die strukturellen Organisationsbeziehungen und (b) den Nachrichtenaustausch zwischen ihnen darzustellen. Dazu wird auf die Kenntnisstandmodelle 215 in den individuellen Agenten zugegriffen. Es kann auch ein Flag gesetzt werden, das bewirkt, dass die Nachrichtenverwalter 205 der Agenten alle Nachrichten an den Visualisierer 140 kopieren.
  • Um (a) oder (b) anzuzeigen, verwenden die Anwender Menüs, um Anfragen an bezeichnete Teilmengen zu senden, womit angefragt wird, dass sie die Tool-Instanz in Bezug auf das gegenwärtige Wissen über die Organisationsbeziehungen aktualisieren, oder um Kopien aller ihrer abgehenden Nachrichten an die Tool-Instanz zu senden.
  • Die Organisationsbeziehungen beschreiben die Rollen als Abnehmer, Zulieferer, Nebenlieferant oder Gleichgestellter. Die Kenntnis dieser Beziehungen ist beim Debuggen wichtig, da sie die Agenten bei der Koordinierung ihrer Aktivitäten beeinflussen. Beispielsweise können die Agenten so konfiguriert werden, dass sie alle Tasks zunächst selbst durchzuführen versuchen, wenn das fehlschlägt, an Zulieferer delegieren, wenn das fehlschlägt, an Nebenlieferanten abgeben, und nur wenn das fehlschlägt, an Gleichgestellte abgeben. Das Tool unterstützt die Graphische Darstellung der Agenten je nach ihrer Rolle. Momentane Darstellungen beinhalten eine vertikale Darstellung (wie in Fig. 12 dargestellt), bei der die vertikale Abnehmer- Zuliefererbeziehung betont wird, eine horizontale zirkulare Darstellung, bei der Nebenlieferanten betont werden und Gruppen von Nebenlieferanten in Kreisen angeordnet werden, eine horizontale zirkulare Darstellung, bei der Gleichgestellte betont werden und Gruppen von Gleichgestellten in Kreisen angeordnet werden, und eine einzelne Agentenzentrierte Darstellung, bei der alle anderen Agenten um einen vom Anwender bezeichneten zentralen Agenten zentriert sind. In den Darstellungsgraphen werden die Verbindungen zwischen den Agenten je nach ihrer Rolle farbcodiert. Es sind Möglichkeiten vorgesehen, Knoten der verschiedenen Graphen zu kooperieren, zu expandieren, zu verbergen und anzuzeigen. Die verschiedenen Darstellungen sind wichtig, insbesondere wenn sie mit dem Nachrichtenmerkmal des Tools verwendet werden, da sie dem Anwender erlauben, ohne weiteres die Organisationsstruktur der Agenten anzuzeigen und den Fortschritt der Koordinierung innerhalb dieser Struktur darzustellen. Dieses ermöglicht es, Fehler entweder in der Art der Organisation der Agenten oder in der Art der Fortschreitung der Koordinierung innerhalb der Organisation zu identifizieren.
  • Man beachte, dass kein einzelner Agent notwendigerweise ein vollständiges Bild der Organisationsstruktur besitzen muss. Dies fällt in die Verantwortlichkeit des Gesellschafts-Tools, das die lokale Information, die durch die Agenten zurückgeschickt wird zu einem globalen Bild der Organisation zusammengesetzt.
  • Nachrichten zwischen Agenten können farbcodiert werden (für die einfache Darstellung), indem nach Typ eingeteilt wird, z. B. alle Anfragenachrichten in einer Farbe, oder nach Inhalt eingeteilt wird, z. B. alle Nachrichten in einer Farbe, die zu einem bestimmten Job gehören. Zusätzlich unterstützt das Tool das Filtern der Nachrichten vor der Darstellung. Nachrichten können nach Sender, Empfänger, Typ oder Inhalt gefiltert werden. Zum Beispiel kann eine Filteroption sein "Zeige nur Gegenvorschlagsnachrichten [Typfilterung] von der Gruppe von Agenten ... [Senderfilter] an die Gruppe von Agenten ... [Empfängerfilter] in Bezug auf Job ... [Inhaltsfilter]". Diese Merkmale vereinfachen das Debuggen, indem dem Anwender erlaubt wird, sich auf die besonders interessierenden Nachrichten zu konzentrieren. Außerdem bieten sie ein leistungsfähiges Debug-Tool, in der Art eines Videos kombiniert mit Offline-Wiedergabemöglichkeiten mit Vorspul- und Rückspulmoden (was als nächstes diskutiert wird).
  • Wie bereits erwähnt, bietet das Gesellschafts-Tool außerdem die Möglichkeit der Abspeicherung in einer Datenbank für die spätere Wiedergabe von Nachrichten, die von Agenten gesendet und empfangen wurden. Wiederum können Nachrichtenfilter beim Speichern und/ oder bei der Wiedergabe verwendet werden, um bestimmte Nachrichten auszuwählen, die interessieren. Wiedergabemöglichkeiten unterstützen die Videoäquivalenz, so dass ein Anwender die Nachrichten vorwärts oder rückwärts, im Einzelschritt oder als Animation ansehen kann. Da außerdem die Nachrichten in einer relationalen Datenbank gespeichert sind, können Anwender normale (z. B. relationale) Datenbankabfragen bezüglich der gespeicherten Nachrichten machen, z. B. "Wie viele Nachrichten hat Agent A in Bezug auf Job 21 abgeschickt?". Die Videowiedergabemöglichkeiten mit Nachrichtenfiltern und der Unterstützung von Datenbankabfragen steigern für einen Anwender die Wirksamkeit beim Debuggen erheblich, da sie es ermöglichen, sich ein-oder auszublenden und dynamisch die Perspektiven zu ändern, während versucht wird, die Interaktionen zwischen den Agenten zu verstehen.
  • In der Graphischen Anwenderschnittstelle in Fig. 12 ist die Darstellung von Agenten 1200 in der Versorgungskette sichtbar, die das oben beschriebene Szenario bereitstellt. Links in dem Fenster befinden sich Darstellungs-und Anzeigesteuerungselemente 1210. Über Toolbar-Schalter 1220 auf der rechten Seite lässt sich die Wiedergabe von Nachrichten in der Art eines Videos steuern, während sich über die auf der linken Seite 1230 sowie einem Pop-up-Menü 1240 die Position und Sichtbarkeit von Agentensymbolen steuern lässt.
  • Die tatsächliche Speicherung von Nachrichten in einer Datenbank erfolgt durch Öffnen einer Verbindung zu einem Datenbank-Proxy- Agenten und Absenden von Kopien der Nachrichten, die gespeichert werden sollen, an ihn. Das Holen erfolgt auf ähnliche Art, allerdings in umgekehrter Richtung. Dieses Arrangement bietet einen flexiblen Ansatz, da jedes proprietäre Datenbanksystem verwendet werden kann, indem man es einfach über eine Schnittstelle mit einem Standard-Proxy verbindet, der die Agentenkommunikationssprache versteht und in ihr kommuniziert.
    • 5.2 Report-Tool
  • Bei einem kooperativen Multiagentenaufbau ist es im Allgemeinen das Verhalten der Gesellschaft als Ganzes (d. h. der kombinierten Eingangsgrößen aller Agenten), die wichtig ist, und nicht das eines individuellen Agenten. Ein typisches Problem beim Debuggen von Multiagentensystemen entsteht aus der Tatsache, dass jeder Agent nur eine lokale Ansicht des Aufwandes der Gesellschaft bei der Problemlösung bietet.
  • Jeder Agent hat nur Kenntnisse über Jobs und Teiljobs, die durch ihn und/oder ihm zugeordnet sind. Kein einzelner Agent hat Daten bezüglich der Gesamtaufgliederung und des Zustandes aller Jobs.
  • Um zum Beispiel einen Computer herzustellen, kann der Agent C einen Teil dieser Aufgabe an P abgeben, der einen Laserdrucker bereitstellt. P seinerseits kann einen Teil dieses Auftrags an T abgeben, der eine Tonerkartusche bereitstellt. Wegen der Autonomie der individuellen Agenten kennt C nur den Teil des Tasks, der zur Durchführung geplant ist, und dieser Teil wird abgegeben an P; keine Kenntnis ist vorhanden über den Teil, der von P an T delegiert wurde. Damit erhält ein Anwender, der einen der Agenten isoliert betrachtet, ein unvollständiges Bild des Aufwandes der Gesellschaft bei der Problemlösung. Wenn somit zum Beispiel C einen Fehlschlag beim Durchführen des Tasks anzeigt, ist der Anwender nicht in der Lage, beispielsweise unmittelbar die Wurzel dieses Fehlschlags zu erkennen, nämlich dass T die Tonerkartusche nicht wie von P gefordert geliefert hat.
  • Das Report-Tool kann die relevanten Daten von jedem der Agenten abfragen, vergleichen und anzeigen. Das Report-Tool wendet den im folgenden erläuterten Algorithmus an, um die Daten zu vergleichen und ein vollständiges Bild zu erzeugen, was dann in einer GANTT- Darstellung wie in Fig. 7 gezeigt werden kann.
  • In Fig. 8 ist zu beachten, dass bei diesem Tool ein Job J für einen Agenten A aufgeteilt werden kann in Teiljobs J1 und J2, die den Agenten B und C zugeordnet sind. Der Teiljob J2 kann weiter in J21, J22, J23 aufgeteilt werden und weiteren Agenten E, F und G zugewiesen werden. Der Teiljob J1 kann ebenfalls aufgespaltet werden, wobei der Agent B die Verantwortung für einen Teiljob J11 behält, aber einen Teiljob J12 dem Agenten D zuweist.
  • Wichtig ist es, sicherzustellen, dass jeder oberste Job, wie zum Beispiel der Job J, eine eindeutige Identifizierung aufweist, die selbst dann aufrechterhalten wird, wenn Teiljobs (und Teil-Teiljobs etc.) dieses obersten Jobs erzeugt werden. Dies wird bei jedem Agenten mittels der Zusagetabelle aus Fig. 9 und als Ergebnis der Entscheidungen durch die Koordinierungsmaschine und das Bewertungssystem 210 gespeichert. Wenn also der Agent A einen Job mit der Identifizierung "J" in die Teiljobs J1 und J2 aufspaltet und sie an andere Agenten zuweist, dann halten diese anderen Agenten die Identifizierung "J" aufrecht, selbst wenn sie die Teiljobs (J1, J2 etc.) in weitere Teiljobs aufspalten und sie weiteren Agenten zuordnen. Man beachte, dass ein Teiljob "J1" seinen eigenen Identifizierungen "1" zusätzlich "J" hinzugefügt hat, um aufzuspüren, woher er stammt, wenn er weiter zerlegt wird, und dies trifft auch zu, wenn ein Teiljob wie "J1" weiter in "J11" und "J12" zerlegt wird. In diesem Fall werden die beiden Identifizierungen "J" und "1" beibehalten.
  • Damit kann das Report-Tool unter Verwendung einer Wurzel-Ziel- Identifizierung und von Eltern-Kind-Verbindungen eine globale Task-Zerlegung über die Gesellschaft graphisch darstellen. Tatsächlich wird derselbe Mechanismus bei dem Gesellschafts-Tool verwendet, um Nachrichten je nach Ziel farbig zu codieren.
  • Daher ist der Algorithmus des Report-Tools für die Verarbeitung der Daten (die von allen Agenten geholt wurden) der folgende:
  • i) Für irgendeinen Agenten "A": Wähle einen Job/ein Ziel zu diesem Agenten;
  • ii) hole den eindeutigen Identifizierungen für das Ziel, zum Beispiel "J";
  • iii) versuche alle anderen Jobs/Ziele mit diesem Identifizierungen zu finden und gib sowohl Jobs/Ziele als auch ihre Beziehungen (mit Bezug auf das ausgewählte Ziel "J") zurück;
  • iv) stelle die Beziehungen (und Zustände) wie in Fig. 7 graphisch dar.
  • In Fig. 7 wird nun das Szenario mit den drei Agenten A, B und E betrachtet. Um einen Job, zum Beispiel J1, durchzuführen, kann der Agent A einen Unterabschnitt (J11) dieses Jobs an Agenten B delegieren, der seinerseits einen Unterabschnitt (J111) von J11 an den Agenten E delegiert. Wegen der Autonomie der individuellen Agenten hat der Agent A nur Kenntnis von dem Unterabschnitt von J1, den er durchführen soll, und dem Unterabschnitt (J11), den er an den Agenten B delegiert hat. Er hat keine Kenntnis von dem Unterabschnitt (J111), der von dem Agenten B an den Agenten E delegiert wurde. Damit erhält ein Anwender, der einen der Agenten isoliert betrachtet, ein unvollständiges Bild des Aufwandes der Gesellschaft bei der Problemlösung. Wenn also zum Beispiel der Agent A einen Fehlschlag bei der Durchführung von J1 berichtet, ist der Anwender nicht in der Lage, sofort bei Darstellung von Agent A festzustellen, dass der letztendliche Grund des Fehlschlags darin lag, dass der Agent E J111 nicht durchgeführt hat.
  • Das Report-Tool bietet eine globale Ansicht der Problemlösung in einer Gesellschaft von Agenten und ist nützlich sowohl als Debug- als auch als Verwaltungs-Tool. Damit wird einem Anwender ermöglicht, eine Gruppe von Agenten auszusuchen und aufzufordern, den Zustand aller ihrer Jobs an ihn zu melden. Als nächstes kann der Anwender einen interessierenden Agenten und einen Job von diesem Agenten auswählen. (Ein Agent besitzt einen Job, wenn er diesen Job oder einen Unterabschnitt an einem Wurzelknoten in einer Task-Zerlegungshierarchie des Jobs durchführen soll.) Für die Auswahl des Agenten und des Jobs erzeugt das Report-Tool die GANTT- Darstellung 700 nach Fig. 7 mit der Zerlegung 560 des Jobs, Zuordnung der Bestandteile an unterschiedliche Agenten in der Gemeinschaft und relevante Zustände des Jobs und der Unterabschnitte. Andere Attribute des Jobs können ebenfalls in der Darstellung gezeigt werden, so zum Beispiel wann jeder Agent seinen Abschnitt durchführen soll, ihre Kosten, die Priorität, die durch die Agenten zugeordnet wurde, und die erforderlichen Ressourcen.
  • In Fig. 13 kann, wenn man auf den obigen Task "Computerherstellung" zurückgreift, die GANTT-Darstellung 700 auf einem Bildschirm mit Auswahlkästen für das Auswählen des Agenten und des Tasks für die Darstellung angezeigt werden. Wie gezeigt, wurden die Auswahlkästen 1305, 1310 verwendet, um den Task "Computerherstellung" für den Agenten C 1300 auszuwählen. Die GANTT- Darstellung 700 zeigt die Zerlegung des Tasks "Computerherstellung" in Tonerkartuschenherstellung (Agent T) 1315, Monitorherstellung (Agent M) 1325, CPU-Herstellung (Agent U) 1320 und Druckerherstellung (Agent P) 1316. Der Task-Zustandsschlüssel 1335 zeigt farbcodiert (nicht sichtbar in Fig. 13), dass die Tonerkartuschenherstellung und Monitorherstellung 1315, 1325 laufen, die CPU-Herstellung 1320 beendet ist und die Druckerherstellung und Computerherstellung 1316, 1300 warten. Ein Dialogkasten 1330 wurde eingefügt, um Einzelheiten der Tonerkartuschenherstellung 1315 zu zeigen.
  • Das Report-Tool benötigt daher Zugang beispielsweise zu den Task- Zerlegungen 560 und zu der Zusagendatenbank 24S bei jedem Agenten.
  • Wie erwähnt zeigt die Jobgraphik des Report-Tools außerdem den momentanen Zustand jedes Unterabschnitts des Jobs, d. h. wartend, arbeitend, beendet oder fehlgeschlagen. Damit kann auf Grund der Graphik durch einen Anwender sofort der Gesamtstatus eines Jobs bestimmt werden, und wenn ein Job fehlschlägt, wo genau - was offensichtlich der Debug-Effizienz zugute kommt. Für die einfache Sichtbarmachung können verschiedene Zustände eines Jobs in der Graphik farbcodiert werden.
  • Fig. 7 zeigt als Ganzes einen Task-Report 700 für den Job J1 des Agenten A. Der Unterabschnitt J111 (Agent E) schlug fehl, während J12 (Agent C) bearbeitet wird und J13 (Agent D) beendet wurde. J11 (Agent B) und J1 (Agent A) warten, aber wegen des Fehlschlags bei J111 werden beide fehlschlagen, es sei denn, es wird etwas unternommen, um J111 auf andere Art erfolgreich auszuführen.
  • Das Tool bietet dem Anwender außerdem Möglichkeiten zum Kooperieren/Expandieren von Sektionen der Graphik und für das Verbergen/Anzeigen von Knoten in der Graphik - dies ist wichtig bei der Handhabe von sehr großen Graphiken, da sich ein Anwender in interessierende Bereiche einblenden kann, wodurch Einzelheiten reduziert werden, durch welche die Debug-Anstrengung behindert werden können.
  • Der Algorithmus zur Sicherstellung der korrekten Zusammenstellung von Task-Beschreibungen in Graphen beruht auf zwei Tatsachen: Erstens weist der Agent, auf den das Ziel zurückgeht, dem Ziel eine systemweite, eindeutige Identifizierung zu, der über die Task- Zerlegungshierarchie des Ziels weitergereicht wird. Zweitens werden, wann immer ein Agent einen Task in Sub-Tasks zerlegt, eindeutige Identifizierungen für die Sub-Tasks erzeugt und die Identifizierungen bei dem Eltern-Task abgespeichert (dies erfolgt unabhängig davon, ob andere Agenten die Sub-Tasks durchführen). Damit kann unter Verwendung der Wurzel-Ziel-Identifizierungen und der Eltern- Kind-Verbindungen das Report-Tool die globale Task-Zerlegung über die Gesellschaft graphisch darstellen. (In der Tat wird derselbe Mechanismus in dem Gesellschafts-Tool verwendet, um Nachrichten je nach Zielen farbig zu codieren.) Derselbe Mechanismus ermöglicht außerdem die Anzeige von vereinigten Graphen, wo zwei Task- Zerlegungsgraphen durch einen oder mehrere Tasks verbunden werden. Dies geschieht, wenn Nebenaspekte eines Tasks in einem Zielzerlegungsgraphen in einem anderen verwendet werden.
  • Ähnlich dem Gesellschafts-Tool unterstützt das Report-Tool auch Online-Einbuchung der Reportnachrichten in eine Datenbank sowie eine anschließende Offline-Wiedergabe.
    • 5.3 Mikro-Tool
  • In Fig. 14 ermöglicht es das Mikro-Tool einem Anwender, einen einzelnen Agenten auszuwählen, in der Darstellung ist dies Agent C, und seine momentanen Daten und Nachrichten darzustellen, die von verschiedenen Komponenten des Agenten gesendet und empfangen wurden. Beispielsweise kann man die letzen zehn Nachrichten für eine ausgewählte Komponente anzeigen. Die Betrachtung von Verknüpfungen in der Mailbox kann zur Wiedergabe von Nachrichten, die gerade für die Verschickung bearbeitet werden, oder kürzlich empfangenen Nachrichten dienen. Betrachtet werden kann:
  • 1. "Nachrichteneingangsschlange" 1400: Die jüngsten empfangenen Nachrichten, die noch bearbeitet werden müssen.
  • 2. "Nachrichtenausgangsschlange" 1405: Zu versendende Nachrichten.
  • 3. "Nachrichtenverwalterzusammenfassung" 1410: Zusammenfassung von Reaktionen auf ankommende Nachrichten, zum Beispiel an welches Modul des Agenten die Nachricht für die Verarbeitung im Einzelnen weitergeleitet wurde.
  • 4. "Koordinierungsgraph" 1415: Darstellung des dynamischen Zustands bei der Ausführung von der Koordinierungsmaschine, um den Fortschritt bei der Realisierung irgendeines Ziels anzuzeigen. Wenn es mehrere Ziele gibt, die der Agent zu erreichen versucht, kann der Anwender ein spezielles auswählen, um seinen Fortschritt anzuzeigen. Wenn jeder Knoten 1420 in dem Graphen bearbeitet wird, wird dies GRÜN angezeigt. Wenn der Knoten fehlschlägt, wird dies ROT angezeigt.
  • 5. "Ausführungsmonitorzusammenfassung" 1425: Ein Logbuch mit den Einzelheiten der Tasks, die der Agent durchzuführen zugesagt hat, sowie des momentanen Zustands dieser Tasks (d. h. wartend, arbeitend, beendet oder fehlgeschlagen), z. B. kann der Monitor einen Task anzeigen, der wegen fehlender Ressourcen nicht gestartet wurde (beispielsweise Ergebnisse kamen nicht oder zu spät von einem anderen Agenten an), oder er kann die Ausführung eines Tasks anzeigen, der abgebrochen wurde, da bei ihm die zugewiesene Prozessorzeit überschritten wurde.
  • 6. "Ressourcendatenbankzusammenfassung" 1430: Zusammenfassung der Ressourcen, die der Agent verwaltet. Hier kann auch angezeigt werden, welche frei sind, welche zugeordnet worden sind und an wen.
  • 7. "Zusagetabelle" 1435: Darstellung, wie die Tasks geplant sind. Dies ist eine Zusammenfassung der Ergebnisse bei der Überwachung der Ausführung von Tasks oder bei Tasks, deren Ausführung begonnen werden soll; zum Beispiel kann der Monitor einen Task anzeigen, der nicht begonnen werden konnte, da Ressourcen fehlten, oder es kann die Ausführung eines Tasks angezeigt werden, der gestoppt wurde, da die zugeordnete Prozessorzeit überschritten wurde. Wie gezeigt hat der Agent C zum Zeitpunkt 4 den Task Computerherstellung fest zugesagt.
  • Das Mikro-Tool bietet einem Anwender eine genauere Darstellung der internen Verarbeitung eines Agenten und trägt damit offensichtlich zum Debuggen bei. Zum Beispiel kann das Anzeigen der Ausführung von Tasks, die abgebrochen wurden, da sie die ihnen zugeordnete Prozessorzeit überschritten, einem Anwender mitteilen, dass der zeitliche Aufwand für die Durchführung dieser Tasks unterschätzt wurde. (Es wird angenommen, dass Anwender/Entwickler die Prozessorzeit für jeden Task, die von dem Agenten benötigt wird, beim Planen seiner Aktivitäten konservativ abschätzen.)
  • Als weiteres Beispiel wird ein Anwender bei Betrachtung des momentanen Zustands der Koordinierungsarbeit bei einem Job (auf Grund der Graphischen Darstellung des Koordinierungsprozesses) in die Lage versetzt, beispielsweise zu ergründen, warum der Job durch den Agenten zurückgewiesen wurde. Da jeder Knoten des Koordinierungsgraphen einen speziellen Zustand des Prozesses anzeigt, informiert die Spur eines Jobs in dem Graphen den Anwender über die meisten Dinge, die über die Koordinierung dieses Jobs bekannt sein müssen. Auf Grund der Spur kann ein Anwender schließen, dass beispielsweise Job-0 fehlschlug, da eine bestimmte Ressource erforderlich war, die der Agent nicht hatte; darüber hinaus konnte der Agent keinen anderen Agenten finden, der die Ressource innerhalb der gewünschten Quantität, Zeit, Kosten und anderer Einschränkungen bereitstellen konnte.
    • 5.4 Das Kontrollmonitor-Tool
  • Es bietet die folgenden Funktionen:
  • Durchsuchen (Browse-through)
  • Hinzufügen
  • Modifizieren
  • Löschen
  • Diese Funktionen wirken sich auf momentane Ziele, Jobs, Ressourcen, Tasks, organisatorische Beziehungen und Wissen sowie Koordinierungsstrategien aus. Andere Funktionen beinhalten:
  • Anhalten (von Jobs oder Agenten)
  • Wiederaufnehmen (von Jobs oder Agenten)
  • Abbrechen (von Agenten)
  • Diese letzteren drei erfolgen durch Absenden von Anfragenachrichten an diese Agenten mit dem Inhalt, wie er oben erläutert wurde (z. B. eine Aufforderung anzuhalten).
  • Das Kontrollmonitor-Tool arbeitet wiederum in Beziehung zu einzelnen Agenten. Es sorgt für eine Online-Version der originalen Herstellungsmöglichkeiten von CABS für Agenten.
  • Das Kontrollmonitor-Tool erlaubt es einem Nutzer, einen interessierenden Agenten auszuwählen und bezüglich seiner momentanen Jobs, Ressourcen, Tasks, organisatorischen Beziehungen und seines Wissens sowie seiner Koordinierungsstrategien zu durchsuchen, hinzuzufügen, zu modifizieren oder zu löschen. Außerdem kann der Anwender Jobs anhalten oder wieder starten und genauso sogar Agenten anhalten, wieder starten oder abbrechen. Eine Möglichkeit besteht außerdem für den Anwender darin, verschiedene Parameter eines Agenten abzustimmen, so zum Beispiel wie lange er auf Antworten von anderen Agenten warten muss, bevor er annimmt, dass keine Antwort erfolgt, oder wie der Agent seine Zeit zwischen der Durchführung von Tasks, die er bereits zugesagt hat, und der Koordinierung neuer Tasks aufspalten sollte. Da verschiedene Multiagentensysteme oder Anwendungen verschiedene Ontologien oder Datenverzeichnisse verwenden, um Dateneinträge zu spezifizieren, ermöglicht es dieses Tool den Anwendern, eine Ontologiedatenbank 260 zu laden, die die Ontologien der spezifischen Systeme oder Applikationen definiert.
  • Das Kontrollmonitor-Tool ist nützlich beim Debuggen und/oder Analysieren des Verhaltens einer Gesellschaft von Agenten, indem es einem Anwender gestattet, die Gesellschaft dynamisch neu zu konfigurieren und ihr anschließendes Verhalten zu analysieren. Dies ist von Nutzen, wenn Hypothesen getestet werden sollen. Der Anwender kann hiervon Gebrauch machen, um die Effekte verschiedener Änderungen bezüglich der Konstitution des Agenten, organisatorischer Beziehungen, Koordinierungsverhaltens etc. zu studieren. Beispielsweise kann ein Agent entgegen den Erwartungen einen Job konsequent ablehnen, für den er bereits adäquates Wissen (Task) besitzt, jedoch die erforderlichen Ressourcen nicht hat, obgleich es andere Agenten in der Gesellschaft gibt, die die erforderlichen Ressourcen zur Verfügung stellen können. Unter Verwendung des Kontrollmonitor-Tools zum Durchsuchen der Tasks und Ressourcen des Agenten kann sich ein Anwender vergewissern, dass der Agent das Wissen besitzt, jedoch nicht die Ressourcen. Die Überprüfung der Liste von Koordinierungsstrategien des Agenten kann beispielsweise ergeben, dass der Agent die Koordinierungsfähigkeit zum Abgeben der Produktion der erforderlichen Ressource an andere Agenten in dem Aufbau besitzt. Da der Agent trotzdem den Job ablehnt, kann der Anwender zwei Hypothesen aufstellen, entweder (A) weiß der Agent von anderen Agenten in der Gesellschaft, die die erforderliche Ressource zur Verfügung stellen können, nichts, oder (B) die Beschränkung der Zeit, während der der Agent auf die Akzeptierung nach Absenden von Jobanfragenachrichten an andere Agenten wartet, ist kleiner als die Zeit, die von diesen Agenten benötigt wird, um zu entscheiden, ob sie einen Job annehmen oder nicht. Das Durchsuchen der organisatorischen Beziehungen und des Wissens des Agenten mittels des Kontroll-Tools kann die Hypothese (A) bestätigen oder widerlegen, und wenn man wiederum mit diesem Tool die Wartezeit des Agenten auf eine Annahme vergrößert, so kann dies die Hypothese (B) bestätigen oder widerlegen.
  • Andere Tools, wie zum Beispiel das Mikro- oder Gesellschafts-Tool, können auch zusammen mit dem Kontrollmonitor-Tool verwendet werden, um diese Hypothesen zu untersuchen. Der Anwender kann unter Verwendung des Gesellschafts-Tools beispielsweise herausfinden, ob der Agent Jobanfragenachrichten aussendet - was die Hypothese (A) widerlegt; und unter Verwendung des Mikro-Tools kann der Anwender herausfinden, ob der Agent bei der Koordinierung des Jobs an dem Knoten nach der Wartezeit auf Annahme vorbeigeht, bevor Antworten auf seine Jobanfragenachrichten empfangen worden sind - was die Hypothese (B) bestätigt.
  • Ein Browser-Fenster für das Kontroll-Tool kann es beispielsweise ermöglichen, dass ein Anwender Task-Spezifikationen von Agenten in einer Gesellschaft aus der Ferne durchsucht, hinzufügt, löscht und/oder modifiziert. Ein solches Fenster kann Auflistungskästchen für die Agenten in der Gesellschaft, die Gruppe von Task des gegenwärtig ausgewählten Agenten und den Status des ausgewählten Tasks aufweisen. Ein Textbereich kann die Spezifikation des momentan ausgewahlten Tasks anzeigen. "Modifzieren" und "Hinzufügen" können die Bezeichnungen von Schaltflächen sein, die einen Task-Spezifikationseditor starten, durch den eine existierende Task- Spezifikation modifiziert werden kann oder ein neuer Task definiert werden kann. Der Status der Tasks wird auf OK gesetzt, wenn die Task-Definition in dem Tool die gleiche wie die in der Task- Datenbank des relevanten Agenten ist, so weit dies dem Tool bewusst ist. Ein Statuswert UNBEKANNT zeigt an, dass der Anwender die Task-Spezifikation modifiziert hat, aber der Agent bisher noch keine Bestätigung für den Eingang der neuen Spezifikation zurückgesandt hat.
  • Das Kontroll-Tool ist nützlich beim Debuggen und/oder Analysieren des Verhaltens einer Gesellschaft von Agenten, indem es einem Anwender ermöglicht, die Gesellschaft dynamisch neu zu konfigurieren und ihr anschließendes Verhalten zu analysieren. Das bedeutet, es wird möglich, dass das Agenten-System während der Laufzeit neu definiert wird.
  • Die Stärke des Kontroll-Tools beruht auf der Verwendung von Nachrichten auf hoher Ebene bei der Kommunikation, vielleicht KQML und dessen verwandte Sprachen. Bei Nachrichten auf höherer Ebene können neue Spezifikationen irgendeines Verhaltens an einen Agenten geschickt werden, und es ist Aufgabe des Agenten, die Spezifikation in die relevante Funktionalität zu übersetzen. Würde man Objektebenenbenachrichtigung verwenden, ginge eine solche Dynamik sofort verloren. Eine Analogie ist die Beziehung zwischen interpretierten Sprachen wie Prolog und Lisp, die dynamische Neudefinition von Programmverhalten bieten, und kompilierten Sprachen wie C++ und Fortran, bei denen das nicht der Fall ist.
  • Wegen der verschiedenen Multiagentensysteme können bei Anwendungen verschiedene Ontologien oder Datenverzeichnisse zur Spezifizierung von Dateneinträgen verwendet werden, wobei es dieses Tool dem Anwender gestattet, eine ontologische Datenbank zu laden, die die Ontologie der speziellen Anwendung definiert.
    • 5.5 Statistik-Tool
  • In Fig. 15 ermöglicht dieses Tool einem Anwender, verschiedenen Statistiken bezüglich einer Gesellschaft von Agenten auf einer Agentenbasis oder auf einer Gemeinschaftsbasis zu vergleichen. Die gesammelten Statistiken können beispielsweise, aber nicht ausschließlich aufweisen:
  • (a) Die Zahl und die Art der Nachrichten, die durch Agenten in einem Zeitintervall verschickt werden,
  • (b) die Zahl von Nachrichten, die von Agenten bei der Koordinierung verschiedener Jobs verschickt werden,
  • (c) die mittlere Belastung der Agenten, d. h. das Verhältnis der Zeit, die die Agenten zur tatsächlichen Ausführung von Tasks benötigen, und
  • (d) das Verhältnis der Zeit der Koordinierung zur Ausführung, d. h. wie viel Zeit gegenüber ihrer eigentlichen Laufzeit aufgewendet wird, um Tasks zu koordinieren.
  • Statistiken wie diese sind besonders hilfreich beim Debuggen oder bei der Feinabstimmung der Leistungsfähigkeit einer Gesellschaft von Agenten. Wenn man z. B. das Kontrollmonitor-Tool und das Statistik-Tool verwendet, ist ein Anwender eher in der Lage, die Fragen, wie "Welche organisatorische Struktur und Verteilung von Tasks und Koordinierungswissen minimiert am ehesten die Zeit, die zum Koordinieren von Jobs verwendet wird, und maximiert die Zeit, die für ihre Ausführung benötigt wird (d. h. Erhöhung des Profits der Gesellschaft)" zu beantworten. Wenn die Agenten in der Gesellschaft aus Erfahrung lernen, wird das Statistik-Tool umso nützlicher bei der Abschätzung der Leistungsfähigkeit von verschiedenen Lernstrategien, da bestimmte Statistiken wie die mittlere Anzahl von Nachrichten, die durch den Agenten pro Job abgeschickt werden, und/oder die Koordinierung gegenüber der Ausführung als Zeitverhältnis als Leistungsmaß zum Messen des Lernerfolges herangezogen werden können.
  • Die spezielle Bildschirmdarstellung in Fig. 15 zeigt den Umfang des Verkehrs 1500, der auf die Hauptagenten U, T, P, M, C zurückzuführen ist, die das Ziel Computerherstellung haben. Wie aus der Task-Zerlegung 700 in Fig. 13 zu erwarten ist, sendet Agent C drei Nachrichten "Durchgeführt" ab, während Agent P nur eine auswirft. Die Antwortnachrichten entsprechen der Verhandlung und Nachverhandlung (Task-Management).
  • Das Tool kann verschiedene Anzeigeformate für die Darstellung von Statistiken unterstützen, wie zum Beispiel Histogramm, Torte, Linie oder xy-Streugraphik. Die Wahl des Formats hängt vom Anwender ab, der sie über Toolbar-Schaltflächen 1505 trifft, wobei es vordefinierte Anfangsformate für die verschiedenen Statistiken gibt.
  • Ähnlich den Gesellschafts- und Report-Tools unterstützt das Statistik-Tool Einsparungen in Bezug auf die Datenbank und Wiedergabe von Agenten-Statistiken in der Art eines Videos. Der Verallgemeinerung wegen werden nur Agentenrohdaten (gegenüber verarbeiteten) in der Datenbank gespeichert, so dass bei der Wiedergabe jede beliebige relevante Statistik neu erzeugt werden kann.
    • 5.6 Ein erweitertes Beispiel
  • In Fig. 8 bieten Tools eine sogar noch größere Unterstützung beim Debuggen und bei der Analyse, indem der Anwender einen Blick aus mehreren Richtungen auf das Verhalten des Agenten erhält, wenn sie in Kombination mit anderen Tools verwendet werden, während jedes oben beschriebene Tool von Nutzen ist als Hilfe beim Debuggen, wenn es isoliert verwendet wird. Zur Erläuterung wird unten ein erweitertes Beispiel für die Verwendung von verschiedenen Tools zum Abschätzen von verschiedenen Aspekten des Verhaltens des Agenten bei einem Debug-Problem beschrieben.
  • Es wird eine Multiagentengesellschaft mit sieben Agenten A bis G betrachtet, wie es in Fig. 8 gezeigt ist. Der Anwender geht davon aus, dass die Agenten konfiguriert wurden, so dass bei einem Job J für den Agenten A die Zerlegung des Jobs über die Gesellschaft wie dargestellt vorangehen würde; d. h. J1 an Agent B, J2 an Agent C, J12 an Agent D etc. Wenn jedoch der Job J an den Agenten A übergeben wird, meldet dieser einen Fehlschlag beim Planen des Jobs.
  • Um dieses Problem zu debuggen, kann der Anwender beispielsweise das Gesellschafts-Tool verwenden, insbesondere die Nachrichtenabspeicherung, die Wiedergabe als Video und die Filtermöglichkeiten, um die Koordinierungsaktivitäten der Agenten anzusehen, wenn der Job J dem Agenten A vorgelegt wird. Der Anwender stellt zum Beispiel fest, dass Agent A wie erwartet eine Anfrage (Vorschlagsnachricht) an den Agenten B schickt, um J1 zu bearbeiten, und eine andere Anfrage (Vorschlagsnachricht) an den Agenten C, um J2 zu bearbeiten. Wie erwartet schickt Agent B wieder eine Anfrage an den Agenten D aus, um J12 zu bearbeiten. Agent C jedoch sendet keine Anfrage aus, obgleich erwartet wurde, dass er drei davon aussendet.
  • In einer Wiederholung des Szenarios stellt man unter Verwendung des Mikro-Tools zur Ansicht der inneren Vorgänge von Agent C auf Grund der Spur des Koordinierungsgraphen für Job J2 fest, dass J2 erfolgreich zerlegt wurde in J21, J22 und J23, aber der Koordinierungsprozess fehlschlug, weil kein Agentenkandidat für die Abgabe von J2 gefunden werden konnte. Unter Verwendung des Kontrollmonitor-Tools zum Ansehen der organisatorischen Beziehungen und des Wissens von Agent C stellt man fest, dass sich keine Einträge zum Spezifizieren von Agenten, die J2 bearbeiten könnten, in der organisatorischen Wissensbasis von Agent C finden - damit wird ein Eintrag in die organisatorische Wissensbasis von C hinzugefügt, um diesen "Fehler" zu beheben.
  • Das Problem wird nochmals gestartet, und dieses Mal meldet der Agent A den Erfolg bei der Verteilung des Tasks über die Gesellschaft, meldet aber später einen Fehlschlag auf Grund unzureichender Ressourcen, als er tatsächlich seinen Unterabschnitt des Jobs ausführen will.
  • Unter Verwendung des Report-Tools stellt der Anwender bei einer Wiederholung fest, dass nach der erfolgreichen Zerlegung des Problems über die Gesellschaft die Agenten E, F, G und C erfolgreich begannen und bis zur Beendigung ihrer jeweiligen Unterabschnitte des Jobs liefen. Jedoch versagte der Agent D bei der Bearbeitung von J12, was wiederum zu einem Versagen von Agent B bei der Bearbeitung von J1 führte und dies seinerseits zu der des Agenten A bei der Bearbeitung von J.
  • Der Anwender wiederholt das Szenario und verwendet das Mikro- Tool zur Überwachung des Agenten D. Es wird beobachtet, dass D erfolgreich mit J12 beginnt, aber später anhält, da J12 die zugewiesene Prozessorzeit überschritten hat (was durch eine Ausführungsmonitornachricht angegeben wird). Der Kontrollmonitor wird verwendet, um die Definition von J12 zu modifizieren, so dass die abgeschätzte Laufzeit erhöht wird.
  • Das Szenario wird erneut wiederholt, und dieses Mal läuft alles bis zum Ende.
  • Alternativ kann der Task J12 für die Ausführung Zeit gehabt haben, er gab jedoch die falschen Ausgangsgrößen aus (d. h. der Task war falsch spezifiziert). In diesem Fall erkennt das Tool nicht, dass J12 die Zeit überschritt, und der Task muss durchgesehen und korrigiert werden.
  • Bei einem anderen Fehlerszenario kann mit demselben Arrangement der Agenten wie in Fig. 8 das Statistik-Tool stattdessen zeigen, dass der Agent C tatsächlich zwei Anfragen (Vorschlagsnachrichten) in Bezug auf den J2-Task abschickt, obgleich drei Anfragen erwartet wurden. Jetzt kann man die Hypothese aufstellen, dass der Grund für den Fehlschlag bei Agent C liegt, möglicherweise auf Grund eines oder der beiden folgenden Zusammenhänge:
  • (i) Ein Fehler bei der Spezifikation von dem J2-Task. Die Task- Spezifikation sollte {J21,J22,J23} = {J2} sein, d. h. gegeben sind J21, J22 und J23, dann wird J2 erzeugt. Wenn es einen Fehler in der Spezifikation gibt, zum Beispiel {J29,J22,J23} = {J2}, dann gäbe es zwei Vorschlagsnachrichten, die für die Jobs J22 und J23 ausgesendet werden, aber keine äquivalente Vorschlagsnachricht für J29. Der Agent C sendet keine Vorschlagsnachricht für Job J29, da er keinen anderen Agenten kennt, der J29 erzeugen kann.
  • (ii) Ein Fehler in der Spezifikation der Kenntnisstanddatenbank von Agent C. Wenn man annimmt, dass der Task korrekt spezifiziert wurde, dann ist der wahrscheinlichste Grund dafür, dass die dritte Vorschlagsnachricht nicht abgesendet wurde, dass (einmal mehr) kein Agent in der Kenntnisstanddatenbank von C aufgeführt ist, der in der Lage wäre, den dritten Job zu erledigen.
  • Die Gesamthypothese, dass der Fehlschlag auf Agent C zurückzuführen ist, kann beispielsweise verifiziert werden unter Verwendung es Mikro-Tools für die Ansicht der inneren Vorgänge von Agent C. Beispielsweise kann man feststellen, dass auf Grund der Spur des Koordinierungsgraphen der Agent C die Aktivitäten in J2 nicht planen oder koordinieren konnte, und somit ist diese Hypothese bestätigt.
  • Wenn man die Hypothesen (i) und (ii) betrachtet, so kann das Kontroll-Tool verwendet werden, um aus der Ferne die Task- Spezifikationsdatenbank von Agent C anzusehen. Wenn dies korrekt ist, ist (i) eliminiert. Um die Hypothese (ii) zu bestätigen, kann das Kontroll-Tool verwendet werden, um die Kenntnisstanddatenbank von Agent C direkt anzusehen, womit alle Spezifikationen in Bezug auf J21, J22 und J23 überprüft werden (durch Durchsuchen der Kenntnisstanddatenbank von Agent C unter Verwendung eines Task-Browser-Fensters des Kontroll-Tools).
  • Wenn die Kenntnisstanddatenbank groß ist, ist es in einer Alternative möglich, das Gesellschafts-Tool zu verwenden, um die Nachrichten anzusehen, die durch den Agenten C abgesendet worden sind. Es kann dabei aufgedeckt werden, dass der Agent C Nachrichten an die Agenten F und G für die Durchführung der Jobs J22 und J23 abgeschickt hat. Jetzt steht mit einiger Sicherheit fest, dass der Fehlschlag bei der Durchführung von Job J auf einen Spezifizierungsfehler in der Kenntnisstanddatenbank von Agent C in Bezug auf J21 (das Ziel) und Agent E zurückzuführen ist. Dies kann bestätigt werden durch Verwendung des Kontroll-Tools, um die Kenntnisstanddatenbank von Agent C anzusehen und zu modifizieren.
  • Man beachte, dass die Folge von Tools, die oben beschrieben wurde, nicht jede mögliche Fehlerursache in einem Multiagentensystem detektieren kann, das sie überwacht, aber das Debuggen wird dadurch sehr viel leichter.
  • Obgleich in Beziehung auf das obige spezielle CABS- Multiagentensystem beschrieben, können eines oder mehrere der Debug-Tools leicht auch bei anderen Multiagentensystemen eingesetzt werden, die auf anderen Architekturen, Agenten, Beziehungen und Sprachen basieren. Es wäre lediglich notwendig, dass die Agenten des/der Debug-Tools des Multiagentensystems, bei dem ein Debug-Vorgang durchgeführt wird, in der Lage sind, Nachrichten und andere Informationen in der gleichen Art wie zum Beispiel Task- Spezifikationen zu verstehen, so dass von dem/den Debug-Tool/s verstanden wird, was die Nachrichten betreffen, und die andere Information angesehen und verbessert werden kann.
  • Ausführungsformen der vorliegenden Erfindung können in Beziehung auf einen weiten Bereich von Multiagentensystemen verwendet werden. Beispielsweise wurden insbesondere die folgenden Anwendungen evaluiert:
  • - ein Reisemanagementsystem mit 17 Agenten, bei dem ein Reisemanageragent mit Hotel-, Fluglinien-, Auto-, Zug- und Taxireservierungsagenten verhandelt, um eine Route für eine Überseereise eines Anwenders auszuhandeln.
  • - ein Telekommunikationsnetzsystem mit 27 Agenten. Hier verhandeln Agenten, die die Netzwerkverbindungen Steuern, um virtuelle private Netze für Anwender bereitzustellen. Für diese Anwendung wurde das Report-Tool sehr einfach Anwender orientiert, um ein anderes Anzeigeformat für die Task-Zerlegungsgraphen zu unterstützen.
  • - ein elektronisches Handelssystem, bei dem Agenten Gegenstände und Dienstleistungen kaufen und verkaufen unter Verwendung von verschiedenen Verhandlungsstrategien. Diese Anwendung wies über 100 Agenten auf, die simultan viele verschiedene Tasks durchführten, und die Farbcodierung der Nachrichten nach Ziel war essentiell für das Verständnis der Interaktionen zwischen den Agenten.
  • Obgleich verschiedene Sprachen und Hardware-Elemente je nach verschiedenen Umständen geeignet sein können, so können doch Ausführungsformen der vorliegenden Erfindung vollständig in der Java-Programmiersprache implementiert werden und unter Unix laufen, zum Beispiel auf Solaris- und Windows-NT-Workstations.

Claims (7)

1. Modul für ein Software-System für verteilte Steuerung, Überwachung und/ oder Verwaltung eines Prozesses oder einer Vorrichtung mit
i) einer Kommunikationseinrichtung zum Kommunizieren mit anderen derartigen Software-Modulen,
ii) einer Koordinierungseinrichtung (210) für das Koordinieren der Zuordnung von Tasks unter Software-Modulen mit den anderen derartigen Software-Modulen,
iii) einem Datenspeicher (230) oder Zugriff auf einen Datenspeicher zum Speichern von Task-Definitionsdaten einschließlich Zeitdaten, die die Task-Ausführungszeit angeben, und
iv) einer Ablaufsteuerungseinrichtung (220) für die Ablaufsteuerung eines Tasks, wobei die Ablaufsteuerungseinrichtung so ausgelegt ist, dass Daten (245) gespeichert werden, die unter der wenigstens einen Task-Definition ausgewählt wurden, einschließlich der Zeitdaten für die jeweilige Task-Definition oder - Definitionen, die dem Task entsprechen,
wobei die Koordinierungseinrichtung ausgelegt ist, um eine Anfrage, dass ein Task (J) ausgeführt wird, zu empfangen, wobei der Task die Verwendung einer oder mehrerer Ressourcen umfasst, und
die Ablaufsteuerungseinrichtung so betrieben werden kann, dass in Abhängigkeit von dem Empfang der Anfrage identifiziert wird, ob dem Modul die oder jede der angeforderten Ressourcen zur Verfügung steht oder nicht, und wenn angenommen wird, dass die oder jede der angeforderten Ressourcen zur Verfügung steht, den Task zu planen.
2. Modul nach Anspruch 1, bei dem die Koordinierungseinrichtung ausgelegt ist, eine Anfrage zu erzeugen, wenn angenommen wird, dass die oder irgendeine der angeforderten Ressourcen nicht zur Verfügung steht, und die erzeugte Anfrage an wenigstens eines der anderen Module zu senden.
3. Modul nach einem der vorangehenden Ansprüche, bei dem die Ablaufsteuerungseinrichtung für ein Modul Daten von mehr als einer Task-Definition speichern kann, wobei die Daten so angeordnet werden, dass die Reihenfolge festgelegt wird, in der das Modul den relevanten Task beim Betrieb des Systems steuert oder ausführt.
4. Modul nach Anspruch 3, bei dem die Ablaufsteuerungseinrichtung ausgelegt ist, um die Task- Daten zusammen mit einem Zustandsindikator, der aus wenigstens zwei alternativen Zuständen wie "versuchsweise" und "sicher" ausgewählt ist, abzuspeichern, wobei der Zustandsindikator die Art festlegt, in der die Ablaufsteuerungseinrichtung die relevanten Task-Daten behandelt.
5. Modul nach Anspruch 4, bei dem die Ablaufsteuerungseinrichtung ausgelegt ist, um eine Zeitbegrenzung in Bezug auf Task-Daten mit einem der Zustandsindikatoren zu bewirken, nach der die Daten durch die Planungseinrichtung gelöscht und/oder durch nachfolgende ankommende Daten überschrieben werden können.
6. Modul nach Anspruch 5, bei dem die Ablaufsteuerungseinrichtung ausgelegt ist, um Ressourcen durch Abspeichern von Daten von mehr als einer Task- Definition zu überbuchen, wobei das Abspeichern von Daten zeitliche Beschränkungen in Bezug auf die gleiche Ressource oder gleichen Ressourcen überlappt.
7. Modul nach einem der vorangehenden Ansprüche, bei dem die Ablaufsteuerungseinrichtung außerdem ausgelegt ist, um Task-Definitionsdaten von zwei oder mehreren Tasks abzuspeichern, so dass wenigstens ein Teil der zwei oder mehreren Tasks gleichzeitig durch jedes der Module abgearbeitet werden kann, wenn das Software-System zwei oder mehrere derartige Module umfasst.
DE69808633T 1997-07-25 1998-07-27 Ablaufsteuerung für ein softwaresystem Expired - Lifetime DE69808633T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP97305601 1997-07-25
PCT/GB1998/002237 WO1999005594A1 (en) 1997-07-25 1998-07-27 Scheduler for a software system

Publications (2)

Publication Number Publication Date
DE69808633D1 DE69808633D1 (de) 2002-11-14
DE69808633T2 true DE69808633T2 (de) 2003-06-12

Family

ID=8229436

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69808633T Expired - Lifetime DE69808633T2 (de) 1997-07-25 1998-07-27 Ablaufsteuerung für ein softwaresystem

Country Status (6)

Country Link
US (1) US6263358B1 (de)
EP (1) EP0996887B1 (de)
AU (1) AU735024B2 (de)
CA (1) CA2297935A1 (de)
DE (1) DE69808633T2 (de)
WO (1) WO1999005594A1 (de)

Families Citing this family (153)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3892558B2 (ja) * 1997-12-16 2007-03-14 富士通株式会社 エージェント装置及びプログラム記録媒体
US6484155B1 (en) * 1998-07-21 2002-11-19 Sentar, Inc. Knowledge management system for performing dynamic distributed problem solving
US7020878B1 (en) 1998-08-28 2006-03-28 Oracle International Corporation System for allocating resource using the weight that represents a limitation on number of allowance active sessions associated with each resource consumer group
US7526767B1 (en) 1998-08-28 2009-04-28 Oracle International Corporation Methods for automatic group switching according to a resource plan
US7451448B1 (en) 1998-08-28 2008-11-11 Oracle International Corporation Methods for selectively quiescing a computer system
US6393433B1 (en) * 1998-09-24 2002-05-21 Lucent Technologies, Inc. Methods and apparatus for evaluating effect of run-time schedules on performance of end-system multimedia applications
US7386586B1 (en) * 1998-12-22 2008-06-10 Computer Associates Think, Inc. System for scheduling and monitoring computer processes
US7730172B1 (en) * 1999-05-24 2010-06-01 Computer Associates Think, Inc. Method and apparatus for reactive and deliberative service level management (SLM)
US7114154B1 (en) * 1999-07-26 2006-09-26 Mark Ira Crohn Automating time sequenced tasks
US6766348B1 (en) * 1999-08-03 2004-07-20 Worldcom, Inc. Method and system for load-balanced data exchange in distributed network-based resource allocation
US7200563B1 (en) * 1999-08-20 2007-04-03 Acl International Inc. Ontology-driven information system
US7137116B2 (en) * 1999-11-09 2006-11-14 Microsoft Corporation Method and system for performing a task on a computer
US6859927B2 (en) * 1999-12-21 2005-02-22 Lockheed Martin Corporation Apparatus and method for controlling allocation of resources and task execution
US7260635B2 (en) * 2000-03-21 2007-08-21 Centrisoft Corporation Software, systems and methods for managing a distributed network
USRE42153E1 (en) * 2000-03-30 2011-02-15 Hubbard Edward A Dynamic coordination and control of network connected devices for large-scale network site testing and associated architectures
US6963897B1 (en) * 2000-03-30 2005-11-08 United Devices, Inc. Customer services and advertising based upon device attributes and associated distributed processing system
US8010703B2 (en) * 2000-03-30 2011-08-30 Prashtama Wireless Llc Data conversion services and associated distributed processing system
US20090216641A1 (en) * 2000-03-30 2009-08-27 Niration Network Group, L.L.C. Methods and Systems for Indexing Content
US20040103139A1 (en) * 2000-03-30 2004-05-27 United Devices, Inc. Distributed processing system having sensor based data collection and associated method
US20090222508A1 (en) * 2000-03-30 2009-09-03 Hubbard Edward A Network Site Testing
US20010039497A1 (en) * 2000-03-30 2001-11-08 Hubbard Edward A. System and method for monitizing network connected user bases utilizing distributed processing systems
US7092985B2 (en) * 2000-03-30 2006-08-15 United Devices, Inc. Method of managing workloads and associated distributed processing system
US7093252B1 (en) * 2000-04-12 2006-08-15 International Business Machines Corporation Self-submitting job for testing a job scheduling/submitting software
US6785889B1 (en) * 2000-06-15 2004-08-31 Aurema, Inc. System and method for scheduling bandwidth resources using a Kalman estimator with active feedback
US7409356B1 (en) * 2000-06-21 2008-08-05 Applied Systems Intelligence, Inc. Method and system for intelligent supply chain collaboration
US7177827B1 (en) * 2000-10-06 2007-02-13 I2 Technologies Us, Inc. Generating an order plan for a supply chain network
CA2322604C (en) * 2000-10-06 2005-06-28 Ibm Canada Limited - Ibm Canada Limitee Deadlock management in database systems with demultiplexed connections
US6990667B2 (en) 2001-01-29 2006-01-24 Adaptec, Inc. Server-independent object positioning for load balancing drives and servers
US7054927B2 (en) * 2001-01-29 2006-05-30 Adaptec, Inc. File system metadata describing server directory information
US6862692B2 (en) 2001-01-29 2005-03-01 Adaptec, Inc. Dynamic redistribution of parity groups
US20020169827A1 (en) * 2001-01-29 2002-11-14 Ulrich Thomas R. Hot adding file system processors
EP1246097A1 (de) * 2001-03-29 2002-10-02 BRITISH TELECOMMUNICATIONS public limited company Arbeitszuweisungssystem
US20030055895A1 (en) * 2001-08-27 2003-03-20 Peters Charles A. Internet based system designer with live agent assist
US6895575B2 (en) * 2001-06-20 2005-05-17 Sap Ag Generic Java rule engine framework
US6961740B2 (en) * 2001-08-01 2005-11-01 Valaran Corporation Method and system for multimode garbage collection
US6985871B2 (en) * 2001-08-10 2006-01-10 United Parcel Service Of America, Inc. Systems and methods for scheduling reoccurring deliveries and pickups
US8024395B1 (en) 2001-09-04 2011-09-20 Gary Odom Distributed processing multiple tier task allocation
US6880002B2 (en) * 2001-09-05 2005-04-12 Surgient, Inc. Virtualized logical server cloud providing non-deterministic allocation of logical attributes of logical servers to physical resources
US7441016B2 (en) * 2001-10-03 2008-10-21 Accenture Global Services Gmbh Service authorizer
US7472091B2 (en) * 2001-10-03 2008-12-30 Accenture Global Services Gmbh Virtual customer database
US7640006B2 (en) * 2001-10-03 2009-12-29 Accenture Global Services Gmbh Directory assistance with multi-modal messaging
US7254384B2 (en) * 2001-10-03 2007-08-07 Accenture Global Services Gmbh Multi-modal messaging
US7233655B2 (en) * 2001-10-03 2007-06-19 Accenture Global Services Gmbh Multi-modal callback
US7114157B2 (en) * 2001-11-27 2006-09-26 Kuka Roboter Gmbh System controlling exclusive access by control programs to system resources
US7574496B2 (en) 2001-11-30 2009-08-11 Surgient, Inc. Virtual server cloud interfacing
US6854633B1 (en) * 2002-02-05 2005-02-15 Micron Technology, Inc. System with polymer masking flux for fabricating external contacts on semiconductor components
US7257584B2 (en) 2002-03-18 2007-08-14 Surgient, Inc. Server file management
US6990666B2 (en) * 2002-03-18 2006-01-24 Surgient Inc. Near on-line server
US20030223090A1 (en) * 2002-05-28 2003-12-04 Mustafa Seifi Method and implementation for message-driven job processing
US20030225474A1 (en) * 2002-05-31 2003-12-04 Gustavo Mata Specialization of active software agents in an automated manufacturing environment
US7076781B2 (en) * 2002-05-31 2006-07-11 International Business Machines Corporation Resource reservation for large-scale job scheduling
US20040064499A1 (en) * 2002-09-26 2004-04-01 Kasra Kasravi Method and system for active knowledge management
US8359540B2 (en) * 2002-10-09 2013-01-22 Goldman, Sachs & Co. Apparatus, methods, and articles of manufacture for constructing and maintaining a calendaring interface
US7233999B2 (en) * 2003-01-28 2007-06-19 Altaf Hadi System and method for delivering last mile computing over light from a plurality of network edge locations
EP1616295A1 (de) * 2003-04-15 2006-01-18 United Parcel Service Of America, Inc. Rush-hour-modellierung zum routen und einteilen
US7643484B2 (en) * 2003-09-26 2010-01-05 Surgient, Inc. Network abstraction and isolation layer rules-based federation and masquerading
US7769004B2 (en) * 2003-09-26 2010-08-03 Surgient, Inc. Network abstraction and isolation layer for masquerading machine identity of a computer
US20050096946A1 (en) * 2003-10-30 2005-05-05 International Business Machines Corporation System and method for dynamically resolving travel arrangement problems based on changes in travel conditions
US20050108077A1 (en) * 2003-11-17 2005-05-19 Capotosto Thomas P. System for separating managed services technology from service labor provider
US20050108275A1 (en) * 2003-11-17 2005-05-19 Capotosto Thomas P. Disaggregation of services into building blocks
US20050114224A1 (en) * 2003-11-24 2005-05-26 Hodges Donna K. Methods for providing communications services
US7711575B2 (en) * 2003-11-24 2010-05-04 At&T Intellectual Property I, L.P. Methods for providing communications services
US7467219B2 (en) * 2003-11-24 2008-12-16 At&T Intellectual Property I, L.P. Methods for providing communications services
US7509373B2 (en) 2003-11-24 2009-03-24 At&T Intellectual Property I, L.P. Methods for providing communications services
US7464179B2 (en) 2003-11-24 2008-12-09 At&T Intellectual Property I, L.P. Methods, systems, and products for providing communications services amongst multiple providers
US7536308B2 (en) * 2003-11-24 2009-05-19 At&T Intellectual Property I, L.P. Methods for providing communications services
US7743008B2 (en) * 2003-12-30 2010-06-22 International Business Machines Corporation Adaptive management method with workflow control
US7404189B2 (en) 2003-12-30 2008-07-22 International Business Machines Corporation Scheduler supporting web service invocation
US7650590B2 (en) * 2004-01-13 2010-01-19 Sap Ag Flexible code generation
US7899179B2 (en) * 2004-01-20 2011-03-01 International Business Machines Corporation Method for monitoring off-schedule software agents
DE102004011201B4 (de) * 2004-03-04 2006-10-12 Siemens Ag Verfahren zum Management und zur Überwachung des Betriebs mehrerer in wenigstens ein Kommunikationsnetz eingebundener verteilter Hard- und/oder Softwaresysteme sowie System zur Durchführung des Verfahrens
US7594227B2 (en) * 2004-03-08 2009-09-22 Ab Initio Technology Llc Dependency graph parameter scoping
US20050235284A1 (en) * 2004-04-14 2005-10-20 International Business Machines Corporation Systems and methods for tracking processing unit usage
US20050289266A1 (en) * 2004-06-08 2005-12-29 Daniel Illowsky Method and system for interoperable content player device engine
US7861246B2 (en) * 2004-06-17 2010-12-28 Platform Computing Corporation Job-centric scheduling in a grid environment
US7844969B2 (en) * 2004-06-17 2010-11-30 Platform Computing Corporation Goal-oriented predictive scheduling in a grid environment
US7340654B2 (en) * 2004-06-17 2008-03-04 Platform Computing Corporation Autonomic monitoring in a grid environment
US20060085321A1 (en) * 2004-07-20 2006-04-20 Staib William E Simulation auction for public offering
JP2008517385A (ja) * 2004-10-14 2008-05-22 コンピュータ・エイド・インコーポレーテッド プロセスのオートメーションおよび実施のためのシステムおよび方法
EP1653347B1 (de) 2004-10-27 2007-05-23 Sap Ag Verfahren zur Durchführung eines Softwaredienstes in einer Systemlandschaft
DE602004015295D1 (de) * 2004-10-27 2008-09-04 Sap Ag Rechnersystem und Verfahren zum Bewirken von Softwarewartung in einer Softwaresystemlandschaft
ATE399340T1 (de) * 2004-10-27 2008-07-15 Sap Ag Rechnersystem und verfahren zum bewirken von veränderungen in einer softwaresystemlandschaft
DE602004017012D1 (de) 2004-10-27 2008-11-20 Sap Ag Rechnersystem und Verfahren zum Bewirken eines einleitenden Softwaredienstes in einem produktiven System einer Softwaresystemlandschaft
EP1653317A1 (de) * 2004-10-27 2006-05-03 Sap Ag Verfahren und System zum Setzen von Änderungsoptionen von Softwaresystemen
ATE400844T1 (de) * 2004-10-27 2008-07-15 Sap Ag Verfahren und system zur generierung eines transportweges durch eine softwaresystemlandschaft
EP1653348A1 (de) * 2004-10-27 2006-05-03 Sap Ag Verfahren zur Verfolgung von Transportaufträgen und Computersystem mit verfolgbaren Transportaufträgen
US20080275582A1 (en) * 2004-11-19 2008-11-06 Nettles Steven C Scheduling AMHS pickup and delivery ahead of schedule
US7769579B2 (en) 2005-05-31 2010-08-03 Google Inc. Learning facts from semi-structured text
US7386745B2 (en) * 2005-01-19 2008-06-10 International Business Machines Corporation Enabling a client device in a client device/data center environment to resume from a sleep state more quickly
US8682913B1 (en) 2005-03-31 2014-03-25 Google Inc. Corroborating facts extracted from multiple sources
US9208229B2 (en) * 2005-03-31 2015-12-08 Google Inc. Anchor text summarization for corroboration
US7587387B2 (en) 2005-03-31 2009-09-08 Google Inc. User interface for facts query engine with snippets from information sources that include query terms and answer terms
CA2605879C (en) * 2005-05-09 2012-07-17 United Parcel Service Of America, Inc. Systems and methods for routing and scheduling
US8996470B1 (en) 2005-05-31 2015-03-31 Google Inc. System for ensuring the internal consistency of a fact repository
US7831545B1 (en) 2005-05-31 2010-11-09 Google Inc. Identifying the unifying subject of a set of facts
JP3992721B2 (ja) * 2005-11-09 2007-10-17 株式会社日立製作所 情報処理装置およびプロセス制御方法
US8495613B2 (en) * 2005-12-22 2013-07-23 Microsoft Corporation Program execution service windows
KR20070108432A (ko) * 2006-01-23 2007-11-12 엘지전자 주식회사 장치관리 스케줄링 방법
KR101342372B1 (ko) * 2006-01-23 2013-12-16 엘지전자 주식회사 단말 및 그 단말에서의 장치관리 스케줄링 방법
US8104037B2 (en) 2006-01-23 2012-01-24 Lg Electronics Inc. Terminal and method for performing device management scheduled based on threshold
KR101285886B1 (ko) * 2006-01-25 2013-07-11 엘지전자 주식회사 서버로의 보고 방법 및 그 단말
KR101349805B1 (ko) * 2006-01-25 2014-01-10 엘지전자 주식회사 트랩 메커니즘을 이용한 장치관리 스케줄링 방법 및 그단말
US8260785B2 (en) 2006-02-17 2012-09-04 Google Inc. Automatic object reference identification and linking in a browseable fact repository
US8458661B2 (en) 2006-03-31 2013-06-04 Ebay Inc. Distributed parallel build system
US8078728B1 (en) 2006-03-31 2011-12-13 Quest Software, Inc. Capacity pooling for application reservation and delivery
US20070265927A1 (en) * 2006-05-12 2007-11-15 Temo, Inc. Software design system
US9299039B1 (en) * 2006-08-23 2016-03-29 A9.Com, Inc. Managing task lists utilizing integrated information requests
US8122026B1 (en) 2006-10-20 2012-02-21 Google Inc. Finding and disambiguating references to entities on web pages
US7805326B2 (en) * 2006-11-15 2010-09-28 Sap Ag System to resolve scheduling constraints
CA2677131C (en) 2007-02-06 2014-10-14 Mba Sciences, Inc. A resource tracking method and apparatus
US8347202B1 (en) 2007-03-14 2013-01-01 Google Inc. Determining geographic locations for place names in a fact repository
US8589935B2 (en) * 2007-05-08 2013-11-19 L-3 Communications Corporation Heterogeneous reconfigurable agent compute engine (HRACE)
US8065173B2 (en) * 2007-10-29 2011-11-22 Suhayya Abu-Hakima Collaborative multi-agent system for dynamic management of electronic services in a mobile global network environment
US8812435B1 (en) 2007-11-16 2014-08-19 Google Inc. Learning objects and facts from documents
US9215217B2 (en) 2008-12-05 2015-12-15 Suhayya Abu-Hakima and Kenneth E. Grigg Auto-discovery of diverse communications devices for alert broadcasting
US9338597B2 (en) 2007-12-06 2016-05-10 Suhayya Abu-Hakima Alert broadcasting to unconfigured communications devices
US8194674B1 (en) 2007-12-20 2012-06-05 Quest Software, Inc. System and method for aggregating communications and for translating between overlapping internal network addresses and unique external network addresses
US8650570B2 (en) * 2008-06-02 2014-02-11 Microsoft Corporation Method of assigning instructions in a process to a plurality of scheduler instances based on the instruction, in which each scheduler instance is allocated a set of negoitaited processor resources
WO2009157062A1 (ja) * 2008-06-25 2009-12-30 富士通株式会社 構成管理装置、構成管理プログラム、構成管理方法
US8904003B2 (en) * 2008-06-30 2014-12-02 Oracle America, Inc. Method and system for delegated job control across a network
WO2010057312A1 (en) 2008-11-24 2010-05-27 Certicom Corp. System and method for hardware based security
US8832173B2 (en) * 2009-01-20 2014-09-09 Sap Ag System and method of multithreaded processing across multiple servers
US9672478B2 (en) * 2009-02-26 2017-06-06 Oracle International Corporation Techniques for semantic business policy composition
EP4092590B1 (de) 2009-07-10 2025-07-02 Malikie Innovations Limited System und verfahren zur durchführung von geräteserialisierungen
US9111098B2 (en) 2009-07-10 2015-08-18 Certicom Corp. System and method for managing electronic assets
US8875143B2 (en) * 2009-12-31 2014-10-28 Bmc Software, Inc. Utility-optimized scheduling of time-sensitive tasks in a resource-constrained environment
US8776014B2 (en) 2010-09-23 2014-07-08 Microsoft Corporation Software build analysis
US20120109701A1 (en) * 2010-11-01 2012-05-03 Bank Of America Corporation Fulfillment Workflow Optimization
US9098329B1 (en) * 2011-08-30 2015-08-04 Amazon Technologies, Inc. Managing workflows
US8751420B2 (en) * 2012-04-02 2014-06-10 Telefonaktiebolaget L M Ericsson (Publ) Generic reasoner distribution of resources using a plurality of shallow reasoners, and a predictor server
US10275727B2 (en) * 2012-04-18 2019-04-30 International Business Machines Corporation Dynamic location-aware coordination method and system
US10310903B2 (en) * 2014-01-17 2019-06-04 Red Hat, Inc. Resilient scheduling of broker jobs for asynchronous tasks in a multi-tenant platform-as-a-service (PaaS) system
USD711420S1 (en) * 2014-03-14 2014-08-19 Nike, Inc. Display screen with graphical user interface for athletic achievements
USD710863S1 (en) * 2014-03-14 2014-08-12 Nike, Inc. Display screen with graphical user interface for athletic achievements
US9372724B2 (en) * 2014-04-01 2016-06-21 Freescale Semiconductor, Inc. System and method for conditional task switching during ordering scope transitions
US9372723B2 (en) * 2014-04-01 2016-06-21 Freescale Semiconductor, Inc. System and method for conditional task switching during ordering scope transitions
US9697467B2 (en) 2014-05-21 2017-07-04 International Business Machines Corporation Goal-driven composition with preferences method and system
US9785755B2 (en) * 2014-05-21 2017-10-10 International Business Machines Corporation Predictive hypothesis exploration using planning
US9733981B2 (en) 2014-06-10 2017-08-15 Nxp Usa, Inc. System and method for conditional task switching during ordering scope transitions
US10798146B2 (en) * 2015-07-01 2020-10-06 Oracle International Corporation System and method for universal timeout in a distributed computing environment
US9870266B2 (en) * 2015-07-30 2018-01-16 Nasdaq, Inc. Background job processing framework
US11188878B2 (en) * 2015-09-22 2021-11-30 International Business Machines Corporation Meeting room reservation system
US10430739B2 (en) * 2016-01-26 2019-10-01 International Business Machines Corporation Automatic solution to a scheduling problem
EP3208712B1 (de) * 2016-02-22 2020-02-19 Karlsruher Institut für Technologie Computersystem und verfahren zur parallelprogrammcodeoptimierung und -einsatz
US20170289069A1 (en) * 2016-03-30 2017-10-05 Microsoft Technology Licensing, Llc Selecting an Autonomous Software Agent
US10592280B2 (en) * 2016-11-23 2020-03-17 Amazon Technologies, Inc. Resource allocation and scheduling for batch jobs
CN108432208B (zh) * 2016-12-15 2020-02-21 华为技术有限公司 一种业务编排方法、装置及服务器
US11599857B2 (en) * 2017-01-31 2023-03-07 Microsoft Technology Licensing, Llc Categorized time designation on calendars
US11122083B1 (en) 2017-09-08 2021-09-14 F5 Networks, Inc. Methods for managing network connections based on DNS data and network policies and devices thereof
US11777875B2 (en) * 2017-09-15 2023-10-03 Microsoft Technology Licensing, Llc Capturing and leveraging signals reflecting BOT-to-BOT delegation
US10771406B2 (en) 2017-11-11 2020-09-08 Microsoft Technology Licensing, Llc Providing and leveraging implicit signals reflecting user-to-BOT interaction
US11129236B1 (en) * 2018-10-02 2021-09-21 University Of South Florida Control of multiagent systems with local and global objectives
CN114841499B (zh) * 2022-03-15 2025-07-15 合肥工业大学 基于并发机制的合同网的卫星任务规划方法和系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2692058B1 (fr) * 1992-06-09 1994-07-29 Bull Sa Systeme de traitement transactionnel entre un serveur informatique et une pluralite de stations de travail.
US5437032A (en) * 1993-11-04 1995-07-25 International Business Machines Corporation Task scheduler for a miltiprocessor system
US5412654A (en) * 1994-01-10 1995-05-02 International Business Machines Corporation Highly dynamic destination-sequenced destination vector routing for mobile computers
US5787483A (en) * 1995-09-22 1998-07-28 Hewlett-Packard Company High-speed data communications modem
US5784597A (en) * 1995-09-22 1998-07-21 Hewlett-Packard Company Communications network system including acknowledgement indicating successful receipt of request for reserved communication slots and start time for said reserved communication slots
US5812844A (en) * 1995-12-07 1998-09-22 Microsoft Corporation Method and system for scheduling the execution of threads using optional time-specific scheduling constraints

Also Published As

Publication number Publication date
US6263358B1 (en) 2001-07-17
AU8548698A (en) 1999-02-16
DE69808633D1 (de) 2002-11-14
EP0996887A1 (de) 2000-05-03
CA2297935A1 (en) 1999-02-04
AU735024B2 (en) 2001-06-28
WO1999005594A1 (en) 1999-02-04
EP0996887B1 (de) 2002-10-09

Similar Documents

Publication Publication Date Title
DE69808633T2 (de) Ablaufsteuerung für ein softwaresystem
DE69808632T2 (de) Erzeugung von Softwaresystemen
DE69803575T2 (de) Visualisierung in einem modularen softwaresystem
Ndumu et al. Visualising and debugging distributed multi-agent systems
DE602004011455T2 (de) Verfahren und System zur automatischen Erzeugung von Dienstschnittstellen für eine dienstorientierte Architektur
DE69132012T2 (de) Objektorientierte architektur für fabrikverwaltung
DE112017006164T5 (de) Differenzvergleich von ausführbaren Datenflussdiagrammen
WO2008071448A1 (de) Computerimplementiertes system zur analyse, verwaltung, beherrschung, bewirtschaftung und überwachung einer komplexen hardware-/softwarearchitektur
DE112011102394T5 (de) Verwalten und Optimieren von Workflows zwischen Computeranwendungen
EP2648094B1 (de) Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses
DE69737253T2 (de) Verfahren und Vorrichtung zum Bestimmen des Umfanges eines Suchvorganges für Factory-Objekte
CH701481B1 (de) Prozessmanagement.
EP1202167B1 (de) Verfahren zur modellbasierten objektorientierten Entwicklung von externen Schnittstellen für verteilte Softwaresysteme
Wolf Succeedings of the second international software architecture workshop (isaw-2)
EP1187001A2 (de) Integriertes Wissens-Technologiesystem
DE10065286B4 (de) Verfahren zum Entwurf und/oder zum Betrieb kombinierbarer Komponenten (TYCS)
Mylopoulos et al. Task-oriented development of intelligent information systems
WO2009030490A1 (de) Computerimplementiertes system und verfahren zum strukturierten speichern von informationen
EP0973091A2 (de) Verfahren zum Erzeugen eines regel- und anpassbaren Netzwerkes von Modellen von Verhaltensmustern
DE102021101201A1 (de) Verfahren zum Einsetzen von Software-Stacks und computerlesbares Speichermedium
DE102023111472A1 (de) Verfahren zur modellierung und verwaltung verteilter systeme
DE68929549T2 (de) Verwaltungssystem für verbundene Einheiten
Chung et al. A Java-Based, System for Collaborative Design and Manufacturing
EP0825525A1 (de) Verfahren zur Unterstützung des Erzeugens eines Objektes
WO2009049718A1 (de) Computerimplementiertes system und verfahren zum strukturierten speichern von daten mindestens eines vordefinierten ablaufs

Legal Events

Date Code Title Description
8364 No opposition during term of opposition