DE69803575T2

DE69803575T2 - Visualisierung in einem modularen softwaresystem

Info

Publication number: DE69803575T2
Application number: DE69803575T
Authority: DE
Inventors: Lyndon Chi-Hang Lee; Divine Tamajong Ndumu; Hyacinth Sama Nwana
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1997-07-25
Filing date: 1998-07-27
Publication date: 2002-08-29
Anticipated expiration: 2018-07-28
Also published as: CA2296391C; DE69803575D1; WO1999005597A1; EP0998708B1; AU8456598A; US6266805B1; AU750332B2; CA2296391A1; EP0998708A1

Description

Die vorliegende Erfindung betrifft die Visualisierung in einem modularen Softwaresystem und findet beispielsweise bei der Fehlerbehebung und beim Editieren von Softwaresystemen Anwendung, die eine Gemeinschaft zusammenarbeitender Software-Agents umfassen.
Die Software-Agent-Technologie hat sich in den letzten Jahren in mehreren unterschiedlichen Bereichen entwickelt. Ein Software- Agent ist ein Computerprogramm, das als Vertreter einer Einheit, wie eines Benutzers, eines Teils einer Anlage oder eines Geschäfts agiert. Der Software-Agent hält normalerweise Daten, die die Einheit betreffen, die er vertritt, hat einen Satz von Einschränkungen oder Bedingungen zur Bestimmung seines Verhaltens und ist, was am wesentlichsten ist, mit einer Entscheidungsfindungssoftware zum Treffen von Entscheidungen im Namen der Einheit im Rahmen der Einschränkungen und Bedingungen bzw. aufgrund dieser ausgestattet. Agents arbeiten im allgemeinen innerhalb eines Systems, und die Entscheidungen, die ein Agent fällt, können zu einer Aktivität des Systems führen. Bei Steuerungssoftwaresystemen führen diese Entscheidungen zu Steuerungsaktivitäten, wie der Initialisierung der Herstellung einer Verbindung in einem durch das System gesteuerten Kommunikationsnetz.
Ein innerhalb eines Systems arbeitender Agent hält im allgemeinen auch das System betreffende Daten, so daß er im Kontext arbeiten kann.
In einer verteilten Umgebung können viele derartige Agents zusammenarbeiten, um die Steuervorgänge zu koordinieren und auszuführen. Typischer Weise bilden derartige Agents eine Agent-Schicht, wobei jeder Agent mit einer Reihe externer Systeme (der Domänenschicht) in Verbindung steht, die er steuert, überwacht oder verwaltet, wie in Fig. 1 gezeigt.
Ein auf Agents basierendes System kann sehr komplex sein, da die Interaktionen zwischen den Agents, die Entscheidungsfindungsprozesse einzelner Agents und die Interaktionen zwischen den Agents und den externen Systemen, die sie steuern, berücksichtigt werden müssen.
Unterschiedliche Typen von auf Agents basierenden Systemen sind in vielen Druckschriften, wie den in den "Proceedings of the First and Second International Conferences on the Practical Application of Intelligent Agents and Multi-Agent Technology" veröffentlichten, beschrieben. Diese wurden jeweils 1996 und 1997 von der Practical Application Company Ltd., Blackpool, Lancashire veröffentlicht. Eine allgemeine, umfassende Besprechung der auf Agents basierenden Technologie von Hyacinth S. Nwana, "Software Agents: An Overview" wurde 1996 in dem Journal "Knowledge Engineering Review", Bd. 11, Nr. 3, Seiten 205-244 veröffentlicht.
Ein Beispiel eines in diesem Fall für eine Kommunikationsnetzverwaltung verwendeten, kollaborativen Agent-Systems ist in der Internationalen Patentanmeldung Nr. WO95/ 15635 auf den Namen des vorliegenden Anmelders beschrieben.
In der gleichzeitig laufenden europäischen Patentanmeldung Nr. 97305600, 5, ebenfalls auf den Namen des vorliegenden Anmelders, ist eine Softwareerstellungsumgebung zum Aufbau eines Softwaresystems unter Verwendung zusammenarbeitender Agents beschrieben. Ein unter Verwendung der Umgebung erstelltes Softwaresystem kann dann beispielsweise zur Steuerung, Überwachung und/oder Verwaltung eines Prozesses oder einer Vorrichtung verwendet werden. Die Umgebung umfaßt mindestens ein Softwaremodul, eine Einrichtung zur Erfassung von Daten zum Laden einer Kopie des Moduls zur Verwendung in einem Softwaresystem und eine Einrichtung zur Erzeugung des Softwaresystems selbst. Das erstellte Softwaresystem umfaßt mindestens zwei der geladenen Module.
Jedes geladene Softwaremodul umfaßt vorzugsweise einen kollaborativen Software-Agent. Es umfaßt daher mindestens eine beispielsweise als Regel oder Algorithmus ausgedrückte Kooperations- oder Koordinationsstrategie oder hat Zugriff auf diese. Die mindestens zwei geladenen Module können dann zusammen eine Gemeinschaft von mehreren Agents zur Steuerung, Überwachung und/oder Verwaltung des Prozesses bzw. der Vorrichtung erzeugen.
Eine derartige kollaborative Agent-Erstellungsumgebung ermöglicht einem Systementwickler die Definition eines Satzes von Agents, die in einem System zusammenarbeiten sollen, ihre Organisation in bezug aufeinander auf jede von ihnen gewählte Weise, ihre Ausstattung mit für die Aufgaben, zu deren Lösung die Agents bestimmt sind, geeigneten Koordinationsfähigkeiten, die Unterstützung von Verbindungen von den Agents zu dem Prozeß oder der Vorrichtung, mit dem bzw. der sie, beispielsweise zu Steuerungs- oder Aktualisierungszwecken, kommunizieren müssen, und die Erzeugung des Softwarecodes für die Agents.
Ein besonderes Problem tritt bei "kollaborativen" Agents auf. Kollaborative Agents arbeiten zusammen, um ihre Aktivitäten bei der Ausführung einer bestimmten Aufgabe zu koordinieren. Eine derartige Kooperation kann erforderlich sein, da Kenntnisse, Ressourcen oder Verarbeitungsleistung über die Umgebung oder unter den Agents in dem System verteilt sein können. Es ist wesentlich, die Aktivitäten der Agents problem- und kontextabhängig zu koordinieren. Das Problem betrifft die Fehlerbehebung bei potentiell sehr komplexen Systemen dieses Typs.
In der Druckschrift "INFORMATION AND SOFTWARE TECHNO- LOGY", Bd. 37, Nr. 2, Februar 1995, Seiten 103-112, VAN LIEDE- KERKE M.H. et al.: "Debugging Multiagent Systems" ist eine Visualisierungsanordnung zur Fehlerbehebung zur Verwendung in einem Softwaresystem mit mehreren Agents offenbart, bei der die Agents getrennte Softwaremodule sind, die interagieren, um eine gemeinsame Aufgabe zu lösen.
Gemäß Ausführungsformen der vorliegenden Erfindung, die im beiliegenden Anspruch 1 im Einzelnen definiert sind, wird eine Visualisierungsanordnung zur Verwendung in einem Softwaresystem zur Steuerung, Überwachung oder Verwaltung eines Prozesses oder einer Anordnung geschaffen, wobei das Softwaresystem mehrere mit einer Einrichtung zur Kommunikation miteinander versehene Softwaremodule umfaßt, die Visualisierungsanordnung eine Einrichtung zum Speichern und zur Erzeugung einer Anzeige von Kommunikationsereignissen, die in Verbindung mit einem einzelnen ausgewählten Softwaremodul auftreten, oder diese betreffenden Daten und eine Einrichtung zur Speicherung und zur Erzeugung einer Anzeige von Kommunikationsereignissen, die zwischen mindestens zwei der Softwaremodule auftreten, oder diese betreffenden Daten aufweist.
Eine Feherbehebungsanordnung, die dem Benutzer die Auswahl der Überprüfung der entweder für ein einzelnes Softwaremodul oder für eine Gemeinschaft kommunizierender Softwaremodule relevanten Kommunikation oder beides ermöglicht, kann dem Benutzer einen sehr effizienten Fehlerbehebungsmechanismus bieten.
Vorzugsweise weist die Visualisierungsanordnung eine Einrichtung zum Erhalt von die Softwaremodule betreffenden organisatorischen Daten und eine Einrichtung zur derartigen Verarbeitung der Kommunikationsvorgänge oder Daten vor der Anzeige auf, daß die Kommunikationsvorgänge oder die sie betreffenden Daten auf eine durch die organisatorischen Daten bestimmte Weise angezeigt werden können.
Es ist auch vorteilhaft, wenn die Visualisierungsanordnung eine Einrichtung zum Zugreifen auf Daten oder einen in einem oder mehreren der Softwaremodule gehaltenen, ausführbaren Softwarecode zum Herunterladen der Daten bzw. des Codes, zum Bereitstellen der Daten bzw. des Codes für eine Modifikation und zum Laden der veränderten Daten bzw. des veränderten Codes in das Softwaremodul aufweist. Die Daten bzw. der Code können durch eine innerhalb der Visualisierungsanordnung selbst vorgesehene Aufbereitungseinrichtung oder durch eine separate Aufbereitungseinrichtung verändert werden.
In der folgenden Beschreibung sollte beachtet werden, daß Softwaremodule in der Praxis in einer verteilten Umgebung nicht, wie vorstehend erwähnt, selbst Daten oder Software, wie die Kooperations- oder Koordinantionsstrategien, umfassen müssen. Sie können statt dessen einfach Zugriff auf sie haben, beispielsweise um sie in der relevanten Laufzeit zu laden.
Im folgenden wird unter Bezugnahme auf die beiliegenden Zeichnungen als eine Ausführungsform der vorliegenden Erfindung lediglich beispielhaft ein als System zur Erstellung kollaborativer Agents oder Collaborative Agent Building System ("CABS") bekanntes Dienstprogrammpaket eines Agent- Erzeugungssystems beschrieben. Es zeigen:
Fig. 1 ein unter Verwendung des CABS erstelltes, auf Agents basierendes Steuersystem, das mit externer Hardware und/oder Software in Verbindung steht;
Fig. 2 eine schematische Architektur für ein Softwaremodul, das einen Agent für eine verteilte Steuerung, Überwachung und Verwaltung eines Systems bildet;
Fig. 3 eine CABS-Plattform zur Erstellung eines Agent, wie dem in Fig. 2 gezeigten;
Fig. 4 ein geschichtetes Modell eines Agent in Begriffen einer primären Charakterisierung;
Fig. 5 ein Ablaufdiagramm von an der Erstellung eines Agent unter Verwendung der Plattform gemäß Fig. 3 beteiligten Schritten;
Fig. 6 mögliche organisatorische Beziehungen zwischen unter Verwendung von CABS erstellten Agents;
Fig. 7 unter Verwendung eines Fehlerbehebungsprogramms zur Fehlerbehebung bei einem unter Verwendung von CABS erstellten, auf Agents basierenden Steuersystem erhaltene Daten;
Fig. 8 ein Szenario für eine Fehlerbehebung unter Verwendung des Fehlerbehebungs-Dienstprogramms zur Fehlerbehebung bei einem CABS-Agent-System;
Fig. 9 eine Aufgabentabelle für einen Agent gemäß Fig. 2;
Fig. 10 ein Fehlerbehebungs- und Visualisierungssystem zur Verwendung mit dem auf Agents basierenden Steuersystem gemäß Fig. 1;
Fig. 11 ein Ablaufdiagramm eines Koordinationsprozesses zur Verwendung unter Agents in einem System gemäß Fig. 1;
Fig. 12 schematisch ein Beispiel des bildschirmbasierenden Ausgangs eines "Gemeinschafts-Dienstprogramms" des verwendeten Visualisierungssystems;
Fig. 13 schematisch eine GANTT-Übersicht als Beispiel des bildschirmbasierenden Ausgangs eines "Protokoll-Dienstprogramms" des verwendeten Visualisierungssystems;
Fig. 14 schematisch ein Beispiel des bildschirmbasierenden Ausgangs eines "Mikro-Dienstprogramms" des verwendeten Visualisierungssystems; und
Fig. 15 schematisch ein Beispiel des bildschirmbasierenden Ausgangs eines "Statistik-Dienstprogramms" des verwendeten Visualisierungsprogramms.
In der folgenden Beschreibung wird ein auf Agents basierendes System zusammen mit einer Umgebung zu seiner Erzeugung beschrieben. Die spezifische Technologie der vorliegenden Erfindung und die Fehlerbehebungs- und Visualisierungsaspekte sind in Abschnitt 5, "FEHLERBEHEBUNG UND VISUALISIERUNG" beschrieben.

1. UNTER VERWENDUNG DES CABS-DIENSTPROGRAMM- PAKTETS ERSTELLTES AGENT-SYSTEM

Das in Fig. 1 gezeigte System ist ein Beispiel eines auf Agents basierenden Systems zur Verwendung bei der Kommunikation. Eine CABS-Plattform könnte jedoch zur Erstellung fast jedes auf Agents basierenden Systems verwendet werden, bei dem Software-Agents sowohl mit anderen Agents zusammenarbeiten als auch Aufgaben ausführen müssen, die einen Ausgang zur Folge haben. Der Ausgang ist bei dem Beispiel gemäß Fig. 1 die Steuerung der Bereitstellung von Diensten mittels der Komponenten eines Kommunikationssystems. Der Ausgang könnte alternativ beispielsweise eine Datenerzeugung oder die Steuerung eines Produktionsprozesses, und an anderer Stelle in dieser Beschreibung werden andere Beispiele verwendet.
Das System umfaßt eine in der Programmiersprache Java implementierte Gruppe von Klassen (im Sinne der objektorientierten Technologie), was ihm das Laufen auf einer Vielzahl von Hardware- Plattformen ermöglicht. Java ist als Sprache zur Erstellung von Anwendungen mit mehreren Agents eine gute Wahl, da sie objektorientiert und mehrschichtig ist und jeder Agent aus mehreren Objekten und einigen Schichten bestehen kann. Sie hat auch den Vorteil, daß sie über Betriebssysteme übertragbar ist und ein umfassendes Paket von Klassenbibliotheken bietet, die ausgezeichnete Netzwerkkommunikationseinrichtungen umfassen *
Die Klassen des Systems können in drei primäre funktionale Gruppen kategorisiert werden: eine Agentkomponentenbibliothek, ein Dienstprogramm zur Erstellung von Agents und ein Dienstprogramm zur Visualisierung von Agents.
Die Agent-Komponentenbibliothek enthält Java-Klassen, die die "Bausteine" einzelner Agents bilden. Diese implementieren zusammen die für einen kollaborativen Agent funktional erforderliche "Agent- Schicht". Damit bietet das System beispielsweise für die Kommunikation, zum Schlußfolgern, für die Zusammenarbeit der Agents und die Fähigkeit zur Teilnahme an zielgerichteten Interaktionen zwischen den Agents:
- eine leistungsorientierte Sprache für die Kommunikation zwischen den Agents,
- eine Kenntnisdarstellung und -speicherung unter Verwendung von Ontologien,
- ein asynchrones, einen Stecker verwendendes Nachrichtenaustauschsystem,
- ein Planungs- und Terminierungssystem,
- ein Ereignismodell zusammen mit einer Anwendungsprogrammierungsschnittstelle (API, applications programming interface), die Programmierern die Überwachung von Veränderungen des internen Status eines Agent und die externe Steuerung seines Verhaltens ermöglicht,
- eine Koordinationsmaschine,
- eine Bibliothek vorab definierter Koordinationsprotokolle und
- eine Bibliothek vorab definierter organisatorischer Beziehungen.
Es bietet ferner Unterstützungs-Agents bekannter, allgemeiner Typen wie Namensverzeichnisse, Vereinfachungseinrichtunge (klassifixierte Verzeichnisse) und Visualisierungseinrichtung.
Vorzugsweise verwenden die Komponenten des Systems, soweit dies möglich ist, Standardtechnologien, wie die Kommunikation über TCP/IP-Stecker unter Verwendung einer auf KQML (Knowledge Query Management Language, Informationsabfrageverwaltungssprache) basierenden Sprache.
Weitere Beschreibungen dieser Aspekte sind nachstehend zu finden.
Im Folgenden werden die Begriffe "Aufgabe", "Task" und "Job" verwendet. Diese sind wie folgt definiert:
"Aufgabe": logische Beschreibung einer Ressource (Tatsache), die ein Agent erzeugen soll,
"Task": logische Beschreibung eines Prozesses, für den null oder mehr Ressourcen verwendet werden und der eine oder mehrere Ressourcen erzeugt, und
"Job": bezeichnet abhängig vom Kontext eine Aufgabe oder einen Task. (Im Zusammenhang mit der nachstehend unter der Überschrift 5. FEHLERBEHEBUNG UND VISUALISIE- RUNG besprochenen Visualisierungseinrichtung 140 bezeichnet der Begriff beispielsweise Aufgaben.)
Gemäß Fig. 1 umfaßt ein unter Verwendung der CABS-Plattform erstelltes, auf Agents basierendes System 100 einen Satz kommunizierender Agents 105, 110, 115, 120 zur Steuerung / Repräsentation von Entitäten in einem externen System sowie einen Satz Infrastruktur-Agents 135, 140, 145.
Die Agents des Systems 100 kommunizieren unter Verwendung eines Netzwerks, wie eines lokalen Netzwerks 150, miteinander. Sie könnten alternativ unter Verwendung von Kapazitäten in dem externen System selbst kommunizieren.
Außerhalb des Agent-Systems 100 befindet sich ein Kommunikationssystem 125 mit verschiedenen Komponenten. Innerhalb des externen Systems 125 befindet sich beispielsweise ein Terminal 155, eine eine Authentifizierung 160 bereitstellende Software-Anwendung und mehrere Netzwerkverbindungen 165, 170, 175. Eine der Netzwerkverbindungen 175 weist einen externen Agent 180 auf, der von dem unter Verwendung der CABS-Plattform erstellten, auf Agents basierenden System 100 getrennt ist.
Die CABS-Agents 105, 110, 115, 120 haben verschiedene Tasks auszuführen und unterschiedliche Ressourcen zu steuern. Die Agents müssen sowohl zusammenarbeiten als auch Tasks ausführen. Die Tasks umfassen die direkt an der Bereitstellung von Diensten für einen Benutzer beteiligten, können jedoch auch zusätzliche Tasks umfassen.
Wenn der Benutzer bei dem dargestellten System beispielsweise Daten auf das Terminal 155 herunterladen möchte, hat der Benutzer-Agent 110 den Task, eine Authentifizierungsressource 160 bereitzustellen, der Terminal-Agent 105 hat den Task, im Terminal 155 ausreichend Speicher für die Daten bereitzustellen, und die Netzwerk-Agents 115, 120 haben den Task, die Netzwerkbandbreite bereitzustellen, um die Daten zum Terminal 155 zu übertragen. Die Netzwerk-Agents 115, 120 müssen auch miteinander kooperieren, beispielsweise durch Gebote gegeneinander bezüglich der Kosten, der Geschwindigkeit und der Qualität des Diensts der Bereitstellung der Netzwerkbandbreite.
Nach einer Stufe der Zusammenarbeit zwischen den Agents führen die Agents 105, 110, 115, 120 die Tasks durch Ausgeben von Steuernachrichten an die Bauteile des Systems 125 aus, das sie steuern. Der Terminal-Agent 105 muß daher das Terminal 155 so steuern, daß es die zugesagte Speicherkapazität bereitstellt. Der Benutzer-Agent 110 muß die Authentifizierungsanwendung 160 aktivieren. Einer der beiden Netzwerk-Agents 120 muß die als Ergebnis der Zusammenarbeit vereinbarte Bandbreite auf seiner jeweiligen Netzwerkverbindung 170 bereitstellen.
Während dieser Aktivitäten haben die Agents 105, 110, 115, 120 Zugriff auf gemeinsame Ressourcen innerhalb des CABS-Agent- Systems 100, die beispielsweise die vorstehend genannten Infrastruktur-Agents, einen Namensverzeichnis-Agent 135, einen hier als Visualisierungseinrichtung bezeichneten Fehlerbehebungs- /Fehlersuch-Agent 140 und einen Vereinfachungs-Agent 145 einschließen.
Der separate Agent 180, der eine Netzwerkverbindung 175 des externen Systems 125 steuert, kann für den Fall, daß die Bandbreite über die direkt von den über CABS erstellten Agents 115, 120 gesteuerten Netzverbindungen nicht verfügbar ist, ein Backup für die Netzwerk-Agents 115, 120 des CABS-Systems 100 bereitstellen. Es ist klar, daß in diesem Fall die CABS-Agents 105, 110, 115, 120 eine gemeinsame Kommunikationssprache sowie eine Art Koordinationsprotokoll mit dem separaten Agent · 180 teilen müssen. Die Kommunikation mit dem externen Agent 180, beispielsweise zum Erhalt von Kapazitäten auf seiner Verbindung als Reserve-Ressource, könnte einem oder mehreren der CABS-Agents als Task zugeordnet werden.

2. AUFBAU EINES EINZELNEN, UNTER VERWENDUNG EINER CABS-PLATTFORM BZW. EINES CABS-DIENSTPROGRAMM- PAKETS ERSTELLTEN AGENT

Gemäß Fig. 2 umfaßt der innere Aufbau eines einzelnen, kollaborativen Agent für eine verteilte Steuerung, Überwachung und Verwaltung externer Systeme 240, der unter Verwendung von CABS erstellt werden kann:
(i) eine Mailbox 200 oder eine Kommunikationsvorrichtung, die die Kommunikation zwischen dem Softwaremodul und weiteren internen oder externen Software- oder Hardwaresystemen verarbeitet,
(ii) eine Nachrichtenverarbeitungseinrichtung 205 die von der Mailbox 200 hereinkommende Nachrichten verarbeitet und sie an weitere Komponenten in der Architektur weiterleitet, (iii) ein Koordinationsmaschinen- und Schlußfolgerungssystem 210, das die von dem Agent auszuführenden Aufgaben betreffende Entscheidungen trifft, entscheidet, wie diese Aufgaben zu wahrzunehmen sind, wann sie fallengelassen werden sollen, etc. und wie die Aktivitäten des Agent mit anderen CABS-Agents des Systems koordiniert werden sollen, wobei das Koordinationsmaschinen- und Schlußfolgerungssystem sowohl einen Motor als auch eine Datenbank 255 der Koordinationsprozesse enthält,
(iv) ein Beziehungsmodell 215, das die Kenntnisse des Agent bezüglich der Kapazitäten weiterer Agents des Systems beschreibt,
(v) eine Planungs- und Terminplanungseinrichtung 220, die die von dem Agent gesteuerten, überwachten und verwalteten Tasks auf der Grundlage der von dem Koordinationsmaschinen- und Entscheidungsfindungssystem 210 getroffenen Entscheidungen und der dem Agent zur Steuerung, Überwachung und/oder Verwaltung zur Verfügung stehenden Ressourcen und Tasks plant und zeitlich abstimmt,
(vi) eine Ressourcendatenbank 225, die logische Beschreibungen der dem Agent gegenwärtig zur Verfügung stehenden Ressourcen enthält und eine Schnittstelle zwischen der Datenbank und externen Systemen bereitstellt, so daß die Datenbank die Verfügbarkeit von Ressourcen von externen Systemen abrufen und externe Systeme informieren kann, wenn die Ressourcen von dem Agent nicht mehr benötigt werden, wobei die externen Systeme auf eigene Initiative Ressourcenteile in der Datenbank hinzufügen, löschen oder verändern können, wodurch Veränderungen des Verhaltens des Agent initiiert werden,
(vii) eine Task-Datenbank 230, die logische Beschreibungen der für die Steuerung, Überwachung und/oder Verwaltung durch den Agent verfügbaren Tasks enthält, und
(viii) eine Ausführungsüberwachungseinrichtung 235, die von der Planungs- und Terminplanungseinrichtung zur Ausführung oder Beendigung vorgesehene Tasks externer Systeme startet, beendet und überwacht und das Koordinationsmaschinen- und Entscheidungsfindungssystem 210 bezüglich erfolgreicher und außergewöhnlicher Beendigungsbedingungen bei den Tasks informiert, die sie überwacht.
Bei der Erstellung eines Agent verwendet der Entwickler verschiedene, von CABS bereitgestellte Editoren zur Erzeugung der für verschiedene Module der Agent-Architektur einschließlich der Koordinations- und Entscheidungsfindungsmaschine 210, des Beziehungsmodells 215, der Ressourcendatenbank 225 und der Task- Datenbank 230 erforderlichen Beschreibungen.
Bei der Verwendung wird der Agent durch Ereignisse angetrieben, die eine Veränderung des Status des Agent verursachen. Der Agent läßt ein durch die Komponentenbibliothek des Systems erzeugtes Ereignismodell ablaufen, um diese inneren Veränderungen zu überwachen, wobei er sie über eine API für einen Programmierer sichtbar macht. Es existieren drei mögliche externe Ereignisquellen (siehe Fig. 2): externe Nachrichten von anderen Agents an die Mail- box 200 (beispielsweise die Anforderung eines Dienstes), von der die externen Systeme überwachenden Ausführungsüberwachungseinrichtung 240 (beispielsweise von verschiedenen Sensoren) initiierte externe Ereignisse und durch Veränderungen der Ressourcendatenbank 225 initiierte externe Ereignisse. Wenn beispielsweise ein Ereignis stattfindet, durch das der Zustand des Agent verändert wird, beispielsweise der Verlust einer Ressource, muß er seine Aufzeichnungen dementsprechend aktualisieren.
Eine Veränderung des Zustands kann eine Folge von Aktivitäten innerhalb und/oder außerhalb des betreffenden Agent initiieren. Der Verlust einer zur Bereitstellung eines Diensts erforderlichen Ressource (beispielsweise durch eine Fehlfunktion) würde beispielsweise den Versuch des Planungs- und Terminplanungsmoduls 220 erforderlich machen, eine andere Ressource zu sichern, die zum Ausführen des gleichen Job geeignet ist. Gelingt ihm dies, können alle aus dem Verlusts der Ressource resultierenden Aktivitäten in dem Agent enthalten sein. Kann das Planungs- und Terminplanungsmodul 220 jedoch keine weitere lokale Ressource lokalisieren, wird das Koordinationsmaschinen- und Entscheidungsfindungssystem 210 aufgerufen, um entweder zu versuchen, die Ressource bei einem anderen Agent zu sichern oder den Task, der diese Ressource erfordert, an einen anderen Agent zu delegieren / zu übertragen. In beiden Fällen fordert das Koordinationsmaschinen- und Entscheidungsfindungssystem 210 über die Nachrichtenverarbeitungseinrichtung 210 die Mailbox 200 an, um eine Nachricht zu erstellen und sie an ausgewählte andere Agents weiterzuleiten. Auf diese Weise wird die Koordination der Aktivitäten mit anderen Agents realisiert.
Weitere Einzelheiten der Komponenten der Agent-Struktur, die den vorstehend beschriebenen Mechanismus unterstützen, sind nachstehend ausgeführt.

2.1. Die Mailbox 200

Die Mailbox 200 ist als mehrschichtiges Modul mit Kommunikation zwischen den Agents über TCP/IP-Stecker implementiert. Eine Schicht der Ausführung, die Server-Schicht, wartet auf hereinkommende TCP-Verbindungsanforderungen von anderen Agents und nimmt sie entgegen, empfängt alle ankommenden Nachrichten von diesen Agents und legt sie in einer Eingangsablage ab (stellt sie in eine Warteschlange). Eine zweite Schicht, die Client-Schicht, öffnet TCP-Verbindungen mit anderen Agents, um Nachrichten zu versenden. Zu versendende Nachrichten werden aus einer Ausgangsablage (einer Warteschlange) abgerufen. Wenn andere Module des Agent das Versenden einer Nachricht an einen anderen Agent anfordern, werden diese Nachrichten in der Ausgangsablage der Mailbox abgelegt, um später durch die Client-Schicht aufgenommen zu werden. Die bei der vorliegenden Implementation verwendete Nachrichtensprache ist die KQML-Agent-Kommunikationssprache (Tim Finin, Yannis Labrou & Jamens Mayfield (1997), "KQML as an Agent Communication Language" in Bradshaw, J (Ed.), "Software Agents", Cambridge Mass.: MIT Press, Kapitel 14, Seiten 291-316).
Die Mailbox-Technologie ist relativ standardisiert und könnte unter Verwendung eines alternativen Kommunikationsprotokolls anstelle von TCP/IP, wie elektronischer Post und dem HyperText Transfer Protocol (HTTP), implementiert werden.

2. 2. DIE NACHRICHTENVERARBEITUNGSEINRICHTUNG 205

Die Nachrichtenverarbeitungseinrichtung 205 überprüft die Eingangsablage der Mailbox 200 durchgehend auf neu eingehende Nachrichten, die sie zur detaillierten Verarbeitung an weitere relevante Komponenten des Agent weiterleitet. Dieses Modul basiert auf Standardtechnologie, umfaßt eine durchgehend laufende Schicht, die die Mailbox 200 überprüft, und hat Zugriff auf die Verarbeitungseinrichtungen sämtlicher Hauptkomponenten des Agent, um Nachrichten an sie zu senden.
In CABS ist das Format von KQML-Nachrichten wie folgt:
KQML [:Absender:Empfänger:Inhalt].
Für Agent-Nachrichten einschließlich der Kommunikation zwischen den Agents, wie sie normalerweise für die Koordination in CABS verwendet werden, werden KQML-Funktionen verwendet, und die Einzelheiten der Kommunikation sind normalerweise in dem KQML-Inhaltsfeld enthalten. Ein CABS-Agent, der eine Veränderung des Zustands weiterer Agents (die im CABS-Koordinationsprotokoll einen Vorschlag, einen Gegenvorschlag oder ein Akzeptieren repräsentieren kann) veranlaßt, verwendet die KQML-Funktion "achieve". Die Empfänger-Agents antworten bei einem Gegenvorschlag durch die Verwendung der KQML-Funktion "reply" und beim Akzeptieren eines Vorschlags durch "accept".

2.3 Das Koordinationsmaschinen- und Entscheidungsfindungssystem 210

Gemäß den Fig. 2 und 3 sind sowohl das Koordinationsmaschinen- und Entscheidungsfindungssystem 210 als auch das Planungs- und Terminplanungsprogramm 220 bei CABS-Agents einmalig und werden nun beide im Einzelnen beschrieben. Auf sie wird ferner nachstehend bei der Beschreibung der Verwendung der CABS- Plattform zur Erstellung eines Agent-Systems in dem Abschnitt mit dem Titel" 4. VERWENDUNG DER CABS-PLATTFORM ZUR ER- STELLUNG EINES AGENT-SYSTEMS" jeweils unter den Überschriften "Schritt 4: Spezifikation der Agent Koordinationsstrategie und "Schritt 2: Agent-Definition" Bezug genommen.
Die Koordination ist in CABS besonders wichtig, da die Agents kollaborativ sind. Kollaborative Software-Agents bezeichnen die komplexe Klasse von Agents, die sowohl autonom als auch zur Kooperation mit anderen Agents zum Ausführen von Tasks für die Entitäten geeignet sind, die sie repräsentieren. Sie können verhandeln müssen, um für alle Seiten akzeptable Vereinbarungen mit anderen Agents zu treffen. Ein Agent kann beispielsweise eine Anfrage nach einer Ressource von einem anderen Agent empfangen. Er antwortet entsprechend der Beziehung zwischen ihnen und entsprechend seinen eigenen besonderen Umständen (seinem "Status"), der beispielsweise davon abhängt, ob er über diese Ressource verfügt. Die Antwort bildet einen Teil eines Interaktionsprozesses zwischen den beiden Agents, der durch ein "Koordinationsprotokoll" bestimmt wird. Das Koordinationsmaschinen- und Entscheidungsfindungssystem 210 ermöglicht dem Agent eine Interaktion mit anderen Agents unter Verwendung von einem oder mehreren vom Entwickler als für die Domäne des Agents geeignet ausgewählten Koordinationsprotokollen.
In der Vergangenheit waren Koordinationsprotokolle typischer Weise in der Art, in der einzelne Software-Agents arbeiten, "fest verdrahtet", so daß ihre Änderung ein vollständiges Neuschreiben er gesamten, verteilten Anwendung erforderte. Bei einem CABS-System verfügt der Agent jedoch über einen oder mehrere Koordinationsgraphen 255 und eine Maschine 210 zu deren Ausführung. Jeder Graph umfaßt einen Satz Kennzeichnungen für Knotenpunkte sowie einen Satz Kennzeichnungen für Bögen, die Übergangsbedingungen für die Bewegung von einem Knotenpunkt zum anderen identifizieren. Der Agent hat auch Zugriff auf ein Depot der ausführbaren Form der durch die Kennzeichnungen identifizierten Knotenpunkte und Bögen. Dieses Depot kann innerhalb des Agent oder außerhalb desselben gehalten werden. Die Koordinationsmaschine 210 verwendet Graphenbeschreibungen zum dynamischen Erstellen und Ausführen von Koordinationsprozessen durch Zusammenfügen der von den Knotenpunkt- und Bogenkennzeichnungen der Graphen identifizierten Prozeßschritte.
Zum Zeitpunkt der Erstellung des Agent wählt der Benutzer aus einer Koordinationsgraphendatenbank die spezifischen Koordinationsgraphen für den Agent aus, die in die lokale Koordinationsgraphendatenbank 255 des Agent geladen werden. (Der bei CABS einmalige Visualisierungs-Agent 140 weist ein Steuerungsdienstprogramm auf, das Benutzern die Änderung der Koordinationsgraphen des Agent während der Laufzeit ermöglicht. Dies ist nachstehend unter der Überschrift "5. FEHLERBEHEBUNG UND VISUALISIERUNG" genauer beschrieben.)
Ein besonders wesentliches Merkmal des CABS-Agent ist, daß seine Koordinationsmaschine 210 mehr als einen Koordinationsprozeß und damit mehr als ein Koordinationsprotokoll gleichzeitig implementieren kann. Dies erfolgt effektiv durch die Multiplex- Ausführung der in der Koordinationsgraphendatenbank 255 gehaltenen Koordinationsgraphen durch einen Agent. Die Maschine 210 befaßt sich mit dem ersten Knotenpunkt jedes Koordinationsgraphen 255, der in sie geladen wurde, und fährt dann der Reihe nach mit den zweiten Knotenpunkten sämtlicher Graphen etc. fort. Dadurch läuft sie effizient parallel durch die Koordinationsgraphen 255.
CABS bietet daher in der Agens-Hülle 300 ein Koordinationsmaschinen- und Entscheidungsfindungssystem 210, dessen Funktionalität bei der Erstellung des Agent durch die Auswahl aus einem Satz von Koordinationsgraphen 310 bestimmt wird. Ist ein Agent einmal in Betrieb, werden die Koordinationsgraphen von dem Koordinationsmaschinen- und Entscheidungsfindungssystem 210 für die Ausführung spezifizierter Koordinationsprozeßschritte und Protokolle verwendet.
Das von den Kennzeichnungen identifizierte Depot von Prozeßschritten wird nicht notwendigerweise selbst in jedem Agent gespeichert. Es kann einfach von dem Agent entsprechend dessen Koordinationsgraphen während der Laufzeit darauf zugegriffen werden.
(Im folgenden wird das Koordinationsmaschinen- und Entscheidungsfindungssystem 210 auch als Koordinationssoftwaremodul 210 bezeichnet.)
Der Gesamtaufbau des Koordinationssoftwaremoduls 210 ist der einer Turingmaschine. Es nimmt als Eingänge verschiedene Statusvariablenwerte, Parameter, Aufgaben, Ausnahmen und Einschränkungen auf und gibt Entscheidungen aus.
Wenn bei einem System mit mehreren Agents zwei oder mehr Agents unter Verwendung ihrer jeweiligen Koordinationssoftwaremodule 210 einen Koordinationsprozeß ausführen, kann die Gesamtprozeßfunktionalität allgemein wie folgt durch ein "universelles Koordinationsprotokoll" (UCP) repräsentiert werden:

UCP

Das UCP ist eine 3-Phasen-Folge der Aktivitäten "Vorschlag", "Gegenvorschlag" und "Annahme/Bestätigung" mit den gezeigten möglichen Schritten. Jede Aktivität wird durch einen "Knotenpunkt" repräsentiert (der hier durch die Beschreibung eines Prozesses auf hohem Niveau repräsentiert wird), und die Knotenpunkte sind durch (hier als Pfeile dargestellte) "Bögen" verbunden, die jeweils eine Übergangsbedingung für die Bewegung von einem Knotenpunkt zum anderen darstellen. Das Koordinationssoftwaremodul 210 jedes Agent muß zur Unterstützung der Rolle des Agent in dem UCP geeignet sein.

2.3.1 Das Koordinationssoftwaremodul 210

Das Koordinationssoftwaremodul 210 ist so beschaffen, daß es die Koordinationsgraphen interpretiert, wenn ihm ein Ausgangszustand gegeben (eine Aufgabe gestellt) wird. Der Ausgangszustand spezifiziert die Ausgangsbedingungen der Probleme und die erforderlichen Daten.
Die Ausführung eines Graphen durch das Koordinationssoftwaremodul 210 erfolgt wie folgt: die Maschine wählt den ersten Knotenpunkt des Graphen aus und leitet einen durch die Kennzeichnung des Knotenpunkts identifizierten Prozeß ein. Dieser Prozeß wird durch Aufrufen seines exec() in Gang gesetzt, auf das eines von drei möglichen Ergebnissen zurückgesendet wird: FAIL, OK oder WAIT. Wenn auf exec() die Antwort OK folgt, wird ein durch die Kennzeichnung des ersten, den Knotenpunkt verlassenden Bogens identifizierter Prozeß initialisiert und ausgeführt. Wenn die Überprüfung des Bogens erfolgreich verläuft, wird der Knotenpunkt, auf den der Bogen weist, zur Ausführung vorgemerkt. Der Graph wird auf diese Weise ausgeführt, bis ein letzter Knotenpunkt erreicht ist, von dem aus keine weiteren Bögen existieren.
Das Koordinationssoftwaremodul 210 kreist in dem Sinne durchgehend durch die Graphen, daß es eine Überwachung auf Ereignisse und Ausnahmen ausführt, die zu jeder beliebigen Zeit auftreten.
Wenn eine Bogenüberprüfung an einem Knotenpunkt scheitert, wird der nächste Bogen von dem Knotenpunkt überprüft. Wenn das exec()-Verfahren eines Knotenpunkts mit FALL beantwortet wird oder sämtliche den Knotenpunkt verlassenden Bögen scheitern, wird der Knotenpunkt (durch Aufrufen des backtrack()-Verfahrens des Knotenpunkts, das sämtliche Veränderungen rückgängig macht, die durch das exec()-Verfahren vorgenommen wurden) bis zum vorhergehenden Knotenpunkt der Kette zurückverfolgt.
Wenn das exec()-Verfahren eines Knotenpunkts mit WAIT beantwortet wird, wird der Knotenpunkt in eine Warteschlange gestellt, bis eine von zwei Bedingungen erfüllt ist: entweder wird von der Maschine ein neues externes Ereignis (beispielsweise eine Antwortnachricht von einem anderen Agent) empfangen oder ein von dem Knotenpunkt spezifiziertes Zeitlimit wird überschritten. In beiden Fällen wird der Knotenpunkt erneut zur Ausführung vorgemerkt. Zusammenfassend führt die Maschine eine Tiefenverarbeitung des Graphen aus, bei dem eine Rückverfolgung zulässig ist.
Weitere Attribute der Maschine umfassen:
(i) die Fähigkeit, Graphen und Bögen äquivalent zu verarbeiten, wenn eine Bogenkennzeichnung tatsächlich einen Graphen bezeichnet - dadurch verfügt die Maschine über eine Rekursivfunktion - und
(ii) die Fähigkeit, mehrere Ereignisse des gleichen Bogens zu erzeugen und sie parallel zur Verwaltung der Fehlfunktion der parallelen Zweige auszuführen. Dies bedeutet, daß beim Scheitern eines Zweigs eines parallelen Bogens die Maschine automatisch an der Ausführung sämtlicher anderen parallelen Zweige scheitert.
Die genaue Logik der Koordinationsmaschine 210 ist wie folgt:
Die folgenden Codefragmente beschreiben das grundsätzliche Verhalten eines Knotenpunkts. Es wird darauf hingewiesen, daß bei der Definition eines neuen Knotenpunkts nur die Funktionen exec() und backtrack() definiert werden müssen. Die nachstehend aufgeführten weiteren Funktionen beschreiben, wie die Knotenpunkte mit der Maschine und den Bögen interagieren.
Das folgende Codefragment beschreibt die Funktionen, die das Veralten eines Graphen implementieren. Es wird erneut darauf hingewiesen, daß der Benutzer diese Funktionen nicht implementieren muß. Zur Beschreibung eines Graphen muß der Benutzer einfach eine zweidimensionale Datensatzanordnung erstellen, in der die Knotenpunkte und Bögen des Graphen aufgelistet sind.
Nachstehendes ist ein Beispiel einer Graphenbeschreibung, die in der Koordinationsgraphendatenbank 255 gespeichert ist und zur Erzeugung und zum Ausführen eines Koordinationsprozesses verwendet wird.
Die Anordnung beschreibt einen Graphen mit vier Zuständen s1-s4 und fünf Bögen a1-a5. Vom Knotenpunkt s0 kann der Bogen a1 zum Status s 1 oder der Bogen a2 zum Status s4 oder alternativ der Bogen a3 zum Status s4 genommen werden. Wenn von einem Knotenpunkt mehr als ein Bogen genommen werden kann, werden die Bögen in der Reihenfolge geprüft, in der sie in der Beschreibung des Graphen präsentiert werden.
Der Code, mit dem ein Benutzer einen Knotenpunkt definiert, muß einfach ein exec()- und ein backtrack()-Verfahren implementieren. Für Bögen sollte der Code ein exec()-Verfahren implementieren, das ein boolesches Ergebnis mit dem Wert wahr oder falsch zurücksendet.

2.3.2 Koordinationsmechanismen

Gemäß Fig. 11 wird bei CABS-Agents jeder Koordinationsmechanismus in Begriffen eines 14-stufigen Rahmens spezifiziert, wobei in jeder Stufe zumindest eine Statusprozeßfunktion implementiert werden sollte. Der 14-stufige Rahmen kann als "Zusammenfassung" der genauen Logik der vorstehend als Code aufgeführten Koordinationsmaschine 210 betrachtet werden. Die gattungsmäßigen atomaren Prozeßfunktionen für die vierzehn Stufen sind nachstehend aufgelistet. Fig. 11 beschreibt die nachstehend aufgelisteten Stufen in schematischer Form.

Ressourcenphase

In dieser Phase wurde ein Agent A2 durch eine ankommende Nachricht von einem weiteren Agent A1 aktiviert, der beispielsweise Tasks delegieren muß. Die ankommende Nachricht wird an das Koordinationsmaschinen- und Entscheidungsfindungssystem 210 des Agent A2 gesendet, der bei der Erstellung und Ausführung eines Koordinationsgraphen die Planungs- und Terminplanungseinrichtung 220 und die verschiedenen Datenbanken 230, 225, 215, 245 aufruft, um dem Agent A1 zu antworten. In der Ressourcenphase verwendet der Agent A2 die Task-Datenbank 230, um festzustellen, welche Ressourcen ein Task erfordert, und die Ressourcen- und Verpflichtungsdatenbanken 225, 245 um festzustellen, ob diese Ressourcen verfügbar sind.

Stufe 1

Verifizieren der Verfügbarkeit der Ressourcen und Bestimmen der Aktionen für Situationen mit ausreichenden/nicht ausreichenden Ressourcen;
Entscheidung:
- wenn die Ressourcen vollständig/teilweise ausreichen gehe zur nächsten Stufe
- wenn die Ressourcen zur Gänze nicht verfügbar sind zurückweisen und beenden;

Stufe 2

die Ressourcen vorläufig reservieren;

Delegationsphase

Diese Phase kommt nur ins Spiel, wenn der Agent 2 nicht selbst über die Ressourcen verfügt, um Agent A1 zu antworten.

Stufe 3

Bestimmung der Position/Rolle des Agents im Gesamtkontext der Koordination (Kopf - Eigner des aktuellen Aufgabe, oder kein Kopf - d. h. ein Agent, an den ein untergeordnete Aufgabe delegiert wurde) und Bestimmung des Niveaus der Verfügbarkeit der Ressourcen (teilweise /vollständig ausreichend).
- Wenn die Ressourcen nur teilweise ausreichend sind gehe zur nächsten Stufe (S&sub2;-S&sub5;);
- wenn die Ressourcen nur teilweise ausreichend sind, ist es erforderlich, mit anderen Agents zu verhandeln, um zusätzliche Ressourcen zu finden. Die Stufen 53 bis 59 bringen Verhandlungsprozeßstufen ein, die nicht erforderlich sind, wenn die Ressourcen vollständig ausreichend sind. Daher gilt, wen die Ressourcen vollständig ausreichend sind und die Rolle das Agent "Kopf" ist, gehe zu Stufe 13 (S&sub2;-S&sub1;&sub3;);
- die Ressourcen sind vollständig ausreichend, aber die Rolle des Agent ist nicht "Kopf" gehe zu Stufe Zehn (S&sub2;-S&sub1;&sub0;);

Stufe 4

Suchen des ersten Satzes von Tasks, für den die erforderlichen Ressourcen nicht bereitgestellt werden können;
Entfernen des ausgewählten Satzes (S&sub3;-S&sub4;);

Stufe 5

Erzeugung eines neuen Vorschlags unter Verwendung jedes Task in dem ausgewählten Satz (S&sub4;-S&sub6;);

Stufe 6

Suche nach einem Satz von Agents, an die der Vorschlag weitergeleitet werden kann (S&sub5;-S&sub6;);

Verhandlungsphase

Stufe 7

(hängt von der anzuwendenden Koordinationsstrategie, beispielsweise "Multiple Round Second Price Open Bid" oder "Contract Net" - siehe unten, ab.)
Vorschlag versenden (S&sub6;-S&sub7;)
- Accceptance-Verarbeitung ausführen (S&sub7;-S&sub6;);
- (Counter proposal-Verarbeitung ausführen)(S&sub6;-S&sub7;),
- (Modified proposal-Verarbeitung ausführen) (S&sub7;-S&sub6;);

Stufe 8

Zusammenfassung der in der Verhandlungsphase erhaltenen Ergebnisse (S&sub7;-S&sub8;)

Stufe 9

Entscheidung: Auswahl eines Satzes von Annahmen anhand des Ergebnisses (S8-S9);

Stufe 10

Entscheidung:
- wenn weitere Sätze von Tasks vorhanden sind, für die die erforderlichen Ressourcen nicht bereitstehen gehe zu Stufe 3 (S&sub9;-S&sub3;);
- wenn keine weiteren Sätze von Tasks vorhanden sind, für die die erforderlichen Ressourcen nicht bereitgestellt werden können, und der Agent ein Kopf-Agent ist gehe zu Stufe 13 (S&sub9;-S&sub1;&sub2;);
- wenn keine weiteren Sätze von Tasks vorhanden sind, für die die erforderlichen Ressourcen nicht bereitgestellt werden können, und der Agent kein Kopf-Agent ist gehe zur nächsten Stufe (S&sub9;-S&sub1;&sub0;);

Stufe 11

- Annahme und Antworten senden (S&sub1;&sub0;-S&sub1;&sub1;);
- Bestätigungsverarbeitung ausführen (S&sub2;-S&sub1;&sub0;);
- falls anwendbar, Verarbeitung des veränderten Vorschlags ausführen (S&sub1;&sub1;-S&sub1;&sub0;).

Stufe 12

Entscheidung:
- falls keine Delegierung erfolgte und eine Bestätigung empfangen wurde gehe zu Stufe 14 (S&sub1;&sub1;-S&sub1;&sub3;);
- falls eine Delegierung erfolge und eine Bestätigung empfangen wurde gehe zur nächsten Stufe (S&sub1;&sub1;-S&sub1;&sub3;);
- falls keine Bestätigung empfangen wurde zurückweisen und beenden (S&sub1;&sub1;-SE).

Stufe 13

Bestätigung senden (S&sub1;&sub2;-S&sub1;&sub3;).

Stufe 14

Die Ressourcen fest reservieren und beenden (S&sub1;&sub3;-S&sub1;&sub4;, S&sub1;&sub4;- SE).

2.3.3 Definition neuer Koordinationsmechanismen

Der Aufbau der Koordinationsmaschine ermöglicht eine praktisch unendliche Erweiterung auf die verschiedenen UCP-konformen Koordinationsgraphen und selbst auf nicht UCP-konforme Graphen. Dies wird durch die Tatsache erreicht, daß die Koordinationsmaschine eine gattungsmäßige und domänenunabhängige Funktion ist, die jede Graphenbeschreibung der vorstehend beschriebenen Form interpretiert. Wenn der Maschine verschiedene Koordinationsgraphen zugeführt werden, werden unterschiedliche Koordinationsverhalten ausgeführt. Überdies verhält sich die Maschine bei einer Veränderung der durch die Knotenpunkt- und Bogenkennzeichnungen eines Graphen identifizierten, implementierten Funktionen (d. h. Programme) und bei der anschließenden Ausführung des Graphen selbst dann unterschiedlich, wenn der Satz der gegebenen Kennzeichnungen unverändert bleibt.
Es wurde festgestellt, daß das UCP und sein Derivat, der vierzehnstufige Rahmen, viele existierende Koordinationsmechanismen fassen. Es wurde auch festgestellt, daß sich diese Mechanismen lediglich in bestimmten, untergeordneten aber feinen Aspekten unterscheiden. Nach sorgfältiger Analyse wurde festgestellt, daß bei einer Differenzierung des UCP in 14 Stufen die meisten Mechanismen viele der Stufen gemeinsam haben und sich lediglich hinsichtlich einer geringen Anzahl von Stufen unterscheiden. Dies ermöglicht die Implementierung einer großen Anzahl verschiedener Mechanismen durch die Entwicklung nur weniger neuer Funktionen, und viele der üblichen Funktionen können erneut verwendet werden. Zudem ermöglicht die Spezifikation von Mechanismen, die einen gemeinsamen, zugrunde liegenden Rahmen verwenden, die Lösung eines Problems unter Verwendung einer Mischung unterschiedlicher Mechanismen.
Ist ein Koordinationsverhalten gegeben, sollten die folgenden Schritte zur Definition eines neuen, UGP-konformen Koordinationsgraphen ausreichen:
- Verfeinern des Verhaltens, so daß die Entscheidungsfindung und die Verarbeitung der vierzehnstufigen Rahmen entsprechen;
- Durchsuchen der Bibliothek der Koordinationsmaschine und Wiederverwendung implementierter Funktionen soweit möglich. Dies ist der Fall, wenn das funktionale Verhalten mit dem erforderlichen identisch ist;
- Implementation neuer Funktionen, für die die folgenden drei Verfahren existieren müssen, bei Stufen, für die keine implementierten Funktionen wiederverwendet werden können:
- exec: Ausführen der erforderlichen Änderungen an Status und Nachrichtenübertragung und Aktualisierung bestimmter Datenbanken zur Überprüfung, ob eine Funktion anwendbar ist;
- backtrack: zum Zurücksetzen sämtlicher ausgeführten Operationen und zur Wiederherstellung des ursprünglichen Zustands;
- label: Zuweisung einer Kennzeichnung zu jeder neu implementierten Funktion.

2.3.4 Einfügen neuer Koordinationsgraphen in die Maschine

Nach der Definition eines Vorrats an implementierten Funktionen sollte der Maschine einfach eine Datensatzbeschreibung des Graphen hinzugefügt werden, um der Maschine die Verwendung eines bestimmten Koordinationsgraphen zu ermöglichen. (Die Maschine kann mehrere Koordinationsgraphen zu einem vereinigten Graphen vereinen, der keine Duplikate von Zuständen enthält.) Wenn zur Lösung eines bestimmten Problems mehr als ein Koordinationsmechanismus erforderlich ist, sollte die Maschine die Graphen erhalten, die die erforderlichen Koordinationsprozesse beschreiben. Nach der Vereinigung der Graphen kann die Maschine die verschiedenen, in den vereinigten Graphen implizierten Mechanismen opportunistisch anwenden.

2. 4. Die Beziehungsdatenbank 215

Die Ressourcen-; Task- und Beziehungsdatenbanken 225, 230, 215 dienen primär als Informationsdepots und können unter Verwendung herkömmlicher Datenbanktechnologien implementiert werden, die Speicher-, Wiederbeschaffungs- und Abfragefunktionen unterstützen. Bei einer Implementation wird eine Hash-Tabelle (die jeden zu speichernden Datensatz mit einem eindeutigen Schlüssel verbindet) als Hauptdatenspeicherstruktur für jedes Modul verwendet.
In der Beziehungsdatenbank 215 ist ein Beziehungsmodell für den Agent in Form einer Beziehungstabelle gespeichert, wie in dem folgenden Beispiel: die Domäne ist gemäß diesem Beispiel eine Handelsumgebung, wie zwischen zwei Geschäften: Shop 1 und Shop 2. Gemäß Fig. 6 hat der Verwaltungs-Agent von Shop 1 (der Agent A1) zwei Assistenten, die Agents B1 und C1, während der Verwaltungs- Agent von Shop 2 (der Agent A2) drei Assistenten B2, C2 und D2 hat.
Notwendiger Weise sind A1 in diesem Szenario die Existenz und die Fähigkeiten von B1 und C1 bekannt, da sie seine Assistenten sind, und ähnliches gilt für A2 bezüglich B2, C2 und D2. Es wird davon ausgegangen, daß A1 A2 und die Ergebnisse bekannt sind, die A2 liefern kann, A2 jedoch keine Kenntnis von A1 hat. Ferner wird davon ausgegangen, daß sämtliche Assistenten in jedem Shop Kenntnis voneinander und ihren jeweiligen Fähigkeiten haben. Die beiden nachstehenden Tabellen fassen ein mögliches Beispiel der organisatorischen Kenntnisse der Agents der Shops 1 und 2 zusammen. Tabelle: Beispiel der organisatorischen Kenntnisse der Agents von Shop 1 Tabelle: Beispiel der organisatorischen Kenntnisse der Agents von Shop 2
Die Tabelle von Shop 1 zeigt die vier bei der aktuellen Implementation des CABS-Systems verwendeten organisatorischen Beziehungen. Die Beziehungen übergeordnet und untergeordnet behalten ihre natürliche Interpretation als vertikale strukturelle Beziehungen mit Untertönen der Autorität bei. Partner und Gleichgestellte sind horizontale strukturelle Beziehungen; in CABS ist ein Gleichgestellter ein weiterer Agent in der gleichen statischen Agentur, der weder übergeordnet noch untergeordnet ist. Partnerbeziehungen sind der Standard und betreffen jeden dem Basis-Agent bekannten Agent, der weder übergeordnet, noch untergeordnet noch ein Gleichgestellter ist.
Einige der Implikationen der unterschiedlichen organisatorischen Beziehungen auf Verhandlungs- und Koordinationsstrategien werden nachstehend unter der Überschrift "4.4 Schritt 4: Spezifikation 510 der Agent-Koordinationsstrategie" besprochen.
Es wird darauf hingewiesen, daß, daß organisatorische Beziehungen nicht standardmäßig bidirektional sind. Dies bedeutet, daß ein Agent X, obwohl er der Ansicht sein kann, Y sei ihm untergeordnet, nicht notwendigerweise impliziert, daß Y glaubt, X sei ihm übergeordnet. Es wird ebenso darauf hingewiesen, daß die Shop 2 betreffende Tabelle keine Partnerbeziehung für den Agent A2 zeigt. Dies reflektiert die Tatsache, daß Agent A2 keine Kenntnis von dem Verwalter von Shop 1, d. h. Agent A1 hat.
Es wird auch darauf hingewiesen, daß die Annahmen eines Agents bezüglich eines zweiten nicht mit den den zweiten betreffenden Annahmen (Daten) eines dritten Agent übereinstimmen müssen. Gemäß der Shop 1 betreffenden Tabelle nimmt A1 beispielsweise an, daß C1 das Ergebnis Item2 zu Kosten von 4 Einheiten und unter Verwendung von 3 Zeiteinheiten bereitstellen kann. B1 hingegen geht davon aus, daß C1 Item² zu Kosten von 3 Einheiten und unter Verwendung von 5 Zeiteinheiten bereitstellt. Dies kann in der Praxis beispielsweise auftreten, wenn die Agents unterschiedliche Dienstniveauvereinbarungen haben.

2.5 Die Planungs- und Terminplanungseinrichtung 220

Die Rolle der Planungs- und Terminplanungseinrichtung 220 ist die Planung und Terminplanung für die von dem Agent auszuführenden Tasks. Es können die herkömmlichen Planungstechniken (beispielsweise eine einrichtungsseitige Analyse wie bei SIPE- oder O- PLAN-Planungseinrichtungen, siehe die Druckschriften in "IEEE Expert: Intelligent Systems and their Applications", Bd. 11, Nr. 6, Dezember 1996) und Terminplanungstechniken (beispielsweise eine Job-Shop-Zeitplanung) verwendet werden. Die Planungs- und Terminplanungseinrichtung 220 des CABS-Agent weist jedoch zusätzliche, innovative Aspekte auf. Sie kann beispielsweise eine Überbuchungsfunktion zur Sicherstellung einer maximierten Nutzung der Ressourcen bieten.
Die Implementation der Planungs- und Terminplanungseinrichtung 220 eines CABS-Agent ist eine einrichtungsseitige, teilweise und hierarchische Planungseinrichtung. Gemäß Fig. 9 hält sie eine Übertragungstabelle (oder -datenbank) 245, die eine zweidimensionale Anordnung mit verfügbare Prozessoren enthaltenden Zeilen 900 und Zeitpunkte enthaltenden Spalten 905 ist (wobei eine ganzzahlige Repräsentation der Zeit verwendet wird). Der Basiszeitpunkt ("0") der Tabelle ist der aktuelle Zeitpunkt, wogegen die maximale Zeit der aktuelle Zeitpunkt plus die maximale Vorausplanungsperiode des Agent ist.
Eingaben in die Planungs- und Terminplanungseinrichtung 220 sind Aufgaben der Form: Bereitstellung einer Ressource R bis zum Zeitpunkte zu maximalen Kosten c. Es wird darauf hingewiesen, daß die Aufgabenspezifikation weitere Parameter, wie die Qualität, enthalten kann. Dies hängt von der verwendeten Planungseinrichtung ab. Ihre Ausgänge sind:
(a) Ausgabe-Tasks
- ein Satz von Tasks, die ausgeführt werden müssen, um das Aufgabe zu erfüllen; und
(b) Untergeordnete Ausgabe-Aufgaben
- ein Satz von untergeordneten Aufgaben, die der Agent an andere Agents übertragen muß, wenn die Aufgabe der obersten Ebene ausgeführt werden soll.
Das Verhalten der Planungseinrichtung ist wie folgt:
Die Berechnung der Gesamtkosten zur Ausführung einer Aufgabe erfolgt durch Aufsummieren der Kosten für die Ausführung sämtlicher zur Ausführung der Aufgabe erforderlicher Tasks. Wenn die Planung einmal erfolgt ist, bucht die Planungseinrichtung vorläufig den geplanten Terminplan in der Zuweisungstabelle. Beim Empfang einer Bestätigung der Buchung durch die Koordinationsmaschine wird der Terminplan fest gebucht, und die Tasks werden für die Ausführung zu den geplanten Zeitpunkten vorbereitet. Diese Verendung der vorläufigen und festen Buchung gibt der Koordinationsmaschine Zeit zum Delegieren zur Ausführung der Aufgaben erforderlicher, externer Unter-Aufgaben und ebenso die Möglichkeit zur Löschung von Zuweisungen.
Das Verhalten der Planungseinrichtung des CABS-Agent führt die folgenden, besonders nützlichen Konzepte ein:
- die Verwendung von vorläufigen und festen Buchungen gibt der Planungseinrichtung die Möglichkeit der doppelten Buchung bereits vorläufig gebuchter Slots (prinzipiell ähnlich der Handlungsweise von Luftfahrtreservierungsgesellschaften). Diese Idee verbessert die Chancen des Agent, mit voller Kapazität zu arbeiten. Der Mechanismus zur Handhabung doppelter Buchungen arbeitet wie folgt: Die Planungseinrichtung hält eine zweite Kopie der Zuweisungstabelle, die nur die fest gebuchten Slots und die vorläufig doppelt gebuchten Slots aufzeichnet. Wenn von dem Agent eine doppelte Buchung gestattet wird, verwendet die Planungseinrichtung diese Tabelle für die Planung, wenn sie unter Verwendung der normalen Zuweisungstabelle keine freien Slots für einen Task finden kann. Werden in der zweiten Tabelle freie Slots gefunden, werden diese Slots als doppelt gebucht gekennzeichnet. Bei der gegenwärtigen Implementation werden bei der Buchung von zwei Aufgaben auf den gleichen Slot der ersten zu bestätigenden Aufgabe die Slots zugewiesen und
- die zweite Aufgabe wird zurückgewiesen. Es kann eine andere Auswahlpolitik implementiert werden, beispielsweise entsprechend der Aufgabe mit der höchsten Priorität oder der Aufgabe mit den höchsten Kosten, etc. Es ist auch möglich, den Grad der doppelten Buchungen zu steuern, indem der Planungseinrichtung ein Prozentsatz der Summe der Slots vorgegeben wird, die doppelt gebucht werden können;
- Begrenzen der maximalen Anzahl an parallelen Zweigen auf der Grundlage der verfügbaren Prozessoren;
- die Voraussetzungen für einen Task können bestellt werden, ein Task mit drei Voraussetzungen A, B und C kann beispielsweise die Einschränkung beinhalten, daß A vor B und dann c erfüllt sein muß. Obwohl dies ein Merkmal einiger herkömmlicher Planungseinrichtungen ist, führt eine derartige Einstufung der Aufgaben bei CABS zu einer Überlappung der Planung mit der Koordination. Bei herkömmlichen, auf Agents basierenden Systemen steuert die Koordinationsmaschine die Planungseinrichtung, doch bei CABS-Agents teilen die Planungseinrichtung 220 und die Koordinationsmaschine 210 die Steuerung bei der Verarbeitung der Einstufung der Aufgaben. Bei dem vorstehend erwähnten Fall A, B, C kann A für den Agent geplant und B nach außen delegiert worden sein. Die Wahl des Agent für die Erfüllung von B und die Art und Weise, in der B erfüllt werden soll (variable Bindungen), sowie die Art und Weise, auf die A erhalten wird, beeinflussen C. Damit hängt die endgültige Entscheidung, welcher Agent den Vertrag erhält, von der Planungseinrichtung ab und basiert nicht einfach auf einem einzigen Faktor, wie den günstigsten Kosten. Derartige Probleme treten typischer Weise auf, wenn die untergeordneten Aufgaben nicht unabhängig sind, und die Überlappung der Planung mit der Koordination schafft einen flexiblen Mechanismus zur Handhabung einer derartigen Abhängigkeit.
Vorstehend wird auf "variable Bindungen" Bezug genommen. Sie sind ein bekanntes Konzept zur Durchsetzung einer Gleichwertigkeitsbeschränkung zwischen einer Variable und einer Tatsache oder einer weiteren Variable. Eine Bindung wird verwendet, wenn eine Variable einer Tatsache gleichwertig eingestuft wird. Wenn beispielsweise die Variable "v1" der Tatsache "f1" gleichgestellt ist, wird "v1" als an "f1" gebunden bezeichnet.
CABS-Agents können auch das Anbringen eines Optimierungszeitplaners an der Zuweisungstabelle ermöglichen. Bei einer einfachen Implementation kann ein Beschränkungserfüllungsalgorithmus zur derartigen Neuterminierung bereits geplanter Aktivitäten verwendet werden, daß keine der während der Planung auferlegten Einschränkungen verletzt wird. Dies ist bei der Handhabung von Ausnahmen oder beim Ausführen von Planungsaufgaben nützlich. Die Optimierung kann zu der auf Einschränkungen basierenden Neuterminierungseinrichtung hinzugefügt werden.
Im Fall von Ausnahmen kann eine Ausnahme (eine unerwartete Fehlerbedingung) auftreten, wenn ein ausgeführter Task die geplante Zeit überschreitet. Wenn in der Zuweisungstabelle freie Slots verfügbar sind, könnte die Planungseinrichtung ihre Aktivitäten möglicherweise neu planen, um den ausgeführten Task mehr Zeit zu verschaffen. Für eine einfache Neuplanung des Beschränkungseinhaltungstyps versucht die Planungseinrichtung ein neues Arrangement zu treffen, bei dem keine der durch die Aufgaben auferlegten Einschränkungen verletzt wird. Bei einer optimierenden Neuterminierungseinrichtung könnte der Planer eine Verletzung der Einschränkungen zulassen, soweit ein optimales Arrangement gefunden wird (die Optimierung basiert in diesem Fall auf Kriterien, die vom Entwickler festgelegt werden). Ein Job mit geringen Kosten, mit dem die Planungseinrichtung bereits beschäftigt ist, kann beispielsweise zugunsten der Verlängerung der Verarbeitungszeit eines Jobs mit hohen Kosten fallengelassen werden, der diese überschritten hat.
Ein Zeitplaner kann auch zur Sicherstellung von Verfahrenszielen verwendet werden. Ein Agent kann beispielsweise das Verfahrensziel haben, sicherzustellen, daß Jobs so rasch wie möglich ausgeführt werden. In einem derartigen Fall kann er in der in Fig. 9 gezeigten Zuweisungstabelle 245 die untergeordneten Tasks B und C jeweils zwei bzw. eine Zelle nach links verschieben und mit ihrer Ausführung beginnen, wenn dem Agent sämtliche für sie erforderlichen Ressourcen zur Verfügung stehen. Eine derartige erneute Zeitplanung verletzt keine der Beschränkungen, die durch die Aufgabe der obersten Ebene auferlegt werden.

2.6 Die Ressourcen-Datenbank 225

In der Ressourcen-Datenbank 225 sind Ressourcendefinitionen gespeichert.
Im allgemeinen ist eine "Variable" eine logische Beschreibung einer Sache, während ein "Fact" ein bestimmtes Beispiel dieser Sache ist, wobei relevante Daten zu der logischen Beschreibung hinzugefügt wurden. Ressourcen sind in diesem Zusammenhang Tatsachen, die daher zum Zwecke der Erstellung der Zuweisungstabelle die Eingabe von jede Ressource betreffenden Daten durch den Benutzer erfordern. Der Tatsachen-/Variablen-Editor 355 ist so beschaffen, daß er dem Benutzer das Laden der erforderlichen Daten unter Verwendung eines Objekt-Attribut-Wert-Formalismus auf Rahmenbasis ermöglicht.
Eine Ressource ist als Objekt mit zugeordneten Attribut-Wert- Paaren definiert. Ein Agent in einem Kommunikationssystem kann eine Ressource beispielsweise benötigen, um eine Optikfaser- Netzwerkverbindung von London nach Ipswich bereitzustellen, die Videodaten überträgt. Der Ressourcenbedarf des Agent kann wie folgt ausgedrückt werden: Ressourcenbeispiel 1
Die besonderen Ressourcen und die ausgewählten zugehörigen Attribute hängen davon ab, wie der Benutzer beschließt, die Domäne anzulegen.
Wenn die "is-variable"-Flagge falsch ist, wie bei dem vorstehenden Beispiel, dann ist die Ressource tatsächlich eine Tatsache. Anderenfalls wird sie als Variable betrachtet. Das "id"-Feld gibt die eindeutige Identifikation der Ressource an. Die beiden folgenden Beispiele betreffen Ressourcenvariablen: Ressourcenbeispiel 2
Es wird darauf hingewiesen, daß "?Begriff" eine lokale Variable bezeichnet.
Die Ressourcen-Datenbank 225 enthält auch die Ontologiedatenbank 260. In dieser ist die logische Definition jedes Tatsachen- Typen - die für ihn zulässigen Attribute, der Bereich der zulässigen Attributwerte für jedes Attribut, sämtliche Beschränkungen zwischen den Attributwerten und sämtliche Beziehungen zwischen den Attributen der Tatsache und andere Fakten - gespeichert. Die Agents müssen die gleichen ontologischen Informationen verwenden, wenn sie einander verstehen sollen.

2.7 Die Task-Datenbank 230

In der Task-Datenbank sind Task-Definitionen gespeichert, die beispielsweise von dem Planer und Zeitplaner 220 verwendet werden. Die Task-Definition stellt einen skelettartigen Programmierrahmen bereit, der umfaßt:
- eine Folge von Aktivitäten
- eine Auswahl (if, then...)
- eine Iteration (eine Ausstiegsbedingung)
Die CABS-Task-Definition (oder -Beschreibung) führt auch das Konzept der "zwingend parallelen" Tasks und der "wahlweise parallelen" Tasks ein. Wenn eine Task-Beschreibung zwingend parallele Aktivitäten enthält, muß mehr als eine Aktivität gleichzeitig ausgeführt werden. Dies verhindert, daß ein Agent, dem nur eine einzige Ressource zur Verfügung steht, den Task beansprucht.
Ein Task kann ein primitiver Task sein, der nur eine Aktivität umfaßt, oder er kann einen Satz untergeordnete Tasks umfassen. Ein Beispiel für letzteres ist ein Task, der eine einfache arithmetische Berechnung, wie "ax² + dx + c" ausführen soll. Wenn dieser Task die Indikation zwingend parallel aufweist, werden die drei Werte ax², dx und c gleichzeitig berechnet, worauf der sequentielle Schritt des Addierens der berechneten Werte folgt. Für einen Task dieser Art wird von dem Task-Definitions-Editor eine Aufteilung 560 erzeugt (siehe nachstehend unter der Überschrift "4.5 Schritt 5: Task-Definition"), und ein wesentlicher Aspekt der Task-Beschreibung sind die Schnittstellen zwischen den Ausgängen einer Task-Aktivität und den Eingängen der nachfolgenden Task-Aktivitäten.
Eine Task-Beschreibung umfaßt ferner die Voraussetzungen für den Task, wie die Ressourcen, die er erfordert und die Auswirkungen, die er hat (Eingänge/Ausgänge), die Dauer der Verarbeitung des Task, logische Beschreibungen zur tatsächlichen Ausführung des Task auf dem externen System 125 und, bei komplexen Tasks, die vorstehend erwähnte Aufteilung 560, die eine Liste von untergeordneten Tasks des komplexen Tasks ist.
Ein Ausgang des Task ist eine Rückmeldung 555, die eine Anweisung zum Ausführen einer relevanten Funktion ist, die über den Ausführungsmonitor 250 an das externe System 125 ausgegeben wird. Ein Beispiel könnte das Ausführen einer Faksimileaktivität sein. Die logische Beschreibung umfaßt eine Variable 550, die das Laden von Papier und das Wählen einer Faksimilenetznummer umfaßt. Eine Aufteilung 560 des Task listet untergeordnete Tasks, wie die Erfassung des Vorhandenseins eines zu versendenden Vorlagenblatts oder eines Blocks von Textdaten im korrekten Puffer, die Erfassung eines Klingeltons, die Erfassung einer Entgegennahme des Anrufs und des Verlaufs der Übertragung oder die Feststellung eines Besetztzeichens, das Speichern der erforderlichen Nummer und den erneuten Anruf nach einem eingestellten Zeitintervall, auf. (Dies sind klarer Weise untergeordnete Tasks, die nicht parallel ausgeführt oder unter Faksimilegeräten aufgeteilt werden können.) Die Rückmeldung 555 ist in der Realität die Anweisung an ein Faksimilegerät, die tatsächliche Faksimileaktivität auszuführen.
Tasks und Task-Definitionen sind nachstehend (unter der Überschrift "4.5 Schritt 5: Task-Definitionen" genauer besprochen.

2.8 Ausführungsmonitor 250

Der Ausführungsmonitor 250 weist Schnittstellen zu dem externen System 125, zum Planer und Zeitplaner 220 und zum Koordinationsmaschinen- und Entscheidungsfindungssystem 210 auf.
Der Ausführungsmonitor 250 führt die Aufgaben des Agents aus, indem er die Ausführung von Tasks in dem externen System 125 veranlaßt. Für jeden Task-Typ in der CABS-Umgebung ist eine benutzerdefinierte Task-Rückmeldungsfunktion vorgesehen. Wenn der Ausführungsmonitor 250 entscheidet, einen bestimmten Task auszuführen, erfolgt dies, indem er die entsprechenden Task- Rückmeldungsfunktionen aufruft und sie an das externe System 125 ausgibt.
Zur Vereinfachung der Konstruktion des CABS wird die tatsächliche Ausführung dieser Task-Rückmeldungsfunktionen simuliert. Nach dem erfolgreichen Abschluß eines Task wird ein Signal an den Ausführungsmonitor 250 gesendet. Nichtsdestotrotz kann auch ein Scheitern einer Task-Ausführung (beispielsweise aufgrund eines Hardwareproblems der Roboterarme des externen Systems 125) simuliert werden. Unter diesen Umständen wird der Ausführungsmonitor 250 wegen des Scheiterns alarmiert, und damit können geeignete Korrekturaktivitäten entwickelt werden. Der Ersteller des Agent kann den Agent beispielsweise so gestalten, daß er bei einer Fehlfunktion die auszuführenden Aufgaben neu terminiert, indem er alternative Task-Rückmeldungsfunktionen ablaufen läßt oder indem er sie über die Koordinationsmaschine 210 an andere Agents delegiert.
Überdies kann der Ausführungsmonitor 250 entscheiden, daß die zum Ausführen eines Task erforderliche Zeit die erwartete Dauer überschritten hat, wenn er kein geeignetes Eingangssignal empfangen hat. Durch den gleichen Token kann der Ersteller des Agent bestimmen, welche geeigneten Aktionen in einem derartigen Fall ausgeführt werden sollen.
Der Ausführungsmonitor 250 hat die folgenden Funktionen für durch PID und Seq gekennzeichnete Vorschläge.

Book (reserviert Ressourcen)

Book [PID, Level, Seq, AID]
wobei
- PID, die Vorschlags-ID, einen bestimmten Vorschlag bezeichnet;
- Level, Seq Z die Ebenennummer und die Folgenummer des Vorschlag ist;
- AID die ID der Aktion angibt, mit der die Funktion antwortet.

UnBook (hebt die Reservierung von Ressourcen auf)

UnBook [PID, Level, Seq, AID]
wobei
- PID, die Vorschlags-ID, einen bestimmten Vorschlag kennzeichnet;
- Level, Seq Z die Ebenennummer und die Folgenummer des Vorschlags ist;
- AID die ID der Aktion angibt, mit der die Funktion antwortet.

Commit (weist Ressourcen zu)

Commit (PID, Level, Seq, AID]
wobei
- PID, die Vorschlags-ID, einen bestimmten Vorschlag kennzeichnet;
- Level, Seq Z die Ebenennummer und die Folgenummer des Vorschlags ist;
- AID die ID der Aktion angibt, mit der die Funktion antwortet.

Uncommit (löscht die Zuweisung von Ressourcen)

Uncommit [PID, Level, Seq, AID]
wobei
- PID, die Vorschlags-ID, einen bestimmten Vorschlag kennzeichnet;

Uncommit (löscht die Zuweisung von Ressourcen)

Uncommit [PID, Level, Seq, AID]
wobei
- PID, die Vorschlags-ID, einen bestimmten Vorschlag kennzeichnet;
- Level, Seq Z die Ebenennummer und die Folgenummer des Vorschlags ist;
- AID die ID der Aktion angibt, mit der die Funktion antwortet. (Diese Funktion kann nur ausgeführt werden, wenn die Ausführung des Proposal noch nicht begonnen hat)

3. ÜBERSICHT ÜBER DIE CABS-PLATTFORM

Gemäß Fig. 3 wird durch die CABS-Plattform die Einrichtung zur Erfassung von Daten zum Laden der Architektur zur Erzeugung eines Systems mit einer oder mehreren Entitäten gemäß der Architektur und zur automatischen Erstellung eines Softwaremoduls gemäß der Architektur bereitgestellt. Dadurch werden ein Agent- Templat 300, das die in Fig. 2 gezeigte Agent-Struktur diktiert, eine Benutzerschnittstelle 305, die primär ein Satz Editoren zur Identifikation eines Satzes von Agents, zur funktionalen Auswahl eines Agent und zur Eingabe von Tasks und Domäne betreffenden Daten ist, und eine Bibliothek von Koordinationsstrategien 310 sowie ein Satz unterstützender Standard-Agents 315 bereitgestellt.
Die Agent-Schablone 300 ist einfach der Rahmen zur Unterstützung der in Fig. 2 gezeigten Agent-Struktur, die hier vollständig beschrieben wird. Die Editoren werden nachstehend beschrieben. Die Koordinationsstrategien 310 sind vorstehend unter der Überschrift Koordinationsstrategien 310 sind vorstehend unter der Überschrift "2.3 Das Koordinationsmaschinen- und Entscheidungsfindungssystem 210" beschrieben. Einer der Unterstützungs-Agents 315 ist jedoch besonders wesentlich und neuartig. Er ist nachstehend unter der Überschrift "5. FEHLERBEHEBUNG UND VISUALISIERUNG" beschrieben. Er könnte Anwendung in weiteren Systemen mit mehreren Agents und verteilten Systemen finden, nicht nur bei den unter Verwendung des CABS-Systems erzeugten.
Die Editoren der Benutzerschnittstelle 305 unterstützen vom Entwickler bei der Erstellung und Eingabe der Agents über eine Erstellungsschnittstelle 350 gefällte Entscheidungen und zeichnen sie auf. Genauer umfassen sie folgendes:
- einen Agent-Definitionseditor 320 (der nachstehend unter "4.2 Schritt 2: Agent-Definition 500" besprochen wird) zur Erstellung einer logischen Beschreibung des Agent, seine Fähigkeiten und ursprünglichen Ressourcen, etc.;
einen Organisationseditor 325 (der nachstehend unter "4.2 Schritt 3: Agent-Organisation 505" besprochen wird) zur Beschreibung der relationalen Verbindungen zwischen Agents in einem Szenario und auch der Vorstellungen, die jeder Agent von den anderen Agents im System hat;
- einen Koordinationseditor 330 (der nachstehend unter "4.4 Schritt 4: Spezifikation der Agent-Koordinationstragegien 510" besprochen wird) zur Auswahl und/oder Beschreibung der Koordinationsstrategien der Agents;
- einen Task-Beschreibungseditor 335 (der nachstehend unter "4.5 Schritt S: Task-Definition 520" besprochen wird) zur Beschreibung der Tasks, die die Agents in der Domäne ausführen können;
- einen Ontologieeditor 340 (der nachstehend unter "4.1 Schritt 1: Domänenüberprüfung und Agent-Identifikation 515" besprochen wird) zur Beschreibung einer geeigneten Ontologie für die Domäne;
- einen Fakten-/Variablen-Editor 355 (der nachstehend unter "4.2 Schritt 2: Agent-Definition 500" und unter "4.5 Schritt 5: Task-Definition 520" besprochen wird) zur Beschreibung bestimmter Beispiele von Fakten und Variablen unter Verwendung der vom Ontologieeditor 340 bereitgestellten Template;
- einen Codeerzeugungseditor 360 (der nachstehend unter "4.6 Schritt 6: Erzeugung domänenspezifischer Problemlösungscodes 525" besprochen wird) zur Erzeugung eines Codes entsprechend den für jeden Agent bereitgestellten Definitionen; einen Editor 365 für summarische Tasks (der nachstehend unter "4.5 Schritt 5: Task-Definition 520" besprochen wird) zur Beschreibung summarischer Tasks, die Tasks sind, die aus einem oder mehreren untergeordneten Tasks zusammengesetzt sind, die in einer gewissen Reihenfolge ausgeführt werden müssen;
- einen Beschränkungseditor 370 (der nachstehend unter "4.5 Schritt 5: Task-Definition 520" besprochen wird) zur Beschreibung der Beschränkungen durch (i) die Voraussetzungen für einen und die Auswirkungen eines Task, (ii) eine oder mehrere Vorraussetzungen für einen Task und (iii) die Auswirkungen eines vorhergehenden Task und die Voraussetzungen für einen nachfolgenden Task in der Beschreibung eines summarischen Task.
Der Ausgang 100 der CABS-Plattform ist dann eine logische Beschreibung eines Satzes von Agents und eines Satzes von Tasks, die in einer Domäne ausgeführt werden sollen, zusammen mit einem ausführbaren Code für jeden Agent und Ansätze für einen ausführbaren Code für jeden Task.
CABS verkörpert ein System aus Verfahren und eine Umgebung zur Bereitstellung einer Entwicklungseinrichtung für Systeme mit mehreren Agents mit den Mitteln
- zur Konfiguration einer Reihe unterschiedlicher Agents mit variierenden Funktionen und unterschiedlichem Verhalten, zu ihrer Organisation in jeder gewählten Weise,
- zur Ausstattung jedes Agent mit aus einer von dem CABS bereitgestellten Liste von Kommunikations- und Koordinationsfähigkeiten,
- zur Ausstattung jedes Agent mit dem erforderlichen, domänenspezifischen Problemlösungscode und
- zur automatischen Herstellung der erforderlichen Ausführbarkeit der Agents.
Zudem kann die CABS-Plattform dem Entwickler eine Reihe von Unterstützungs-Agents 315 eines bekannten allgemeinen Typs, wie Namens-Server, Vereinfachungseinrichtungen (klassifizierte Verzeichnisse) und Visualisierungseinrichtungen, zur Verfügung stellen. Insgesamt ermöglicht es das CABS dem Systementwickler, sich auf die domänenspezifische Analyse zu konzentrieren, ohne Mühen auf agentbezogene Themen verwenden zu müssen.

4. DIE NUTZUNG DER CABS-PLATTFORM ZUR ERSTELLUNG EINES AGENT-SYSTEMS

Die CABS-Plattform basiert auf einer Verfahrensweise zur Erstellung kollaborativer Software-Agents, bei der davon ausgegangen wird, daß die Agents über fünf primäre Gruppen von Charakteristika oder "Ebenen" verfügen. Gemäß den Fig. 4 und 5 müssen Entwickler wie folgt drei von diesen, d. h. eine Definitionsebene 400, eine Organisationsebene 405 und eine Koordinationsebene 410, betreffende Eingaben liefern.
In einem für die Definitionsebene 400 relevanten "Agent- Definitionsschritt" 500 bestimmen Benutzereingaben den Agent in Begriffen seiner Entscheidungsfindungsfähigkeit (und Lernfähigkeit), seiner Aufgaben, Ressourcen, etc.
In einem für die Organisationsebene 405 relevanten "Agent- Organisationsschritt" 505 bestimmen Benutzereingaben den Agent in Begriffen seiner Beziehungen zu anderen Agents, beispielsweise seiner Zugehörigkeit zu Agencies, seiner Rolle in diesen Agencies, der anderen Agents, die ihm bekannt sind, der ihm bekannten Fähigkeiten dieser anderen Agents, ete. (Eine Agency ist eine Gruppe von Agents, die ein gemeinsames Attribut teilen, beispielsweise ihre Zugehörigkeit zur gleichen Firma. Agencies können virtuell oder real sein. Eine virtuelle Agency ist eine Gruppe von Agents, die eine Art von Kooperationsvereinbarung teilen.)
In einem für die Koordinationsebene 410 relevanten "Agent- Koordinationsschritt" 510 bestimmen Benutzereingaben die Koordinations- und Verhandlungstechniken für den Agent.
Die beiden anderen, in jedem Agent vorhandenen "Ebenen" sind in Fig. 4 gezeigt. Sie sind eine Kommunikationsebene 415, die technische Aspekte der Kommunikation zwischen den Agents verarbeitet, und eine Anwendungsprogrammierschnittstellenebene (API-Ebene) 420, die eine Schnittstelle für externe Systeme zum Hinzufügen, Modifizieren oder Löschen von Ressourcen bereitstellt, die dem Agent zur Verfügung stehen. Bei dem in Fig. 2 gezeigten Aufbau wird die Kommunikationsebene 415 durch die Mailbox 200 und die Nachrichtenhandverarbeitungseinrichtung 205 bereitgestellt. Die API-Ebene 420 wird durch die Schnittstelle zwischen den externen Systemen 240 und der Ressourcen-Datenbank 225 und dem Ausführungsmonitor 235 bereitgestellt. Sie werden daher beide von dem Agent- Templat 300 gemäß Fig. 3 bereitgestellt.
Die von dem CABS-Verfahren benötigten Benutzereingaben für die Definitionsebene 400, die Organisationsebene 405 und die Koordinationsebene 410 sind gemäß den folgenden sechs Schritten strukturiert:
1. Domänenuntersuchung und Agent-Identifikation 515,
2. Agent-Definition 500,
3. Agent-Organisation 505,
4. Spezifikation der Agent-Koordinationsstraategie 510,
5. Task-Definition 520 und
6. Erzeugung eines domänenspezifischen Problemlösungscodes 525
Gemäß den Fig. 3 und 5 stellt die CABS-Plattform über die Benutzerschnittstelle 305 visuelle Programmiereditoren zur Unterstützung und Automatisierung der Schritte 1-5 bereit. Diese Schritte sollten iterativ ausgeführt werden, bis der Entwickler überzeugt ist, daß der endgültige Satz von Agents das modellierte Problem akkurat abbildet.
Die Verwendung der CABS-Plattform zur Ausführung der Schritte 1-6 wird nun genauer beschrieben.

4. 1 Schritt 1: Domänenuntersuchung und Agent Identifikation 515

Die CABS-Plattform dient der Verwendung durch einen Entwickler, der eher Domänenfachmann als Fachmann für Software- Agents ist. Der erste Schritt wird auf die Art und Weise ausgeführt, die der Domänenexperte für die beste hält. Es ist möglich, daß der Domänenfachmann eine Entscheidung beispielsweise darauf gründet, wo in der Domäne die Steuerungsprozesse ausgeführt werden müssen. Der bevorzugte Ansatz ist jedoch die Bevorzugung der autonomen Entscheidungsfähigkeit als Hauptkriterium zur Identifikation des ursprünglichen Satzes von in Frage kommenden Agents in der Domäne. Das Niveau der Körnigkeit, mit der die Domäne modelliert wird, wird durch den Domänenfachmann festgelegt und bestimmt die Grenzen der in Frage kommenden Agents. Als Startpunkt werden normalerweise in Frage kommende Agents identifiziert, wann immer eine Entscheidungen treffende Entität in der Domäne vorhanden ist.
Die Benutzereingabe ist in diesem Stadium einfach eine Liste von Agent-Identifikationen, die den von dem Domänenfachmann als wahrscheinlich zur Erstellung eines sinnvollen Modells der Domäne und damit einer funktionsfähigen Steuerungsstruktur für diese geeignet ausgewählten Satz von in Frage kommenden Agents repräsentiert. Das CABS weist jeder der Identifikationen eine Kopie der Agent- Schablone 300 zu, und der Ausgang des Schritts 1 ist dieser Satz von Agent-Schablonen 300.
Wenn in einem späteren Stadium festgestellt wird, daß ein Konflikt vorliegt, beispielsweise weil einem in Frage kommenden Agent Entscheidungen in bezug auf einen Prozeß zugeordnet werden müssen, den er in der Praxis nicht beeinflussen kann, kann die Liste der Agent-Identifikationen geändert werden, um den Satz in Frage kommenden Agents einzustellen, beispielsweise um einen neuen hinzuzufügen, und der Erstellungsprozeß wird wiederholt, um die Veränderungen zu reflektieren.
Zur Agent-Identifikation ist kein besonderer Editor erforderlich.
Eine weitere wesentliche Benutzereingabe ist das Vokabular der Domäne. Es wird unter Verwendung des Ontologieeditors 340 eingegeben. Ein Ontologie- oder Datenwörterbuch für eine für eine Domäne beschreibt sämtliche möglichen Konzepte oder Objekte, die in der Domäne vorhanden sein können. Im CABS wird ein Objekt-Attribut- Wert-Formalismus zur Beschreibung der Domänenobjekte und - konzepte verwendet. Der Ontologieeditor 340 liefert einfach Template zur Beschreibung der Objekte, d. h. (i) der unterschiedlichen Objektarten, (ii) der Liste der Attribute jedes dieser Objekttypen, (iii) des Typs von Werten, die jedes Attribut annimmt und (iv) der Standardwerte für jedes Attribut (sofern vorhanden).
Der Editor liefert ein Templat oder eine Form, damit das Vokabular der Domäne beschrieben werden kann, die die Agents kontrollieren sollen.
Der Ontologieeditor 340 ermöglicht dem Benutzer die Identifikation einer ENTITÄT, ihrer ATTRIBUTE, der WERTE, die die Attribute annehmen und typischer STANDARDWERTE. Ein Beispiel im Bereich der Kommunikationsnetzwerke wäre wie folgt:

4.2 Schritt 2: Agent-Definition 500

Für jeden der im Schritt 1 identifizierten Agents müssen über den Agent-Definitionseditor 320 die folgenden Benutzereingaben erfolgen:
- die Identitäten der Tasks, die der Agent ausführen kann;
- die Anzahl der Tasks, die der Agent gleichzeitig ausführen kann;
- die Zeitperiode, über die der Agent seine Ressourcen normalerweise zuweist (über die er seine Aktivitäten plant); und
- die Ressourcen, die dem Agent zur Verfügung stehen.
Diese Daten werden zur Verwendung bei der Erstellung einer Zuweisungstabelle 245 zu dem vorstehend unter Bezugnahme auf Fig. 2 beschriebenen Planer und Terminplaner 220 weitergeleitet.
Die die Task-Identifikationen, die Anzahl der Tasks und den Planungszeitrahmen betreffende Dateneingabe ist ein ziemlich geradliniger Prozeß, mit der Ausnahme, daß, was den Zeitrahmen betrifft, verschiedene Faktoren ins Spiel kommen. Bei einigen Szenarien ist beispielsweise ein Agent, der nur über kürzere Zeitspannen vorausplanen kann, weniger geeignet, die Anforderungen der Kunden zu erfüllen, kann jedoch besser auf veränderte wirtschaftliche Bedingungen reagieren.
Die Tasks werden in einem späteren, nachstehend unter der Überschrift "4.5 Sohritt 5 Task-Definition" beschriebenen Stadium definiert, und in diesem Stadium ist es lediglich erforderlich, die Identifikationen einzugeben. Es müssen jedoch die Ressourcen definiert werden, die dem Agent zur Verfügung stehen. Da der Kontext, in dem der Agent arbeiten kann, ein beliebiger unter einer großen Anzahl sehr unterschiedlicher Kontexte sein kann, ist es erforderlich, dem Agent eine Definition der Ressourcen zu geben, die ausreicht, damit er ein korrektes logisches Modell der tatsächlichen physischen Ressourcen zu erzeugen, die ihm zur Verfügung stehen, so daß er seine Aktivitäten geeignet planen kann. Das CABS stellt einen Fakten/Variablen-Editor 355 bereit, der zur Beschreibung der Ressourcen verwendet wird, die dem Agent zur Verfügung stehen.
Im allgemeinen ist eine "Variable" eine logische Beschreibung einer Sache, wogegen ein "Faktum" ein bestimmtes Beispiel dieser Sache ist, wobei relevante Daten zu der logischen Beschreibung hinzugefügt werden. Ressourcen sind in diesem Kontext Fakten, die daher zum Zwecke der Erstellung des logischen Modells der tatsächlichen physischen Ressourcen die Bereitstellung von jede Ressource betreffenden Daten durch den Bediener erfordern. Der Fakten- /Variablen-Editor 355 ist so beschaffen, daß er dem Benutzer unter Verwendung eines Objekt-Attribut-Wert-Formalismus auf Rahmenbasis das Laden der erforderlichen Daten ermöglicht.
Eine Ressource (bzw. ein Faktum) ist als Objekt mit zugeordneten Attribut-Wert-Paaren definiert. Ein Agent eines Kommunikationssystems kann beispielsweise eine Ressource benötigen, um eine faseroptische Netzwerkverbindung von London nach Ipswich bereitzustellen, über die Videodaten übertragen werden. Der Ressourcenbedarf des Agent kann möglicherweise wie folgt ausgedrückt werden: Ressourcenbeispiel 1
Die besonderen Ressourcen und die ausgewählten zugehörigen Attribute hängen davon ab, wie sich der Benutzer entschließt, die Domäne zu modellieren.
Wenn die "is-variable"-Flag auf false gesetzt ist, wie bei dem vorstehenden Beispiel, ist die Ressource tatsächlich ein Faktum. Anderenfalls wird sie als Variable betrachtet. Das "id"-Feld enthält die eindeutige Identifikation der Ressource. Die folgenden beiden Beispiele betreffen Ressourcenvariablen. Ressourcenbeispiel 2
Es wird darauf hingewiesen, daß "?Begriff" eine lokale Variable bezeichnet.
Gemäß Fig. 2 lädt der Fakten-/Variablen-Editor 255 die Ressourcendaten in die Ressourcendatenbank 225 des Agent, auf die der Planer und Terminplaner 22 zum Zwecke der Erstellung und der Verwaltung einer Zuweisungstabelle Zugriff hat.
Der Ausgang des Schritts 2 sind daher ein Satz von Fakten 530 (ein Satz von Ressourcen) und eine Liste von Task-Identifikationen 535, für die in einem nachstehend beschriebenen Schritt S Definitionen bereitgestellt werden müssen.

4.3 Schritt 3: Agent-Organisation

Für jeden der im Schritt 1 identifizierten Agents müssen über den Organisationseditor 325 die folgenden Benutzereingaben erfolgen:
- Identifikation der anderen Agents in der Gemeinschaft, die ihm bekannt sind;
- Bestimmung der primären strukturellen Beziehung, in der er zu jedem der identifizierten Agents steht;
- Identifikation der Task-Ausgänge (sofern vorhanden), die jeder der identifizierten Agents erzeugen kann;
- Spezifikation der durchschnittlichen Kosten und Zeiten (sofern bekannt) für jeden der identifizierten Task-Ausgänge.
Die die Task-Ausgänge betreffenden Dateneingaben müssen erneut nur die Identifikationen für Task-Ausgänge umfassen, die von dem Agent anhand der nachstehend unter Schritt S beschriebenen Task-Definitionen verstanden werden können.
Der Organisations-Editor 325 verwendet die Dateneingaben in diesem Schritt (Schritt 3) zur Erstellung einer Beziehungstabelle, die dann in dem Beziehungsmodell 215 des Agent gespeichert wird. (Die Beziehungstabelle ist vorstehend unter der Überschrift "2.4 Beziehungsdatenbank 215" beschrieben.)
Die Ausgänge des Schritts 3 sind daher ein Satz von Agent- Beziehungen 545, die das CABS in dem Beziehungsmodell 215 des Agent speichert, und ein Satz von Variablen 540, die die Ressourcen (Produkte) beschreiben, von denen der Basis-Agent annimmt, daß der Ziel-Agent sie erzeugen kann.

4.4 Schritt 4: Spezifikation der Agent-Koordinationsstrategien

Für jeden der im vorstehend beschriebenen Schritt 1 identifizierten Agents müssen über den Koordinationseditor 330 die Identitäten der UCP-konformen Koordinationsgraphen eingegeben werden, die der Agent ausführen kann, um seine unterschiedlichen Koordinationsstrategien zu realisieren. Das CABS hält derzeit die folgenden Koordinationsgraphen in seiner Koordinationsgraphendatenbank 310, die der Benutzer durch Laden der Koordinationsgraphendatenbank 255 auswählen und den Agents zuweisen kann:
1. Master - Slave (hierarchische Task-Verteilung)
2. Vertragsnetz (Begrenztes Vertragsnetz)
3. Gebote über mehrere Runden mit verdecktem ersten Preis
4. Gebote über mehrere Runden mit offenem ersten Preis (ähnlich English Auction)
5. Gebote über mehrere Runden mit verdecktem zweitem Preis
6. Gebote über mehrere Runden mit offenem zweiten Preis (ähnlich Vickery Auction)
7. Gebote über mehrere Runden mit offenem Gegenpreis (ähnlich Dutch Auction)
8. Derivate der fünf zuletzt genannten Strategien über eine Runde
Eine Client-Server- oder Master-Slave-Koordination tritt auf, wenn ein Master einem Slave einen auszuführenden Job zuweist. Diese Strategie erfordert notwendiger Weise eine übergeordnete Beziehung zwischen Master und Slave. Die Vertragsnetz-Strategie liegt vor, wenn ein Agent einen Task ausschreibt, wobei er Angebote zur Ausführung des Task von anderen Agents anfordert. Dann bewertet er die Gebote und weist den Vertrag dem geeignetsten Agent (den geeignetsten Agents) zu. Diese Strategie beruht nicht auf einer organisatorischen Beziehung zwischen den beteiligten Agents. Das begrenzte Vertragsnetz ist der Vertragsnetz-Strategie ähnlich, mit der Ausnahme, daß der ausschreibende Agent die Agents auswählt / einschränkt, an die Gebote gesendet werden.
Die vorstehend aufgelisteten Koordinationsprotokolle können über eine Runde oder mehrere Runden ablaufen. Ein Verhalten über eine Runde zwischen zwei Agents betrifft den Empfang (beispielsweise) eines Vorschlags und seine sofortige Annahme. Alternativ kann der Agent eine weitere Runde des Zyklus initiieren, wobei in diesem Falle ein Verhalten über mehrere Runden zustande kommt. Der Schlüsselpunkt ist hierbei, daß die Beendigungsbedingung bei dem Agent, der die Interaktion initiiert, erfüllt sein muß, bevor die Interaktion beendet wird.
Typischer Weise haben die meisten anderen Agent- Anwendungen Agents mit einer oder höchstens zwei festgelegten Strategien. CABS-Agents können viel mehr aufweisen, wie durch die vorstehende Liste dargestellt. Daher kann ein Agent beispielsweise ein erstes Koordinationsprotokoll verwenden (beispielsweise English Auction), um eine Antiquität zu verkaufen, während er gleichzeitig zum Verkauf von Blumen ein zweites Protokoll (beispielsweise Dutch Auction) und für weitere Task-Verteilungen ein drittes Protokoll (das Vertragsnetz) verwendet.
Wenn ein Benutzer eine Koordinationsstrategie benötigt, die von dem CABS nicht bereitgestellt wird, kann der Koordinationseditor 330 verwendet werden, um einen neuen Koordinationsgraphen zu definieren, der dann zur Koordinationsgraphendatenbank 255 des Agents hinzugefügt wird. Unter Verwendung des UCP als Ausgangspunkt können beispielsweise durch Hinzufügen eines neuen Untergraphen, der in einem der vorab definierten Graphen neue Knoten zwischen existierenden Knoten herstellt, und/oder durch Modifizieren eines oder mehrerer der Bögen in einem vorab definierten Graphen neue Koordinationsgraphen erzeugt werden. Alternativ kann ein vollständig neuer Graph erstellt werden, indem dem vorstehend unter "2.4.1 Koordinationssoftwaremodul: Definition neuer Koordinationsgraphen" beschriebenen Prozeß gefolgt wird. Der Hauptvorteil dieses neuartigen Ansatzes ist, daß ein einfacher Kern beibehalten wird (das UCP), während zu entwickelnde und zu installierende komplexere Koordinationstechniken erheblich vereinfacht werden. Neue Koordinationsgraphen können auf der Grundlage des UCP aus bereitgestellten primitiven und mit von dem Koordinationseditor 330 bereitgestellten Einschränkungen zusammengestellt werden. Der Editor 330 stellt sicher, daß der Ersteller eines neuen Protokolls folgendes ausführt:
1. Starten mit dem UCP;
2. Identifizieren der Teile des UCP, zu denen weitere Komplexität hinzugefügt werden muß, um das neue Protokoll zu realisieren; und
3. Definieren und Implementieren des neuen Graphen entweder durch Hinzufügen eines Untergraphen oder durch Verfeinerung vorhandener Bögen oder Knoten eines vorab definierten Graphen.
4. Wenn neue Knoten oder Bögen definiert werden müssen, stellt der Editor 330 dem Benutzer Template für diese zur Verfügung.
Daher wählt und/oder entwickelt der Benutzer über den Koordinationseditor 330 für jeden der im Schritt 1 identifizierten Agents Null oder mehr Verhandlungs-/Koordinationsstrategien, die der Agent aufrufen kann.

4.5 Schritt 5: Die Task-Definition 520

Für jeden der im Schritt 2 definierten Tasks müssen über den Task-Beschreibungseditor 335 für jeden Agent die folgenden Benutzereingaben erfolgen:
1. Bestimmung der durchschnittlichen Kosten und der durchschnittlichen Dauer für die Ausführung des Task;
2. umfassende Auflistung sämtlicher Elemente (Ressourcen), die erforderlich sind, bevor der Task ausgeführt werden kann, als Variablen 550;
3. umfassende Auflistung sämtlicher Elemente (Produkte), die erzeugt werden, wenn der Task einmal ausgeführt wird, als Variablen 550;
4. Bestimmung und Protokollierung sämtlicher Einschränkungen zwischen den konsumierten Elemente (Punkt 2) und den erzeugten Elementen (Punkt 3) und innerhalb jeder Gruppe;
5. Feststellung, ob der Task durch direktes Ausführen einer Domänenfunktion ausgeführt werden kann (primitive Tasks) oder ob es sich tatsächlich um eine abstrakte Spezifikation eines Netzwerks weiterer Tasks (d. h. einen summarischen Task) handelt.
6. Wenn der Task primitiv ist, sind die beiden folgenden Funktionen bereitzustellen: (a) eine zur Ausführung des Task (eine Rückmeldung 555) und (b) eine zur Berechnung der tatsächlichen Kosten des Task, wenn dieser einmal ausgeführt wurde. Für summarische Tasks ist eine Beschreibung der summanschen Tasks in Begriffen ihrer Teil-Tasks zu erstellen.
Tasks verbrauchen bestimmte Ressourcen, um ihre Produkte zu erzeugen, wobei die Ausführung jedes Task eine endliche Zeitspanne in Anspruch nimmt. Die CABS-Plattform bietet einen Variableneditor 355, der eine Objekt-Attribut-Wert-Darstellung auf Rahmenbasis zur Definition der verbrauchten und erzeugten Elemente verwendet.
Die Einschränkungen zwischen und innerhalb der verbrauchten und erzeugten Elemente dienen der Beschränkung jedes Task auf besondere, genau definierte Fälle. Ein Task kann beispielsweise eine bestimmte Ressource anfordern, für die Ressource kann jedoch in bezug auf diesen besonderen Task eine Einschränkung beispielsweise hinsichtlich der Verarbeitungskapazität oder des Anlagentyps vorliegen. Es ist auch ein Beschränkungseditor 370 zur Beschreibung der Einschränkungen zwischen den Variablen vorgesehen, um sicherzustellen, daß die Tasks realistische Variablen verwenden und daß jeder Task-Ausgang dem Eingang der nächsten Stufe entspricht. Dies kann auf nicht übereinstimmende Einstellungen ausgeweitet werden, beispielsweise durch Festlegen, was ein Ausgang nicht sein darf, beispielsweise eine/keine ganze Zahl.
Zudem ist zur Auflistung der Teil-Tasks von summarischen Tasks ein Editor 365 für summarische Tasks (ein Planeditor) vorgesehen. Dieser Editor läßt zu, daß summarische Tasks (i) einfache Aktionen, (ii) wahlweise parallele Mehrfachaktionen, (iii) (zwingend) parallele Mehrfachaktionen, (iv) überwachte Aktionen (Wahlmöglichkeiten) und (v) sich wiederholende Aktionen umfassen. Überdies können diese Aktionen als Netzwerk verbunden sein, wobei eine Einrichtung zur Beschränkung der Variablen an den Endpunkten jeder Verbindung vorgesehen ist.
Nachstehendes ist ein Beispiel einer unter Verwendung des Task-Beschreibungseditors 335 erstellten Task-Beschreibung. Der Task beschreibt die Tatsache, daß zur Herstellung einer Verbindung von A (?Link-141.from) nach B (?Link-141.to) eine Verbindung 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) erforderlich sind.
Die Liste consumed_facts der von dem Task verbrauchten Facts listet die zur Ausführung des Tasks erforderlichen Ressourcen auf, d. h. die Verbindungen von A nach X und von X nach B. Die Liste produced_facts listet die Ressource auf, die erzeugt wird, wenn der Task ausgeführt wird, d. h. die Verbindung von A nach B. Die Einschränkungen spezifizieren Beziehungen zwischen konsumierten und erzeugten Fakten. Die Einschränkung "?Link-141.from = ?Link-131.from" spezifiziert beispielsweise die Bedingung, daß die Quelle der erzeugten Verbindung mit der Quelle der erforderlichen Verbindungen übereinstimmen sollte. Diese und ähnliche Einschränkungen werden von dem Planer 220 des Agent während der Laufzeit durchgesetzt, wodurch sichergestellt wird, daß die Variable ?Link-141.from an den gleichen Token wie ?Link-131.from gebunden ist.
Die Ordnung gibt die Reihenfolge an, in der die Vorraussetzungen überprüft werden sollen. In diesem Fall gibt sie an, daß der Planer versuchen sollte, eine Ressource zu erhalten, die der Ressourcenbeschreibung ?Link-131 entspricht, bevor er versucht, eine Ressource zu erhalten, die der Beschreibung ?Link-136 entspricht.
Eine Ressourcenbeschreibung consumed_fact, deren Bereich auf lokal eingestellt ist, ist eine Flagge, die den Planer 220 anweist, nur lokal zu versuchen, die erforderliche Ressource zu erhalten, d. h. keine Außenvergabe der Ressource an einen weiteren Agent vorzunehmen. Konsumierte Fakten mit globalen Bereichsfeldern können zur Produktion nach außen an andere Agents vergeben werden. Wenn das Bereichsfeld für ein erzeugtes Faktum auf lokal eingestellt ist, ist dies das Signal für den Planer, diesen Task bei dem Versuch dieses besondere zu erhalten, nicht zu verwenden. Ein lokales Bereichsfeld gibt an, daß der Task beim Versuch, die Ressource zu erzeugen, verwendet werden kann.
Folgendes ist ein Beispiel einer Task-Beschreibung:
Ein interessanter Aspekt einer derartigen Task-Definition ist, daß durch sie ein Optimum erzwungen werden kann. Durch Einführen von Fristeinschränkungen zusammen mit den Ressourcendefinitionen werden beispielsweise unzureichende Ressourcen offensichtlich. Es kann tatsächlich erforderlich sein, daß der Systembenutzer die verfügbaren Ressourcen damit erweitert oder sie zu ihnen hinzufügt.
Wenn das Agent-System beispielsweise mit der Verarbeitung von Anrufaufzeichnungsdaten in einem Telekommunikationssystem befaßt ist, könnten die beteiligten technischen Prozesse wie folgt Tasks zugeordnet werden:
i) im Anrufaufzeichnungszentrum empfangene Informationen;
ii) nach Prioritäten sortierte Informationen;
iii) an die geeigneten Ressourcen / Leute weitergeleitete Informationen; und
iv) Ausnahmenhandhabung, beispielsweise "Ressource nicht verfügbar".
Wenn der Ausnahmenverarbeitungsschritt "Ressource nicht verfügbar" ausgibt, kann es extrem wichtig sein, weitere Ressourcen verfügbar zu machen. Dies könnte der Fall sein, wenn das Anrufaufzeichnungszentrum eine Fehlerlokalisierung unterstützt. Die Fristen für die Rückführung von Netzwerkkapazitäten in den Betrieb können beispielsweise für bestimmte Kategorien von Kunden nicht erweiterbar sein. Es wäre daher für den Dienstanbieter sehr wichtig, daß das Anrufaufzeichnungszentrum die Ressourcen zur Verarbeitung der Anrufprotokolle innerhalb der zeitlichen Beschränkung aufweist.

4.6 Schritt 6: Erzeugung domänenspezifischer Problemlösungscodes 525

Zur Ausgabe eines funktionalen kollaborativen Agent muß das CABS einen tatsächlichen Code erzeugen. Die für einen CABS-Agent erforderlichen Daten umfassen zwei Typen: deklaratorische und die Prozeduren betreffende. Vorab definierte Objekte stellen die die Prozeduren betreffende Seite. Sämtliche deklarativen Informationen werden über Editoren und Task-Beschreibungen aufgenommen. Zum Zeitpunkt der Kompilierung eines Agent kann der Code-Generator für Aspekte, die sämtlichen Agents gemeinsam sind, wie die Mailbox, einfach einen Speicherauszug von Codes aufnehmen, der der Agent- Schablone 300 zugeordnet ist. Für agentspezifische Informationen wie Task- und Ressourcen-Informationen wird all dies als Datenbankdateien abgelegt und bei der Kompilation mit dem Mailbox-Code, etc. für jeden Agent verbunden.
Dies bedeutet, daß für sämtliche definierten Agents zusammen mit den Agent-Beziehungen, Koordinationsfähigkeiten und einer optischen Visualisierung sämtliche Codekomponenten und Datenbanken sowie die Ablage in Verzeichnissen erzeugt und kompiliert werden müssen. Effizienter Weise wird dabei ein Beispiel der Aufgaben jedes Agent erstellt, dann werden die Beziehungs- und Koordinationsinformationen und die Standardkomponenten hinzugefügt.
Der Benutzer muß jedoch einen domänenspezifischen Code bereitstellen, um die Funktionalität des Task zu implementieren. Dies bedeutet, daß der Benutzer einen Code für sämtliche Funktionen zur Berechung der Kosten für einen primitiven Task und zur Erzeugung von Rückmeldungen 555 zur Steuerung externer Systeme bereitstellen muß. Dies erfolgt unter Verwendung des Codeerzeugungseditors 360.
Dies ist die einzige Stelle, an der der Entwickler einen ausführbaren Code definieren muß. Das CABS kann Prototypen für diese Funktionen definieren und bietet auch eine API-Bibliothek 380 zur Verwendung durch Entwickler bei der Codeerzeugung.
Der Ausgang des CABS 100 in Form von Software-Agents wird über Scripts 390 auf die Benutzerumgebung verteilt. Existierende Systeme können dann unter Verwendung einer durch das System definierte API der Wrapper-Klasse eingebunden werden, die einen zusammen mit den vom Benutzer gelieferten Daten aus der Komponentenbibliothek übernommenen Code einbindet.

5. FEHLERBEHEBUNG UND VISUALISIERUNG

Es ist bereits schwierig, ein einzelnes Programm zu erstellen, selbst ein Programm, das nicht mit anderen Programmen interagiert, in dem keine Fehler oder Schwachstellen enthalten sind. Es ist um eine Größenordnung schwieriger, verteilte Software, die mehrere Agents enthält, zu analysieren und ihre Fehler zu beheben. Das Verhalten, das die verteilte Software insgesamt zeigt, kann völlig anders sein, als erwartet. Ferner findet die Kommunikation oft auf einer so hohen Ebene statt, daß es nicht möglich ist, die beteiligten Daten direkt einzusehen. Selbst ein System auf Objektbasis kann so konstruiert sein, daß es dem Programmierer Einsicht in die tatsächlich an einer Folge von Ereignissen beteiligten Daten gestattet, doch Agents, die eine Kommunikation auf Nachrichtenbasis verwenden, können dem Programmierer dies einfach nicht ermöglichen.
Natürlich ist es wesentlich, zu analysieren, wo der Fehler liegt, damit er korrigiert werden kann. Bei Anwendungen mit einem "Agent" verwendete Ansätze können verwendet werden, sind zur Analyse und Fehlerbehebung bei verteilten Software-Systemen jedoch häufig unzureichend. Eine Fehleranalyse kann beispielsweise als "Post-Mortem-Vorgang" erfolgen, bei dem die zum Zeitpunkt des Fehlers gespeicherten Daten später einen "Schnappschuß" der vorliegenden Umstände liefern, anhand derer der Versuch unternommen werden kann, die Fehlerursache festzustellen. Ein bekanntes, in der internationalen Patentanmeldung Nr. WO93 / 24882 auf den Namen des vorliegenden Anmelders beschriebenes Fehlersuchprogramm zeigt, wie derartige Daten in einer Protokolldatei erfaßt werden können, die später wie ein Video "abgespielt", "erneut abgespielt", "zurückgespult", "vorgespult", etc. werden kann.
Ein derartiger Ansatz kann bei verteilter Software unter einigen Bedingungen hilfreich sein, aber sicher nicht unter allen. Es existieren viele Klassen von Fehlern, die in Systemen mit mehreren Agents auftreten. Es können strukturelle Fehler auf der Ebene einzelner Agents in dem System mit mehreren Agents auftreten, wie fehlerhafte oder fehlende Kenntnisbeziehungen unter den Agents, fehlende Ressourcen, fehlerhaft spezifizierte (typischer Weise zu kurz bemessene) Zeiten für die Ausführung von Tasks, etc. Es können funktionale Fehler auftreten, d. h. Fehler, die die Logik der Tasks betreffen, die die Agents ausführen betreffen. Diese können auf der Tatsache beruhen, daß einzelne Agents funktional "korrekte sein können, das resultierende Verhalten des Gesamtaufbaus der verteilten Steuerungs- Agents jedoch nicht sein muß, wie erwartet. Dies ist typischer Weise auf sogenannte Koordinationsfehler zurückzuführen. In einigen Fällen kann ein derartiges Verhalten zu Systemen mit mehreren Agents führen, die inkohärent sind.
Einige Beispiele der Art von unerwünschten Verhalten, das bei derartigen Systemen auftritt, umfassen folgendes:
- Deadlock: Hierbei konkurrieren Agents um geteilte Ressourcen. Ein Agent kann auf eine entscheidende geteilte Ressource zugreifen und diese aus irgendeinem Grund nicht freigeben, vielleicht aufgrund eines Fehlers beispielsweise auf der Ebene des einzelnen Agent. Doch diese Ressource ist für andere Agents unersetzbar, die "festhängen", während sie auf die Freigabe dieser Ressource warten. Im Grunde bezeichnet ein Deadlock einen Zustand, in dem eine weitere Aktion zwischen zwei oder mehr Agents unmöglich ist.
- Livelock: Hierbei agieren die Agents kontinuierlich (d. h. sie interagieren oder tauschen Nachrichten aus), doch es wird kein Fortschritt bei der Lösung der aktuellen Aufgabe erzielt. Dies kommt häufig in Fällen vor, in denen die Agents ihre Aktivitäten über eine dezentralisierte Planung koordinieren. Hierbei können die Agents unendlich untergeordnete Pläne austauschen, ohne notwendigerweise die Koordinationsaufgabe weiterzubringen, insbesondere wenn keine Strukturüberprüfungen zur Erfassung und Verhinderung von Endlosschleifen im Planungsprozeß vorhanden sind.
- Chaos: Chaotisches Verhalten ist in einer verteilten Umgebung immer möglich.
Derartiges Verhalten führt neben gewöhnlichem "fehlerhaften" Verhalten oder Fehlern auf der Seite einzelner Agents häufig zu einem unkoordinierten Verhalten. Natürlich sollte ein verteiltes Steuersystem normalerweise koordiniert sein. Ein korrekt koordinierter Aufbau nutzt die Kapazitäten einzelner Agents vollständig aus und minimiert Konflikte, die Konkurrenz um Ressourcen und die Redundanz zwischen ihnen. Daher ist Koordination natürlich eine wünschenswerte Eigenschaft von Agent-Systemen.
Ebenso wie die Fehlerbehebung ermöglicht auch die Visualisierung dem Benutzer die Bestätigung, das Verständnis, die Steuerung und/oder die Analyse des Verhaltens des Systems.
Visualisierungseinrichtungen des nachstehend beschriebenen Typs können ein Mittel zur Analyse und Fehlerbehebung bei einer derartigen verteilten Steuerungssoftware bieten, so daß das erhaltene Verhalten dem von den Konstrukteuren beabsichtigten entspricht. Die Visualisierungseinrichtung bietet ein gattungsmäßiges, anpaßbares und kalibrierbares Visualisierungssystem zur Verwendung mit einem domänenunabhängigen Dienstprogrammpaket zur Konstruktion von Anwendungen mit mehreren Agents. Die besonders beschriebene Visualisierungseinrichtung ist gattungsmäßig in dem Sinne, daß sie mit jeder unter Verwendung des Dienstprogrammpakets entwickelten Anwendung verwendet werden kann, und anpaßbar in dem Sinne, daß sie Baugruppen zur Konstruktion anwendungsspezifischer Visualisierungseinrichtungen liefert. Die Anforderung der Kalibrierbarkeit impliziert, daß sie bei einer begrenzten Verschlechterung der Leistung die Visualisierung von Systemen mit einer beliebigen Anzahl an Agents unterstützen sollte. Die verteilte Natur der Anwendungen mit mehreren Agents macht es zwingend erforderlich, daß die Visualisierungseinrichtung zur Visualisierung entfernter Agents über ein Fernnetz geeignet ist. Ferner ist es für Verwaltungs- und Fehlerbehebungszwecke wesentlich, daß die Visualisierungseinrichtung sowohl online wie offline arbeitet.
Gemäß Ausführungsformen einer erfindungsgemäßen Visualisierungseinrichtung wird ein Aufbau zur Analyse und Lokalisierung nicht beabsichtigten Verhaltens in verteilten Steuerungssystemen geschaffen, der eine Reihe von Dienstprogrammen umfaßt, die alle unterschiedliche Gesichtspunkte der Analyse des verteilten Steuerungssoftwaresystems bereitstellen.
In all den unterschiedlichen Dienstprogrammen sind unterschiedliche Zustandsdaten gespeichert. Obwohl kein Dienstprogramm eine komplette Analyse des verteilten Systems bieten kann, kann die Kombination eines Dienstprogramms mit einem anderen dies. Unterschiedliche Dienstprogramme stellen Diagnosen bereit oder schlagen diese vor. Wenn die Nachweise eines Dienstprogramms die eines anderen Dienstprogramms bekräftigen, wird die Vertrauenswürdigkeit der Diagnose gesteigert. Es ist daher wahrscheinlicher, daß die Diagnose bei dem Problem zu einer erfolgreichen Fehlerbehebung führt. Wenn die Anzeichen einander widersprechen, kann die Kombination eines Dienstprogramms mit einem anderen eine Hypothese ausschließen oder andere mögliche Diagnosen nahelegen. Die Dienstprogramme des aktuellen CABS-Visualisierungs- /Fehlerbehebungs-Dienstprogrammpakets umfassen:
- Ein Gemeinschafts-Dienstprogramm: Es zeigt die Interaktionen zwischen unterschiedlichen Agents in der gesamten Gemeinschaft (die unter den unterschiedlichen Agents in der gesamten Gemeinschaft ausgetauschten Nachrichten). Es umfaßt ein Dienstprogramm des Video-Typs, das die unter unterschiedlichen Agents ausgetauschten Nachrichten für eine spätere "Post-Mortem-Analyse" aufzeichnen kann. Diese Nachrichten werden in einer Datenbank gespeichert, von der für tiefergehende Untersuchungen relationale Abfragen erfolgen können. Dieses Dienstprogramm kann entweder zur Analyse eines einzelnen Agent oder einer Gemeinschaft von Agents verwendet werden.
- Ein Statistik-Dienstprogramm: Es nimmt die verschiedenen Statistiken über einzelne Agents (beispielsweise die Typen und die Anzahl der unter den Agents ausgetauschten Nachrichten) auf. Es beantwortet Fragen, wie beispielsweise, "Wie viele Nachrichten wurden in einem bestimmten Zeitrahmen von Agent A an Agent B gesendet?" oder "Zeige die Anzahl der Nachrichten auf, die Agent A im Laufe der Zeit erhalten hat", etc. Das Statistik-Dienstprogramm bietet zusätzlich zu unterschiedlichen Graphen eine Visualisierung der Aktivitäten einzelner Agents in Form von Torten- und Balkendiagrammen. Stehen sowohl das Video- als auch das Statistik-Dienstprogramm zu Verfügung, können die Agents von Interesse ausgewählt und ihre aufgezeichneten Agent-Zustände näher untersucht werden. Dieses Dienstprogramm kann entweder zur Analyse eines einzelnen Agent oder einer Gemeinschaft von Agents verwendet werden.
- Ein Mikro-Dienstprogramm: Es zeigt Interna eines Agent mit einem gewissen Grad an Abstraktion. Tatsächlich kann sich der Konstrukteur häufig nur durch Beobachten des Mikro- Dienstprogramms vergewissern, ob der Agent "tot" ist, sich im "Deadlock" befindet oder "aktiv" ist; alternativ kann er bzw. sie sich versichern, ob Teile der Interna des Agent aus irgendeinem Grund nicht funktionieren.
- Ein Protokoll-Dienstprogramm: Es liefert eine Präsentation des gesamten Task, den ein Agent beispielsweise steuern kann, in Form einer GANTT-Übersicht. Typischer Weise nimmt ein Agent die Hilfe und die Dienste vieler anderer Agents in Anspruch, und dieses Dienstprogramm ermöglicht dem Konstrukteur die Auswahl eines bestimmten Agent und eines Task (unter mehreren möglichen Tasks), die der Agent steuert. Dadurch wird in Form einer GANTT-Übersicht angezeigt, wie der Task aufgeteilt (d. h. welche Unter-Tasks beteiligt sind), welche Tasks wem zugeordnet wurden, wie weit die Ausführung des Task fortgeschritten ist und wie die Zustände der unterschiedlichen Unter- Tasks aussehen (d. h. in Ausführung, gescheitert, ausgesetzt oder in der Warteschlange).
- Ein Steuermonitor-Dienstprogramm: wies ist ein sehr wichtiges Verwaltungsdienstprogramm, das zur Unterbrechung sämtlicher Agents, der Suspendierung einiger Agents, der Suspendierung oder zum Herbeiführen einer Fehlfunktion der von ihnen ausgeführten Tasks verwendet wird, damit das resultierende Ausnahmeverhalten untersucht werden kann, etc. Es ist ebenfalls ein wichtiges Prüf- und Fehlerbehebungs-Dienstprogramm in dem Sinne, daß bestimmte Agents suspendiert oder aus der Gemeinschaft herausgenommen werden können, etc., so daß bestimmte Agents näher untersucht werden können.
Die Visualisierungseinrichtung 140 umfaßt einen Software- Agent mit dem gleichen allgemeinen Rahmen wie jeder andere der kollaborativen Agents in einem CABS. Sie ist in der Lage, anderen Agents in dem System Daten zu entnehmen. Sie ist passiv in dem Sinne, daß sie nicht mit anderen Agents verhandelt, doch sie meldet sich bei dem Namensserver 135 anund visualisiert sich auch.
Gemäß Fig. 10 umfaßt die Gesamtarchitektur des Fehlerbehebungs-/Visualisierungs-Softwaremoduls 140 eine zentrale Einrichtung; die aus einer Mailbox 1000, einer Nachrichtenverarbeitungseinrichtung 1005, eine Nachrichtenkontextdatenbank 1010 und einem Dienstprogramm-Starter 1015 aufgebaut ist. Der Einrichtung steht ein Paket von Dienstprogramm-Schablonen 1020 zur Verfügung.
Die Mailbox 1000 stellt Einrichtungen für den Nachrichtenaustausch zwischen der Fehlerbehebungs-/Visualisierungseinrichtung 140 und anderen Agents unter Verwendung der gemeinsamen Agent- Kommunikationssprache bereit, die in diesem Fall die KQML ist. Der Dienstprogrammstarter 1015 startet (auf Anforderung des Benutzers) Abläufe der unterschiedlichen Dienstprogramme in dem Dienstprogrammpaket, d. h. Durchläufe des Gemeinschafts-, des Statistik-, des Mikro-, des Protokoll- und des Steuerungsdienstprogramms. Es gibt eine große Anzahl an Dimensionen, entlang derer ein System mit mehreren Agents visualisiert werden kann. Die Entwicklung eines einzigen, komplexen Dienstprogramms, das sämtliche unterschiedlichen Visualisierungsmodi unterstützt, könnte die Verwendung der Visualisierungseinrichtung erschweren und sie unflexibel und schwer zu warten machen; daher die Verwendung eines Pakets von Dienstprogrammen, des Dienstprogrammsatzes, bei dem die Dienstprogramme ein gemeinsames Aussehen und Bediengefühl aufweisen und für eine einzige Visualisierungsaufgabe bestimmt sind. Sämtliche Dienstprogramme werden von einer zentralen Einrichtung gestartet und teilen eine gemeinsame Schnittstelle mit der Einrichtung. Auf diese Weise ist die Visualisierungseinrichtung leichter zu warten und einfach zu erweitern. Das ausgewählte Dienstprogrammpaket umfaßt die Dienstprogramme, die bei der Visualisierung, Steuerung und Fehlerbehebung bei Systemen mit mehreren Agents für am nützlichsten befunden wurden.
Primär sendet die Visualisierungseinrichtung 140 Nachrichten zur Anforderung von durch diese gehaltenen Daten an andere Agents. Sie fragt den Namens-Server 135 auf Agent-Adressen ab und verwendet diese Adressen dann. Die Nachrichtenverarbeitungseinrichtung 205 des empfangenden Agent leitet die empfangene Anforderungsnachricht abhängig davon, wo die relevanten Daten angeordnet sind, geeignet weiter. Von der Visualisierungseinrichtung 140 empfangene Daten von sämtlichen anderen Agents werden gespeichert, abgerufen und für eine geeignete Anzeige verarbeitet.
Die Visualisierungseinrichtung 140 kann auch Daten in einem Agent installieren. Sie kann daher zur Modifikation des Verhaltens eines Agent verwendet werden. Dies wird nachstehend weiter beschrieben.
Die Nachrichtenverarbeitungseinrichtung 1005 der Visualisierungseinrichtung 140 verarbeitet von der Mailbox 1000 empfangene Nachrichten und leitet sie an Dienstprogrammabläufe weiter, die ein Interesse an Nachrichten dieses Typs angemeldet haben. Dienstprogrammabläufe melden ein Interesse am Empfang von Nachrichten eines bestimmten Typs unter Verwendung der Nachrichtenkontextdatenbank 1010 an, die während der Verarbeitung von der Nachrichtenverarbeitungseinrichtung 1005 konsultiert wird. Daher sendet jeder am Empfang von Protokollnachrichten eines bestimmten Typs von einem Satz Agents interessierter Dienstprogrammablauf zuerst unter Verwendung der Mailbox 1000 (und unter Verwendung einer Steueranweisung des "Wenn-Dann-Typs") eine Anforderung an diese Agents, daß sie Protokollnachrichten an die Fehlerbehebungs- /Visualisierungseinrichtung 140 senden sollen, wann immer Ereignisse dieses Typs auftreten, und meldet zweitens ein Interesse am Empfang von Kopien sämtlicher hereinkommenden Protokollnachrichten des gewünschten Typs bei der Nachrichtenkontextdatenbank 1010 an. Diese Anordnung ermöglicht einem Benutzer der Fehlerbehebungs-/Visualisierungseinrichtung, während der Laufzeit des Satzes von Ereignessen, an deren Überwachung er/sie interessiert ist, dynamisch zu bestimmen und diesen Satz auch jederzeit zu verändern.
Genauer werden die KQML-Dateien reply_with (herausgehende Nachricht) und in_reply_to (hereinkommende Nachricht) verwendet, um jeder Nachricht eine Identifikation zuzuordnen, die für Dienstprogrammablauf und Ereignistypen eindeutig ist. Auf diese Weise muß die Nachrichtenverarbeitungseinrichtung nicht die Inhalte einer Nachricht abtasten, um zu bestimmen, welcher Dienstprogrammablauf sie benötigt. Diese Anordnung ermöglicht Benutzern der Visualisierungseinrichtung, den Satz von Ereignissen, an deren Überwachung sie interessiert sind, während der Laufzeit zu bestimmen und den Satz auch jederzeit zu verändern. Überdies erfordert eine Erweiterung des Dienstprogrammpakets durch ein neues Dienstprogramm und/oder die Überwachung eines neuen Ereignistyps keine Modifikation der zugrundeliegenden Unterstützungsinfrastruktur.
Die Visualisierungseinrichtung 140 ist kein vollständiges Depot von Daten für ein Agent-System. In ihr sind nur Daten für einen begrenzten Zeitrahmen, beispielsweise für zwei Tage, gespeichert. Wenn der Benutzer Daten dauerhaft speichern will, müssen diese beispielsweise in dem im Gemeinschafts-Dienstprogramm enthaltenen Video-Dienstprogramm gespeichert werden: Der Zeitrahmen, für den die Visualisierungseinrichtung 140 Daten hält, wird von der Größe, Aktivität und Komplexität des CABS-Agent-Systems beeinflußt, und wenn beispielsweise zu viele Agents vorhanden sind, kann eine Erweiterung der Visualisierungseinrichtung 140 erforderlich sein.
Die Visualisierungseinrichtung 140 stellt nur einen Protokollmechanismus bereit; sie ist langsamer als die Echtzeitaktivität des Systems. Die Visualisierungseinrichtung 140 kann Nachrichten in der falschen Reihenfolge empfangen. Zur Vermeidung einer Fehlinterpretation ist die Visualisierungseinrichtung 140 mit einem begrenzen Puffer 1025 ausgestattet, der die Nachrichten in ihrer korrekten zeitlichen Abfolge reorganisiert. (Es wird darauf hingewiesen, daß die Nachrichten dementsprechend notwendiger Weise einen Zeitstempel aufweisen.)
Gemäß Fig. 12 ist die Domäne bei einem einfachen implementierten Szenario eine Einrichtung zur Bereitstellung einer Zufuhrkette, bei der Agents zur Herstellung und/oder tsereitsteiiung von tautern zusammenarbeiten, die einen Dienst bilden. Fig. 12 zeigt eine Ansicht der Domäne, die durch das Gemeinschaftsdienstprogramm erzeugt werden könnte. Gemäß dem Beispiel sind fünf Haupt-Agents vorgesehen. C, ein Computerhersteller, hat zwei Untergebene, M und U.M stellt Bildschirme her, und C ist ihm als Vorgesetzter und U als Gleichgestellter bekannt. U stellt Zentraleinheiten (CPUs) her, und ihm sind ähnlich C als Vorgesetzter und M als Gleichgestellter bekannt. Sowohl M als auch U teilen zwei Untergebene (X und Y). C ist ein weiterer Agent P als Partner bekannt, der Tinten- und Tonerkartuschen für Drucker herstellt. P hat einen Untergebenen T, der Tinten- und Tonerkartuschen für Drucker herstellt.
Gleichgestellte sind Agents der gleichen Organisation, die keine Autoritätsbeziehung untereinander haben, während Partner Agents sind, die zu unterschiedlichen Organisationen gehören.
Gemäß dem Beispiel erfordert die Herstellung eines Computers die Grundeinheit (CPU und Bildschirm) sowie einen geeigneten Drucker.
In der Umgebung existieren drei zusätzlichen Unterstützungs- Agents: ein Agent-Namensserver (ANS), der ein "Telefonbuch" zur Abfrage von Agent-Adressen bereitstellt, ein Broker-Agent (PC_Broker), der "gelbe Seiten" bereitstellt, über die Agents andere Agents finden, die zur Ausführung eines Task geeignet sind, und ein Datenbank- Vertretungs-Agent (DB), dessen einzige Funktion das Speichern und Wiederbeschaffen von Nachrichten von geschützten Datenbanken auf Anforderung von Visualisierungseinrichtungen ist. Diese Agents kommunizieren ebenfalls in der gemeinsamen Agent- Kommunikationssprache (ACL). Schließlich gibt es den Visualisierungs-Agent (Visual) selbst.
Die Verwendung eines der Dienstprogramme in dem Paket erfordert, daß die Benutzer eine Verbindung zu einem oder mehreren Namens-Servern herstellen, wenn das Dienstprogramm einmal gestartet ist. In der Umgebung eines Systems mit mehreren Agents enthalten Namens-Server die Namen und Adressen sämtlicher "aktiven" Agents in der Umgebung. Daher beinhaltet die Herstellung eines Kontakts mit einem Namens-Server das Senden einer Anforderung an den Namens-Server, sämtliche Agents in der Umgebung und sämtliche Agents aufzulisten, die später Online gehen. In einer Umgebung mit vielen Namens-Servern kann der Benutzer auswählen, mit welchem er eine Verbindung herstellen will, wodurch der Visualisierungsvorgang auf effizient auf eine relevante Untergruppe von Agents gefiltert wird.

5.1 Das Gemeinschafts-Dienstprogramm

Das Gemeinschafts-Dienstprogramm der Visualisierungseinrichtung sendet drei Typen von Anforderungsnachrichten. Nachrichten des Gemeinschafts-Dienstprogramms
Gemäß Fig. 12 ermöglicht das Gemeinschafts- Dienstprogramm einem Benutzer die Auswahl eines Satzes von Agents und das Einsehen (a) der strukturellen, organisatorischen Beziehungen und (b) des Nachrichtenaustauschs zwischen ihnen. Es greift daher auf die in den einzelnen Agents gespeicherten Beziehungsmodelle 215 zu. Es kann auch einen Zeiger setzen, der veranlaßt, daß die Nachrichtenverarbeitungseinrichtungen 205 der Agents sämtliche Nachrichten für die Visualisierungseinrichtung 140 kopieren.
Um (a) oder (b) einzusehen, verwenden Benutzer Menüoptionen zum jeweiligen Senden von Anforderungen an designierte Untersätze des Agent, die eine Aktualisierung des Dienstprogrammablaufs mit ihrer aktuellen Kenntnis der organisatorischen Beziehungen oder das Senden von Kopien ihrer sämtlichen herausgehenden Nachrichten an den Dienstprogrammablauf anfordern.
Die organisatorischen Beziehungen beschreiben Rollenbeziehungen, wie übergeordnet, untergeordnet, Gleichgestellter oder Partner. Die Kenntnis dieser Beziehungen ist bei der Fehlerbehebung wichtig, da sie beeinflussen können, wie die Agents ihre Aktivitäten koordinieren. Die Agents können beispielsweise so konfiguriert sein, daß sie zunächst versuchen, sämtliche Tasks auszuführen, wenn sie an der Delegation an Untergebene und an der Beauftragung von Gleichgestellten scheitern, und nur wenn keiner an Partner vergeben werden kann. Das Dienstprogramm unterstützt das graphische Layout der Agents entsprechend der Rollenbeziehungen. Derzeitige Layouts umfassen ein vertikales Layout (wie in Fig. 12 gezeigt), bei dem die vertikale Überordnungs-Unterordnungs-Beziehung im Vordergrund steht, ein horizontal-kreisförmiges Layout, bei dem Gleichgestellte im Vordergrund stehen, wobei Gruppen von Gleichgestellten kreisförmig angeordnet sind, ein horizontal-kreisförmiges Layout, bei dem Partner im Vordergrund stehen, wobei Gruppen von Partnern kreisförmig angeordnet sind, und ein auf einen einzelnen Agent zentriertes Layout, bei dem sämtliche anderen Agents um einen benutzerdesignierten zentralen Agent zentriert sind. In den Layoutdiagrammen sind die Verbindungen zwischen den Agents entsprechend ihren Rollenbeziehungen farbcodiert. Die Funktionen sind so ausgelegt, daß sie die Knoten der verschiedenen Diagramme einfahren, erweitern, verbergen und zeigen. Die unterschiedlichen Layouts sind insbesondere dann wesentlich, wenn sie mit der Nachrichtenfunktion des Dienstprogramms verwendet werden, da sie dem Benutzer eine leichte Einsicht in die organisatorische Struktur der Agents und das Fortschreiten der Koordination innerhalb dieser Struktur gestatten. Dies ermöglicht ihm bzw. ihr die Identifikation von Fehlern entweder anhand der Art und Weise, in der die Agents organisiert sind, oder anhand der Art und Weise, in der die Koordination innerhalb der Organisation fortschreitet.
Es wird darauf hingewiesen, daß kein einzelner Agent notwendigerweise über ein vollständiges Bild der organisatorischen Struktur verfügt. Es liegt in der Verantwortlichkeit des Gemeinschaftsdienstprogramms, von den Agents zurückgesendete lokale Informationen in ein globales Bild der Organisation zu integrieren.
Nachrichten zwischen Agenten können (zur einfacheren Visualisierung) nach Typen, beispielsweise sämtliche Anforderungsnachrichten in einer Farbe, oder nach Inhalt farbcodiert sein, beispielsweise sämtliche Nachrichten, die einen bestimmten Job betreffen, in einer Farbe. Zudem unterstützt das Dienstprogramm das Filtern von Nachrichten vor der Anzeige. Nachrichten können nach Sender, Empfänger, Typ oder Inhalt gefiltert werden. Die Filteroption könnte beispielsweise angeben "nur die den Job... [Inhaltsfilter] betreffenden Gegenvorschlagsnachrichten... [Typenfilter] von der Gruppe von Agents... [Senderfilter] an die Gruppe von Agents... [Empfängerlilter] anzeigen". Diese Funktionen erleichtern die Fehlerbehebung, indem sie dem Benutzer gestatten, sich auf die bestimmten Nachrichten zu konzentrieren, die von Interesse sind. Ferner bieten sie, kombiniert mit den Offline-Wiedergabefunktionen mit Vorspul- und Rückspul- Videomodi (die als nächstes besprochen werden), ein potentes Dienstprogramm zur Fehlerbehebung.
Wie vorstehend erwähnt, bietet das Gemeinschaftsdienstprogramm auch Funktionen zur Speicherung der von den Agents gesendeten und empfangenen Nachrichten in einer Datenbank zur späteren Wiedergabe. Wieder können während der Speicherung und/oder Wiedergabe Nachrichtenfilter verwendet werden, um bestimmte Nachrichten auszuwählen, die von Interesse sind. Wiedergabefunktionen unterstützen die Videometapher, wobei sie einem Benutzer die schrittweise oder animierte erneute Ansicht der Nachrichten im Vor- oder Rückspulmodus gestatten. Da die Nachrichten in einer relationalen Datenbank gespeichert sind, können die Benutzer ferner Abfragen des normalen (d. h. relationalen) Datenbanktyps an den gespeicherten Nachrichten ausführen, beispielsweise "wie viele den Job 21 betreffende Nachrichten hat Agent A versendet?". Die Videowiedergabefunktionen mit Nachrichtenfiltern und die Unterstützung der Datenbankabfrage verbessern die Fehlerbehebungsbestrebungen eines Benutzers signifikant, indem sie ihm bzw. ihr bei dem Versuch, die Interaktionen unter den Agents zu entschlüsseln, eine Einschränkung und Erweiterung des Blickwinkels sowie einen Wechsel der Perspektive ermöglichen.
Bei der in Fig. 12 gezeigten grafischen Benutzerschnittstelle ist es möglich, die Konstruktion von Agents 1200 in dem vorstehend beschriebenen Zufuhrkettenbereitstellungszenario einzusehen. Zur Linken des Fensters befinden sich Konstruktions- und Ansichtensteuerungen 1210. Die Mehrfunktionsknöpfe 1220 auf der rechten Seite steuern die videoartige Wiedergabe von Nachrichten, wogegen diejenigen 1230 auf der linken Seite sowie ein Pop-Up-Menü 1240 die Position und Sichtbarkeit der Agent-Icons steuern.
Die tatsächliche Steuerung der Nachrichten in einer Datenbank erfolgt durch Öffnen einer Verbindung durch einen Datenbankverbindungs-Agent und dem Senden von Kopien der zu speichernden Nachrichten an diesen. Die Wiederherstellung erfolgt auf ähnliche Weise, wenn auch umgekehrt. Dieses Arrangement bietet einen flexiblen Ansatz, da jedes Datenbanksystem in Eigenbesitz einfach durch Herstellen einer Schnittstelle mit einer Standardverbindung zu ihm verwendet werden kann, die die Kommunikationssprache der Agents versteht und in ihr kommunizieren kann.

5.2 Das Protokoll-Dienstprogramm

In einer kollaborativen Umgebung mit mehreren Agents ist im allgemeinen das Verhalten der Gemeinschaft als ganzes (d. h. die kombinierten Eingänge sämtlicher Agents) wesentlich, und nicht das eines einzelnen Agent. Ein typisches Problem bei der Fehlerbehebung bei Systemen mit mehreren Agents ist auf die Tatsache zurückzuführen, daß jeder Agent nur einen lokalen Einblick in die Problemlösungsaktivitäten der Gemeinschaft bietet.
Jedem Agent sind nur Jobs und untergeordnete Jobs bekannt, die ihm/von ihm zugewiesen wurden. Kein einzelner Agent hält Daten bezüglich des Gesamtzusammenhangs und des Status sämtlicher Jobs.
Zur Bereitstellung eines Computers kann der Agent C beispielsweise einen Teil seines Task an P übertragen, um einen Laserdrucker bereitzustellen. P wiederum kann zur Bereitstellung einer Tonerkartusche einen Teil der übernommenen Aufgaben an T delegieren. Aufgrund der Autonomie der einzelnen Agents sind C nur der Teil des Task, den er ausführen soll, und der Teil bekannt, den er an P weitergegeben hat; der Teil, den P an T delegiert hat, bleibt im unbekannt. Daher erhält ein Benutzer, der einen der Agents isoliert betrachtet, ein unvollständiges Bild der Problemlösungsaktivitäten der Gemeinschaft. Daher ist der Benutzer, wenn beispielsweise C einen Fehlschlag der Ausführung des Task meldet, nicht in der Lage, beispielsweise unverzüglich zu bestimmen, daß die dem Fehlschlag zugrundeliegende Ursache war, daß T nicht, wie von P angefordert, eine Tonerkartusche bereitstellen konnte.
Das Protokoll-Dienstprogramm ist so beschaffen, daß es die relevanten Daten von jedem der Agents abfragen, kollationieren und abbilden kann. Das Protokoll-Dienstprogramm wendet den nachstehend ausgeführten Algorithmus an, um die Daten zu kollationieren und ein vollständiges Bild zu erzeugen, das dann in Form einer GANTT-Übersicht des in Fig. 7 gezeigten Typs repräsentiert werden kann.
Gemäß Fig. 8 wird für dieses Dienstprogramm darauf hingewiesen, daß ein einem Agent A zugewiesener Job J in untergeordnete J1 und J2 aufgeteilt werden kann, die jeweils Agents B und C zugewiesen werden. Der untergeordnete Job J2 kann weiter in J21, J22, J23 aufgeteilt und weiteren Agents E, F und G zugewiesen werden. Der untergeordnete Job J1 kann ebenso aufgeteilt werden, wobei der Agent B die Verantwortung für einen untergeordneten Job J11 behält, einen untergeordneten Job J12 jedoch einem Agent D zuweist.
Wesentlich dabei ist, sicherzustellen, daß jeder Job der obersten Ebene, wie der Job J, eine eindeutige Identifikation hat, die selbst dann beibehalten wird, wenn untergeordnete Jobs (und untergeordnete Unterjobs, etc.) des Jobs der obersten Ebene erzeugt werden. Dies wird in jedem Agent mittels der Zuordnungstabelle gemäß Fig. 9 und als Ergebnis der Entscheidungen durch das Koordinationsmaschinen- und Entscheidungsfindungssystem 210 aufgezeichnet. Wenn also der Agent A einen Job mit der Identifikation "J" in untergeordnete Jobs J1 und J2 aufteilt und diese anderen Agents zuordnet, behalten diese anderen Agents die Identifikation "J" selbst dann bei, wenn sie selbst die untergeordneten Jobs (J1, J2, etc.) in weitere untergeordnete Jobs aufteilen und diese weiteren Agents zuordnen. Es wird darauf hingewiesen, daß dem untergeordnete Job "J1" zusätzlich zu "J" seine eigene Identifikation "1" beigefügt wird, um seinen Ursprung bei einer weiteren Aufteilung zurückverfolgen zu können, was zutrifft, wenn ein untergeordneter Job wie "J12" weiter in "J11" und, "J12" zerlegt wird. In diesem Fall werden beide Identifikationen, "J" und "1" beibehalten.
Daher kann das Protokoll-Dienstprogramm unter Verwendung einer Ursprungsaufgabenidentifikation und Überordnungs- Unterordnungs-Verbindungen eine globale Task-Aufteilung über die Gemeinschaft darstellen. Tatsächlich wird der gleiche Mechanismus vom Gemeinschafts-Dienstprogramm für die Farbcodierung von Nachrichten nach Aufgaben verwendet.
Daher ist der Algorithmus des Protokoll-Dieristprogramms für die Verarbeitung der (von sämtlichen Agents erhaltenen) Daten wie folgt:
i) Auswahl eines dem Agent zugeordneten Jobs/einer Aufgabe für einen Agent "A",
ii) Abruf der eindeutigen Identifikation, beispielsweise "J", für die Aufgabe,
iii) Ausführen einer Suche zur Ermittlung sämtlicher weiteren Jobs/Aufgaben mit dieser Identifikation und Zurückmelden sowohl der Jobs/Aufgaben als auch ihrer Beziehungen (zu der ausgewählten Aufgabe "J"),
iv) grafische Darstellung der Beziehungen (und Zustände), wie in Fig. 7 gezeigt.
Unter erneuter Bezugnahme auf Fig. 7 wird ein Szenario mit drei Agents A, B und E betrachtet. Um beispielsweise einen Job J1 auszuführen, könnte der Agent A einen untergeordneten Teil (J11) dieses Jobs an einen Agent B delegieren; der wiederum einen untergeordneten Teil (J111) von J11 an einen Agent E delegiert. Aufgrund der Autonomie der einzelnen Agents sind dem Agent A nur der untergeordnete Teil J1, den er ausführen soll, und der untergeordnete Teil (J11) bekannt, den er an den Agent B delegiert hat, der untergeordnete Teil (J111), der vom Agent B an den Agent E delegiert wurde, bleibt ihm unbekannt. Damit erhält ein Benutzer, der einen der Agents isoliert betrachtet, ein unvollständiges Bild der Problemlösungsaktivitäten durch die Gemeinschaft. Wenn der Agent A also beispielsweise einen Fehlschlag bei der Ausführung von J1 meldet, ist der Benutzer nicht in der Lage, durch eine Überprüfung des Agent A unverzüglich zu bestimmen, daß die Ursache des Scheiterns war, daß der Agent E J111 nicht ausführen konnte.
Das Protokoll-Dienstprogramm bietet eine globale Einsicht in die Problemlösung durch eine Gemeinschaft von Agents und ist sowohl als Fehlerbehebungs- als auch als Verwaltungs- Dienstprogramm nützlich. Es ermöglicht einem Benutzer die Auswahl einer Gruppe von Agents und die Anforderung einer Meldung des Status sämtlicher beteiligter Jobs durch diese. Als nächstes kann der Benutzer einen relevanten Agent und einen diesem Agent zugeordneten Job auswählen. (Einem Agent ist ein Job zugeordnet, wenn die Ausführung des Jobs oder eines untergeordneten Teils desselben durch ihn an einem Ursprungsknoten in einer Task-Zerlegungshierarchie für den Job geplant ist.) Zur Auswahl des Agent und des Jobs erzeugt das Protokoll-Dienstprogramm die Grafik 700 des GANTT-Übersichtstyps gemäß Fig. 7, die die Aufteilung 560 des Jobs, die Zuweisung der untergeordneten Teile, aus denen er zusammengesetzt ist, zu unterschiedlichen Agents in der Gemeinschaft und den relevanten Status der Jobs und der untergeordneten Teile zeigt. Weitere Attribute der Jobs könnten ebenfalls in der Übersicht gezeigt werden, beispielsweise, wann die Ausführung seines Teils durch jeden der Agents geplant ist, ihre Kosten, die ihnen von den Agents zugeordneten Prioritäten und die Ressourcen, die sie benötigen.
Gemäß Fig. 13 und unter erneuter Bezugnahme auf den vorstehend erwähnten Task "Bereitstellung eines Computers" kann die GANTT-Übersicht 700 mit Auswahlkästchen zur Auswahl des Agent und des Task, die eingesehen werden sollen, auf dem Bildschirm angezeigt werden. Wie dargestellt, wurden die Auswahlkästchen 1305, 1310 verwendet, um den Task "Bereitstellung eines Computers" für den Agent C 1300 auszuwählen. Die GANTT-Übersicht 700 zeigt die Aufteilung des Task "Bereitstellung eines Computers" in "Bereitstellung einer Tonerkartusche" (Agent T) 1315, "Bereitstellung eines Bildschirms" (Agent M) 1325, "Bereitstellung einer CPU" (Agent U) 1320 und Bereitstellung eines Druckers" (Agent P) 1316. Der Task- Statusschlüssel 1335 zeigt durch eine (in Fig. 13 nicht sichtbare) Farbcodierung, daß die Tasks 1315, 1325, "Bereitstellen einer Tonerkartusche" und "Bereitstellen eines Bildschirms laufen, der Task 1320 "Bereitstellung einer CPU" abgeschlossen ist und die Tasks 1316, 1300, "Bereitstellen eines Druckers" und "Bereitstellen eines Computers" in der Warteschlange stehen. Ein Dialogkästchen 1330 wurde aufgerufen, um die Einzelheiten des Task 1315 "Bereitstellen einer Tonerkartusche" zu zeigen.
Das Protokoll-Dienstprogramm muß daher beispielsweise auf die Task-Aufteilungen 560 und die Zuweisungsdatenbank 245 jedes Agent zugreifen.
Wie erwähnt, zeigt die vom Protokoll-Dienstprogramm erzeugte Job-Grafik auch den aktuellen Status jedes untergeordneten Teils des Jobs, d. h. entweder in der Warteschlange, läuft, abgeschlossen oder fehlgeschlagen. Daher ist es einem Benutzer anhand der Grafik unverzüglich möglich, den Gesamtstatus eines Jobs und bei einem Fehlschlag des Jobs zu den genauen Ort des Fehlschlags bestimmen - wodurch die Fehlerbehebungsaktivitäten offensichtlich unterstützt werden, Zur einfachen Visualisierung können die unterschiedlichen Zustände eines Jobs in der Grafik farbcodiert sein.
Fig. 7 zeigt ein Task-Protokoll 700 für den dem Agent A zugeordneten Job J1 als Ganzem. Der untergeordnete Teil J111 (Agent E) ist fehlgeschlagen, während J12 (Agent C) läuft und J13 (Agent D) abgeschlossen ist. J11 (Agent B) und J1 (Agent A) befinden sich in der Warteschlange, doch aufgrund der gescheiterten Ausführung von J111 werden sie beide scheitern, falls keine Aktion zur anderweitigen Ausführung von J111 eingeleitet wird.
Das Dienstprogramm bietet dem Benutzer auch Einrichtungen zum Einklappen/Ausklappen von Abschnitten der Grafik und zum Verbergen/Anzeigen von Knoten des Graphen - dies ist bei der Arbeit mit sehr großen Graphen wesentlich, da es dem Benutzer die Konzentration auf die Bereiche gestattet, die von Interesse sind, wobei übermäßig viele Einzelheiten verringert werden können, die die Fehlerbehebungsarbeiten behindern könnten.
Der Algorithmus zur Sicherstellung der korrekten Integration der Task-Beschreibungen in die Grafiken beruht auf zwei Tatsachen: zunächst weist der Agent, mit dem die Aufgabe initiiert wird, der Aufgabe eine systemweite, eindeutige Identifikation zu, die in der Task- Aufteilungshierarchie der Aufgabe nach unten weitergegeben wird. Zweitens erzeugt ein Agent, wann immer er einen Task in untergeordnete Tasks aufteilt, eindeutige Identifikationen für die untergeordneten Tasks und zeichnet die Identifikationen für den übergeordneten Task auf (dies geschieht unabhängig davon, ob die anderen Agents die untergeordneten Tasks ausführen oder nicht). Daher kann das Protokoll-Dienstprogramm unter Verwendung der Ursprungsidentifikation der Aufgabe und der Überordnungs-Unterordnungs- Verbindungen die globale Task-Aufteilung über die Gemeinschaft grafisch darstellen. (Tatsächlich wird der gleiche Mechanismus vom Gemeinschafts-Dienstprogramm für die Farbcodierung nach Aufgaben verwendet.) Der gleiche Mechanismus ermöglicht auch die Anzeige kombinierter Graphen, bei denen zwei Task-Aufteilungsgraphen durch einen oder mehrere Tasks verbunden werden. Dies geschieht, wenn Nebeneffekte eines Task in einem Aufgabenaufteilungsgraphen in einem anderen verwendet werden.
Ähnlich wie das Gemeinschafts-Dienstprogramm unterstützt auch das Protokoll-Dienstprogramm eine Online-Anmeldung von Protokollnachrichten an eine Datenbank und eine anschließende Offline- Wiedergabe.

5.3 Das Mikro-Dienstprogramm

Gemäß Fig. 14 ermöglicht das Mikro-Dienstprogramm einem Benutzer die Auswahl eines einzelnen Agent, gemäß der Darstellung des Agent C, und die Einsicht in seine Verarbeitung durch die Überprüfung seiner aktuellen Daten und der durch die unterschiedlichen Teile des Agent gesendeten und empfangenen Daten. Es können beispielsweise die letzten zehn Nachrichten für einen gewählten Teil eingesehen werden. Durch die Überprüfung von Eintragungen in der Mailbox können für den Versand in Vorbereitung befindliche Nachrichten oder kürzlich empfangene Nachrichten eingesehen werden. Die Einsicht in folgendes kann angefordert werden:
1. "Nachricht in der Warteschlange" 1400: kürzlich empfangene Nachrichten, die noch bearbeitet werden müssen;
2. "Nachrichten, die die Warteschlange verlassen haben" 1405: Nachrichten, die versendet werden sollen;
3. "Zusammenfassung der Einrichtung zur Verarbeitung der Nachrichten" 1410: eine Zusammenfassung der als Reaktion auf hereinkommende Nachrichten eingeleiteten Aktionen, beispielsweise, an welches Modul des Agent die Nachricht zur detaillierten Verarbeitung gesendet wurde;
4. "Koordinationsgraph" 1415: visuelle Anzeige des dynamischen Status der Ausführung der Koordinationsmaschine zur Visualisierung des Verlaufs der Realisierung einer Aufgabe. Wenn mehrere Aufgaben vorhanden sind, die der Agent auszuführen versucht, kann der Benutzer eine bestimmte auswählen, um ihre Fortschritte zu visualisieren. Wenn jeder Knoten 1420 des Graphen aktiv ist, wird er GRÜN angezeigt. Wenn der Knoten scheitert, wird er ROT angezeigt.
5. "Zusammenfassung des Ausführungsmonitors" 1425: ein Protokoll, in dem Einzelheiten der Tasks, deren Ausführung der Agent übernommen hat, sowie der aktuelle Status dieser Tasks (d. h. in der Warteschlange, läuft, abgeschlossen oder gescheitert) aufgelistet sind; der Monitor kann beispielsweise einen Task anzeigen, der aufgrund unzureichender Ressourcen nicht gestartet werden konnte (die von einem anderen Agent erwarteten Ergebnisse könnten beispielsweise nie oder zu spät eintreffen sein); oder er kann einen ausgeführten Task kennzeichnen, der wegen einer Überschreitung seiner planmäßig zugewiesenen Prozessorzeit beendet wurde;
6. "Zusammenfassung der Ressourcen-Datenbank" 1430: Zusammenfassung der Ressourcen, die der Agent verwaltet. Hier wird auch angezeigt, welche Ressourcen frei sind, welche zugewiesen wurden und wem sie zugewiesen wurden; und
7. "Zuweisungstabelle" 1435: visuelle Darstellung der Planung von Tasks. Dies ist eine Zusammenfassung der Ergebnisse der Überwachung der Ausführung von Tasks oder der zur Ausführung anstehenden Tasks; der Monitor kann beispielsweise einen Task darstellen, der aufgrund unzureichender Ressourcen nicht gestartet werden konnte, oder einen ausgeführten Task kennzeichnen, der aufgrund einer Überschreitung der ihm planmäßig zugeordneten Prozessorzeit beendet wurde. Wie dargestellt, ist der Agent C zum Zeitpunkt 4 fest für den Task "Bereitstellen eines Computers" vorgesehen.
Das Mikro-Dienstprogramm bietet dem Benutzer eine genauere Einsicht in die interne Verarbeitung durch einen Agent und hat ein offensichtliches Fehlerbehebungspotential. Das Setzen von Flaggs für die Ausführung von Tasks, die aufgrund einer Überschreitung der ihnen zugewiesenen Prozessorzeit beendet wurden, könnte einem Benutzer beispielsweise anzeigen, daß er bzw. sie die zur Ausführung dieser Tasks erforderliche Zeit unterschätzt hat. (Es wird davon ausgegangen, daß Benutzer/Entwickler eine konservative Schätzung der für den Ablauf jedes Task erforderlichen Prozessorzeit abgeben, die vom Agent für die Planung seiner Aktivitäten verwendet wird.)
Als weiteres Beispiel kann ein Benutzer durch die Überprüfung des aktuellen Status des Koordinationsprozesses für einen Job (anhand der grafischen Darstellung des Koordinationsprozesses) beispielsweise feststellen, warum der Job von dem Agent abgelehnt wurde. Da jeder Knoten des Koordinationsgraphen einen bestimmten Status des Prozesses anzeigt, informiert die Spur eines Jobs in dem Graphen den Benutzer über annähernd alles, was es über die Koordination dieses Jobs zu wissen gibt. Anhand einer Spur kann ein Benutzer beispielsweise feststellen, daß der Job O beispielsweise gescheitert ist, weil er bestimmte Ressourcen erforderte, über die der Agent nicht verfügte, und der Agent ferner keinen anderen Agent finden konnte, der die Ressource in der erforderlichen Quantität und Zeit sowie innerhalb des Kostenrahmens und weiterer Beschränkungen bereitstellen konnte.

5.4 Das Steuermonitor-Dienstprogramm

Es ermöglicht die folgenden Funktionen:
Blättern
Hinzufügen
Ändern
Löschen
Diese Funktionen sind auf aktuelle Aufgaben, Jobs, Ressourcen, Tasks, organisatorische Beziehungen und Kenntnisse sowie auf Koordinationsstrategien anwendbar. Weitere Funktionen umfassen:
Aussetzen (Jobs oder Agents)
Wiederaufnehmen (Jobs oder Agents)
Abbrechen (Agents)
Die zuletzt genannten drei werden durch Senden von Anforderungsnachrichten mit dem vorstehenden Inhalt (beispielsweise einer Aussetzungsbenachrichtigung) an die Agents ausgeführt.
Das Steuermonitor-Dienstprogramm arbeitet wiederum in bezug auf einzelne Agents. Es bietet eine Online-Version der ursprünglichen CABS-Agent-Erstellungsmöglichkeiten.
Das Steuermonitor-Dienstprogramm ermöglicht einem Benutzer die Auswahl eines Agent, der von Interesse ist, sowie die Durchsicht, das Hinzufügen, Ändern oder Löschen seiner aktuellen Jobs, Ressourcen, Tasks, organisatorischen Beziehungen und Kenntnisse sowie der Koordinationsstrategien. Ferner kann der Benutzer Jobs aussetzen und wieder aufnehmen und ebenso Agents aussetzen, wieder aufnehmen oder sogar abbrechen. Es ist auch eine Funktion vorgesehen, durch die der Benutzer verschiedene Parameter eines Agent einstellen kann, beispielsweise, wie lange er auf Antworten von anderen Agents wartet, bevor er davon ausgeht, daß keine Antwort erfolgt, oder wie der Agent seine Zeit zwischen dem Ausführen von Tasks, die er bereits übernommen hat, und der Koordination neuer Tasks aufteilen soll. Da unterschiedliche Systeme oder Anwendungen mit mehreren Agents unterschiedliche Ontologien- oder Datenverzeichnisse zur Spezifikation von Datensätzen verwenden können, ermöglicht dieses Dienstprogramm Benutzern das Laden einer Ontologiedatenbank 260, die die Ontologie ihres speziellen Systems bzw. ihrer Anwendung definiert.
Das Steuermonitor-Dienstprogramm ist bei der Fehlerbehebung und/oder der Analyse des Verhaltens einer Gemeinschaft von Agents nützlich, da es einem Benutzer die dynamische Rekonfiguration der Gemeinschaft und die Analyse ihres anschließenden Verhaltens ermöglicht. Dies ist bei der Überprüfung von Hypothesen nützlich. Der Benutzer kann es zur Überprüfung der Auswirkungen verschiedener Änderungen auf die Struktur, die organisatorischen Beziehungen und das Koordinationsverhalten, etc. der Agents verwenden. Ein Agent kann beispielsweise entgegen allen Erwartungen einen Job konsequent zurückweisen, für den er ausreichende Kenntnisse (Task) besitzt, während ihm erforderliche Ressourcen fehlen, obwohl andere Agents in der Gemeinschaft vorhanden sind, die die erforderlichen Ressourcen bereitstellen können. Unter Verwendung des Steuermonitor-Dienstprogramms zum Durchblättern der Tasks und Ressourcen des Agent kann sich ein Benutzer überzeugen, daß der Agent über die Kenntnisse, nicht aber über die Ressourcen verfügt. Die Überprüfung der Liste der Koordinationsstrategien des Agent kann beispielsweise angeben, daß der Agent die Koordinationsfähigkeiten zur Beauftragung anderer Agents in der Umgebung mit der Bereitstellung der erforderlichen Ressourcen hat. Da der Agent den Job trotzdem zurückweist, könnte der Benutzer zwei Hypothesen aufstellen, nämlich daß entweder (A) dem Agent die anderen Agents in der Gemeinschaft, die die erforderliche Ressource bereitstellen können, nicht bekannt sind oder daß (B) die das Zeitlimit, das der Agent nach dem Absenden von Jobanforderungsnachrichten an andere Agents auf ein Akzeptieren wartet, kürzer als die Zeit ist, die diese Agents benötigen, um zu bestimmen, ob sie einen Job akzeptieren oder nicht. Durch die Verwendung des Steuerungs-Dienstprogramms zum Durchblättern der organisatorischen Beziehungen und der Kenntnisse des Agent kann die Hypothese (A) entweder bestätigt oder widerlegt werden, und durch die erneute Verwendung dieses Dienstprogramms zur Verlängerung der Periode, die der Agent auf eine Akzeptanz wartet, kann die Hypothese (B) bestätigt oder widerlegt werden.
Andere Dienstprogramme, wie das Mikro- oder das Gemeinschafts-Dienstprogramm, können ebenfalls in Kombination mit dem Steuermonitor-Dienstprogramm verwendet werden, um diese Hypothesen zu überprüfen. Durch die Verwendung des Gemeinschafts- Dienstprogramms kann der Benutzer beispielsweise feststellen, ob der Agent Jobanforderungsnachrichten sendet - was Hypothese A widerlegen würde; und unter die Verwendung des Mikro- Dienstprogramms kann der Benutzer bei der Zurückverfolgung der Koordination für den Job feststellen, daß der Agent den Knoten für das Warten auf eine Akzeptanz überschritten hat, bevor Antworten auf seine Jobanforderungsnachrichten eingehen - was die Hypothese (B) bestätigt.
Ein Browser-Fenster für das Steuerungs-Dienstprogramm kann dem Benutzer beispielsweise das Durchblättern, Hinzufügen, Löschen und/oder Ändern der Task-Spezifikationen von Agents in einer Gemeinschaft aus der Ferne ermöglichen. Ein derartiges Fenster könnte Kästchen mit Listen der Agents in der Gemeinschaft, der Gruppe von Tasks des aktuell ausgewählten Agent und den Status des ausgewählten Task zeigen. Ein Textbereich könnte die Spezifikation des aktuell ausgewählten Task zeigen. Knöpfe für ein "Ändern" und "Hinzufügen" könnten einen Task-Spezifikationseditor aktivieren, über den eine vorhandene Taskspezifikation geändert oder ein neuer Task definiert werden können. Der Status der Tasks wird auf OK eingestellt, wenn die Task-Definition im Dienstprogramm, soweit dies dem Dienstprogramm bekannt ist, mit der in der Task- Datenbank des relevanten Agent übereinstimmt. Der Statuswert UN- BEKANNT gibt an, daß der Benutzer die Task-Spezifikation geändert hat, daß der Agent jedoch bislang keine Bestätigung des Empfangs der neuen Spezifikation zurückgesendet hat.
Das Steuerungs-Dienstprogramm ist bei der Fehlerbehebung und/ oder der Analyse des Verhaltens einer Gemeinschaft von Agents nützlich, da er dem Benutzer die dynamische Rekonfiguration der Gemeinschaft und die Analyse ihres anschließenden Verhaltens ermöglicht. Dies bedeutet, daß es eine Neudefinition des Agent-Systems wahrend der Laufzeit ermöglicht.
Die Stärke des Steuerungs-Dienstprogramms liegt in der Verwendung von Nachrichten auf einer hohen Ebene bei der Kommunikation, beispielsweise durch KQML und verwandten Sprachen. Mit Nachrichten auf hoher Ebene können neue Spezifikationen eines beliebigen Verhaltens an einen Agent gesendet werden, und es ist die Funktion des Agent, die Spezifikation in die relevanten Funktionen umzusetzen. Würde eine Nachrichtenübertragung auf Objektebene verwendet, ginge diese Dynamik augenblicklich verloren. Eine Analogie ist die Beziehung zwischen übersetzten Sprachen wie Prolog und Lisp, die eine dynamische Neudefinition des Programmverhaltens ermöglichen, und kompilierten Sprachen, wie C++ und Fortan, bei denen dies nicht der Fall ist.
Da verschiedene Systemanwendungen mit mehreren Agents unterschiedliche Ontologien oder Datenverzeichnisse zur Spezifikation von Datensätzen verwenden, ermöglicht dieses Dienstprogramm dem Benutzer das Laden einer Ontologiedatenbank, die die Ontologie seiner spezifischen Anwendung definiert.

5.5 Das Statistik-Dienstprogramm

Gemäß Fig. 15 ermöglicht dieses Dienstprogramm die Erstellung verschiedener Statistiken über eine Gemeinschaft von Agents auf der Grundlage einzelner Agents sowie auf der Grundlage der Gemeinschaft. Die erstellten Statistiken können beispielsweise folgendes einschließen, sind aber nicht darauf beschränkt:
(a) die Anzahl der von den Agents innerhalb einer Zeitperiode versendeten Nachrichten sowie ihre Typen,
(b) die Anzahl der durch die Agents bei der Koordination unterschiedlicher Jobs versendeten Nachrichten,
(c) die durchschnittliche Auslastung der Agents, d. h. der Prozentsatz der Zeit, die die Agents tatsächlich mit der Ausführung von Tasks verbringen, und
(d) das zeitliche Verhältnis zwischen Koordination und Ausführung, d. h. wie viel Zeit mit der Koordinierung von Tasks im Vergleich zu ihrer tatsächlichen Ausführung verbracht wird.
Statistiken wie diese sind besonders nützlich bei der Fehlerbehebung oder Feineinstellung der Leistung einer Gemeinschaft von Agents. Unter Verwendung des Steuermonitor-Dienstprogramms und des Statistik-Dienstprogramms ist ein Benutzer beispielsweise besser in der Lage, Fragen zu beantworten, wie "welche organisatorische Struktur, Task-Verteilung und Koordinationskenntnisse minimieren am besten die für die Koordination aufgewendete Zeit und maximieren die mit ihrer Ausführung verbrachte Zeit (d. h. steigern die Wirtschaftlichkeit der Gemeinschaft)?. Wenn die Agents in der Gemeinschaft aus Erfahrungen lernen, wird das Statistik-Dienstprogramm noch nützlicher für die Einschätzung der Leistungsfähigkeit verschiedener Lernstrategien, da bestimmte Statistiken, wie die durchschnittliche Anzahl der durch den Agent pro Job versandten Nachrichten und/oder das zeitliche Verhältnis zwischen Koordination und Ausführung, als Leistungsmaßstab zur Messung des Lernerfolgs dienen können.
Der in Fig. 15 gezeigte spezielle Bildschirm zeigt das durch die Haupt-Agents U, T, P, M, C bei der Ausführung des Aufgabe "Computer bereitstellen" erzeugte Kommunikationsaufkommen 1500. Wie anhand der in Fig. 13 gezeigten Task-Aufteilung 700 zu erwarten, versendet der Agent C drei Ausführungsnachrichten, während der Agent P lediglich eine ausgibt. Die Antwortnachrichten entsprechen Verhandlungs- und Nach-Verhandlungs-Dialogen (Task-Verwaltungsdialogen).
Das Dienstprogramm kann unterschiedliche Anzeigeformate, wie Histogramme, Tortenansichten, Linien oder xy-Streugrafikformate für die Anzeige von Statistiken unterstützen. Die Wahl des Formats ist durch den Benutzer bestimmbar, wobei Mehrfunktionsknöpfe 1505 verwendet werden, obwohl vorab spezifizierte Standardformate für die verschiedenen Statistiken vorhanden sind.
Ähnlich wie das Gemeinschafts- und das Protokoll-Dienstprogramm unerstützt das Statistik-Dienstprogramm eine Datenbanksicherung und eine videoartige Wiedergabe von Agent-Statistiken. Zur Generalisierung werden in der Datenbank nur rohe (im Gegensatz zu verarbeiteten) Agent-Daten gespeichert, wodurch bei der Wiedergabe jede relevante Statistik neu erzeugt werden kann.

5.6 Erweitertes Beispiel

Gemäß Fig. 8 bieten die vorstehend beschriebenen Dienstprogramme, obwohl jedes isoliert verwendet als Fehlerbehebungshilfe nützlich ist, in Kombination mit den anderen Dienstprogrammen verwendet eine noch größere Unterstützung der Fehlerbehebung und
- analyse, indem sie dem Benutzer aus mehreren Perspektiven Einblick in das Verhalten der Agents gestatten. Zu Veranschaulichungszwecken wird nachstehend ein erweitertes Beispiel für die Verwendung verschiedener Dienstprogramme zur Einschätzung unterschiedlicher Aspekte des Verhaltens der Agents bei einer Fehlerbehebungsaufgabe beschrieben.
Es wird eine Gemeinschaft mit mehreren Agents betrachtet, die sieben Agents A-G aufweist, wie in Fig. 8 gezeigt. Der Benutzer nimmt an, daß die Agents so konfiguriert wurden, daß, wenn dem Agent A der Job J zugewiesen wird, die Aufteilung des Jobs über die Gemeinschaft erfolgen würde, wie dargestellt, d. h. J1 an Agent B, J2 an Agent C, J12 an Agent D, etc. Wenn der Job J jedoch dem Agent A zugewiesen wird, meldet dieser ein Scheitern der Planung des Jobs.
Zur Behebung dieses Problems kann der Benutzer beispielsweise das Gemeinschafts-Dienstprogramm, genauer den Nachrichtenspeicher, die Videowiedergabe und die Filterfunktionen, zur Überprüfung der Koordinationsaktivitäten der Agents verwenden, wenn Agent A der Job J präsentiert wird. Der Benutzer bemerkt beispielsweise, daß der Agent A erwartungsgemäß eine Anforderung (eine Vorschlagsnachricht) an den Agent B sendet, um J1 zu erfüllen, und eine weitere Anforderung (eine weitere Vorschlagsnachricht) an den Agent D, um J2 zu erfüllen. Weiterhin sendet der Agent B erwartungsgemäß eine Anforderung an den Agent D, um J12 zu erfüllen. Der Agent C versendet jedoch keine Anforderungen, obwohl er erwartungsgemäß drei hätte versenden sollen.
Bei einem erneuten Ablauf des Szenarios unter Verwendung des Mikro-Dienstprogramms zur Überprüfung der Interna des Agent C wird anhand der Zurückverfolgung des Koordinationsgraphen für den Job J2 festgestellt, daß J2 erfolgreich in J21, j22 und J23 aufgeteilt wurde, daß der Koordinationsprozeß jedoch scheiterte, weil keine in Frage kommenden Agents gefunden wurden, die mit J22 beauftragt werden konnten. Unter Verwendung des Steuermonitor-Dienstprogramms zur Überprüfung der organisatorischen Beziehungen und Kenntnisse des Agent C wird festgestellt, daß keine Einträge, die Agents spezifizieren, die J22 erledigen könnten, in der Datenbank der organisatorischen Kenntnisse des Agent C aufgelistet waren - daher wird ein Eintrag in der Datenbank der organisatorischen Kenntnisse des Agent C angelegt, um diesen "Fehler" zu beheben.
Ein erneuter Ablauf des Problems wird gestartet, und diesmal meldet der Agent A eine erfolgreiche Verteilung des Tasks über die Gemeinschaft, meldet jedoch später beim Versuch, seinen untergeordneten Teil des Jobs tatsächlich auszuführen, ein Scheitern aufgrund unzureichender Ressourcen.
Unter Verwendung des Protokoll-Dienstprogramms stellt der Benutzer fest, daß die Agents E, F, G und C nach der erfolgreichen Aufteilung des Problems auf die Gemeinschaft ihre jeweiligen untergeordneten Teile des Jobs erfolgreich gestartet und abgeschlossen haben. Der Agent D scheiterte jedoch an der Erfüllung von J12, was wiederum ein Scheitern der Erfüllung von J1 durch den Agent B verursachte, was wiederum ein Scheitern der Erfüllung von J durch den Agent A zur Folge hatte.
Der Benutzer läßt das Szenario erneut ablaufen und verwendet das Mikro-Dienstprogramm zur Überwachung des Agent D. Er stellt fest, daß D J12 erfolgreich startet, die Verarbeitung jedoch später beendet, da J12 die ihm zugewiesene Prozessorzeit überschritten hat (angezeigt durch eine Ausführungsüberwachungsnachricht). Der Steuermomtor wird verwendet, um die Definition von J12 zu ändern, um die geschätzte Laufzeit zu steigern.
Das Szenario wird erneut gestartet, und diesmal wird alles abgeschlossen.
Alternativ kann der Task J12 über die Zeit zur Ausführung verfügt, aber die falschen Ausgänge erzeugt haben (d. h. der Task-Körper wurde falsch spezifiziert). In diesem Fall erfaßt das Mikro-Dienstprogramm nicht, daß J12 die Zeit überschritten hat, und der Task- Körper muß überprüft und korrigiert werden.
Bei einem anderen Fehlerszenario, bei dem die gleiche Anordnung von Agents verwendet wird, wie in Fig. 8 gezeigt, kann statt dessen das Statistik-Dienstprogramm zeigen, daß der Agent C tatsächlich zwei Anfragen (Vorschlagsnachrichten) versendet, die den Task J2 betreffen, obwohl drei Anfragen zu erwarten gewesen wären. Es ist nun möglich, die Hypothese aufzustellen, daß die Ursache für den Fehler beim Agent C zu finden ist, wahrscheinlich aufgrund eines oder beider folgenden Gründe:
i) einem Fehler bei der Spezifikation des Task J2. Die Task- Spezifikation ist erwartungsgemäß {J21, J22, J23} = {J2}, d. h. wenn J21, J22 und J23 erfüllt werden können, kann J2 erfüllt werden. Wenn die Spezifikation fehlerhaft ist, beispielsweise statt dessen {J29, J22, J23{ = {J2} lautet, würde dies dazu führen, daß zwei Vorschlagsnachrichten für die Jobs J22 und J23 versendet würden, aber keine äquivalente Vorschlagsnachricht für J29. Der Agent C versendet keine Vorschlagsnachricht für den Job J29, da ihm kein anderer Agent bekannt ist, der J29 ausführen kann;
ii) einem Fehler bei einer Spezifikation in der Beziehungsdatenbank des Agent C. Unter der Annahme, daß der Task ordnungsgemäß spezifiziert ist, wäre der wahrscheinlichste Grund für den nicht ausgeführten Versand der dritten Vorschlagsnachricht (erneut) daß in der Beziehungsdatenbank des Agent C kein Agent aufgelistet ist, der in der Lage ist, den dritten Job auszuführen.
Die Gesamthypothese, daß der Fehler beim Agent C liegt, kann beispielsweise unter Verendung des Mikro-Dienstprogramms zur Überprüfung der Interna des Agent C verifiziert werden. Es könnte beispielsweise anhand der Zurückverfolgung seines Koordinationsgraphen festgestellt werden, daß der Agent C die an J2 beteiligten Aktivitäten nicht planen oder koordinieren konnte, wodurch die Hypothese bestätigt würde.
Hinsichtlich der Hypothesen (i) und (ii) kann das Steuerungs- Dienstprogramm verwendet werden; um aus der Entfernung die Task-Spezifikationsdatenbank des Agent G zu überprüfen. Wenn sie korrekt ist, wird (i) ausgeschlossen. Zur Bestätigung der Hypothese (ii) kann das Steuerungs-Dienstprogramm verwendet werden, um die Beziehungsdatenbank des Agent C direkt zu überprüfen und (durch Durchblättern der Beziehungsdatenbank des Agent C unter Verwendung eines Task-Browser-Fensters des Steuerungs-Dienstprogramms) sämtliche Spezifikationen zu überprüfen, die J21, J22 und J23 betreffen.
Alternativ ist es bei einer großen Beziehungsdatenbank möglich, das Gemeinschafts-Dienstprogramm zur Überprüfung der vom Agent C versendeten Nachrichten zu verwenden. Es könnte festgestellt werden, daß der Agent C Nachrichten an die Agents F und G versendet hat, um jeweils die Jobs J22 und J23 auszuführen. Es ist nun verhältnismäßig sicher, daß das Scheitern der Ausführung des Jobs J auf einen Spezifikationsfehler in der Beziehungsdatenbank des Agent C bezüglich J21 (der Aufgabe) und des Agent E zurückzuführen ist. Dies kann unter Verwendung des Steuerungs-Dienstprogramms zur Überprüfung und Änderung der Beziehungsdatenbank des Agent C bestätigt werden.
Es wird darauf hingewiesen, daß mit dem vorstehend beschriebenen Paket von Dienstprogrammen nicht jede mögliche Fehlerursache in einem System mit mehreren Agents erfaßt werden kann, zu dessen Überwachung es verwendet wird, daß er jedoch die Aufgabe der Fehlerbehebung ungeheuer erleichtert.
Obwohl sich die Beschreibung auf ein bestimmtes, vorstehend beschriebenes CABS-System mit mehreren Agents bezog, können eines oder mehrere der Fehlerbehebungs-Dienstprogramme leicht für andere Systeme mit mehreren Agents verwendet werden, die auf unterschiedlichen Architekturen, Agents, Beziehungen und Sprachen basieren. Es wäre lediglich erforderlich, daß die Agents des Fehlerbehebungs-Dienstprogramms (der Fehlerbehebungs-Dienstprogramme) und des Systems mit mehreren Agents, in dem die Fehlerbehebung vorgenommen wird, die Nachrichten und weitere Informationen, wie Task-Spezifikationen, auf die gleiche Weise verstehen können, so daß das Fehlerbehebungs-Dienstprogramm (die Fehlerbehebungs- Dienstprogramme) verstehen kann (können), was die Nachrichten beinhalten, und die weiteren Informationen überprüfen und ändern kann (können).
Ausführungsformen der vorliegenden Erfindung können in Verbindung mit einem breiten Spektrum an Systemen mit mehreren Agents verwendet werden. Sie wurden insbesondere beispielsweise in Verbindung mit den folgenden Anwendungen bewertet:
- einer Reisemanagementanwendung mit I7 Agents, bei der ein Reisemanagement-Agent mit Hotels, Luftfahrtgesellschaften, Auto-, Bahn- und Taxireservierungs-Agents verhandelt, um eine Reiseplanung für eine transatlantische Reise für einen Benutzer zu erstellen;
- einer Telekommunikationsnetzwerkverwaltungsanwendung mit 27 Agents. Hier verhandeln Netzwerkverbindungen steuernde Agents, um virtuelle private Netzwerke für Benutzer zu erzeugen. Bei dieser Anwendung war das Protokoll-Dienstprogramm sehr leicht so einzustellen, daß es ein anderes Anzeigeformat für Task-Aufteilungsgraphen unterstützte; und
- eine elektronische Handelsanwendung, bei der die Agents unter Verwendung unterschiedlicher Verhandlungsstrategien Güter und Dienstleistungen kaufen und verkaufen. Diese Anwendung verfügte über mehr als 100 Agents, die gleichzeitig viele verschiedene Tasks ausführten, und die Farbcodierung der Nachrichten nach Aufgaben war entscheidend für das Verständnis der Interaktionen zwischen den Agents.
Obwohl unter verschiedenen Umständen unterschiedliche Sprachen und unterschiedliche Hardware für geeignet befunden werden können, können Ausführungsformen der vorliegenden Erfindung vollständig in der Programmiersprache Java implementiert werden und unter UNIX beispielsweise auf Solaris- und Windows-NT- Arbeitsplätzen laufen.

Claims

1. Visualisierungsvorrichtung (140) zur Verwendung in einem Softwaresystem (100) zur Steuerung, Überwachung oder Verwaltung eines Prozesses oder einer Anordnung, wobei das Softwaresystem mehrere mit Einrichtungen (200) zur Kommunikation miteinander versehene Softwaremodule (105, 110, 115) umfaßt und die Visualisierungsvorrichtung umfaßt:

eine Einrichtung (1015) zum Speichern und zum Veranlassen einer Anzeige von in Verbindung mit einem einzelnen Softwaremodul und oder zwischen mindestens zwei der Softwaremodule auftretenden Kommunikationsvorgängen oder diese betreffenden Daten,

eine Einrichtung (1000, 1005) zum Erhalt die Softwaremodule betreffender organisatorischer Daten (510), die die Kooperationsbeziehung zwischen zwei oder mehr Softwaremodulen bestimmen, und

eine Einrichtung (1015) zur derartigen Verarbeitung der Kommunikationsvorgänge oder Daten vor der Anzeige, daß die Kommunikationsvorgänge oder die sie betreffenden Daten auf eine durch die organisatorischen Daten bestimmte Weise angezeigt werden können,

dadurch gekennzeichnet, daß

die Einrichtung zur Veranlassung der Anzeige der Kommunikationsvorgänge eine dynamische Neudefinition zumindest entweder der organisatorischen Daten und/oder der Kommunikationsdaten, die eines oder mehrere der Softwaremodule betreffen, als Reaktion auf einen Eingang erzeugt, der Veränderungen zumindest entweder der organisatorischen Daten und/oder der Kommunikationsdaten repräsentiert, die eines oder mehrere der Softwaremodule betreffen.

2. Vorrichtung nach Anspruch 1, bei der die Eingänge Signale einschließen, die zumindest entweder ein Durchblättern, ein Hinzufügen, ein Verändern oder ein Löschen von Aspekten der organisatorischen Daten repräsentieren.

3. Vorrichtung nach Anspruch 1 oder 2, bei der die Eingänge Signale einschließen, die zumindest entweder ein Beenden, ein Aussetzen der Aktivitäten und/oder eine Wiederaufnahme der Aktivitäten eines oder mehrerer der Softwaremodulen repräsentieren.

4. Vorrichtung nach Anspruch 3, bei der die Aspekte der organisatorischen Daten aktuelle Jobs, Ressourcen, Tasks, organisatorische Beziehungen und Kenntnisse sowie die einem Modul vorab zugewiesenen Kooperationsbeziehungen umfassen.

5. Vorrichtung nach einem der vorhergehenden Ansprüche, bei der die Aspekte der organisatorischen Daten ferner eine zeitliche Beschränkung für das Akzeptieren eines einem Softwaremodul zugewiesenen Jobs umfassen.

6. Vorrichtung nach einem der vorhergehenden Ansprüche mit einem Satz Auswahleinrichtungen (1400, 1405, 1410, 1415, 1425. 1430,1435), wobei mindestens zwei Auswahleinrichtungen aus dem Satz von Auswahleinrichtungen eine derartige Visualisierung von verschiedene Aktivitäten der verwendeten Softwaremodule des Systems betreffenden Kommunikationsvorgängen erzeugen, daß die Verwendung der beiden Auswahleinrichtung eine Visualisierung mittels zweier Teilansichten des Protokolls der Aktivitäten der Softwaremodule erzeugt.

7. Vorrichtung nach Anspruch 6, bei der der Satz von Auswahleinrichtungen auf der Grundlage von zwei oder mehr der folgenden Punkte Teilansichten erzeugt:

(i) interne Daten und Vorgänge (1400, 1405) in einem Softwaremodul,

(ii) Task-Zuweisung (1415) zwischen Softwaremodulen,

(iii) Task-Zuweisung und Planung (1435) innerhalb eines einzelnen Softwaremoduls,

(iv) statistische Daten (1500), die die Aktivitäten der mehreren Softwaremodule betreffen, und

(v) Kommunikation zwischen einem Satz von unter Bezugnahme auf die hierarchischen Kooperationsbeziehungen zwischen den Softwaremodulen betreffende, organisatorische Daten ausgewählten Softwaremodulen.