Spezifikation von Interaktionsprotokollen

REkoS bietet ein sehr mächtiges Interaktionsmodell, das die Leistungsfähgikeit der meisten anderen Agentenprogrammiersprachen übersteigt. Der wesentliche Unter-schied zu anderen Ansätzen liegt in der Gestaltungsmöglichkeit von rollenbasierten Protokollen, an denen beliebig viele Agenten partizipieren können. Herkömmliche Interaktionsprotokollsprachen für Agenten berücksichtigen nur zwei Teilnehmer bzw. Rollen⁹.

5.6.1 Protokollklassen

Die Diskussion globaler Koordinierungstechniken in Abschnitt 2.3.6 hat gezeigt, daß Interaktionsprotokolle einen allgemeinen Rahmen für die Lösung unterschied-licher Koordinationsprobleme darstellen. Entsprechend werden in REkoS definierte Interaktionsprotokolle sogenannten Protokollklassen zugeordnet. Beispielsweise ist das Contract-Net ein Vertreter der Klasse „Aufgabenverteilung“, während SANP in die Rubrik „Konfliktbehandlung“ gehört.

Hinter dem Konzept der Protokollklassen stecken mehrere Ideen. Wenn eine Klasse ein Problemfeld oder Ziel abdeckt, kann ein passendes Protokoll automa-tisch beim Auftreten einer Problemsituation aktiviert werden. Es braucht dazu nur eine Zuordnung von Problemen auf Protokollklassen definiert sein. Sind mehrere Vertreter in einer Klasse enthalten, besteht eine Auswahlmöglichkeit, in die Krite-rien wie voraussichtlicher Aufwand oder Lösungsqualität einfließen können.

8. Ein allgemeinerer Mechanismus zum Erkennen und Auflösen interner Konflikte ist nicht vorgesehen.

Dazu fehlt es an einem schlüssigen Modellierungskonzept für Ressourcen oder Koordinationsbezie-hungen wie beispielsweise in TÆMS(siehe Abschnitt 4.4 „TÆMS / GPGP“ auf Seite 102).

9. Beispielsweise COOL (siehe Abschnitt 4.3), GCCP oder IMAGINE (Abschnitt 4.5).

5.6.2 Rollen

Jedes Protokoll besteht aus einer Menge von Rollen, die jeweils durch einen Proto-kollgraphen beschrieben werden. Eine ausgezeichnete Rolle spielt die des rationsmanagers. Sie wird automatisch von dem Agenten ausgefüllt, der die Koope-ration startet. Mit der Managerrolle sind weitreichende Kontrollkompetenzen ver-bunden, so ist nur er in der Lage, ein Protokoll vorzeitig zu beenden. Jeder Agent in einer Kooperation füllt immer genau eine Rolle aus, die sein Verhalten bestimmt.

Die Zuorndung von Rolle zu Agent ist eine 1:n-Beziehung. Auf diese Weise kann auf einfache Art z.B. das Verhalten eines Teams beschrieben werden.

Agenten müssen nicht über die gesamte Zeit einer Kooperation dieselbe Rolle ausfüllen, sondern können aus der Kooperation aussteigen oder die Rolle wechseln.

Kommentarloses Beenden einer Kooperation ist einerseits der Autonomie geschul-det, kann auf der anderen Seite aber auch unbeabsichtigt durch Termination des Agenten oder Ausfall von Kommunikationsinfrastruktur geschehen. Ein Beispiel für einen Rollenwechsel bietet die unten beschriebene Realisierung eines Contract-Net-Protokolls. Dort schlüpft der Agent, der den Zuschlag bekommt, von der Rolle des Anbieters zu der des Contractors.

Die Kommunikation innerhalb eines Protokolls findet zwischen Rollen statt. Al-le Sprechakte, die an eine RolAl-le adressiert sind, werden automatisch an sämtliche Agenten, die aktuell „in der Rolle“ sind, weitervermittelt.

5.6.3 Sprache zur Beschreibung von Interaktionsprotokollen

Die zwei wesentlichen Elemente von Interaktionsprotokollen, Kommunikation und lokales Handeln, werden bereits von den in Abschnitt 5.5 behandelten Skripten ab-gedeckt. Das dort beschriebene Skriptmodell wurde daher für die besonderen An-forderungen der Interaktionsprotokolle erweitert.

Kooperationsskripte

Jede Rolle besteht aus einer Menge von Kooperationsskripten, die eine Spezialform der Klasse der oben beschriebenen Handlungsskripte darstellen. Das eigentliche Skript, das den Handlungsablauf in einem Kooperationszustand durch eine Sequenz von Steps beschreibt, ist in eine Vor- und eine Nachbedingung eingekleidet.

Die Vorbedingung bestimmt, wann das Skript aktiviert wird. Anders als bei Handlungsskripten hängt die Aktivierung nicht von einer Task oder einem Ziel ab, sondern vom Verlauf der Kooperation. Prinzipiell kann an dieser Stelle ein beliebi-ger boolescher Ausdruck stehen. Die Aufgabe der Vorbedingung liegt aber in der Si-cherstellung der Ablaufreihenfolge innerhalb der Rolle und in der Synchronisation

mit den anderern Kooperationsrollen. Daher werden hier typischerweise Zwischen-ergebnisse von vorherigen Skripten oder das Eintreffen von Sprechakten anderer an der Kooperation beteiligter Agenten abgefragt.

Die Nachbedingung erfüllt zwei Funktionen. Zum einen findet aktive Synchro-nisation durch Versenden von Sprechakten an andere Rollen statt. Zum andern legt sie fest, welches Skript der Rolle als nächstes aktiviert wird. Verlassen einen Knoten mehrere Kanten, so wird dies durch bedingte Verzweigungen realisiert. Entspricht das Kooperationsskript einem Endknoten, existiert kein Nachfolgeskript, sondern die Mitwirkung des Agenten an der Kooperation ist beendet. Einen Sonderfall stellt der mögliche Rollenwechsel dar, auch dieser wird in der Nachbedingung beschrie-ben.

Kommunikation

Kommunikation findet über den gewohnten Mechanismus der Sprechakte statt.

Weil die Verarbeitung von Nachrichten innerhalb von Interaktionsprotokollen frei definierbar ist, hat die illokutionäre Ebene der Sprechakte hier keine Bedeutung, d.h. die send_function bzw. receive_function wird nicht ausgeführt. Im Prinzip han-delt es sich demnach um reine Daten- oder Synchronisationskommunikation¹⁰.

Beim Start eines Interaktionsprotokolls wird neben einer Protokollinstanz eine eindeutige Kooperations-ID generiert. Auf der Suche nach Partnern (bei der Initia-lisierung, s.o.) schickt der Kooperationsmanager an die potentiellen Kandidaten ei-nen Sprechakt, der den Namen des Protokolls, die ID und eventuell die einzuneh-mende Rolle enthält. Nimmt ein angesprochener Agent teil, so generiert er sich eine Protokollinstanz der ihm zugewiesenen Rolle und ordnet ihr die zugehörige ID zu.

Jeder Sprechakt, der aus einem Kooperationsskript abgeschickt wird, wird automa-tisch mit der Kooperations-ID und dem Rollennamen versehen. Auf diese Weise können eingehende „normale“ von zu Protokollen gehörenden Sprechakten unter-schieden werden.

Neben der gerichteten Kommunikation von Agent zu Agent werden auch Broad-cast- und MultiBroad-cast-Nachrichten unterstützt. Broadcastnachrichten erreichen alle Agenten, die am Interaktionsprotokoll teilnehmen. Als Adressat kann aber auch ein Rollenname angegeben werden, entsprechend wird der Sprechakt allen Agenten der Rolle zugestellt.

10. Laut [Levinson 1981] (siehe Zitat in Abschnitt 2.2.2) sind Sprechakte und Interaktionsprotokolle (Dia-loge) prinzipiell nicht miteinander vereinbar.

5.6.4 Spezifikationswerkzeug für Interaktionsprotokolle

Zur Spezifikation von Interaktionsprotokollen wurde ein Grapheneditor entwickelt.

Er bietet Funktionalität zur Eingabe und Verwaltung von Protokollklassen, Proto-kollen und Rollen. Das wesentliche Element bei der Spezifikation ist die Beschrei-bung des synchronisierten Ablaufs zwischen den einzelnen Rollen.

Jede Rolle eines Interaktionsprotokolls wird durch einen gerichteten Graphen mit einem ausgezeichneten Anfangs- und - eventuell mehreren - Endknoten model-liert (siehe Abbildung 5-6 links). Dabei definieren Knoten Zustände, in denen ein Agent Berechnungen durchführt, während die Kanten Zustandsübergänge markie-ren. Bei der Abarbeitung eines Protokolls „wandert“ ein Agent durch den Graphen, bis er einen Endknoten erreicht.

Abbildung 5-6: Graphische Repräsentation von Kooperationsrollen

Mit jedem Knoten ist ein Kooperationsskript assoziiert, das über einen Knotenedi-tor direkt aus dem Graphen heraus spezifiziert werden kann (siehe Abbildung 5-6

rechts). Der Aufbau eines derartigen Skripts ähnelt den Konversationsregeln in COOL (siehe Abschnitt 4.3). Es besteht aus einer Aktivierungsbedingung (passive sync actions), dem Handlungsrumpf (script actions) und einem Verzweigungsteil (active sync actions). Dabei wird die Handlungsausführung eines Knotens solange verzögert, bis die Aktivierungsbedingung wahr wird. Zum Abschluß der Skriptab-arbeitung wird im Verzweigungsteil der Nachfolgeknoten bestimmt.

Die Aktivierungsbedingung eines Kooperationsskripts dient zur Synchronisation mit den Rollen anderer an der Kooperation beteiligter Agenten. Zur Unterstützung des Programmierers wurden einige oft benötigte Synchronisationsprimitive vorde-finiert. Diese können, zusammen mit weiteren von Hand zu programmierenden Tests, mit Hilfe boolescher Operatoren zu logischen Ausdrücken zusammengefaßt werden.

Der Skriptrumpf wird mittels der Skriptsprache zur Programmierung der prozedura-len Fähigkeiten (siehe Abschnitt 5.5.2) beschrieben. Zusätzlich muß noch der Name des Nachfolgeknotens, sofern es sich nicht um einen Endknoten handelt, bestimmt werden. In der graphischen Spezifikation sind die möglichen Nachfolgeknoten be-reits definiert; sie finden sich als „Sprunglabels“ im Verzweigungsteil des Koope-rationsskripts wieder. Die Verzweigung zum Nachfolger geschieht dann aus dem Skript heraus mittels eines goto-Konstrukts, in das ein gültiges Label eingetragen wird.

TABELLE 4. Synchronisationsprimitive in Kooperationsskripten

Synchronisations-primitive Bedeutung

sleep( X ) X Sekunden warten

know( Term ) warten bis der Prolog-Ausdruck Term in der Wissensbasis erfüllbar ist

wait_until( X ) bis zum Zeitpunkt X warten s_a( X ) auf einen Sprechakt X warten

s_a( From, X ) auf Sprechakt X eines Kooperationspart-ners der Rolle From warten

s_a_set( Num, X ) auf mindestens Num Sprechakte der Art X warten

s_a_set( Num, From, X ) auf mindestens Num Sprechakte der Art X von Rolle From warten