Sonderdruck (PDF) - Institut für Automatisierungs- und ...

2003–04
Automatisierungstechnische
Praxis
Softwareagenten – Einführung und
Überblick über eine alternative Art
der Softwareentwicklung
Sonderdruck
Oldenbourg

Universität Stuttgart
Institut für Automatisierungs- und Softwaretechnik
Prof. Dr.-Ing. Dr. h. c. P. Göhner
Agenten in der Automatisierungstechnik
Liebe Leser,
die Entwicklung von Software für moderne Automatisierungssysteme
ist eine beständige Herausforderung für
Ingenieure und findet häufig im Spannungsfeld einer
Reihe verschiedenster Anforderungen statt. Dazu gehören
die zunehmende Dezentralisierung und komplexere
Abläufe in Automatisierungssystemen sowie die Notwendigkeit
zu mehr Flexibilität, Robustheit, Skalierbarkeit,
Anpassbarkeit und Integrationsfähigkeit der Automatisierungssoftware.
Um diese Anforderungen zukunftssicher bewältigen zu
können, muss die Automatisierungssoftware flexibel und
ohne großen Aufwand an Änderungen des Automatisierungssystems
oder seiner Umgebung anpassbar sein.
Dabei besteht häufig die Schwierigkeit, die komplexen
Abläufe und Verhaltensweisen eines solchen, flexiblen
Systems zu beherrschen. Der Einsatz von Softwareagenten
bietet viel versprechende Möglichkeiten, diesen Herausforderungen
zu begegnen. Dabei handelt es sich um
autonome Softwareeinheiten, die selbstständig innerhalb
ihres Entscheidungsrahmens handeln und dabei vorgegebene
Ziele verfolgen. Agenten können miteinander
flexibel interagieren und durch Verhandlungen kooperieren,
um ihre individuellen Ziele zu erreichen.
Besonderes Potential beim Einsatz von Softwareagenten
ist überall dort zu erwarten, wo in verteilten Strukturen
lokale Dynamik und Selbstständigkeit von Bedeutung
sind und zugleich vielfältige, systemübergreifende Abhängigkeiten
zwischen Teilprozessen das Verhalten des
Gesamtssystems wesentlich beeinflussen. Mit Hilfe von
Agenten wird es möglich, die notwendige Flexibilität und
Anpassungsfähigkeit von Automatisierungssystemen
systematisch zu entwerfen. Damit kann der längst fällige
Paradigmenwechsel in der Automatisierungstechnik vollzogen
werden – weg von hierarchischen, statischen Systemen,
hin zu flexiblen, dezentralen Netzwerken aus
autonomen, kooperierenden Elementen.
In den letzten Jahren haben Agenten in den verschiedensten
Bereichen den Weg in konkrete Anwendungen
gefunden, beispielsweise im E-Business, in der Telekommunikation
oder in der Logistik. In der Automatisierungstechnik
werden die Vorteile agentenorientierter
Systeme bisher noch kaum genutzt. Ein Grund hierfür ist
sicherlich, dass heute noch keine einheitliche Vorstellung
darüber besteht, was Agenten genau ausmacht, und wie
agentenorientierte Automatisierungssysteme systematisch
entwickelt und realisiert werden können.
Das Institut für Automatisierungs- und Softwaretechnik
beschäftigt sich seit einigen Jahren mit dem Einsatz von
Agenten in der Automatisierungstechnik. Die vorliegende
Beitragsreihe bietet einen Überblick über dieses spannende
Thema. Der erste Teil gibt eine Einführung in die
wesentlichen Merkmale von Agenten, beschreibt die
Vorgehensweise bei der agentenorientierten Softwareentwicklung
und zeigt die Vor- und Nachteile agentenorientierter
Systeme – insbesondere im Hinblick auf die
Automatisierungstechnik – auf. Im zweiten Teil wird die
Denk- und Vorgehensweise bei der agentenorientierten
Softwareentwicklung an Hand der Modellierung eines
technischen Anwendungsbeispiels veranschaulicht. Der
dritte Teil diskutiert die Möglichkeiten zur Implementierung
von Agentensystemen und verdeutlicht diese mit
Hilfe des modellierten technischen Beispiels. Die drei
Beiträge wurden in der atp, Hefte 10/2003, 11/2003 und
2/2004 veröffentlicht.
Wenn Sie weitere Fragen zu diesem Thema oder zu
den Forschungsarbeiten des Instituts für Automatisierungs-
und Softwaretechnik auf dem Gebiet „Agenten in
der Automatisierungstechnik“ haben, freuen wir uns über
Ihre Kontaktaufnahme. Sie finden unsere Kontaktadressen
am Ende dieses Sonderheftes.
Herzlichst, Ihr
Prof. Dr.-Ing. Dr. h. c. P. Göhner

3
Softwareagenten – Einführung und
Überblick über eine alternative Art der
Softwareentwicklung
Thomas Wagner, Paulo G. de A. Urbano und Peter Göhner
Universität Stuttgart
Agentenorientierte Softwareentwicklung
Immer häufiger fällt im Zusammenhang mit moderner industrieller Software der Begriff des Agenten. Ob im
Internet, E-Business, Telekommunikation, Logistik und teilweise bereits in der Automatisierungstechnik, Software,
die auf Agenten basiert, scheint die Herauforderungen an moderne Anwendungen besser und einfacher
zu bewältigen. Häufig wird bei den vorgestellten Anwendungen aber nicht klar, um was es sich bei dem
Begriff des Softwareagenten eigentlich handelt und warum damit Probleme besser gelöst werden sollen.
Handelt es sich hierbei um eine Technologie, eine Architektur oder ein Programmierkonzept? In diesem Artikel
wollen wir eine allgemeine Einführung in das Thema Softwareagenten aus der Sicht des Softwareentwicklers
geben, die theoretischen Grundlagen sowie die praktische Anwendung erläutern und verdeutlichen,
bei welchen Problemen Softwareagenten überhaupt einen sinnvollen Lösungsansatz darstellen. Der
Schwerpunkt liegt dabei auf Anwendungen in der Automatisierungstechnik.
Agent systems in industrial automation: Agent-oriented software engineering
Evermore frequently, the term „agent“ is associated with modern industrial software.Whether in the Internet,
e-business, telecommunications, logistics or even in the industrial automation area, software based on
agents seems to make the challenges in modern applications easier to overcome effectively. However, in a
particular application, it is often unclear what the function of the software agent is and why problems can
be better solved with it. Is it concerning a technology, an architecture or a programming concept? In this article
we intend to present a general introduction to the software agent subject from the software engineer's
perspective, elucidating the theoretical basis in addition to the practical applications and clarifying to which
type of problems software agents could represent a reasonable approach. The main focus therefore lies in
industrial automation applications.
1. Einführung
Der Begriff des (Software-) Agenten existiert seit fast 40 Jahren
in den verschiedensten Ausprägungen. Zunächst wurde
die Idee des Agenten in der Science-Fiction Literatur 1964
von Arthur C. Clarke in seinem Buch 2001 – Odyssee im Weltraum
als künstliches, intelligentes Computerwesen HAL skizziert.
In den achtziger Jahren entwickelte sich ein Forschungs-zweig
der Informatik, der sich mit so genannten
Agentensystemen beschäftigt und seinen Schwerpunkt
zunächst im Bereich der künstlichen Intelligenz (KI) hatte.
Hier wurden unter Agenten vorwiegend verteilte Problemlösungsprozesse
verstanden.
In den letzten 15 Jahren haben sich die Agenten 1 und
Agentensysteme zu einem wichtigen Forschungsbereich
1
Im Folgenden verwenden wir den Begriff Agent stets im Sinne von
Softwareagent. Eine allgemeine Taxonomie des Begriffes Agent findet sich
in [1].
entwickelt. Auch bei industriell eingesetzter Software findet
sich in den letzten Jahren vermehrt der Begriff des Agenten
wieder, ausgehend von der Informationssuche im Internet,
über E-Business und Supply Chain Management Systeme bis
hin zu bestimmten Programmen in heutigen Windows-Betriebssystemen.
Vielfach werden Agenten dabei als Mittel
dargestellt, mit dem die Eigenschaften und Fähigkeiten von
Software entscheidend verbessert werden können. Dies ist
sicherlich zum einen auf die Tatsache zurückzuführen, dass
sich der Forschungsbereich der Agentensysteme zunehmend
etablieren konnte und immer mehr Synergien mit
anderen Forschungsgebieten entstanden. Zum anderen ist
der Begriff des Agenten aber wegen seiner unterschiedlichen
umgangssprachlichen Bedeutung als Handels- und als
Geheimagent ein schillernder Begriff, so dass er bestens als
Werbeschlagwort geeignet ist, um alles und nichts zu
bezeichnen. Von manchen Softwareherstellern wird heute
selbst ein einfaches Makro als Agent bezeichnet, ohne dass
sich seine Funktionalität dadurch geändert hätte.

4
Es ist ein bekanntes Paradoxon in der Gemeinschaft der
Agentenforscher, dass es trotz umfangreicher Entwicklungen
auf diesem Gebiet bis hin zu real eingesetzten Systemen
kein festgelegtes und allgemein akzeptiertes Verständnis
darüber gibt, was ein Agent genau ist und welche
grundlegenden Eigenschaften diesen Begriff charakterisieren.
Nick Jennings, einer der bekanntesten Pioniere auf dem
Gebiet der Agentenforschung, hat diese Tatsache auf den
Punkt gebracht: „In particular, there is no real agreement
even on the core question of exactly what an agent is.“ [2].
Nach Parunak gibt es fast so viele Definitionen von Agenten
wie Forscher auf diesem Gebiet [3]. Viele dieser Definitionen
sind historisch entstanden und beziehen sich meist auf
ein spezifisches Anwendungsgebiet. Beispiele hierfür sind
der AIMA Agent [4], der Maes-Agent [5], der Hayes-Roth-
Agent [6], weitere Beispiele unter [1]. Zwar bestehen die
verschiedenen Definitionen häufig aus ähnlichen Kernbegriffen
wie Autonomie, Reaktivität und Zielorientierung,
diese werden aber unterschiedlich ausgelegt und gewichtet.
Dieses Paradoxon führt zu einem grundsätzlichen
Dilemma in der Agentenforschung und -anwendung: Einerseits
ist es nicht möglich, ohne allgemeine Definition Agentensysteme
(auch: agentenorientierte Softwaresysteme) in
vernünftiger Weise von anderen Arten von Softwaresystemen
abzugrenzen. Andererseits ist es schwierig, ein agentenorientiertes
Softwaresystem zu entwickeln, wenn die charakteristischen
Eigenschaften eines solchen Systems – und
somit auch die Entwicklungsmethodik – nicht klar sind. Ein
Softwaresystem kann herkömmlich entwickelt und auf Basis
einer passenden Definition als Agentensystem bezeichnet
werden. Dies ist sicherlich mit ein Grund für den eingangs
erwähnten Wildwuchs bei der Verwendung der Begriffe
Agent und Agentensystem.
Aus der Sicht des Anwenders ist Software stets ein mehr
oder weniger gut funktionierendes Produkt. Aus der Sicht
des Ingenieurs und Softwareentwicklers ist aber vielmehr
von wesentlichem Interesse, wie dieses Produkt entsteht,
welche Instrumente und Methoden bei seiner Entwicklung
zum Einsatz kommen und wie einfach damit die gewünschte
Funktionalität erreicht werden kann. In den letzten Jahren
hat sich daher auch in der Gemeinde der Agentenforscher
die Erkenntnis durchgesetzt, dass die Theorie der Agenten
und Agentensysteme für eine breite industrielle Anwendbarkeit
nicht nur aus der Sichtweise der Informatik, sondern
vielmehr aus Sicht der Softwaretechnik betrachtet werden
muss [7, 8].
Eine Ursache für die vielfach bekannten Probleme in der
heutigen Softwareentwicklung ist sicherlich die hohe Komplexität
der Programme. In den letzten drei Jahrzehnten hat
die Softwaretechnik ein zunehmend besseres Verständnis
über die Eigenschaften und Zusammenhänge der Komplexität
von Software erreicht. Heute ist es zunehmend anerkannt,
dass Verteiltheit und Interaktion wohl die hervorstechendsten
Merkmale komplexer Software sind [9, 10]. Es
zeigt sich, dass aufgrund der zunehmenden Vernetzung
zwischen und innerhalb von Systemen die meisten realen
Anwendungen genau diese Eigenschaften von Komplexität
aufweisen. Dies gilt für Internet- und Officeanwendungen
gleichsam wie für automatisierungstechnische Systeme.
Moderne Softwaresysteme bestehen häufig aus vielen
dynamisch interagierenden Elementen, die getrennt
voneinander ablaufen und untereinander in vielfältiger
und komplexer Weise kommunizieren. Sie sind jedoch viel
schwieriger zu entwickeln als diejenigen, die mit einer einzelnen
Funktion Eingabewerte in Ausgabewerte überführen.
Daher liegt der Schwerpunkt der Softwaretechnik
zunehmend darin, Instrumente und Methoden zu entwickeln,
mit denen diese Systeme besser verstanden, modelliert
und implementiert werden können. Die Objektorientierung
ist ein Beispiel dafür.
Im Kontext dieser Entwicklungen kann man Agenten als
neuen Ansatz im Sinne der Softwaretechnik unter zwei
Gesichtspunkten betrachten: als Hilfsmittel für die Softwareentwicklung
und als Technologie für die Implementierung
von Softwaresystemen.
1.1 Agenten als Instrument für die
Softwareentwicklung
Die Erfahrungen seit Beginn der Softwaretechnik haben
gezeigt, dass ein Ansatz zur Entwicklung von Softwaresystemen
nicht nur auf die Aspekte der Programmierung
beschränkt sein darf, soll er umfassend für die systematische
Entwicklung von Systemen anwendbar sein. Statt dessen
müssen Hilfsmittel bereit gestellt werden, die den Softwareentwickler
bei allen Schritten des Entwicklungsprozesses
unterstützen – ausgehend von der Analyse der Problemstellung
über den Entwurf des Systems bis hin zu seiner Implementierung.
Das Konzept des Agenten ist ein solches Instrument
für die Entwicklung von komplexen Systemen mit vielfältiger
Funktionalität und verteilten, interagierenden
Elementen [11]. Mit Hilfe von Agenten können verteilte Informationen,
Funktionalität und Entscheidungsprozesse in
einem Softwarekonstrukt integriert werden. Dieser Aspekt
des Agentenbegriffes wird als agentenorientierte Softwareentwicklung
bezeichnet und im ersten Teil des Artikels
behandelt.
1.2 Agenten als Technologie für die
Implementierung
Für die Implementierung eines agentenorientierten Softwareentwurfes
in ein agentenorientiertes Softwaresystem –
als Agentensystem bezeichnet – existieren eine Reihe von
Technologien, welche die agentenorientierten Entwicklungskonzepte
direkt auf Implementierungsebene umsetzen.
Die agentenorientierten Technologien bieten dem Programmierer
eine umfassende Unterstützung für die Implementierung
einzelner Agenten, eines Agentensystems, der
Interaktion von Agenten und agenteninternen Abläufen und
Abläufen zwischen Agenten. Zu diesen Technologien zählen
agentenorientierte Programmiersprachen, Klassenbibliotheken,
Entwicklungsumgebungen, Laufzeitumgebungen,
Agentenarchitekturen. Diese Gesichtspunkte werden zusammen
mit einem Modellierungs- und Implementierungsbeispiel
aus der Automatisierungstechnik in den folgenden
zwei Teilen des Artikels vorgestellt.

5
2. Wie entwickelt man eigentlich
Software?
Ausgangspunkt einer Softwareentwicklung
ist immer eine konkrete Aufgabenstellung
in Form einer Problembeschreibung.
Ist die Aufgabenstellung
klein und überschaubar genug, so kann ein Programmierer
möglicherweise die gewünschte Funktionalität direkt in
einer bestimmten Programmiersprache implementieren.
Heutige Aufgabenstellungen sind aber häufig viel zu komplex
und umfangreich, als dass sie für eine Einzelperson
überschaubar und direkt implementierbar wären [12]. Daneben
können allgemeine Qualitätsmerkmale von Software
wie Robustheit, Änderbarkeit und Wiederverwendbarkeit
mit dieser Vorgehensweise nur sehr begrenzt gewährleistet
werden [13]. Vielmehr stellt sich die Frage: Wie muss ein realer
Sachverhalt betrachtet werden, damit sich dessen Merkmale
und die gewünschte Funktionalität am Ende im erstellten
Softwaresystem widerspiegeln? Zur Beantwortung dieser
Fragen stellt die Softwaretechnik Grundsätze, Methoden,
Konzepte und Notationen für die systematische Entwicklung
von komplexen und umfangreichen Softwaresystemen
bereit. Durch die systematische Betrachtung der Aufgabenstellung
entsteht ein Modell 2 davon (siehe Bild 1), das die
Spezifikation von Funktion, Struktur und Verhalten des Systems
beinhaltet.
Nach [15, 16] gibt es drei wesentliche Strategien bei der
Softwareentwicklung, um die Komplexität der Aufgabenstellung
zu bewältigen:
Zerlegung (Modularisierung) der Aufgabe in kleinere, überschaubare
Teilbereiche (Systemelemente), die relativ isoliert
voneinander betrachtet werden können. Damit kann
die Komplexität reduziert werden.
Abstraktion der wesentlichen Merkmale des Sachverhalts
und Unterdrückung nicht relevanter Eigenschaften.
Dadurch kann das Modell wesentlich vereinfacht werden.
Die Abstraktion ist abhängig vom Standpunkt des
Betrachters, das heißt das gegenwärtige Ziel bestimmt,
welche Merkmale von Bedeutung sind.
Strukturierung (Organisation) durch geeignete Anordnung
der Systemelemente (z. B. Hierarchisierung, Bildung
von Subsystemen) und Beschreibung der Beziehungen
zwischen den Systemelementen.
Analyse & Entwurf
Modell
Bild 1: Vorgehensweise bei der Softwareentwickung.
Implementierung
Aufgabenstellung
Softwaresystem
In der Softwaretechnik gibt es eine ganze Reihe von
unterschiedlichen Ansätzen zur Umsetzung dieser Strategien.
Die dabei zum Einsatz kommenden Entwicklungskonzepte
und -methoden unterscheiden sich in den Abstraktionsmöglichkeiten
zur Beschreibung einer Systemkomponente
[16]. Bei der Betrachtung eines Sachverhalts gibt es
sehr verschiedene mögliche Blickwinkel, je nach Denkweise
des Betrachters. Diese Tatsache soll allgemein am Beispiel
eines Autos verdeutlicht werden: Ein Kunde betrachtet das
Auto beispielsweise unter den Gesichtspunkten Geschwindigkeit
und Benzinkosten. Der Maschinenbauer betrachtet
unter anderem die Bremsen und die Bremskraftverläufe. Der
Elektroingenieur betrachtet das Auto als Netzwerk von Steuergeräten
und die Software in den Steuergeräten. Jedem
dieser Blickwinkel liegt eine andere Denkweise zu Grunde,
die unterschiedliche Merkmale des realen Sachverhalts auf
unterschiedliche Weise hervorhebt und verschiedene Herangehensweisen
bei der Betrachtung des Sachverhalts zur
Folge hat. Diese Tatsache gilt insbesondere auch für die Entwicklung
von Software. Hier sind mögliche Denkweisen
unter anderem die strukturierte Entwicklung oder die Objektorientierung.
In der Softwaretechnik werden solche Denkmuster, die
dem jeweiligen Blickwinkel und der Herangehensweise zu
Grunde liegen, als Paradigma bezeichnet. Das Paradigma
bestimmt die Art und Weise, wie ein Sachverhalt abstrahiert
wird. Zu einem Paradigma der Softwaretechnik gehören
Konzepte und Methoden. Konzepte bieten Hilfsmittel, auf
deren Basis man einen Sachverhalt analysieren, abstrahieren
und beschreiben kann, um ein Modell davon zu entwickeln
[16]. Ein Beispiel ist das Konzept der Kapselung, das benötigte
Daten mit den zugehörigen Operationen assoziiert. Methoden
beschreiben auf Basis der Konzepte eine Vorgehensweise,
mit der ein konkretes Problem am besten gelöst werden
kann.
Auf der Basis dieses Verständnisses der Softwareentwicklung
wird deutlich, dass der Begriff des Agenten nicht nur
eine Zusammenfassung von bestimmten Eigenschaften
eines Softwaresystems sein kann. Russel und Norvig [4]
haben dies bereits 1995 angemerkt:„The notion of an agent
is meant to be a tool for analyzing systems, not an absolute
characterization that divides the world into agents and nonagents.“
Agenten sind also eine bestimmte Denk- und
Herangehensweise bei der Entwicklung von Software. Man
spricht vom Paradigma der agentenorientierten Softwareentwicklung.
2
Ein Modell ist eine idealisierte, vereinfachte [. .] Darstellung eines Gegenstands,
Systems oder sonstigen Weltausschnitts [14].
3. Wie entwickelt man Software
agentenorientiert?
Gegenstand der agentenorientierten Softwareentwicklung
sind Konzepte, Methoden, Vorgehensweisen und Werkzeuge
für die Erstellung von agentenorientierter Software. Darunter
versteht man Software, deren Struktur und Funktionalität
unter dem Blickwinkel einer Menge von Agenten betrachtet
wird [17]. Dabei wird das Verhalten eines Softwaresystems
durch das Zusammenwirken komplex interagierender, autonomer
Softwareeinheiten beschrieben. Die im vorhergehenden
Abschnitt beschriebenen allgemeinen Strategien bei
der Softwareentwicklung werden bei der agentenorientierten
Softwareentwicklung wie folgt umgesetzt: Die Zerlegung

6
eines Problems erfolgt in autonome Agenten als elementare
Einheiten und die Abstraktion basiert auf agentenorientierten
Konzepten. Bemerkenswert ist, dass die Strukturierung
des Systems nicht explizit im Detail vorgegeben wird, sondern
lediglich ein struktureller „Rahmen“ in Form von Organisationsmodellen
festgelegt und die Art möglicher Beziehungen
durch Interaktionsmodelle bestimmt wird. Damit
wird eine dynamische Bildung von Strukturen zur Laufzeit
ermöglicht.
Um das Paradigma der agentenorientierten Softwareentwicklung
genauer zu beschreiben und zu verstehen, sollen
im Folgenden drei elementare Fragen beantwortet werden:
Konzepte: Welche grundlegenden Konzepte stellt die
agentenorientierte Denkweise für die Abstraktion eines
realen Sachverhalts bereit? Diese Konzepte werden in
Abschnitt 3.1 erläutert.
Methoden: Wie sieht die systematische Vorgehensweise
zur Anwendung der agentenorientierten Konzepte bei
der Softwareentwicklung aus? Die Merkmale und Vorgehensweisen
von agentenorientierten Methoden werden
in Abschnitt 4 vorgestellt.
Problembereich: Für welche grundsätzlichen Probleme ist
die agentenorientierte Denkweise geeignet? Dieser
Punkt wird in Abschnitt 5 ausgeführt, sowie die Vor- und
Nachteile der Agentenorientierung diskutiert.
3.1 Agentenorientierte Konzepte
Zur Vorstellung des Ansatzes der agentenorientierten Softwareentwicklung
werden zunächst die Konzepte erläutert,
auf denen der Ansatz basiert. Dazu gehört zuerst das Konzept
des Agenten selbst als zentrales Abstraktionsmittel bei
der agentenorientierten Betrachtung eines Sachverhalts. Die
folgende Definition ist angelehnt an die allgemein anerkannten
und verwendeten Definitionen aus [2, 7, 18, 19] (für
eine vergleichbare Definition in deutscher Sprache siehe
[17]):
In der agentenorientierten Softwareentwicklung ist das Konzept
des Agenten eine abgrenzbare Softwareeinheit mit einem
definierten Ziel. Ein Agent versucht, dieses Ziel durch autonomes
Verhalten zu erreichen und interagiert dabei kontinuierlich
mit seiner Umgebung und anderen Agenten.
In dieser Definition sind die folgenden Grundkonzepte der
Agentenorientierung enthalten (Bild 2):
Kapselung: Zustand und Verhalten sind in einer Einheit,
dem Agenten, zusammengefasst.
Zielorientierung: Ein Agent orientiert sein Verhalten an
einem bestimmten Ziel, das er zu erreichen versucht. Ziele
können entweder vom Entwickler vorgegeben sein (z. B.
den eigenen Zustand dauernd zu optimieren) oder zur
Ausführungszeit von einem Benutzer in Form eines Auftrages
übertragen werden.
Reaktivität: Reaktivität (Reaktionsfähigkeit) ist die Fähigkeit,
die Umwelt wahrzunehmen und darauf angemessen
zu reagieren.
Autonomie: Autonomie bedeutet die Kontrolle über den
internen Zustand und das Verhalten. Das heißt zum
einen, dass das Verhalten, mit dem ein Agent auf externe
Stimuli reagiert, im Wesentlichen durch den Agenten
Autonomie
Interaktion
Kapselung
Agent
Persistenz
Bild 2: Die Grundkonzepte der Agentenorientierung.
Zielorientierung
Reaktivität,
Proaktivität
selbst bestimmt wird und nicht von „außerhalb“ festlegbar
ist. Zum anderen ist Autonomie die Voraussetzung
für Proaktivität.
Proaktivität: Proaktivität bedeutet die Fähigkeit, ohne
direkten Einfluss von außen, zielgerichtet und vorausschauend
zu handeln (Eigeninitiative). Voraussetzung für
Proaktivität ist die Existenz von Zielen (siehe Zielorientierung).
Interaktion: Agenten treten untereinander auf hohem
Niveau in Wechselwirkung (z. B. Verhandlungen). Die Basis
für die Interaktionen zwischen Agenten ist ein zu Grunde
liegender organisatorischer Kontext [7]. Agenten interagieren
miteinander, um individuelle Ziele zu erreichen
oder um Abhängigkeiten untereinander zu handhaben.
Persistenz: Ein Agent verfügt über einen fortlaufenden
Kontrollfluss, der unabhängig ist von externer Aktivierung
– also die Fähigkeit, seinen inneren Zustand während seines
Lebenszyklus beizubehalten.
Die Grundkonzepte der Agentenorientierung können je
nach Ziel der Softwareentwicklung unterschiedlich stark
ausgeprägt sein, so dass die Agentenartigkeit (engl. Agency)
einer Softwareeinheit nicht zwingend vom Auftreten einer
einzelnen Eigenschaft abhängig ist. Beispielsweise kann
Aktivität im einfachsten Fall die simple Reaktion auf
bestimmte Wahrnehmungen (Eingangssignale) oder – stärker
ausgeprägt – die selbstständige Abarbeitung von Aufgaben
bis hin zur autonomen Anpassung vorgegebener Ziele
bedeuten. Neben diesen Grundkonzepten gibt es noch weitere
Konzepte, um spezifische Anforderungen aus einem
bestimmten Anwendungsbereich zu erfüllen. Dazu gehören:
Mobilität: Mobilität ist die Fähigkeit zur Migration von
einem Ort (Ausführungskontext) zu einem anderen –
sowohl räumlich zwischen Plattformen als auch logisch
zwischen Systemen. Sie ist dann erforderlich, wenn der
Agent eine Aufgabe nur sinnvoll an einem bestimmten
Ort lösen kann oder wenn zur Lastverteilung in einem
Netzwerk die Verlagerung eines laufenden Prozesses von
einem Rechner auf einen anderen erforderlich ist. Das
Konzept der Mobilität entstand weitgehend unabhängig,
so dass bei mobilen Agenten andere agentenorientierte
Grundkonzepte häufig schwächer ausgeprägt sind [20].
Problemlösendes Verhalten (Anpassungsfähigkeit) und
Intelligenz (Lernfähigkeit): Unter problemlösendem Verhalten
versteht man die Fähigkeit eines Agenten, sein Verhalten
aufgrund von Erfahrungen anzupassen. Ist er darüber
hinaus in der Lage, ein internes Modell seiner Umwelt auf-

7
zubauen, zu verfeinern und zu verbessern, spricht man
von Lernfähigkeit bzw. Intelligenz. Intelligente Agenten
für verteiltes Planen und Schlussfolgern sind ein wichtiger
Forschungsbereich auf dem Gebiet der künstlichen Intelligenz.
Die dabei zu Grunde liegenden Theorien und Modelle,
wie z. B. Wissensrepräsentation, mentale Zustände
und Planungsalgorithmen, gehen jedoch über den Fokus
dieses Artikels hinaus und werden im Folgenden nicht
weiter betrachtet.
3.2 Agenten im Vergleich zu Objekten und
Komponenten
Die Verwandtschaft zwischen Agenten und Objekten wird
stets intensiv diskutiert. Obwohl es offensichtliche Ähnlichkeiten
zwischen der Objekt- und der Agentenorientierung
gibt, sind Agenten dennoch keine Objekte. Dies wird besonders
deutlich am Konzept der Autonomie. Obwohl Objekte
ihre Identität („wer“), ihren Zustand („was“) und ihr vorgegebenes,
passives Verhalten („wie, wenn aufgerufen“) kapseln,
so haben sie dennoch keine Kontrolle über ihr Verhalten.
Eine öffentliche Methode eines Objekts kann zu jeder Zeit
aufgerufen werden und die festgelegten Aktionen werden
stets ausgeführt. Agenten kapseln dagegen zusätzliche Freiheitsgrade
in ihrer Aktionswahl und Interaktion („wann“,„mit
wem“ und „ob überhaupt“) [21]. Sie besitzen somit die Autonomie,
eine geforderte Leistung entsprechend ihrer aktuellen
Situation zu erbringen. Bei der Interaktion zwischen
Agenten handelt es sich also vielmehr um die Anfrage eines
Dienstes als um den Aufruf einer Methode. Daneben können
Agenten auch von sich aus aktiv werden. Im übertragenen
Sinn ist ein Objekt vergleichbar mit einem Auto, ein Agent
eher mit einem Taxi. Das Auto kann entweder den Fahrwunsch
des Fahrers erfüllen oder es ist defekt. Ein Taxi ist
nicht immer verfügbar, gegebenenfalls muss der Fahrgast
auf das Taxi warten oder ein anderes Taxi nehmen. Darüber
hinaus nimmt ein Taxi nicht immer den Weg, den der Fahrgast
sich wünscht, sondern meist bestimmt der Taxifahrer
den Weg (manchmal ist er sogar wirklich eine Abkürzung).
Wichtig ist, dass es bei diesem Vergleich zwischen Agenten
und Objekten nicht um die Frage
geht, ob autonomes Verhalten mit
objektorientierten Programmiersprachen
implementiert werden kann. Entscheidend
ist, dass in der Objektorientierung
das Konzept der flexiblen Kontrolle
eines Objekts über den Aufruf
einer seiner Methoden nicht existiert.
Komponenten weisen eine stärkere
Kapselung, standardisierte Schnittstel-
3 Eine Methode besteht aus (methodenspezifischen)
Konzepten, Notation und methodischer
Vorgehensweise [16].
len, eine größere Granularität und
damit eine bessere Wiederverwendbarkeit
als Objekte auf. In diesen Punkten
sind Agenten mit Komponenten
vergleichbar, integrieren jedoch zusätzlich
Autonomie, Zielorientierung und Proaktivität. Darüber
hinaus werden bei der komponentenbasierten Softwareentwicklung
die Beziehungen zwischen den Systemelementen
im Allgemeinen im Entwurf fest vorgegeben, während dies
bei der agentenorientierten Softwareentwicklung nicht der
Fall ist. Somit weisen Agenten im Vergleich zu Komponenten
mehr Aktivität und Flexibilität auf.
4. Agentenorientierte Methoden
Die Aufgabe einer agentenorientierten Methode3 ist es, alle
Phasen der Softwareentwicklung für ein agentenorientiertes
System zu unterstützen, ausgehend von der agentenorientierten
Analyse der Problemstellung über den Entwurf bis
hin zur Implementierung. Obwohl seit eineinhalb Jahrzehnten
umfangreiche Arbeiten im Bereich der Theorie von
Agenten, Architekturen, Kommunikationsmechanismen usw.
durchgeführt wurden, gab es weitaus weniger Entwicklung
im Bereich der Spezifikation und Anwendung von Methoden
zur agentenorientierten Entwicklung von Systemen. Das
Fehlen einer umfassend evaluierten Methode einerseits und
der Unterstützung durch industriell einsetzbare CASE-Werkzeuge
andererseits waren nach Ansicht vieler Autoren die
hauptsächlichen Hemmnisse für den umfassenden Einsatz
agentenorientierter Softwareentwicklung. In den letzten
Jahren ist – aufgrund dieser Erkenntnis – die Entwicklung
von Methoden, die speziell die Agentensicht unterstützen,
immer mehr in den Mittelpunkt der Forschungstätigkeit
gerückt. Inzwischen stehen eine Reihe von Entwicklungsmethoden
zur Verfügung, die im Folgenden genauer betrachtet
werden sollen.
Nach [21] lassen sich die verfügbaren Entwicklungsmethoden
nach ihren Ansätzen in drei Gruppen unterteilen:
Erweiterungen von objektorientierten Methoden, Erweiterungen
von Methoden aus dem Knowledge Engineering
und Methoden, die auf eine rein agentenspezifische Sicht
ausgelegt sind. Die Vor- und Nachteile der unterschiedlichen
Ansätze werden in [22] diskutiert und sind in Tabelle 1
zusammengefasst.
Tabelle 1: Bewertung der Ansätze für agentenorientierte Methoden.
Ansatz Vorteile Nachteile
Erweiterungen • Konzeptionelle Gemeinsamkeiten • Spezifische Agentensichtweise
objektorientierter zwischen OO und AO muss integriert werden
Methoden (z. B. Kapselung) (z. B. Autonomie, Ziele,
• Einfachere Erlernbarkeit
organisatorische Aspekte)
• Vorhandensein einer statischen • Agenteninteraktion findet
und einer dynamischen Modellsicht auf höherer Abstraktionsebene
als Methodenaufruf statt
Erweiterungen von • Mittel zur Modellierung • Betrachtung als zentralisiertes,
Knowledge kognitiver Fähigkeiten von wissensbasiertes System
Engineering (intelligenten) Agenten • Keine Betrachtung der Aspekte
Methoden • Mittel zur Modellierung der Verteilung, Organisation,
Wissensbasis von (intelligenten) Interaktion und Zielorientierung
Agenten
Agentenspezifische • Schwerpunkt auf Agentenkonzepte • Hoher Einführungsaufwand
Methoden und organisatorische Aspekte • Geringe Werkzeugunterstützung
• Erfahrungen aus der Entwicklung • (Noch) keine Standardisierung
realer Agentensysteme

8
Analyse
Damit die Agentenorientierung sich als eigenständiges
Paradigma der Softwareentwicklung etablieren kann, sind
Entwicklungsmethoden erforderlich, die speziell auf die
agentenorientierten Konzepte angepasst sind [8]. Dabei
stellt sich die Frage, wie eine Problemstellung betrachtet
werden muss, um Konzepte wie Autonomie, Zielorientierung
und Proaktivität integrieren zu können. Um dies zu erreichen,
muss der Schwerpunkt einer agentenorientierten
Methode auf den Prozessen und Abläufen liegen, die zwischen
Agenten stattfinden [17]. Hierfür sind zusätzliche Analyse-
und Entwurfskonzepte zur praktischen Unterstützung
des Entwicklers erforderlich. Sie helfen dabei, eine Problemstellung
so zu abstrahieren, dass ein Modell erstellt werden
kann, das die agentenorientierten Grundkonzepte widerspiegelt.
Agentenspezifische Methoden verwenden hierzu
u. a. die Rollenanalyse, Use Cases und Zielanalyse. Die Rollenanalyse
ist hierbei eine der wichtigsten Vorgehensweisen.
Rollen leiten sich aus den Verantwortlichkeiten und Aufgaben
ab, die eine Einheit innerhalb eines Systems übernimmt
[23]. Die Identifikation von Agenten erfolgt dann über die
Zusammenfassung mehrerer Rollen. Beispielsweise könnte
in einem E-Businesssystem ein Agent sowohl die Rolle „Käufer“
als auch „Anbieter“ wahrnehmen. Durch die aufgabenbetonte
Sicht der Rollenanalyse werden bei der Abstraktion
des realen Sachverhalts wieder mehr die „funktionalen“
Aspekte eines Systems berücksichtigt als dies beispielsweise
in der Objektorientierung der Fall ist (durch den erkennbaren
Bruch zwischen Use Cases und Klassenidentifikation).
Neben den unterschiedlichen Ansätzen für Analyse und
Entwurf unterscheiden sich verfügbare Methoden auch in
der Unterstützung der verschiedenen Phasen im Entwicklungsprozess.
In Bild 3 sind die vier Methoden PASSI, MaSE,
Gaia und Agent-UML eingeordnet (siehe auch [24]). Die
genannten Methoden werden im Rahmen dieses und des
zweiten Teils des Artikels noch genauer betrachtet.
Im Folgenden werden drei Methoden exemplarisch vorgestellt,
welche die agentenorientierte Sichtweise in den
Mittelpunkt stellen und die unserer Einschätzung nach gut
verständlich und praktisch anwendbar sind. Alle drei Methoden
werden gegenwärtig am Institut für Automatisierungsund
Softwaretechnik eingesetzt und erprobt.
4.1 Gaia
Gaia
Grobentwurf
Ma SE
PASS I
Agent-UML
Feinentwurf
Implementierung
Bild 3: Abdeckung des Entwicklungsprozesses durch verschiedene
agentenorientierte Methoden.
Die Gaia-Methode [8] wurde von Wooldridge, Jennings und
Kinny auf Basis ihrer langjährigen Erfahrungen bei der Entwicklung
von Agentensystemen konzipiert. Gaia basiert auf
der Abstraktion eines Agentensystems als ein organisatorisches
Modell, bestehend aus verschiedenen interagierenden
Rollen.
Im Analyseprozess werden zunächst die einzelnen Rollen
im System identifiziert und die Interaktionen zwischen diesen
Rollen spezifiziert. Die Beschreibung einer Rolle enthält
die Aufgabe der Rolle, ihre Rechte, Aktivitäten und verwendete
Protokolle. In der Spezifikation der Aufgabe einer Rolle
werden die möglichen Reihenfolgen und Zusammenhänge
aller Aktivitäten sowie einzuhaltende Sicherheitsbestimmungen
in Form von regulären Ausdrücken formal festgelegt.
Aktivitäten sind interne Abläufe einer Rolle. Protokolle
sind Interaktionsmechanismen, mit denen die Abhängigkeiten
und Beziehungen zwischen verschiedenen Rollen
beschrieben werden. In der Entwurfsphase werden Rollen zu
Agententypen zusammengefasst. Weiter werden die möglichen
Kommunikationspfade zwischen Agententypen und
alle Dienste, die mit jeder Rolle eines Agententyps zusammenhängen,
festgelegt. Als Endergebnis liegt ein Systementwurf
vor, der allerdings für eine Implementierung nicht ausreicht
und noch mit anderen Methoden weiter verfeinert
werden muss [25].
Gaia ist leicht verständlich und daher gut für einen Einstieg
in die agentenorientierte Softwareentwicklung geeignet.
Eine Einschränkung von Gaia ist, dass die Beziehungen
zwischen Agententypen festgelegt sind und sich nicht dynamisch
verändern können.
4.2 MaSE – Multiagent Systems Engineering
Die MaSE-Methode [26, 27, 28] besteht aus sechs Analyseund
Entwurfsphasen, die eng miteinander verzahnt sind und
den gesamten Entwicklungszyklus abdecken.
In der ersten Phase, der Zielerfassung, wird die Anforderungsbeschreibung
in detaillierte Systemziele überführt. Die
Systemziele werden nach Wichtigkeit strukturiert und in
einem Zielhierarchiediagramm dargestellt (Bild 4 links).
Dann werden die Ziele in Rollen übertragen. Dabei können
Ziele mit hoher Kohäsion in einer Rolle zusammengefasst
werden, oder ein Ziel auf mehrere Rollen aufgeteilt werden.
Im zweiten Schritt werden Use Cases und Sequenzdiagramme
verwendet, um die Interaktion der verschiedenen
Rollen bei den einzelnen Anwendungsfällen des Systems zu
ermitteln. In der dritten Phase werden aus den Ergebnissen
der Phasen eins und zwei alle Rollen ermittelt, verfeinert und
gefestigt. Damit ist eine systematische Vorgehensweise zur
Identifikation aller Rollen innerhalb des Systems gewährleistet.
Ein Rollenmodell ist in Bild 4 rechts dargestellt: einzelnen
Rollen (in Rechtecken) wurden die Ziele (durch Nummern)
aus dem Zielhierarchiediagramm zugeordnet. Ovale stellen
die Aufgaben einer Rolle dar und Pfeile weisen auf verwendete
Kommunikationsprotokolle hin.
In Phase vier werden Agententypen auf Basis von zusammenhängenden
Rollen sowie die Kommunikationsbeziehungen
zwischen den Agententypen ermittelt. In Phase fünf
werden die Kommunikationsprotokolle auf Basis von
Zustandsdiagrammen spezifiziert. Daneben wird die Architektur
der einzelnen Agententypen erstellt. In der letzten
Phase werden in einem Verteilungsdiagramm die Anzahl, die

9
1. Überwache Pumpsystem
und informiere Personal
GrenzwertWächter
1.1.1
Temp.Melder
1.1
1.1 Überwache
Temperatur und
melde Ereignisse
1.2 Überwache
Druck und
melde Ereignisse
Ermittle
Temperatur
Prüfe
Bereich Grenzwertüberschreitung
Melde
Ereignis
Bild 4: MaSE Zielhierarchiediagramm
(links) und Rollenmodell
(rechts).
1.1.1
Überwache
Grenzwerte
1.1.2
Überwache
Schwankung
1.1.3
Informiere
Personal
…
Personal
Zeige An
Ereignismelder
1.1.3
Informiere
Personal
Ereignismeldung
Klassen und die Ausführungsorte der Agenten dargestellt.
Als Endergebnis liegt ein detaillierter Systementwurf vor, der
direkt implementiert werden kann.
MaSE weist eine systematischere Vorgehensweise und
detailliertere Modellierung als Gaia auf. Die meisten Modelle,
die in den einzelnen Phasen erstellt werden, sind dabei an
die UML angelehnt. Allerdings steht durch die Ziel- und Rollenanalyse
die Agentensicht stark im Vordergrund. Daher erscheint
MaSE gut für den Einsatz in der Praxis geeignet, auch
weil die Methode durch das Werkzeug agentTool unterstützt
wird, das momentan allerdings nur als Prototyp verfügbar ist
(weitere Informationen unter [29]). Die Einschränkungen bei
MaSE sind ähnlich den Einschränkungen bei Gaia.
4.3 PASSI – Process for Agent Societies
Specification and Implementation
Die PASSI-Methode [30] wurde in den letzten Jahren an der
Universität Palermo entwickelt. Die Methode besteht aus
fünf Entwicklungsphasen mit den jeweiligen Modellen und
unterstützt eine iterative Vorgehensweise.
Bei PASSI handelt es sich ebenfalls um eine umfassende
und detailliert ausgearbeitete Methode, die den gesamten
Softwareentwicklungszyklus bis hin zur Implementierung
abdeckt. Die Notation der einzelnen Modelle basiert auf der
UML Notation, wobei die Modellelemente teilweise eine
andere Bedeutung erhalten. Dies hat den großen Vorteil,
dass für die PASSI-Methode ein Plugin für das UML Modellierungswerkzeug
Rational Rose existiert (unter [31]), mit dem
die verschiedenen Modelle und die Codegenerierung weitreichend
unterstützt werden.
Die Identifikation von Agenten erfolgt bei der PASSI
Methode nicht wie bei Gaia und MaSE über eine Rollenanalyse,
sondern durch Analyse der Systemfunktionalität mit
Hilfe von Use Cases und Gruppierung in einzelne Agenten
(Bild 5). Es ist noch zu evaluieren, ob dadurch agentenorientierte
Aspekte ausreichend unterstützt werden können.
Auch bei PASSI ist die Flexibilität der Beziehungen zwischen
Agenten eingeschränkt.
Generell ist bei den vorgestellten Methoden erkennbar,
dass sie die agentenorientierten Grundkonzepte zur Erstellung
flexibler, anpassungsfähiger Systeme noch nicht in vollem
Umfang ausschöpfen. Hier besteht sicherlich noch Forschungsbedarf.
Es muss weiter untersucht werden, welche
Betrachtungs- und Vorgehensweisen bei der ingenieurmäßigen
Softwareentwicklung tatsächlich agentenorientierte
Konzepte wie Autonomie geeignet abbilden können. Insbesondere
die Methoden MaSE und PASSI weisen jedoch
bereits eine gute Unterstützung des Softwareingenieurs auf,
so dass ein Praxiseinsatz durchaus möglich ist.
Eine kommentierte Literaturübersicht über weitere aktuelle
Methoden der agentenorientierten Softwareentwicklung
findet sich in [21].
5. Für welche Probleme ist agentenorientierte
Softwareentwicklung geeignet?
Bei der agentenorientierten Softwareentwicklung wird eine
Aufgabenstellung in autonome Agenten zerlegt, die flexibel
miteinander interagieren können. Diese Denkweise ist für
bestimmte Arten von Problemstellungen besonders geeignet
und sie bringt Vorteile, aber auch Nachteile mit sich. In
diesem Abschnitt soll verdeutlicht werden, wann die Agentenorientierung
allgemein nützlich ist und welche Eigenschaften
einer Problemstellung auf eine sinnvolle agentenorientierte
Lösung hinweisen.
Im Allgemeinen sind Agenten am besten geeignet für
Anwendungen, die modular, dezentral, veränderbar, unzureichend
strukturiert und komplex sind [3]. Im Folgenden werden
Kategorien von Systemen vorgestellt, denen diese
Eigenschaften zugeordnet werden können. Eine reale
Bild 5: Gruppierung
von Use Cases zu
Agenten bei der
PASSI-Methode.
HW-Schnittstelle
Transportband
Sensoren abfragen Aktoren ansteuern Werkstück transportieren

10
Anwendung kann in eine oder mehrere
dieser Kategorien fallen.
5.1 Kategorien von
Anwendungsbereichen
Konventionell:
Änderungen an einem
Systemelement haben
Auswirkungen auf das
Gesamtsystem
Ausführungssequenz
Agentenorientiert:
Unabhängigeres
Hinzufügen, Entfernen
und Ändern von
Systemelementen
5.1.1 Dezentrale, verteilte Systeme
Dezentrale Systeme sind Systeme, die
eine natürliche logische Verteilung aufweisen.
Unter logischer Verteilung sind dabei Anwendungen
zu verstehen, die in abgrenzbare „Prozesse“ aufteilbar sind,
die jeweils unterschiedliche Aufgaben erfüllen. Dies fällt in
vielen Fällen zusammen mit einer physikalischen Verteilung.
Zentrale Ansätze für derartige Systeme bergen die Gefahr zu
hoher Komplexität und geringer Flexibilität, Robustheit und
Änderbarkeit. Dezentrale Systeme weisen zudem meist die
Eigenschaft der Modularität auf. Das heißt sie bestehen aus
natürlich abgrenzbaren Teilen, die einen eigenen unabhängigen
Zustand aufweisen. Beispiel hierfür sind industrielle
Anwendungen im Allgemeinen, da sie häufig von Natur aus
aus einzelnen physikalischen Einheiten (Geräten oder Systemteilen)
bestehen.
Bild 6: Größere Änderbarkeit und Wartbarkeit eines Agentensystems [3].
Unter komplexen Systemen sind Systeme im Sinne von komplexen,
variierenden Abläufen oder eines komplexen
Gesamtverhaltens zu verstehen. Dabei wird als Maßstab für
Komplexität die Anzahl von unterschiedlichen Verhaltensweisen
genommen, die ein System beherrschen muss. Nach
[3] wächst die Anzahl möglicher verschiedener Interaktionen
zwischen den Elementen des Systems sehr viel schneller
als die Anzahl der Elemente. Bei einer deterministischen
Lösung wird es schnell schwierig, die Komplexität möglicher
Abläufe zur Entwurfszeit zu beherrschen. Ein agentenorientierter
Ansatz ist dann sinnvoll, wenn eine vollständige Festlegung
des Systemverhaltens als Kette von Einzelschritten
nicht praktikabel ist. Beispiele hierfür sind Roboter, Planungssysteme,
Produktions- und Fertigungsautomatisierungssysteme.
5.1.4 Kooperative Systeme
5.1.2 Strukturell veränderbare Systeme
Im Allgemeinen wird beim Softwareentwurf eine Architektur
erstellt, in der beschrieben ist, welche Elemente miteinander
interagieren und welche Schnittstellen für diese Interaktionen
verwendet werden. Dies führt dann zu Problemen, wenn
nicht alle möglichen Interaktionen und somit die erforderlichen
Beziehungen zwischen den Elementen von vorne herein
spezifizierbar sind. Agenten sind von Natur aus für solche
Systeme geeignet. Beispiele sind Handels- und Wirtschaftssysteme,
Transportsysteme, Verkehrssysteme und Automatisierungsanlagen.
Auch wenn alle verfügbaren Strukturinformationen über
das System zur Entwurfszeit vorhanden sind, sind manche
Systeme während ihres Lebenszyklus besonders starken
Änderungen unterworfen. Das bedeutet, ein ursprünglich
wohlstrukturiertes System kann sich während des Lebenszyklus
in ein unzureichend strukturiertes System verwandeln
[3]. Strukturelle Änderungen während des Lebenszyklus
haben beispielsweise ihre Ursache in einer Änderung der
Anforderungen an das System, Änderung der Randbedingungen
(z. B. eine veränderte Systemhardware), Änderung
der Systemumgebung (z. B. externe Systeme). Deshalb kann
es sinnvoll sein, auch bei ausreichender Verfügbarkeit struktureller
Informationen diese nicht explizit in der Architektur
festzulegen. Dadurch wird eine flexiblere Architektur und
somit größere Änderbarkeit und Wartbarkeit erreicht (siehe
Bild 6).
5.1.3 Komplexe Systeme
Kooperative Systeme bestehen aus dynamisch interagierenden
Elementen, zwischen denen umfangreiche, mannigfaltige
Kommunikations- und Koordinationsprozesse erforderlich
sind. Dies ist beispielsweise dann der Fall, wenn innerhalb
des Systems individuelle und konfliktträchtige Ziele,
Interessen oder Rechte vorliegen [17]. Dadurch werden
Abstimmung, Verhandlung oder Kooperation notwendig.
Beispiele hierfür sind wiederum Systeme aus dem Wirtschafts-
und Handelsbereich, Börsensysteme, Beratungsund
Informationssysteme.
5.2 Vorteile des agentenorientierten Ansatzes
Sicherlich stellt sich in diesem Zusammenhang die Frage
„Was ist das Besondere an der agentenorientierten Softwareentwicklung,
was macht sie für die genannten Anwendungsbereiche
vorteilhafter als andere Ansätze?“. Die Eignung
eines Softwareparadigmas kann für gewöhnlich nicht
quantitativ belegt werden, es gibt jedoch einige wichtige
qualitative Merkmale.
Betrachtet man die allgemeine Evolution der Denkansätze
in der Softwareentwicklung, so kann die Agentenorientierung
als ein natürlicher nächster Schritt betrachtet werden
[7, 17]. Ausgehend von der maschinennahen monolithischen
Programmentwicklung über die strukturierte und die
objektorientierte Entwicklung bis hin zur Agentenorientierung
zeigen sich zwei klare Tendenzen:
Eine zunehmende Verschiebung der konzeptionellen
Basis vom Lösungsbereich (der Rechnerarchitektur) hin
zum Problembereich [7]. Die Agentenorientierung ist eine
konsequente Fortsetzung dieser Tendenz und bietet
daher geeignete Hilfsmittel zum Verständnis einer komplexen
Aufgabenstellung.
Eine zunehmende Lokalisierung und Kapselung der elementar
notwendigen Entscheidungen zur Laufzeit der

11
Tabelle 1. Zunehmende Lokalisierung [32].
Wie verhält sich eine
(Software-) Einheit?
Monolithisches Strukturierte Objektorientierte Agentenorientierte
Programm Entwicklung Entwicklung Entwicklung
Extern Intern Intern Intern
Welchen Zustand hat eine Einheit? Extern Extern Intern Intern
Wann [und warum] läuft eine Extern Extern (Aufruf ) Extern (Nachricht) Intern (Ziele)
Einheit ab?
[Extern (Anfrage)]
Software (Tabelle 2). Agenten vervollständigen diese Entwicklung
durch Lokalisierung des „Zwecks“ einer Einheit
in Form von eigenem Kontrollfluss und der Möglichkeit,
das Verhalten selbst auszuwählen.
Die Verteilung von Entscheidungsprozessen in autonome
Softwareeinheiten entspricht häufig eher dem natürlichen
Charakter vieler Systeme und führt zu einer geringeren
Kopplung zwischen Systemelementen sowie zu einer
Reduktion „zentraler“ Komplexität. Bei lokalen Problemen
können Entscheidungen an der Stelle gefällt werden, wo die
meiste Information über ein Problem vorliegt. Daneben können
verschiedene Sichtweisen oder gegensätzliche Interessen
der Realität besser im Softwaresystem widergespiegelt
werden.
Ein entscheidender Unterschied des agentenorientierten
Ansatzes zur herkömmlichen Softwareentwicklung ist die
Tatsache, das die Gesamtheit der Systemstruktur und des
Systemsverhaltens nicht zwingend zur Entwurfszeit vollständig
spezifiziert werden muss, sondern sich zur Laufzeit auf
Basis der aktuellen Situation dynamisch bildet und Interaktionen
flexibel im Rahmen festgelegter Variationen stattfinden
können. Durch eine agentenorientierte Entwicklung
kann die Berücksichtigung der Menge möglicher Abläufe
aus der Entwurfsphase in die Laufzeit verschoben und dadurch
die Komplexität des Entwurfes reduziert werden.
Weiter wird auf Basis der abstrakten Interaktionen und
Kommunikationsprotokolle zwischen Agenten (so genannte
Wissensebene statt Methodenaufruf ) die Integration von
neuen, möglicherweise sogar vorher unbekannten Elementen
zur Laufzeit erleichtert.
Zuletzt sind Agenten Softwareeinheiten mit besonders
„starker“ Kapselung. Deshalb folgt die Agentenorientierung
in besonderem Maße dem allgemeinen Prinzip der Modularisierung
und unterstützt somit auch allgemeine Qualitätsmerkmale
von Software wie Robustheit, Skalierbarkeit,
Änderbarkeit, Erweiterbarkeit und Wiederverwendbarkeit
[7].
5.3 Nachteile des agentenorientierten Ansatzes
Die Flexibilität des Softwaresystems zur Laufzeit ist ein
bedeutender Vorteil des agentenorientierten Ansatzes.
Gleichzeitig ist dies aber auch ein inhärenter Nachteil aufgrund
der teilweisen Unvorhersagbarkeit des Verhaltens des
Gesamtsystems zur Laufzeit. Die Verteilung von Entscheidungsprozessen
in autonome Einheiten führt zu einer Variabilität
im Verhalten des Systems, die nicht a priori vorhersagbar
ist. Letztendlich wird dadurch die Komplexität des Systems
aus den Abläufen in den einzelnen Elementen heraus
in die Abläufe der Interaktion zwischen den Elementen verlagert.
Die Struktur und das Ergebnis der Interaktionen zwischen
Agenten sind nicht vollständig von vorne herein
absehbar, sondern abhängig vom Zusammenspiel zwischen
dem aktuellen internen Zustand der Agenten, ihrer aktuellen
Umgebung (bzw. der Wahrnehmung derselben) und der
aktuellen organisatorischen Struktur [7]. Die grundlegende
Erkenntnis, dass das Ganze häufig mehr als die Summe seiner
Einzelteile ist, gilt auch hier. Die bewusste Vermeidung
von Festlegungen zur Entwurfszeit hat die Konsequenz, dass
diese ad hoc zur Laufzeit getroffen werden müssen – und
dies beschränkt die Vorhersagbarkeit.
In vielen Fällen ist diese Flexibilität zur Laufzeit sicherlich
wünschenswert, beispielsweise um unvorhergesehenen
Situationen dynamisch begegnen zu können. Gerade in
technischen Systemen ist aber ein vorhersagbares Verhalten
und die Einhaltung von globalen Anforderungen häufig bis
zu einem gewissen Grad unabdingbar. Es gibt eine Reihe von
Möglichkeiten, die Variabilität des Systemverhaltens in agentenorientierten
Systemen zu beschränken und somit unerwünschten
Effekten geeignet zu begegnen. Zum einen
besteht die Möglichkeit, durch globale Beschränkungen in
Form von Agenten übergeordnete Ziele vorzugeben. Zum
anderen können mögliche Interaktionen zwischen Agenten
durch strikte Interaktionsprotokolle sowie durch die Festlegung
und Einschränkung möglicher organisatorischer Strukturen
begrenzt werden. Weiter können Interaktionsprotokolle
auch mit formalen Methoden spezifiziert werden, um
somit die Korrektheit des Systems gegenüber bestimmten
Anforderungen formal verifizieren zu können (durch Theorembeweise
oder durch Modelchecking) [33, 34].
6. Zusammenfassung
Agentenorientierte Entwicklung ist eine alternative Art der
Analyse, des Entwurfs und der Implementierung von Softwaresystemen.
Dabei wird eine Problemstellung unter den
Gesichtspunkten Autonomie, Interaktion, Zielorientierung,
Reaktivität und Proaktivität in einzelne Agenten abstrahiert,
um so z. B. verteilte Informationen, Funktionalität und Entscheidungsprozesse
beschreiben zu können. Die agentenorientierte
Softwareentwicklung stellt hierfür Konzepte,
Methoden, Vorgehensweisen und Werkzeuge zur Verfügung.
Agentenorientierte Softwareentwicklung ist insbesondere
für Systeme geeignet, die von Natur aus eine logische
Verteilung aufweisen, strukturellen Änderungen zur Laufzeit

12
unterworfen sind, komplexe Abläufe bzw. Verhalten aufweisen
oder umfangreiche Kommunikations- und Koordinationsprozesse
erfordern. Auf Basis eines agentenorientierten
Lösungsansatzes können flexible, anpassungsfähige Softwaresysteme
entwickelt werden, welche die Verteilung von
Aufgaben, Ressourcen oder Leistungen sowie verschiedene
Sichtweisen oder gegensätzliche Interessen der realen Problemstellung
im Softwaresystem widerspiegeln.
Damit wird auch deutlich, dass die Agentenorientierung
nicht prinzipiell für beliebige Arten von Problemen besser
geeignet ist als andere Ansätze der Softwareentwicklung.
Balzert hat diese Erkenntnis wie folgt zusammengefasst [16]:
„Die in der Softwaretechnik existierenden Paradigmen sind
nicht voneinander isoliert zu betrachten, sondern ergänzen
sich gegenseitig. Letztendlich muss der Ingenieur entscheiden,
welches Paradigma für welches Problem oder Teilproblem
am besten geeignet ist.“ Es handelt sich hier also nicht
um eine Frage des „Entweder-oder“, sondern vielmehr um
ein „Sowohl-als-auch“. Zum Beispiel impliziert die Agentensicht
quer über alle Phasen der Softwareentwicklung zahlreiche
neue, etwa von der Objektsicht nicht abdeckte Anforderungen
und Fragestellungen wie Koordination, Kooperation,
dynamische Organisation und verteilte Kontrolle [17]. Die
verschiedenen Perspektiven von Agenten- und Objektorientierung
decken unterschiedliche Aspekte des Softwareentwurfs
ab und können sich somit sinnvoll ergänzen.
Die Agentenorientierung muss für eine breite industrielle
Anwendbarkeit sicherlich noch weiter entwickelt werden.
Theoretische Grundlagen müssen abgegrenzt und fundiert
werden, Methoden müssen die Agentensicht noch mehr in
den Vordergrund stellen und praxistauglicher werden. Dennoch
können agentenorientierte Lösungen heute schon
einen wichtigen Beitrag zur Verbesserung der Situation in
der Automatisierungstechnik leisten, die geprägt ist durch
zunehmende Heterogenität, zu geringe Flexibilität und mangelnde
Integration.
In den folgenden Teilen 2 und 3 dieses Artikels wird die
agentenorientierte Softwareentwicklung an einem umfassenden
Beispiel veranschaulicht sowie der interne Aufbau
und die Realisierung von Agentensystemen erläutert.

13
Agentensysteme in der Automatisierungstechnik:
Modellierung eines Anwendungsbeispiels
Das Konzept von Agenten ist die Basis eines neuen Ansatzes für die Entwicklung von verteilten, komplexen
und kooperativen Anwendungen, der zunehmend den Weg aus der Theorie in die industrielle Praxis findet.
Auch in der Automatisierungstechnik können Agenten für eine Vielzahl von Anwendungen hilfreich eingesetzt
werden, z.B. in Produktionssystemen, Verkehrsleitsystemen, im Netzwerk- und Energiemanagement
und in der Prozessautomatisierung. Autonomie, Interaktion, Reaktivität, Zielorientierung, Proaktivität und
Persistenz sind die zentralen Elemente des agentenorientierten Ansatzes. Es stellt sich jedoch die Frage, wie
diese Konzepte für die praktische ingenieurmäßige Entwicklung von Software angewendet werden. Die Vorgehensweise
bei der agentenorientierten Modellierung wird im vorliegenden Beitrag anhand eines technischen
Anwendungsbeispiels demonstriert und erläutert.
Agent systems in industrial automation: Modeling of an application example
The agent concept is the basis of a new approach to the development of distributed, complex and cooperative
applications, that increasingly finds its way out of theory to the praxis. Agents can also be usefully
employed in a large number of applications in the industrial automation area, e.g. production and traffic
engineering systems, network and energy management, and process automation. Autonomy, interaction,
reactivity, goal-orientation, proactivity and persistence are the key points in the agent oriented approach.
The question can remain about how these concepts could be applied in the practical, systematic development
of software. The procedure in the agent oriented modeling is demonstrated and explained in the present
article.
1. Einführung
Die Entwicklung von Software für moderne Automatisierungssysteme
ist eine beständige Herausforderung für Ingenieure.
Heutige Automatisierungssysteme stehen häufig im
Spannungsfeld einer Reihe von Anforderungen. Dazu
gehören zunehmende Dezentralisierung und komplexere
Abläufe sowie die Notwendigkeit zu mehr Flexibilität,
Robustheit, Skalierbarkeit, Anpassbarkeit und Integrationsfähigkeit.
Zur Bewältigung dieser Anforderungen ist es notwendig,
die Struktur der Software flexibel und ohne großen Aufwand
an strukturelle Änderungen des Automatisierungssystems
anpassen zu können. Daneben besteht häufig die Schwierigkeit,
die komplexen Abläufe und Verhaltensweisen eines solchen
Systems zu beherrschen, insbesondere, wenn diese zur
Entwicklungszeit nicht vollständig vorhersagbar sind. Vielfach
muss auch die Integration des Automatisierungssystems
mit heterogenen Komponenten und externen Systemen
bewerkstelligt werden. Aus diesen Gründen wird die
Softwareentwicklung für Automatisierungssysteme immer
komplexer und aufwändiger.
Eine Alternative zu herkömmlichen Lösungen ist die
agentenorientierte Softwareentwicklung (AOSE). Dabei wird
ein System als eine Menge von autonomen Agenten
betrachtet, die selbstständig innerhalb ihres Entscheidungsrahmens
handeln und dabei vorgegebene Ziele verfolgen.
Agenten können miteinander flexibel interagieren und
durch Verhandlungen kooperieren, um ihre individuellen
Ziele zu erreichen. In der agentenorientierten Denkweise
wird eine Problemstellung unter den Gesichtspunkten Autonomie,
Interaktion, Reaktivität, Zielorientierung, Proaktivität
und Persistenz in einzelne Agenten abstrahiert, um so z.B.
verteilte Informationen, Funktionalität und Entscheidungsprozesse
beschreiben zu können. Die agentenorientierte
Softwareentwicklung stellt hierfür Konzepte, Methoden,Vorgehensweisen
und Werkzeuge zur Verfügung [1].
Die Agentenorientierung ist insbesondere für Systeme
geeignet, die von Natur aus eine logische Verteilung aufweisen,
strukturellen Änderungen zur Laufzeit unterworfen
sind, komplexe Abläufe bzw. Verhalten aufweisen oder
umfangreiche Kommunikations- und Koordinationsprozesse
erfordern. Auf Basis eines agentenorientierten Lösungsansatzes
können flexible, anpassungsfähige Softwaresysteme
entwickelt werden, welche die Verteilung von Aufgaben,
Ressourcen oder Leistungen sowie verschiedene Sichtweisen
oder gegensätzliche Interessen der realen Problemstellung
im Softwaresystem widerspiegeln [1].
Um Software agentenorientiert zu entwickeln, ist eine
grundsätzlich andere Denkweise als bei herkömmlichen
Methoden der Softwareentwicklung erforderlich. Der
Schwerpunkt liegt dabei auf Prozessen und Abläufen, die
zwischen den aktiven Elementen des Systems stattfinden. In
diesem Beitrag wird die agentenorientierte Denkweise
zunächst anhand einer Reihe von Beispielen aus der Automatisierungstechnik
verdeutlicht. Anschließend wird die
systematische Vorgehensweise bei der agentenorientierten
Analyse und dem Entwurf für ein technisches Anwendungs-

14
beispiel veranschaulicht. Das Anwendungsbeispiel zeigt, wie
die agentenorientierten Grundkonzepte Autonomie, Interaktion,
Reaktivität, Zielorientierung, Proaktivität und Persistenz
für die Modellierung einer flexiblen, anpassungsfähigen und
fehlertoleranten Lösung eingesetzt werden.
2. Anwendungsbeispiele in der
Automatisierungstechnik
Die folgenden Anwendungsbeispiele aus verschiedenen
Bereichen der Automatisierungstechnik verdeutlichen, wie
neue Lösungen auf Basis eines agentenorientierten Ansatzes
vorteilhaft zur Bewältigung der Herausforderungen in
technischen Systemen eingesetzt werden können.
2.1 Produktionssysteme
Große Produktionsanlagen werden seit langem in der Industrie
für die Fertigung der unterschiedlichsten Güter eingesetzt.
In einem zunehmend dynamischer werdenden Produktionsumfeld
gibt es bei der Entwicklung von Software
zur Automatisierung dieser Anlagen besondere Herausforderungen
[2, 3]. Heutige Produktionsanlagen sollen beispielsweise
flexibel für verschiedene Produkte oder Fertigungsprozesse
ausgelegt bzw. erweiterbar sein (Stückzahlund
Variantenflexibilität) und hohe Produktivität durch flexiblere
Nutzung und Skalierung von Kapazitäten aufweisen.
Daneben sollen sie eine hohe Verfügbarkeit durch Robustheit
gegenüber Fehlern aufweisen. Fehler in einem Teil der
Produktionsanlage sollen nicht automatisch zu einem Produktionsstillstand
führen, sondern die Anlage selbst soll
automatisch ihre Abläufe flexibel anpassen können.
Die Steuerung herkömmlicher Produktionssysteme ist
meist sehr stark planorientiert: Zuerst wird der Produktionsprozess
im Detail geplant, dann werden die einzelnen
Schritte ausgeführt [2]. Die strikte Trennung von Planung
und Ausführung führt jedoch zu Unflexibilität und Störungsanfälligkeit
im laufenden Betrieb. Beispielsweise führt ein
linearer Ablauf im Fehlerfall in einer Produktionsstation oder
bei Verzögerung eines Bearbeitungsschrittes durch lineare
Fortpflanzung dieses unerwarteten Ereignisses zu einer
geringeren Verfügbarkeit der gesamten Anlage. Ein weiterer
Nachteil liegt in der Notwendigkeit der Modifikation des globalen
Ablaufplans, sobald eine neue Produktvariante gefertigt
werden soll.
Produktionsziele
Aufteilung
Werkstück-Agent Station-Agent Transport-Agent Station-Agent
Lokale Ziele
Ausführung
Überwachung
Lokale Ziele
Ausführung
Überwachung
Lokale Ziele
Ausführung
Überwachung
Bild 1: Agentenorienterter Ansatz für Produktionssysteme.
Ein agentenorientierter Ansatz bietet hier eine dezentrale
Lösung der Ablaufplanung. Produktionsstationen, Werkstücke
und Transporteinheiten können durch Agenten
repräsentiert werden:
Produktionsstation-Agenten haben lokales Wissen über
Bearbeitungsgänge, Kapazitäten und Auslastungsgrad
ihrer Station, steuern und überwachen diese autonom. Ihr
Ziel ist ein hoher Auslastungsgrad.
Ein Werkstück-Agent kennt alle notwendigen Bearbeitungsschritte
des Werkstücks im Rahmen des Fertigungsprozesses
und ihre möglichen Reihenfolgen. Ein Ziel des
Werkstück-Agenten ist es, alle Bearbeitungsschritte möglichst
schnell abzuschließen.
Die Agenten der Transporteinheiten bieten Wege zwischen
den Produktionsstationen an und kennen ebenfalls
ihren Auslastungsgrad.
Das Gesamtverhalten des Systems ergibt sich dann durch
das dynamische Zusammenspiel der einzelnen Agenten, die
sich über Ausschreibungen und Verhandlungen (Bild 1)
abstimmen. Damit ist das System in der Lage, sich entsprechend
der einlaufenden Werkstücke, dem Auslastungsgrad
und Fehlerzustand der Anlage selbst zu organisieren. Tritt
beispielsweise eine Verzögerung bei einem Bearbeitungsschritt
auf und ein Synchronisierungspunkt kann nicht mehr
erreicht werden, können alle von diesem Synchronisierungspunkt
abhängigen Agenten informiert werden und ihre
Abläufe neu koordinieren.
Die Vorteile der Flexibilität einer agentenorientierten
Steuerung können allerdings erst dann voll ausgeschöpft
werden, wenn Entscheidungsalternativen in der realen
Anlage existieren. Alternativen bestehen dort, wo Ressourcen
(Produktionsstationen) mit überlappenden Fähigkeiten
oder parallele Transportwege für Werkstücke vorhanden
sind [2].
Ansätze und Projekte zu agentenorientierten Produktionssystemen
werden in [4, 5, 6] präsentiert. Ein Beispiel für
die erfolgreiche industrielle Realisierung wird in [3] vorgestellt.
2.2 Energiemanagement
Wichtige Kriterien des Kunden beim Kauf eines Automobils
sind Komfort und Sicherheit. Durch die Einführung elektronischer
Systeme und deren Vernetzung (z.B. mit Feldbussystemen
wie CAN) konnten bestehende Funktionen wesentlich
verbessert und neue Funktionen realisiert werden. Beispiele
hierfür sind Kommunikations- und
Telematikfunktionen, passive Sicherheitssysteme
sowie Komfortsitze.
Die zukünftige Integration von
sicherheitsrelevanten elektronischen
Systemen (z.B. Brake-by-Wire) in Fahrzeugen
erfordert eine zuverlässige
Lokale Ziele
Ausführung
Überwachung
elektrische Energieversorgung dieser
Systeme. Dafür ist ein Energiemanagement
erforderlich, welches die elektrischen
Funktionen im Fahrzeug verwaltet
und gegebenenfalls nicht sicher-

15
heitsrelevante Funktionen deaktivieren kann. Es muss zu
jeder Zeit sicherstellen, dass im Idealfall alle, aber vor allem
die sicherheitsrelevanten Systeme im Fahrzeug mit Strom
versorgt werden können. Gleichzeitig soll der Akkumulator
geladen werden, so dass die Wiederstartfähigkeit nach dem
Abstellen des Fahrzeuges gewährleistet ist.
Herkömmliche Energiemanagementsysteme basieren auf
einem zentral organisierten Bordnetzsteuergerät, welches
den Zustand des Generators und des Akkumulators erfasst
und anhand dieser Informationen je nach Auslastung Verbraucher
ab- oder zuschaltet. Das Bordnetzsteuergerät ist
dabei die zentrale Komponente – in ihm laufen die Informationen
über die vorhandene Energie und die Zustände aller
Verbraucher zusammen. Auf der Basis dieser Informationen
werden Verbraucher gemäß einer statischen Prioritätenliste,
in der alle Verbraucher eingeordnet sind, zu- oder abgeschaltet
[7]. Diese zentrale Entscheidungsfindung bringt
eine Reihe von Nachteilen mit sich. Der schwerwiegendste
ist, dass das Bordnetzsteuergerät einen Single Point of Failure
bildet. Es muss deswegen redundant ausgelegt werden,
was mit sehr hohem technischen und finanziellen Aufwand
verbunden ist.
Im Gegensatz dazu bietet ein agentenorientierter Ansatz
eine Lösung mit dezentraler Entscheidungsfindung. Dabei
wird zusätzlich zum Bordnetzsteuergerät jedes Verbrauchersteuergerät
durch einen autonomen Agenten vertreten. Das
Bordnetzsteuergerät stellt in diesem Falle zwar noch die
aktuellen Informationen über den Zustand der Energieversorgung
bereit, die Entscheidungen über die Aktivierung
und Deaktivierung von Verbrauchern werden jedoch nicht
mehr zentral und statisch gefällt, sondern sind das dynamische
Ergebnis von Verhandlungen zwischen den verteilten
Agenten. Das elektrische Engergiebordnetz wird dadurch
zum virtuellen Markt, auf dem Energiekontigente verhandelt
werden. Im Fall eines Ausfalles des Bordnetzsteuergerätes
können die Agenten der Verbraucher mit Hilfe der noch vorhandenen
Informationen und einer geeigneten Notlaufstrategie
die Verfügbarkeit der elektrischen Energie für sicherheitsrelevante
Funktionen gewährleisten. Damit kann ein
Energiemanagement realisiert werden, das ohne die Notwendigkeit
einer redundanten zentralen Entscheidungseinheit
die erforderliche hohe Sicherheit der Energieversorgung
bei gleichzeitiger großer Flexibilität gewährleistet [8].
Zusätzlich wird eine bessere Skalierbarkeit des Systems für
unterschiedliche Verbraucheranzahl und somit eine einfache
Anpassung an die verschiedenen Ausführungsvarianten
eines Fahrzeugs ermöglicht.
2.3 Logistik
In der Logistik sind häufig Aufgaben zu bewältigen, bei
denen die Koordination gegensätzlicher Interessen oder verteilter
Ressourcen erforderlich ist. Eine agentenorientierte
Lösung ist hier sehr nahe liegend. Ein Beispiel ist der Personal
Travel Assistant (PTA), der im Rahmen des Projekts MOTIV
entwickelt wurde. Mit dem PTA können mehrere Reisende,
Transportmedien und Verkehrsformationen koordiniert werden.
So besteht nicht nur die Möglichkeit, die optimale Reiseroute
zu ermitteln, sondern diese auch dynamisch, z.B. an
die aktuelle Verkehrssituation anzupassen. In einem weiteren
Projekt wurde ein Agentensystem für die Koordination
und Führung mobiler Teams entwickelt, wie etwa Wartungsteams
von Telekommunikationsunternehmen oder mobile
Service-Teams des ADAC [9].
Im Rahmen des DFG Schwerpunktprogramms „Intelligente
Softwareagenten und betriebswirtschaftliche Anwendungsszenarien“
werden eine Reihe von Themen aus der
Logistik bearbeitet, insbesondere für die Organisation und
Terminplanung in Krankenhäusern sowie für das Supply
Chain Management.
2.4 Anlagenautomatisierungssysteme
Automatisierungssysteme für den Einsatz in industriellen
Anlagen sind komplexe, umfangreiche und langlebige Hardware-/Software-Systeme,
deren Eigenschaften stark durch
die zu steuernden technischen Prozesse gekennzeichnet
sind. Die Softwarestrukturen in heutigen industriellen Automatisierungssystemen
sind historisch gewachsen und zeichnen
sich durch statische hierarchische Strukturen mit klar
getrennten Aufgaben, Automatisierungsfunktionen und
Informationsstrukturen aus – die so genannte Automatisierungspyramide.
Heutzutage stehen Anlagenautomatisierungssysteme
jedoch neuen Herausforderungen gegenüber.
Die gewünschte Funktionalität, Flexibilität und Verfügbarkeit
der Systeme sowie die Notwendigkeit zur nahtlosen Integration
mit anderen Unternehmensanwendungen (z.B. Warenwirtschaftssysteme)
nimmt beständig zu. Daraus resultieren
neben zunehmenden Kommunikationsanforderungen an
das Automatisierungssystem auch ein zunehmender Aufwand
beim Engineering und Life-Cycle Management des
Automatisierungssystems.
Auch wenn dies nicht auf den ersten Blick offensichtlich
erscheint, können agentenorientierte Lösungen durch ihre
Flexibilität in Interaktion und Organisation einen ganz
erheblichen Beitrag zur Verbesserung der Situation in der
Anlagenautomatisierung leisten. Die grundsätzlichen Möglichkeiten,
Basisideen und Vorteile der Integration von Agenten
in bestehende Automatisierungsstrukturen werden in
[10] und [11] diskutiert. Agenten bieten neue Lösungswege
für effizientes, integriertes Engineering von Anlagen und für
die nahtlose Interaktion mit Systemen aus anderen Unternehmensebenen
[12]. Daneben sind Agenten ein viel versprechender
Ansatz für die umfassende Diagnose von Anlagen
durch den integrierten Einsatz verschiedener Diagnoseverfahren
[13].
3. Modellierungsbeispiel einer agentenorientierten
Softwareentwicklung
Nach den Beispielen für agentenorientierte Lösungen in der
Automatisierungstechnik soll nun die agentenorientierte
Softwareentwicklung an einem umfassenden Modellierungsbeispiel
veranschaulicht werden. Im Folgenden wird
der vollständige Entwicklungsprozess bei agentenorientierter
Analyse und Entwurf vorgestellt, zusammen mit Erläuterungen
der wesentlichen Schritte und Entwurfsentscheidun-

16
gen. Als Beispielanwendung dient die Steuerung einer Eisenbahn.
Das Hauptziel dieses Anwendungsbeispiels ist, die
praktische Anwendung der agentenorientierten Denkweise
und Konzepte bei der Entwicklung eines Softwaresystems zu
veranschaulichen, sowie diejenigen spezifischen Merkmale
der Agentenorientierung herauszuarbeiten, die hier zu einer
sinnvollen Lösung führen.
3.1 Der Modellprozess Eisenbahn
Der Modellprozess Eisenbahn wird am Institut für Automatisierungs-
und Softwaretechnik (IAS) in Lehre und Forschung
eingesetzt. In der Lehre dient die Eisenbahnanlage als Versuchsanlage
für die internetbasierte Fernsteuerung eines
technischen Prozesses. Die Fernsteuerung wird im Rahmen
eines Online-Praktikumversuches im Fachpraktikum Automatisierungstechnik
eingesetzt. Daneben wird die Eisenbahnanlage
als Demonstrations- und Versuchsmodell für
das Forschungsgebiet „Agenten in der Automatisierungstechnik“
genutzt. Sie dient als anschauliches Beispiel eines
Automatisierungssystems, das mit agentenorientierter Software
gesteuert und überwacht werden kann.
3.2 Aufgabenstellung
Für unser Beispiel verwenden wir einen Ausschnitt der Eisenbahnanlage,
bestehend aus den drei Bahnhöfen Stadtbahnhof,
Landbahnhof und Hafenbahnhof. Zwischen Stadtbahnhof
und Landbahnhof bestehen drei Gleisverbindungen und
zwischen Hafenbahnhof und Stadtbahnhof eine (Bild 2). In
einem Betriebswerk können nicht benötigte oder defekte
Züge abgestellt werden (Bild 2 rechts unten).
3.3 Anforderungen an die Steuerung
L
K
Landbahnhof
= 60 Plätze (2x)
= 30 Plätze (3x)
S1
Hafenbahnhof
S2
Stadtbahnhof
18 min.
360 Personen/Stunde
Bild 2: Schematische Darstellung der Eisenbahn.
8 min.
180 P./Std.
Für die dargestellte Eisenbahnanlage soll ein Transportsystem
mit folgenden Anforderungen realisiert werden:
Die Bahnhöfe sind durch verschiedene S-Bahnlinien miteinander
verbunden. Zwischen dem Stadt- und dem Landbahnhof
verkehrt die S-Bahnlinie S1. Eine Anforderung an
die Linie ist, dass jede Stunde 360 Fahrplätze zur Verfügung
stehen (180 von Land nach Stadt und 180 in die Gegenrichtung).
Der zeitliche Abstand zwischen aufeinander folgenden
Fahrten soll gleich groß sein und die Wartezeiten der
Fahrgäste für Anschlusszüge sollen minimiert werden.
Eine zweite S-Bahnlinie S2 verbindet den Stadtbahnhof
mit dem Hafenbahnhof. Hier besteht die Anforderung, zu
jeder Stunde 180 Fahrplätze (90 von Stadt nach Hafen und
90 in die Gegenrichtung) anzubieten. In gleicher Weise wie
bei S1 sollen die zeitlichen Abstände zwischen Fahrten
gleich lang und Wartezeiten möglichst gering sein.
Im Rahmen des Beispiels nehmen wir an, dass ein Zug
unabhängig von seiner Länge 18 Minuten benötigt, um die
Strecke zwischen Land und Stadt zurückzulegen und 8
Minuten für die Strecke zwischen Stadt und Hafen. Für den
Fahrbetrieb stehen folgende Züge zur Verfügung: Drei kurze
Züge K1, K2 und K3, mit einer Kapazität von jeweils 30 Personen
und zwei lange Züge, L1 und L2, mit einer Kapazität von
je 60 Personen.
Die Elemente der Eisenbahn mit sicherheitskritischen
Anforderungen sind Streckenabschnitte und Weichen. Es
muss sichergestellt werden, dass nicht zwei Züge gleichzeitig
eine Strecke befahren. Deshalb müssen alle Streckenelemente
(Streckenabschnitte und Weichen) vom Zug reserviert
werden, damit ein exklusiver Zugriff gewährleistet ist.
Basierend auf diesen exemplarischen Anforderungen soll
eine automatisierte Steuerung des Fahrbetriebs der Eisenbahn
entwickelt werden. Die Komplexität einer solchen
Steuerung mit automatischer Streckenvergabe und Fahrplanverwaltung
wird bereits in diesem einfachen Beispiel
schnell ersichtlich. Während des Betriebes können im
Wesentlichen drei unerwartete Fehlersituationen auftreten,
auf welche die Steuerung dynamisch reagieren muss, um
eine möglichst optimale Verfügbarkeit zu gewährleisten:
Ein Zug hat Verspätung: Diese allen Bahnfahrern nur zu gut
bekannte Situation muss im System propagiert und flexibel
gehandhabt werden, um Anschlussverbindungen
möglichst aufrecht zu erhalten.
Ein Zug fällt aus: Andere Züge müssen neu dispositioniert
werden, um die Transportkapazität einer Verbindung
möglichst aufrecht zu erhalten; gegebenenfalls
müssen Fahrpläne angepasst werden.
Eine Strecke fällt aus: Hier muss – falls Ersatzstrecken zur
Verfügung stehen – gleichfalls eine Neudisposition von
Zügen erfolgen und evtl. Fahrpläne
angepasst werden.
Die Steuerung muss in der Lage sein,
auf alle möglichen Kombinationen dieser
Fehlersituationen so zu reagieren,
dass zum einen die oben genannten
Anforderungen an die Transportkapazität
einer Verbindung möglichst optimal
erfüllt und zum anderen die verfügbaren
Ressourcen des Systems
(Züge und Streckenelemente) bestmöglich
verteilt werden.
Es ist leicht ersichtlich, dass die
Gesamtheit der Situationen, die
während des Betriebs auftreten können,
nicht vorhersagbar ist. Somit kann

17
die optimale Auflösung einer bestimmten Fehlersituation
nicht zur Entwurfszeit vollständig bestimmt werden. Durch
einen agentenorientierten Ansatz kann eine Steuerung für
die Eisenbahn entwickelt werden, die auf Basis einiger elementarer
Strukturen, Mechanismen und Regeln zur Laufzeit
dynamisch das der jeweiligen Situation angemessene Verhalten
aufweist. Diese Basisstruktur des Systems wird im
Rahmen der folgenden agentenorientierten Analyse und
des Entwurfs ermittelt und festgelegt.
3.4 Agentenorientierte Analyse und Entwurf
Für die Analyse und den Entwurf der Steuerung verwenden
wir hier die agentenorientierte Methode Gaia [14]. Bei Gaia
werden in der Analysephase ein Rollenmodell und ein Interaktionsmodell
ermittelt. In der Entwurfsphase werden ein
Agentenmodell und ein Organisationsmodell 1 erstellt. Jedes
dieser Modelle werden wir für unser Beispiel systematisch
entwickeln und beschreiben.
3.4.1 Rollenmodell
In der Analysephase betrachten wir zunächst das System
"von außen", um seine Funktionen und Zusammenhänge zu
ermitteln. Zu diesem Zweck identifiziert im ersten Schritt die
Rollenanalyse die Verantwortlichkeiten und die Aufgaben,
die durch das System gehandhabt werden müssen. Später
werden diese identifizierten Rollen im laufenden System
durch Agenten übernommen. Ein Agent kann während seines
Lebenszyklus unterschiedliche Rollen übernehmen bzw.
eine einzelne Rolle kann auch von mehreren Agenten wahrgenommen
werden. Aufgrund dieser Durchgängigkeit des
Rollenkonzeptes über den gesamten Entwicklungsprozess
wird die Entwicklung eines Systems unterstützt, in dem sich
die ursprünglich erkannten Aufgaben und Verantwortlichkeiten
auch tatsächlich wieder finden. Bei Gaia wird eine textuelle
Beschreibung einer Rolle verwendet, die folgende Elemente
umfasst:
Protokolle und Aktivitäten (Protocols and Activities) – Protokolle
legen fest, wie verschiedene Rollen miteinander
interagieren; Aktivitäten sind Aufgaben, die von einer
Rolle ohne Interaktion erledigt werden. Zum Beispiel
muss ein Zug mit einem Streckenabschnitt interagieren,
um die Erlaubnis zu bekommen, diesen befahren zu dürfen.
Seinen eigenen Fahrplan kann er ohne jegliche Interaktion
ändern.
Rechte (Permissions) – Hier werden die Rechte zum Lesen,
Ändern und Erzeugen von Datenelementen spezifiziert.
Wie hier bereits zu erkennen ist, besteht ein agentenorientiertes
System nicht ausschließlich aus Agenten. Passive
Elemente, wie Datenspeicher, müssen nicht als Agenten
modelliert werden. Ein Beispiel für solche Elemente
bei der Eisenbahn sind die Fahrpläne der Züge.
Verantwortlichkeiten (Responsibilities) – Verantwortlichkeiten
werden in zwei Kategorien unterteilt: Lebendigkeit
(Liveness) und Sicherheit (Safety). Liveness beschreibt die
Reihenfolge der Aufgaben, die von der Rolle realisiert
werden müssen. Sie setzen sich aus den im ersten Bereich
beschriebenen Protokollen und Aktivitäten zusammen.
Safety sind Bedingungen (Invarianten), die eingehalten
werden müssen, um unerwünschte oder sogar gefährliche
Situationen zu vermeiden. Zur Vereinfachung haben
wir die Safety Verantwortlichkeiten im Modell weggelassen.
Bild 3 zeigt das vereinfachte Metamodell der Elemente
bei der agentenorientierten Analyse und des Entwurfs mit
Gaia. Damit werden die Zusammenhänge zwischen Agenten,
Rollen, Protokollen, Aktivitäten, Rechten und Verantwortlichkeiten
in UML-Notation beschrieben.
Agent
übernimmt >
*
1..*
< interagiert mit
*
Rolle
Protokoll
* *
*
Rechte Verantwortlichkeiten Aktivitäten
Bild 3. Metamodell der Elemente von Gaia.
Wie können Rollen identifiziert werden? Aus der Anforderungsspezifikation
des Transportsystems können direkt Verantwortlichkeiten
abgeleitet werden, die einzelnen Bestandteilen
des Systems zugeordnet sind. Zum Beispiel müssen
die beiden S-Bahnlinien eine gewisse Transportkapazität
und eine zeitlich gleichmäßige Verteilung der Fahrten anbieten.
Die Erfüllung dieser Anforderungen impliziert eine
Reservierung der Streckenabschnitte und unter Umständen
den Einsatz von mehreren Zügen. Diese nicht-trivialen Aufgaben
kennzeichnen S-Bahnlinien als gute Ansatzpunkte für
die Modellierung von Rollen. Beispielsweise beschreibt die
Rolle S1 die Verantwortlichkeiten der Züge, welche die Verbindung
zwischen Landbahnhof und Stadtbahnhof befahren.
Analog beschreibt S2 die Rolle der Züge, die zwischen
Hafenbahnhof und Stadtbahnhof verkehren. Um den dynamischen
Einsatz der Züge zu ermöglichen, ist eine weitere
Rolle für Züge sinnvoll, die gerade nicht im Fahrbetrieb eingesetzt
werden. Diese Rolle wird mit dem Namen IDLE
bezeichnet.
Die Sicherheit des Eisenbahnbetriebs hängt davon ab, wie
die Reservierung von Streckenabschnitten und Weichen
durch die Züge gehandhabt wird. Gleichzeitig sollte aber
versucht werden, die Zeitspanne zu minimieren, in der ein
Streckenelement unbenutzt reserviert ist, um die Gesamtverfügbarkeit
des Systems zu erhöhen. Die Handhabung dieser
konfliktträchtigen Anforderungen ist eine Aufgabe, welche
die Modellierung von Streckenabschnitten und Weichen
als Rollen (mit TSEG und TOUT bezeichnet) sinnvoll macht. Im
Gegensatz dazu müssen Bahnhöfe nur die Informationen
über Verspätungen auf einer S-Bahnlinie an Züge anderer
Linien weiterleiten. Das ist eine einfache Aufgabe, für welche
die Modellierung als Rolle nicht erforderlich ist.
Damit haben wir folgende Rollen im System identifiziert:
Die Rollen der S-Bahnlinien S1 und S2, die Rolle IDLE für freie
Züge und die Rollen TSEG bzw. TOUT für Streckenabschnitte
*

18
bzw. Weichen. Im Folgenden werden die identifizierten Rollen
des Systems detailliert beschrieben. Tabelle 1 zeigt die
Rollenbeschreibung von S1 in Gaia Notation.
In dieser Rollenbeschreibung sind zunächst alle Protokolle
und Aktivitäten der Rolle S1 aufgelistet:
FindTrack spezifiziert den Ablauf, wie ein Zug, der gerade
die Rolle S1 wahrnimmt, mit Streckenelementen
(Streckenabschnitte und Weichen) interagiert, um einen
vollständigen Weg von seiner gegenwärtigen Position
zum Zielbahnhof zu finden. Dieser Ablauf ist sinnvoll,
denn wenn Streckenelemente nicht verfügbar sind, kann
der Zug selbstständig eine Alternativroute finden.
Um Unfälle zu vermeiden, reserviert der Zug ein Streckenelement,
bevor er es befährt. Das Protokoll ReserveTrack
legt die Interaktion zwischen Zügen und Streckenelementen
während einer Reservierung fest.
Die Aktivität DriveTrack repräsentiert die Fahrt eines
Zuges durch ein zuvor reserviertes Streckenelement. Da
hierfür keine Interaktionen benötigt werden, wird diese
Aufgabe nicht als Protokoll modelliert.
Anschließend wird das Streckenelement mit dem Protokoll
ReleaseTrack wieder freigegeben.
Die Aktivität InformDelay wird verwendet, um den Zielbahnhof
zu informieren, wenn der Zug seinen Fahrplan
ändert.
Da die Kapazität eines einzelnen Zuges nicht immer ausreicht,
um die geforderte Transportkapazität einer S-
Bahnlinie zu erfüllen, müssen auch mehrere Züge zusammen
eingesetzt werden können. Das bedeutet, dass mehr
als ein Zug die Rolle der S-Bahnlinie übernimmt. Die Züge
müssen dann ihre Aktionen abstimmen, um gemeinsam
die Anforderungen der Linie zu erfüllen. Das Protokoll
NegotiateGoals beschreibt diesen Ablauf.
Weiter sollen zur optimalen Ressourcenausnutzung
immer die am besten passenden Züge für eine S-Bahnlinie
eingesetzt werden. Sieht sich ein Zug aufgrund seiner
Kapazität als geeigneter für die Rolle einer S-Bahnlinie, so
verhandelt er über das Protokoll NegotiateRole mit dem
Zug, der momentan dieser Rolle zugeordnet ist, um die
Rolle zu übernehmen.
Die Rolle S1 greift auf folgende Datenelemente zu: Das
Element TransportCapacity speichert die Information
über die Transportkapazität eines Zuges mit der Rolle S1.
Im Element RoleDB wird die Zuordnung von Rollen zu
Zügen gespeichert. Damit ist RoleDB eine Art schwarzes
Brett, über das ein Zug herausfinden kann, welcher
andere Zug gerade welche Rolle wahrnimmt. Falls ein
Zug sich bei der Interaktion in NegotiateRole entscheidet,
seine Rolle zu ändern, modifiziert er die in RoleDB gespeicherte
Zuordnung. Der Fahrplan der Züge auf der Linie S1
wird im Element TimetableS1 gespeichert und von den
der Rolle S1 zugeordneten Zügen modifiziert. Die Änderung
von TimetableS1 kann notwendig werden aufgrund
von Fehlersituationen im Betrieb, an die sich der Zug
anpassen muss.
Verantwortlichkeiten beschreiben die Zusammenhänge
und Abläufe der Protokolle und Aktivitäten von S1. In Gaia
wird zur Beschreibung der Verantwortlichkeiten eine Notation
benutzt, die auf regulären Ausdrücken basiert. Die
Hauptverantwortlichkeit von S1 lautet:
((DriveToStadt · DriveToLand) | NegotiateGoals | NegotiateRole)_
Das ‘_’ am Ende zeigt eine endlose Wiederholung der aufgelisteten
Aktivitäten an. Die einzelnen Aktivitäten werden
alternativ (‘|‘)ausgeführt:
Fahre von Land nach Stadt und zurück (DriveToStadt • DriveToLand)
Verhandle Ziele mit anderen S1 zugeordneten Zügen
(NegotiateGoals)
Verhandle die Zuordnung zu einer Rolle (NegotiateRole)
Die Aktivitäten DriveToStadt und DriveToLand sind weiter
untergliedert in Unteraktivitäten: Das Finden eines Weges
zum Zielbahnhof, die Reservierung der Streckenabschnitte
und die Fahrt selbst:
DriveToStadt = (FindTrack(Stadt) • ReserveTrack • Drive-
Track • ReleaseTrack • [InformDelay])+
Nachdem ein Weg von der gegenwärtigen Position zum
Stadtbahnhof gefunden wurde, reserviert der Zug die
Streckenabschnitte, die er zu durchfahren beabsichtigt und
beginnt seine Fahrt. Das ’+’-Symbol am Ende des Ablaufes
zeigt an, dass diese Reihe von Aktivitäten mehrmals durchlaufen
wird, bis der Zielbahnhof erreicht ist. Im Fall einer Fehlersituation
(z.B. wenn ein Streckenelement des geplanten
Wegs nicht mehr verfügbar ist) muss der Zug einen Alternativweg
zum Zielbahnhof finden. Gleichzeitig informiert er
den Bahnhof über die Verzögerung.
Die Modellierung der Rolle von S-Bahnlinie S2 ist der von
S1 sehr ähnlich und hat im Grunde dieselben Aktivitäten und
Protokolle. Sie unterscheidet sich nur in den Zielbahnhöfen
und in den benutzten Datenelementen.
Die getrennte Modellierung von Zügen und S-Bahnlinien
ist die Basis für den dynamischen Einsatz von Zügen im
System, abhängig von der aktuellen Situation. Um den flexiblen
Einsatz der Züge zu automatisieren, wird eine Rolle für
Tabelle 1: Rollenbeschreibung von ‘S1’ .
Role Schema: S1
Description: S-Bahnverbindung zwischen Landbahnhof, Stadtbahnhof
und zurück. Stellt eine Transportkapazität von 360 Personen pro
Stunde zur Verfügung (180 Personen pro Stunde in jede Richtung der
Verbindung).
Protocols and Activities
FindTrack, ReserveTrack, DriveTrack,InformDelay,NegotiateGoals,
NegotiateRole
Permissions
Reads: TransportCapacity; Changes: RoleDB, TimetableS1
Responsibilities - Liveness:
S1 = ((DriveToStadt · DriveToLand) | NegotiateGoals | NegotiateRole)_
DriveToStadt = (FindTrack(Stadt) · ReserveTrack · DriveTrack · Release-
Track · [InformDelay])+
DriveToLand = (FindTrack(Land) · ReserveTrack · DriveTrack) · Release-
Track · [InformDelay])+

19
freie Züge (IDLE) benötigt. Diese Rolle nehmen die gerade in
keiner S-Bahnlinie eingesetzten Züge ein und suchen nach
neuen Einsatzmöglichkeiten. Dazu überprüft der jeweilige
Zug die gegenwärtigen Zuordnungen von Zügen zu S-Bahnlinien
und vergleicht seine eigene Transportkapazität mit
den Anforderungen der Linien. Dabei gibt es drei Kriterien:
Die Rolle einer S-Bahnlinie ist gerade von keinem Zug
übernommen.
Es sind nicht genügend Züge dieser Rolle zugeordnet, um
die geforderte Transportkapazität zu erreichen.
Die eingesetzten Züge sind nicht die effizientesten für
diese Aufgabe.
Die erste Situation ist eindeutig: Falls kein Zug einer
bestimmten Rolle zugeordnet ist, kann der unbenutzte Zug
diese Rolle direkt übernehmen. Die zweite Situation tritt zum
Beispiel auf, wenn nur ein langer Zug der Linie S1 zugeordnet
ist. Da die Fahrt knapp 20 Minuten dauert, kann ein langer
Zug maximal 180 Personen pro Stunde befördern (3
Fahrten pro Stunde, 60 Personen pro Fahrt). In diesem Fall
kann ein zweiter langer Zug zusätzlich die Rolle S1 übernehmen,
um die Transportkapazität auf 360 Personen pro
Stunde zu erhöhen und somit die Anforderung der Rolle
erfüllen.
Ein Beispiel für die dritte Situation ist die bestehende
Zuordnung eines langen Zuges zur Linie S2. Da die Fahrt
knapp 10 Minuten benötigt, kann ein langer Zug etwa 360
Personen pro Stunde befördern (6 Fahrten pro Stunde, 60
Personen pro Fahrt). Dies ist viel mehr als auf der Linie
benötigt wird und somit eine nicht optimale Verwendung
von Ressourcen. Dagegen würde ein kurzer Zug 180 Personen
pro Stunde befördern (6 Fahrten pro Stunde, 30 Personen
pro Fahrt), genug, um die Anforderungen der Rolle zu
erfüllen. Der kurze Zug würde die Rolle S2 in diesem Fall
übernehmen und den langen für andere Aufgaben verfügbar
machen. Tabelle 2 fasst die Beschreibung der Rolle IDLE
zusammen.
Die Aktivität CheckRoles der Rolle IDLE überprüft die Information
über die Zuordnung von Zügen zu S-Bahnlinien, die
im Element RoleDB gespeichert ist. Findet der Zug eine der
drei oben genannten Situationen vor, übernimmt er entweder
die Rolle direkt (wenn diese frei ist) oder er initiiert das
NegotiateRole Protokoll. Übernimmt der Zug im Verlauf seiner
Aktivitäten eine neue Rolle, wird RoleDB entsprechend
geändert. Die Hauptverantwortlichkeit der Rolle IDLE
besteht somit in der wiederholten Durchführung von
CheckRoles und gegebenenfalls von NegotiateRole.
Tabelle 2: Rollenbeschreibung von ‘IDLE’ .
Role Schema: IDLE (Freier Zug)
Description: Rolle eines Zuges, der keiner S-Bahnlinie zugeordnet ist.
Protocols and Activities:
CheckRoles, NegotiateRole
Permissions:
Reads: TransportCapacity, RoleDB; Changes: RoleDB
Responsibilities - Liveness:
IDLE = (CheckRoles · [NegotiateRole])_
In der Rolle IDLE ist besonders deutlich die Umsetzung
der abstrakten agentenorientierten Konzepte Zielorientierung
und Proaktivität zu erkennen. Die Ziele der Steuerung –
Erfüllung der Transportkapazitäten bei optimaler Ressourcenausnutzung
– drücken sich in den Regeln aus, nach
denen sich ein gerade nicht eingesetzter Zug neue Aufgaben
sucht. Diese Suche führt er aus eigenem Antrieb aus,
also proaktiv, um das System nach Möglichkeit in einen optimalen
Zustand zu bringen.
Die letzten beiden Rollen des Transportsystems sind die
Rollen TSEG von Streckenabschnitten und TOUT von Weichen.
Die Rolle TSEG eines Streckenabschnitts ist in Tabelle 3
beschrieben.
Tabelle 3: Rollenbeschreibung von ‘TSEG’.
Role Schema: TSEG (Streckenabschnitt)
Description: Bahnstrecken werden in einzelne Streckenabschnitte aufgeteilt,
die nacheinander von einem Zug befahren werden.
Protocols and Activities:
ReserveTrack, CheckReservationTimeout, FindTrack, ReleaseTrack
Permissions:
reads: Station, TSEGReservation; changes: TSEGReservation; generates:
TSEGReservation
Responsibilities - Liveness:
TSEG = (ReserveTrack | CheckReservationTimeout | FindTrack(Destination)
| ReleaseTrack)_
Der Streckenabschnitt interagiert über das ReserveTrack
Protokoll mit den Zügen der S-Bahnlinien, um die exklusive
Benutzung zu einem Zeitpunkt zu gewährleisten. Er kontrolliert
seine eigene Reservierungsinformation in TSEGReservation
und gibt, falls verfügbar, die Durchfahrerlaubnis für eine
begrenzte Zeitdauer. Ist der Streckenabschnitt bereits reserviert,
wird die Reservierungsanfrage des Zuges abgelehnt.
Die Aktivität CheckReservationTimeout überwacht die Zeitdauer
der Reservierungen für den Streckenabschnitt. Dieser
Mechanismus erhöht die Verfügbarkeit des Systems, weil
dauerhafte Blockierungen von Streckenabschnitten vermieden
werden.
Im Protokoll FindTrack reagiert der Streckenabschnitt auf
die Weganfrage eines Zuges und versucht, einen Weg von
seiner gegenwärtigen Position zum gewünschten Zielbahnhof
zu finden. Falls sich der Streckenabschnitt an einem
Bahnhof befindet, ist der Name des Bahnhofs im Element
Station gespeichert.
Die Modellierung der Rolle einer Weiche, TOUT genannt,
ist der eines Streckenabschnitts sehr ähnlich, mit denselben
Interaktionen für Reservierung und Wegfindung. Zusätzlich
existiert die Aktivität ChangeDirection, um die Weichenstellung
zu ändern.
Im zweiten Schritt der agentenorientierten Analyse werden
die Abläufe zwischen den Rollen genauer betrachtet.
3.4.2 Interaktionsmodell
Das Interaktionsmodell gibt eine Übersicht über die spezifizierten
Protokolle auf einer abstrakten Ebene. Hier wird

20
festgelegt, wie die einzelnen Rollen zur Bewältigung ihrer
Aufgaben miteinander interagieren. In Gaia wird eine tabellarische
Notation benutzt, die in Tabelle 4 dargestellt wird.
Tabelle 4: Protokollspezifikation in Gaia.
Name des Protokolls
Auslöser
Empfänger
Beschreibung
Tabelle 5 zeigt die Spezifikation des ersten Protokolls
FindTrack. Das FindTrack Protokoll wird durch die Rollen S1
oder S2 ausgelöst und von einer der Rollen TSEG oder TOUT
beantwortet. Der Zug macht eine Anfrage, während er einen
Weg von seiner gegenwärtigen Position zum Zielbahnhof
(Destination) sucht. Die Anfrage wird zu den Streckenelementen
in der direkten Nachbarschaft des Zuges geschickt
und an alle weiter führenden Streckenelemente weitergeleitet.
Jedes Streckenelement fügt seine ID zur Anfragenachricht
hinzu, bevor diese weitergeleitet wird. Läuft die Nachricht
in einer Schleife, das heißt erreicht sie ein Streckenelement
mehr als einmal, wird sie vernichtet, um unnötige
Anfragen zu vermeiden. Wird ein Streckenabschnitt erreicht,
der im Zielbahnhof liegt, so wird eine Bestätigung entlang
der Reihenfolge der in der Anfragenachricht gespeicherten
IDs zurück zum Zug geschickt.
Tabelle 5: Protokollspezifikation FindTrack.
FindTrack
S1, S2, TSEG, TOUT TSEG, TOUT
(siehe Text)
Tabelle 6 zeigt die Spezifikation des Protokolls Reserve-
Track. Das ReserveTrack Protokoll wird wie bei FindTrack von
S1 oder S2 ausgelöst und von TSEG oder TOUT beantwortet.
Ein Zug, der durch ein Streckenelement fahren will, macht
eine Reservierungsanfrage. Abhängig vom gegenwärtigen
Reservierungsstatus wird die Erlaubnis zur Benutzung
erteilt oder die Anfrage wird abgelehnt. Die Protokollspezifikation
von ReleaseTrack entspricht der von ReserveTrack,
wobei ein Streckenelement seine Freigabe lediglich
bestätigt.
Tabelle 6: Protokollspezifikation ReserveTrack.
ReserveTrack
S1, S2 TSEG, TOUT
(siehe Text)
Eingaben
Ausgaben
Destination
Found | Forward (Add ID)
Train ID
Accept | Decline
In Tabelle 7 ist die Spezifikation des Protokolls Negotiate-
Goals dargestellt. Werden die Rollen S1 oder S2 von mehr als
einem Zug gemeinsam übernommen, muss es einen
Abstimmungsprozess zwischen den Zügen geben, um die
Anforderungen der Rolle zu erfüllen. Jeder der Züge tauscht
mit den anderen seine geplante Verwendung der Ressourcen
(Resource utilization) aus, z.B. die der Streckenabschnitte.
Nachdem die Pläne des anderen bekannt sind, werden
solange neue Vorschläge gemacht, bis eine Strategie gefunden
wurde, die von allen Zügen akzeptiert wird. Aufgrund
der zeitlichen Anforderungen des realen Systems, muss die
Spezifikation dieses Protokolls eine kurze Konvergenzzeit für
diesen Verhandlungsprozess sicherstellen.
Tabelle 7: Protokollspezifikation NegotiateGoals.
NegotiateGoals
S1, S2 S1, S2
(siehe Text)
Die Spezifikation des Protokolls NegotiateRole ist in
Tabelle 8 beschrieben. In NegotiateRole beginnt ein Zug in
der Rolle IDLE eine Interaktion mit einem Zug, welcher der
Rolle S1 oder S2 zugeordnet ist. Er hat das Ziel, dessen Rolle
zu übernehmen. In einer ersten Anfrage sendet der Zug
seine eigene Transportkapazität. Stellt der gegenwärtig der
Rolle zugeordnete Zug die bessere Eignung des freien Zuges
fest, so gibt er seine Rolle S1 oder S2 ab und nimmt die Rolle
IDLE an.
Tabelle 8: Protokollspezifikation NegotiateRole.
NegotiateRole
IDLE S1, S2
(siehe Text)
Bild 4 gibt einen Überblick über alle in der Analysephase
im System identifizierten fünf Rollen und fünf Protokolle. Die
einzelnen Rollen sind durch Rechtecke dargestellt, die Protokolle
durch Verbindungen zwischen den Rollen. Rollen, welche
die gleichen Protokolle verwenden, sind zur Vereinfachung
zusammengefasst.
3.4.3 Agentenmodell
Resource utilization
Resource utilization
Request role (TransportCapacity)
Accept | Decline
In der Entwurfsphase von Gaia wird aus den Ergebnissen der
Analysephase das Agentenmodell erstellt. Darin werden die
Agententypen und die Anzahl der Agenten jedes Typs festgelegt.
Agenten eines bestimmten Typs können eine oder
mehrere der im Analyseprozess definierten Rollen annehmen
(durch einen Pfeil dargestellt).
In den bisher durchgeführten Analyseschritten waren die
aktiven Elemente des Systems mit nicht-trivialen Aufgaben
bereits gut zu erkennen. Es handelt sich um Züge, Streckab-
Negotiate Goals
S1
S2
TSEG
TOUT
Negotiate Role
Find Track, Reserve Track, Release Track
Find Track
IDLE
Bild 4: Übersicht über die Rollen und Protokolle der Eisenbahnsteuerung.

21
schnitte und Weichen. Diese Elemente übernehmen die
identifizierten Rollen im System. Daher ist es naheliegend,
diese Elemente als Agenten zu modellieren. Bild 5 zeigt das
Agentenmodell der Eisenbahnsteuerung, in dem die drei
Agententypen dargestellt sind: der Agententyp Train für
Züge, der Agententyp Track für Streckenabschnitte und der
Agententyp Turnout für Weichen. Agenten vom Typ Train
können die Rollen S1, S1 oder IDLE wahrnehmen. Agenten
vom Typ Track übernehmen die Rolle TSEG und Agenten
vom Typ Turnout die Rolle TOUT. Das ‘+‘ zeigt an, dass im
System von jedem Typ mindestens ein Agent existiert.
Flexible dynamische Zuordnung von Zügen zu S-Bahnlinien
für eine möglichst optimale Ressourcenverteilung
und Erfüllung der geforderten Transportziele.
Dynamische Wegfindung und Streckenbelegung.
Proaktives Suchen freier Züge nach neuen Einsatzmöglichkeiten,
um die Transportkapazitäten oder den Einsatz
der Züge zu optimieren.
Selbstständige Koordination der Züge zur Anpassung an
die aktuelle Betriebssituation.
Das vollständige Modellierungsbeispiel findet sich im
Internet unter der Adresse http://www.ias.unistuttgart.de/agenten.
Train
+
Track
+
Turnout
+
4. Zusammenfassung
S1 S2 IDLE TSEG TOUT
Bild 5: Agentenmodell mit der Zuordnung von Rollen zu Agententypen.
3.4.4 Organisationsmodell
Das letzte Modell im Entwurf ist das Organisationsmodell.
Hier wird festgelegt, welche Kommunikationsbeziehungen
zwischen den Agenten bestehen. Damit wird keine statische
Definition des Informationsflusses vorgegeben, sondern
lediglich mögliche Beziehungen aufgezeigt. Bild 6 zeigt das
Organisationsmodell des Transportsystems: Alle Agententypen
können untereinander interagieren, Agenten vom Typ
Train und Track können auch mit Agenten gleichen Typs
interagieren.
Mit dem Organisationsmodell ist die agentenorientierte
Analyse und der Entwurf mit der Methode Gaia abgeschlossen.
In den erstellen Modellen sind bereits die wesentlichen
Merkmale der Eisenbahnsteuerung zu erkennen:
Track
Turnout
Train
Bild 6: Organisationsmodell mit möglichen Kommunikationsbeziehungen.
In der Automatisierungstechnik kann aus einem agentenorientierten
Ansatz häufig eine vorteilhafte Lösung resultieren.
Eine agentenorientierte Lösung ist dann sinnvoll, wenn ein
System logisch verteilt ist, komplexes Verhalten aufweist,
umfangreiche Koordinationsprozesse erfordert oder eine
flexible Struktur benötigt. Viele Systeme in der heutigen
Automatisierungstechnik weisen diese Eigenschaften auf,
z.B. in der Produktionstechnik, im Energiemanagement, in
der Logistik, bei Verkehrssystemen und in der Anlagenautomatisierung.
Im Zentrum dieses Beitrags steht die praktische Anwendung
der agentenorientierten Denkweise für die systematische,
ingenieurmäßige Entwicklung von Software. Das
Modellierungsbeispiel der Eisenbahnsteuerung verdeutlicht,
wie die agentenorientierten Grundkonzepte für die
Analyse und den Entwurf einer realen Applikation angewendet
werden. Der Schwerpunkt bei der Modellierung liegt auf
der Betrachtung der Aufgaben (Rollen), die durch das
System bewältigt werden müssen und der Interaktionen
zwischen den verschiedenen Rollen zur Bewältigung dieser
Aufgaben. Die Rollen werden von den aktiven Elementen
des Systems, den Agenten, wahrgenommen. Durch diese
Vorgehensweise kann ein Modell als Basis für ein agentenorientiertes
System erstellt werden, das die erforderlichen
Eigenschaften Flexibilität, Anpassungsfähigkeit, Robustheit
und Fehlertoleranz aufweist.
In der Fortsetzung dieses Beitrages wird die grundsätzliche
Struktur von Agentensystemen erläutert und ihre Implementierung
anhand des Anwendungsbeispiels der Eisenbahnsteuerung
demonstriert. Abschließend wird gezeigt,
wie die Vorteile des agentenorientierten Modells der Eisenbahnsteuerung
im Betrieb zum Tragen kommen.

22
Agentensysteme in der Automatisierungstechnik:
Aufbau, Struktur und Implementierung an einem
Anwendungsbeispiel
Der vorliegende Beitrag behandelt zum Abschluss der Reihe über Softwareagenten in der Automatisierungstechnik
die Aspekte der Realisierung von Agentensystemen. Um eine agentenorientierte Lösung als lauffähiges
Softwaresystem zu implementieren, ist zunächst eine grundlegende Struktur für die einzelnen Agenten
und eine Basisarchitektur für Agentensysteme erforderlich, die die notwendige Infrastruktur für die Agenten
zur Verfügung stellt. Daneben existiert eine Reihe von Technologien, die dem Entwickler eine umfassende
Unterstützung bei der Implementierung bieten und die agentenorientierten Entwicklungskonzepte direkt
auf die Programmebene umsetzen. Diese Aspekte werden zuerst aus allgemeiner Sicht und anschließend
anhand der konkreten Implementierung eines technischen Beispiels erläutert.
Agent systems in industrial automation: construction, structure and implementation of an application
example
As a conclusion of the series about software agents, the present article addresses the aspect of realization of
agent systems. In order to implement an agent oriented solution in form of an executable software system,
a basic structure for a single agent and a basic architecture for an agent system are necessary, as they provide
the essential infrastructure needed by the agents. Besides that, there is a number of technologies which
provide the developer with comprehensive support during the implementation, in the task of converting the
agent oriented design concepts directly to program level.These aspects will be explained at first from a general
point of view and sequentially by considering the concrete implementation of a technical example.
1. Einführung
Viele moderne Automatisierungssysteme weisen komplexe
Anforderungen wie zunehmende Dezentralisierung, Flexibilität,
Anpassbarkeit und Integrationsfähigkeit auf, die einen
agentenorientierten Lösungsansatz sinnvoll erscheinen lassen.
Beispielsweise führt eine agentenorientierte Lösung für
Produktionssysteme, bei der alle beteiligten Elemente der
Fertigungsstraße als autonome, kooperierende Agenten
betrachtet werden, zu größerer Flexibilität und Robustheit
des Fertigungsprozesses [1, 2]. Beim Energiemanagement
können die komplexen Abläufe in einem Energieversorgungsnetzwerk
beherrscht und optimiert werden, wenn das
Netzwerk als Marktplatz betrachtet wird, auf den Erzeugerund
Verbraucheragenten dynamisch über verfügbare Energiekontingente
verhandeln. Dieses Prinzip ist sowohl in
großen Stromversorgungsnetzen anwendbar [3] als auch in
abgeschlossenen lokalen Netzwerken, wie zum Beispiel bei
der Energieversorgung im Kraftfahrzeug [4]. Auch in der
Anlagenautomatisierung können Agenten zur Steuerung
von Abläufen, zur Unterstützung des Anlagenfahrers, zur
Diagnose von Fehlerzuständen und zur Verbesserung des
Engineerings eingesetzt werden.
Der erste Teil dieser Beitragsreihe (atp 10/2003) behandelte
eine theoretische Einführung in die Agentenorientierung,
ihre grundlegenden Konzepte und die Vorgehensweise
bei der agentenorientierten Analyse und Entwurf [5].
Im zweiten Teil (atp 11/2003) wurde die praktische Anwendung
dieser Grundlagen bei der agentenorientierten Analyse
und dem Entwurf für eine Eisenbahnsteuerung veranschaulicht
[6]. Abschließend stellen sich noch wichtige Fragen
in Bezug auf die Realisierung von Agentensystemen:
Wie ist ein einzelner Agent bzw. ein (Multi-)Agentensystem
aufgebaut, und wie sieht die grundlegende Architektur aus?
Wie muss bei der Implementierung von Agentensystemen
vorgegangen werden, damit sich die Eigenschaften von
Agenten tatsächlich im realisierten System wieder finden?
Die Basiskonzepte der Agentenorientierung Autonomie,
Interaktion, Reaktivität, Zielorientierung, Proaktivität und
Persistenz scheinen auf den ersten Blick mit den bekannten
Methoden und Technologien der Softwaretechnik nur
schwer modellierbar und implementierbar zu sein. Mit den
heutigen Mitteln der Programmierung ist es jedoch möglich,
die Agentensicht bei der Implementierung auf die Merkmale
eines Softwaresystems zu übertragen. Hinzu kommt, dass für
eine agentenorientierte Lösung einer realen Problemstellung
diese Merkmale nicht nur wünschenswert, sondern
auch unverzichtbar sind. Die Durchgängigkeit der konzeptionellen
Basis bei Analyse, Entwurf und Implementierung ist
ein wichtiger Faktor bei der Softwareentwicklung. Die Vernachlässigung
dieser Tatsache bei der agentenorientierten
Softwareentwicklung birgt die Gefahr in sich, dass ein Softwaresystem
entsteht, welches die agentenorientierten Konzepte
nicht oder nur in unzureichender Weise widerspiegelt
und somit nicht die gewünschten Eigenschaften aufweist. Im
Folgenden wird daher zunächst die grundsätzliche Architektur
von Agentensystemen erläutert. Anschließend wird

23
näher auf ihre Realisierung eingegangen, und es werden die
verfügbaren Hilfsmittel und Technologien vorgestellt, die
den Softwareingenieur bei seiner Arbeit unterstützen. Zum
Abschluss des Beitrags wird anhand des Anwendungsbeispiels
der Eisenbahnsteuerung die Implementierung des in
[6] erstellten Modells erläutert.
2. Aufbau von Agentensystemen
Bei der Realisierung eines agentenorientierten Entwurfs entsteht
ein Agentensystem, bestehend aus einzelnen Agenten,
die miteinander flexibel interagieren, autonom und reaktiv
handeln und gegebenenfalls dabei eigene Ziele proaktiv
verfolgen sollen. Die grundlegenden Mechanismen und
Architekturprinzipien zur Abbildung der Grundkonzepte
von Agenten in einem ausführbaren System sind Gegenstand
des folgenden Abschnitts.
2.1 Wie können agentenorientierte Konzepte in
einem Softwaresystem abgebildet werden?
Letztendlich sind Agenten und Agentensysteme Computerprogramme
und folgen den gleichen Ausführungsprinzipien
wie andere Programme. Die Erstellung eines Programms
erfolgt meist mit Hilfe von Programmiersprachen, welche die
Grundoperationen des Rechners durch mächtigere Sprachkonstrukte
abstrahieren. Diese Sprachkonstrukte bilden die
Basis für die Umsetzung der abstrakten agentenorientierten
Grundkonzepte. Die Grundkonzepte und Mechanismen für
ihre Umsetzung sind:
Autonomie: Unter Autonomie versteht man den Tatbestand,
dass das Verhalten eines Agenten im Wesentlichen
durch den Agenten selbst festgelegt und nicht von
„außen” festlegbar ist. Grundlage für die Autonomie eines
Agenten ist daher die Trennung des Nachrichtenaustausches
zwischen Agenten und der Nachrichtenbearbeitung
innerhalb eines Agenten. Dies bedeutet auch, dass der
Nachrichtenaustausch zwischen Agenten asynchron stattfinden
muss, damit ein Agent nicht durch Warten auf eine
Antwort blockiert wird. Als möglicher Mechanismus können
Nachrichtenaustausch und Nachrichtenbearbeitung
eines Agenten in eigene, parallele Prozesse (Threads)
gekapselt werden. Es wird deutlich, dass der dem Agenten
zu Grunde liegende Kommunikationsmechanismus nicht
wie in der objektorientierten Welt darauf basieren kann,
dass die Funktionalität eines Agenten durch öffentliche
Methoden nach außen zur Verfügung gestellt wird [7]. Der
Agent bietet statt dessen nur eine Schnittstelle für das
Senden und Empfangen von Nachrichten an.
Flexible Interaktionen: Agenten interagieren miteinander,
um Informationen auszutauschen, Ressourcen und Aufgaben
zu verteilen und um zu verhandeln. Hierfür sind
eine Reihe von Grundelementen der Kommunikation
erforderlich. Mögliche Nachrichtenformen sind Informationsübertragung
und Informationsabfrage (inform, query,
subscribe, request), Verhandlung (call-for-proposal, propose),
Zustimmung und Ablehnung (agree, refuse) [7]. Aus
diesen Kommunikationsprimitiven können Protokolle
aufgebaut werden, die den geregelten Ablauf von Interaktionen
festlegen. Weiter ist ein gemeinsames Verständnis
der Bedeutung der Nachrichten erforderlich. Die
Beschreibung dieser Bedeutungsbasis wird als Ontologie
bezeichnet [8]. Um flexible Beziehungen zwischen Agenten
zu ermöglichen, kann den Agenten zusätzlich eine
Infrastruktur zum Auffinden von Kooperationspartnern
zur Verfügung gestellt werden. Eine mögliche Realisierung
ist beispielsweise eine Art Schwarzes Brett, an dem
Agenten ihre Dienste bekannt geben oder benötigte
Dienste abfragen können.
Reaktivität: Die Aktivität eines Agenten kann zum einen
durch andere Agenten ausgelöst werden. Zum anderen
muss ein Agent möglicherweise auch für ihn relevante
Teile der Systemumgebung (Wahrnehmungsbereich)
beobachten können. In technischen Systemen kann dies
beispielsweise durch Abfrage von Sensoren erfolgen.
Gegebenenfalls können diese Sensoren durch Interrupt-
Handler gekapselt werden, bei denen sich Agenten
anmelden, um im Fall von Zustandsänderungen informiert
zu werden.
Ziele und Proaktivität: Ziele sind die Voraussetzung für
Handlungen, die ein Agent ohne externe Aktivierung ausführt.
Die Umsetzung dieser Konzepte kann durchaus
komplex werden, insbesondere wenn die Ziele sehr
abstrakt sind. In technischen Systemen kann die Realisierung
aber auch von ganz einfacher Art sein, beispielsweise
durch Ereignisse, Bedingungen und Regeln, die eine
Aktivität auslösen. Ereignisse können beobachtete
Zustandsänderungen in der Systemumgebung sein, die
dann mit gespeicherten Mustern verglichen oder auf die
Regeln angewendet werden. Es kann aber auch ein ablaufendes
Zeitintervall sein, das eine Aktion auslöst.
Persistenz: Zur Sicherstellung eines fortlaufenden Kontrollflusses
muss ein Agent seinen inneren Zustand speichern
können. Die hierfür notwendigen Mechanismen
müssen durch eine Infrastruktur zur Verfügung gestellt
werden.
Hier wird deutlich, dass zur Realisierung der abstrakten
Agentenkonzepte in einem Softwaresystem zusätzlich eine
von einzelnen Agenten unabhängige Infrastruktur benötigt
wird, beispielsweise für den asynchronen Nachrichtenaustausch
oder für das Auffinden von Diensten. Ein Agentensystem
ist demnach häufig mehr als die bloße Ansammlung
von Agenten: Es bildet auch die Basis für agenteninterne
Abläufe und solche zwischen Agenten. Inwieweit diese
zusätzlichen Mechanismen benötigt werden, hängt von der
jeweiligen Problemstellung ab.
2.2 Grundlegende Struktur eines Agenten
Zur Realisierung eines agentenorientierten Systems ist eine
grundlegende Struktur eines Agenten erforderlich, welche
die genannten Mechanismen unterstützt. Ein Agent muss
eine abgeschlossene Softwareeinheit darstellen, die kontinuierlich
mit der Umgebung interagiert. Diese kann auch
andere Agenten beinhalten. Die Interaktion besteht darin,
die Umgebung wahrzunehmen und diese durch Handlun-

24
Umgebungsmodell
Ziele
Ziel e Ziel e Fähigkeiten
Agent
Verhalten
Wahrnehmung
Beeinflussung
U
m
g
e
b
u
n
g
Age nt
Age nt Agent
Agent
Management
System
Directory
Facilitator
Message Transport System
Weitere
Agentensysteme
Bild 1: Grundlegende Struktur eines einzelnen Agenten.
gen auf Basis der eigenen Fähigkeiten zu beeinflussen. Auch
die Interaktion zwischen Agenten kann als eine Art „Wahrnehmen“
und „Handeln“ gesehen werden, da andere Agenten
als Teil der Umgebung betrachtet werden [9].
Die Fähigkeit, selbst zu entscheiden, was wann zu tun ist
und auf welche Weise, bildet eine fundamentale Eigenschaft
eines Agenten. Das Verhalten wird prinzipiell durch einen
Satz von Zielen unterstützt, die der Agent erreichen soll. Sie
kann auf eine sehr einfache Art und Weise durch eine Liste
von Regeln umgesetzt werden, wonach ein Umgebungszustand
eine Aktion auslöst. In flexibleren Ansätzen wird der
Entscheidungsprozess von Interaktionen mit anderen Agenten
abhängig gemacht. Dies erweitert den Entscheidungsprozess,
da ein Überblick über das ganze Agentensystem
einbezogen wird. Bild 1 zeigt die grundlegende Struktur
eines Agenten.
2.3 Architektur von Agentensystemen
Die meisten agentenorientierten Systeme bestehen aus
mehreren Agenten, die unterschiedliche Aufgaben übernehmen
und kooperieren, um Aufgaben zu lösen. Die flexible
Interaktion zwischen Agenten impliziert unter anderem folgende
Voraussetzungen:
Agenten sind in der Lage zu wissen, welche anderen
Agenten in der Umgebung existieren.
Die Fähigkeiten der Agenten (welchen Dienst oder welche
Funktionalität sie anbieten) sind bekannt.
Den Agenten steht ein Kommunikationsmedium zur Verfügung.
Die Standardisierung dieser architektonischen Elemente
hat den Vorteil, dass Agenten eines (Agenten-) Systems in
der Lage sind, mit Agenten eines anderen Systems zu interagieren.
Ein weithin anerkannter Standard für die Systemarchitektur
von Agentensystemen wurde von der Organisation
Foundation for Intelligent Physical Agents (FIPA) entwickelt
[10]. Die FIPA Organisation wurde 1996 mit dem Ziel
gegründet, Softwarestandards für heterogene, interagierende
Agenten und Agentensysteme zu entwickeln. Einer
der bereits entwickelten Standards ist die Agent Management
Specification [11], in der das in Bild 2 gezeigte Referenzmodell
definiert wird. Darin werden die erforderlichen
Komponenten eines Agentensystems und ihr Aufbau festgelegt.
Ein wesentlicher Bestandteil des FIPA Modells ist das
Agent Management System (AMS). Jedes Agentensystem
besitzt nur ein AMS. Das AMS führt ein Verzeichnis mit den
Bild 2: FIPA Agent Management Referenzmodell [11].
Bezeichnern und Kommunikationsadressen aller Agenten im
System und bietet einen Auskunftsdienst („White Pages“) an.
Wenn ein Agent eine Nachricht an einen anderen Agenten
oder an eine Gruppe von Agenten schicken will, fragt er
beim AMS an und erhält die Adressen, an welche die Nachricht
geschickt werden kann. Befindet sich der gewünschte
Agent in einem anderen System, so wird die Adressanfrage
an das AMS dieses Systems weitergeleitet. Die Registrierung
beim AMS ist für jeden Agenten eines Agentensystems zwingend
erforderlich. Der Directory Facilitator (DF) bietet anderen
Agenten einen “Gelbe Seiten”-Dienst („Yellow Pages“) an.
Agenten können einerseits ihre Dienste beim DF anmelden
und andererseits dort anfragen, welcher Agent welchen spezifischen
Dienst anbietet oder welche Dienste überhaupt
von anderen Agenten angeboten werden. Der Message
Transport Service (MTS) ist die Standard-Kommunikationsinfrastruktur,
die von Agenten zum Nachrichtenaustausch verwendet
wird. Abgesehen von den Methoden zur Kommunikation
werden hier auch Format und Länge der übermittelten
Nachrichten, die Sprache, in der diese codiert sind, sowie
die Semantik der Nachrichten (Ontologie) festgelegt. Eine
Kommunikationssprache für Agenten ist die Agent Communication
Language (ACL).
Codebeispiel 1: Beispiel einer ACL Nachricht.
(inform
sender: agent1
receiver: agent2
content: ok(temperature_sensor_1)
in-reply-to: query(temperature_sensor_1)
reply-with: ok
language: heating_l
ontology: monitor_system
)
Codebeispiel 1 zeigt eine ACL Nachricht, mit der ein
agent1 an agent2 den Status eines Temperatursensors
übermittelt.
3. Technologien zur Realisierung
Zur Unterstützung des Softwareingenieurs bei der Implementierung
von Agentensystemen stehen eine Reihe von
Hilfsmitteln und Technologien zur Verfügung, welche die
Realisierung agentenorientierter Software wesentlich

25
Tabelle 1: Rollen und ihre Verantwortlichkeiten im Modell der Eisenbahnsteuerung.
Rolle
S1
S2
IDLE
TSEG
TOUT
Verantwortlichkeiten und Protokolle
Die Rolle S1 stellt die S-Bahnverbindung zwischen Landbahnhof und Stadbahnhof dar.
• Stelle Transportkapazität von 360 Personen pro Stunde zur Verfügung (180 Personen in jede Richtung)
• Finde dynamisch die am besten geeignete Streckenverbindung, reserviere und befahre die Streckenabschnitte (Protokolle FindTrack,
ReserveTrack, ReleaseTrack).
• Informiere den Zielbahnhof bei Verspätung.
• Stimme Aktionen mit anderen Zügen ab, die gleichzeitig die Rolle S1 wahrnehmen (Protokoll NegotiateGoals).
Die Rolle S2 ist S1 sehr ähnlich und hat dieselben Aufgaben. Sie unterscheidet sich nur in den Zielbahnhöfen.
IDLE stellt die Rolle eines Zuges dar, der keiner S-Bahnlinie zugeordnet ist.
• Überprüfe proaktiv die Zuordnung von Zügen zu S-Bahnlinien, ob Transportkapazitäten erfüllt und Züge effizient eingesetzt werden.
• Verhandle gegebenenfalls mit eingesetzten Zügen, um deren Rolle zu übernehmen (Protokoll NegotiateRole).
Die Rolle TSEG eines Streckenabschnitts interagiert mit den Zügen, um die exklusive Belegung zu einem bestimmten Zeitpunkt zu
gewährleisten.
• Reagiere auf die Weganfrage eines Zuges und versuche, einen Weg von der gegenwärtigen Position zum gewünschten Zielbahnhof
zu finden (Protokoll FindTrack).
• Kontrolliere Reservierungsinformation und erteile die Durchfahrerlaubnis für eine bestimmte Zeitdauer
(Protokolle ReserveTrack und ReleaseTrack).
Die Rolle TOUT einer Weiche entspricht der eines Streckenabschnitts. Zusätzlich existiert die Funktionalität, um die Weichenstellung zu
ändern.
erleichtern. Sie lassen sich in zwei unterschiedliche Kategorien
unterteilen:
Unterstützung durch agentenorientierte Programmiersprachen
und
Unterstützung in Form von APIs und Frameworks.
3.1 Agentenorientierte Programmiersprachen
Mit agentenorientierten Programmiersprachen werden die
agentenorientierten Konzepte direkt durch Elemente einer
Programmiersprache realisiert. Dadurch können Entwurfsstrukturen
leicht auf den Quellcode abgebildet werden. Beispielsweise
ist es auch bei der Objektorientierung einfacher,
einen objektorientierten Entwurf in einer objektorientierten
Programmiersprache wie C++ statt in der strukturierten Programmiersprache
C zu implementieren, da durchgängig dieselben
Grundkonzepte (z.B. Klassen) verwendet werden.
Die bekanntesten agentenorientierten Programmiersprachen
[12] sind: AGENT-0 [13], Concurrent METATEM [14] und
Agent Speak(L) [15]. Bei AGENT-0 wird ein Agent als Satz von
initialen Zielen, Fähigkeiten und Ausführungsregeln definiert.
Wenn eine bestimmte Ausführungsregel zutrifft, werden die
entsprechenden Fähigkeiten des Agenten unter Berücksichtigung
der festgelegten Ziele angewendet. Der Nachteil des
Gebrauchs agentenorientierter Programmiersprachen ist ihre
geringe Präsenz am Markt, die hohen Kosten für die Ausbildung
des Entwicklungspersonals und die deutliche Unreife
dieser Sprachen. Zurzeit ist kein Projekt bekannt, in dem agentenorientierte
Programmiersprachen bei der Entwicklung von
größeren realen Systemen zum Einsatz kommen.
3.2 Agentenorientierte APIs und Frameworks
Eine zweite Form der Entwicklerunterstützung sind umfangreiche
agentenorientierte APIs (Application Programming
Interfaces) und Frameworks.Sie ermöglichen die Implementierung
des Agentensystems auf hoher Abstraktionsebene, da
das Agentensystem auf Basis vorhandener Programmbibliotheken
und Komponenten realisiert wird. APIs bieten hierfür
eine Reihe agentenspezifischer Funktionalitäten, die dann bei
der Implementierung verwendet werden können. Frameworks
erlauben sowohl die Wiederverwendung von Quellcode als
auch von Architektur. Sie bieten vollständige (teilweise auch
standardisierte) Lösungen für wiederkehrende Aufgaben bei
der Realisierung von Agentensystemen wie Kommunikation,
Synchronisation, Verwaltung von Agenten usw. Die Aufgabe
des Entwicklers beschränkt sich auf die Implementierung der
anwendungsspezifischen Funktionalität.
Solche APIs und Frameworks sind häufig in objektorientierten
Programmiersprachen implementiert, was die Einarbeitung
für den Ingenieur (im Gegensatz zur Verwendung
agentenorientierter Programmiersprachen) wesentlich vereinfacht.
Dabei stellt sich natürlich die Frage, wie bei Verwendung
einer objektorientierten Programmiersprache ein
agentenorientiertes System entstehen kann. Die wichtigste
Voraussetzung bei der Entwicklung agentenorientierter
Software ist die agentenorientierte Betrachtung und Modellierung
der realen Problemstellung. Erst dadurch wird die
Realisierung von Agentensystemen möglich und die Implementierung
stellt dann lediglich die Abbildung der agentenorientierten
Konzepte auf die verwendete Programmiertechnologie
dar. Wie diese Abbildung geschehen kann, zeigt
das Anwendungsbeispiel in Abschnitt 4.
Auch hier kann die Parallele zur objektorientierten Softwareentwicklung
gezogen werden. Ein System kann auf
Basis der objektorientierten Konzepte entwickelt, aber mit
einer nicht-objektorientierten Programmiersprache wie C
implementiert werden. Zwar entsteht ein mehr oder weniger
großer zusätzlichen Aufwand, um die objektorientierten
Konzepte auf die Programmiersprache abzubilden,
grundsätzlich ist es aber möglich. Auf ähnliche Weise können
Systeme auf Basis der agentenorientierten Konzepte analysiert
und modelliert werden und mit Technologien implementiert
werden, die den Agentenansatz nicht direkt widerspiegeln.
Ein Beispiel für eine agentenorientierte API ist das Aglets
Software Development Kit (als Open Source verfügbar) [16].
Die Aglets API ist in Java implementiert und umfasst Basis-

26
klassen für einzelne Agenten, Nachrichten und Kommunikationsmechanismen.
Sie bietet eine Infrastruktur zur Implementierung
mobiler Agenten, die zwischen verschiedenen
Rechnern migrieren und lokal ausgeführt werden können.
Ein Beispiel für ein Framework ist das Open Source Projekt
JADE (Java Agent DEvelopment Framework) [17]. JADE
unterstützt die Entwicklung von Agentensystemen mit einer
FIPA-Standard konformen Kommunikationsschicht und
durch Werkzeuge für Konfiguration, Verwaltung und Debugging
von Agentensystemen, die auch auf mehrere Rechner
verteilt werden können. Die Lightweight Extensible Agent
Platform (LEAP) [18] ist eine Erweiterung von JADE für den
Einsatz in Systemen mit begrenzten Hardwareressourcen
wie Mobiltelefonen, PDAs oder Pocket PCs. Weitere Beispiele
für APIs und Frameworks sind ZEUS [19], JATLite [20], FIPA-OS
[21], AGENTBUILDER [22], JACK [23] und Grasshopper [24].
4. Implementierung eines
Anwendungsbeispiels
Nach der allgemeinen Einführung in den Aufbau von Agentensystemen
und die Technologien zur Implementierung soll
nun die Realisierung eines Agentensystems an einem einfachen
Anwendungsbeispiel veranschaulicht werden. Als Beispielanwendung
dient die Steuerung einer Eisenbahn. Im Folgenden
werden die wesentlichen Aspekte der Realisierung,
die konkrete Festlegung der Architektur des Agentensystems
und die Implementierung der einzelnen Agenten sowie ihrer
Rollen vorgestellt. Das Beispiel zeigt, wie die agentenorientierte
Eisenbahnsteuerung als funktionsfähiges Softwaresystem
implementiert werden kann. Abschließend werden Funktionsweise
und Vorteile der agentenorientierten Lösung
anhand einiger Einsatzszenarien demonstriert.
4.1 Anwendungsbeispiel Eisenbahnsteuerung
Im zweiten Teil dieses Beitrags wurden eine agentenorientierte
Analyse und ein Entwurf für die Eisenbahnsteuerung
durchgeführt und ein agentenorientiertes Modell für die
Steuerung entwickelt [6]. Die Anforderungen der Steuerung
sind im Folgenden noch einmal kurz zusammengefasst:
Die Eisenbahnanlage besteht aus
den drei Bahnhöfen Stadtbahnhof,
Landbahnhof und Hafenbahnhof. Zwischen
Stadtbahnhof und Landbahnhof
L
bestehen drei Gleisverbindungen, zwischen
Hafenbahnhof und Stadtbahn-
K
hof eine (Bild 3). In einem Betriebswerk
können nicht benötigte oder defekte
Züge abgestellt werden (Bild 3 rechts
unten). Zwischen Stadt- und Landbahnhof
verkehrt die S-Bahnlinie S1
Landbahnhof
mit 360 Fahrplätzen je Stunde (180 in
jede Richtung). Eine zweite S-Bahnlinie
S2 verbindet den Stadtbahnhof mit
dem Hafenbahnhof mit 180 Fahrplätzen
je Stunde (90 in jede Richtung). Ein
Zug benötigt unabhängig von seiner
Länge 18 Minuten, um die Strecke zwischen Land und Stadt
zurückzulegen und 8 Minuten für die Strecke zwischen Stadt
und Hafen. Für den Fahrbetrieb stehen folgende Züge zur
Verfügung: Drei kurze Züge K1, K2 und K3, mit einer Kapazität
von jeweils 30 Personen und zwei lange Züge, L1 und
L2, mit einer Kapazität von je 60 Personen.
Während des Betriebes können im Wesentlichen die drei
unerwarteten Fehlersituationen Zugverspätung, Zugausfall
und Streckenausfall auftreten, auf welche die Steuerung
dynamisch reagieren muss. Die Steuerung muss in der Lage
sein, diese Fehlersituationen so zu handhaben, dass zum
einen die Transportkapazität jeder Verbindung möglichst
optimal erfüllt wird und zum anderen die verfügbaren Ressourcen
des Systems (Züge und Streckenelemente) bestmöglich
verteilt werden.
Basierend auf diesen Anforderungen wurde in [6] eine
automatisierte Steuerung des Fahrbetriebs der Eisenbahn
entworfen. Die Komplexität der Steuerung entsteht durch
die Tatsache, dass die Gesamtheit der Situationen im
Betrieb und somit die optimale Auflösung einer bestimmten
Fehlersituation zur Entwurfszeit nicht vollständig
bestimmt werden kann. Das im zweiten Teil dieses Beitrags
[6] mit der agentenorientierten Methode Gaia [25]
entwickelte agentenorientierte Modell gibt deshalb lediglich
die elementaren Strukturen, Mechanismen und
Regeln der Eisenbahnsteuerung vor, auf deren Basis die
Agenten der Steuerung zur Laufzeit dynamisch und flexibel
das der jeweiligen Situation angemessene Verhalten
ermitteln.
Der Schwerpunkt bei der agentenorientierten Modellierung
lag auf der Betrachtung der Aufgaben, die durch die
Eisenbahnsteuerung bewältigt werden müssen, ihrer Aufteilung
in so genannten Rollen und der Interaktionen zwischen
den verschiedenen Rollen zur Bewältigung ihrer Aufgaben.
Tabelle 1 gibt eine Übersicht über die identifizierten Rollen
im agentenorientierten Modell der Steuerung, ihre Verantwortlichkeiten
und die Protokolle, mit denen sie zur Erfüllung
ihrer Aufgaben interagieren.
Bild 4 gibt einen Überblick über die Zusammenhänge der
identifizierten fünf Rollen und fünf Protokolle. Die einzelnen
Rollen sind durch Rechtecke dargestellt, die Protokolle durch
Verbindungen zwischen den Rollen. Rollen, welche die glei-
= 60 Plätze (2x)
= 30 Plätze (3x)
S1
Hafenbahnhof
S2
Stadtbahnhof
18 min.
360 Personen/Stunde
Bild 3: Schematische Darstellung der Eisenbahn.
8 min.
180 P./Std.

27
Negotiate Goals
S1
S2
TSEG
TOUT
Negotiate Role
Find Track, Reserve Track, Release Track
Find Track
IDLE
Bild 4 Übersicht über die Rollen und Protokolle der Eisenbahnsteuerung.
Train
+
Track
+
Turnout
+
S1 S2 IDLE TSEG TOUT
Bild 5: Agentenmodell mit der Zuordnung von Rollen zu Agententypen.
chen Protokolle verwenden, sind zur Vereinfachung zusammengefasst.
Die Rollen werden von den aktiven Elementen des
Systems, den Agenten, wahrgenommen. Aktive Elemente im
Modell der Eisenbahnsteuerung sind Züge, Streckenabschnitte
und Weichen. Sie werden als Agententypen modelliert.
Bild 5 zeigt das Agentenmodell der Eisenbahnsteuerung,
in dem die drei Agententypen dargestellt sind: der
Agententyp Train für Züge, der Agententyp Track für
Streckenabschnitte und der Agententyp Turnout für Weichen.
Agenten vom Typ Train können die Rollen S1, S2 oder
IDLE wahrnehmen. Agenten vom Typ Track übernehmen die
Rolle TSEG und Agenten vom Typ Turnout die Rolle TOUT.
Das ‘+‘ zeigt an, dass im System von jedem Typ mindestens
ein Agent existiert.
Das vorgestellte agentenorientierte Modell beschreibt
alle wesentlichen Elemente der Eisenbahnsteuerung und ist
die Basis für die Realisierung der Steuerung als Agentensystem.
struktur eine kleine API in Form einiger Hilfsklassen selbst
realisiert und diese direkt in das System integriert. Damit
kann die Umsetzung der agentenorientierten Konzepte gut
veranschaulicht werden. Für ein umfangreicheres System ist
allerdings die Verwendung einer bestehenden API oder
eines Frameworks mit entsprechender Unterstützung des
Entwicklers sinnvoll.
Das aus Gaia resultierende agentenorientierte Modell
beschreibt zwar alle gewünschten Eigenschaften des agentenorientierten
Systems, allerdings auf einer hohen Abstraktionsebene.
Für die konkrete Implementierung muss dieser
Entwurf noch weiter verfeinert werden. Da die objektorientierte
Programmiersprache Java für die Implementierung
verwendet wird, beschreiben wir den Feinentwurf mit einem
Klassendiagramm. Bild 6 zeigt den relevanten Ausschnitt aus
diesem Diagramm, das aus dem Gaia-Modell abgeleitet
wurde. Die Agententypen und Rollen werden hier durch einzelne
Klassen repräsentiert. Daneben gibt es die Hilfsklassen
Mqueue und Clock,welche die Infrastruktur für die Agenten
bereitstellen.
Die Klasse Agent enthält allgemeine Eigenschaften und
Dienste, die ein Agent für das System bereitstellen muss, z.B.
Kommunikationsmechanismen (durch Austausch von Nachrichten),
mit deren Hilfe die im Modell definierten Protokolle
implementiert werden. Die drei Arten von Agenten, die im
Gaia-Modell identifiziert wurden (siehe Abschnitt 4.1), werden
als Unterklassen Train, Track und Turnout der
Klasse Agent realisiert.
Die Klasse Agent hat Assoziationen zu den Hilfsklassen
Clock und MQueue. Clock ist ein einfacher Zeitgeber, der
in regelmäßigen Abständen Nachrichten an den Agenten
schickt. Durch diesen Mechanismus wird auf einfache Weise
die dauerhafte Aktivität des Agenten erreicht. Der Agent
kann damit unabhängig von externer Aktivierung (durch
einen Benutzer oder andere Agenten) selbstständig agieren
und seine Ziele verfolgen (Proaktivität).
Die Hilfsklasse MQueue bietet dem Agenten einen asynchronen
Kommunikationskanal. Nachrichten, die ein Agent
empfängt, werden von ihm in MQueue in einer Warteschlange
gespeichert und können dann vom Agenten
sequentiell abgearbeitet werden. Der Sender muss nicht
warten, bis die Verarbeitung beendet ist, und dem Empfänger
wird automatisch signalisiert, wenn eine Nachricht
ankommt.
Die Klasse Role repräsentiert die verschiedenen Rollen,
die ein Agent während des Betriebs annehmen kann. In
4.2 Implementierung
Im letzten Entwicklungsschritt muss
das erstellte Modell als Agentensystem
implementiert werden. Für die Implementierung
wird die Programmiersprache
Java verwendet. In diesem kleinen
Beispiel kommt keines der in Abschnitt
3 genannten umfangreichen agentenorientierten
Frameworks oder APIs
zum Einsatz. Statt dessen haben wir für
die benötigte einfache Agenteninfra-
Clock
Agent
MQueue
Track
Train
Turnout
TSEG
TOUT
S1
Bild 6: Klassendiagramm der Implementierung.
Role
S2
IDLE

28
Codebeispiel 2: Implementierung der Klassen Agent und Train.
abstract class Agent {
Role currentRole;
Directory roleDB;
String ID;
Clock timer;
MQueue messageQueue;
synchronized void receive (Message m) {
messageQueue.enqueue(m);
}
void send (Message m, Agent receiver) {
receiver.receive(m);
}
void setRole (Role newRole) {
roleDB.changeEntry(this, newRole);
currentRole = newRole;
}
String getID() {
return ID;
}
}
public class Train extends Agent {
Train(){
currentRole = new IDLE();
// Constructor. Initial role of a
train is IDLE.
}
void driveTrack() {
// Controls the train on the railway.
}
void informDelay(Station destination){
// Informs destination station of a
delay
}
}
unserem Beispiel kann ein Agent zu einem bestimmten Zeitpunkt
nur einer einzigen Rolle zugeordnet sein. Die konkreten
Rollen TSEG, TOUT S1, S2 und IDLE sind von dieser
Klasse abgeleitet. Codebeispiel 2 zeigt das Codegerüst der
Klassen Agent und Train.
Die aktuelle Rolle eines Agenten ist im Attribut currentRole
vom Typ Role der Klasse Agent abgelegt.Wenn der
Agent eine Nachricht erhält, stellt er sie mit der Methode
enqueue() in MQueue. MQueue leitet die Nachricht an
die Methode processMessage() der aktuellen Rolle des
Agenten weiter. Je nach momentaner Rolle des Agenten
wird die Nachricht unterschiedlich verarbeitet. Hier wird also
Polymorphie verwendet, um das dynamische, flexible Verhalten
der Agenten zu realisieren. In der Klasse Train wird die
Klasse Agent um die spezifische Funktionalität erweitert,
die zur Kontrolle der Züge (driveTrack) notwendig ist.
Die Änderung der Rolle des Agenten zur Laufzeit wird in der
Methode setRole implementiert. Diese ändert die Information
in der Variablen roleDB,erzeugt eine neue Instanz
Codebeispiel 3: Implementierung der Klassen Role und IDLE.
public abstract class Role {
Agent currentAgent;
abstract void processMessage(Message m);
}
public class IDLE extends Role {
RoleInfo CheckRoles() {
// Retrieves information from the roleDB
}
synchronized void processMessage(
Message m){
// Process message according to IDLE
requirements.
// The assignment information can be
retrieved,...
RoleInfo result = CheckRoles();
// ...a message can be sent...
currentAgent.send(m, agent_A);
// ... a role change can be performed
(e.g. IDLEàS1)
Role newRole = new S1();
currentAgent.setRole(newRole);
// (...)
}
}
der entsprechenden Rollenklasse und ändert die Referenz in
currentRole.
Codebeispiel 3 zeigt das Codegerüst der Klassen Role
und IDLE. Die Klasse Role hat eine Methode Process-
Message(), die von jeder ihrer Unterklassen S1, S2 und
IDLE implementiert werden muss. Die Methode enthält
das Verhalten der Rolle und wird vom Agenten aufgerufen,
wenn er eine Nachricht aus der Nachrichtenwarteschlange
abarbeitet. Eine Nachricht kann entweder von einem anderen
Agenten als Teil einer Interaktion oder von Clock (in
regelmäßigen Zeitabständen) stammen.
Als Beispiel für die Implementierung einer Rolle wird in
Codebeispiel 3 die Klasse IDLE gezeigt. Die Hauptverantwortlichkeit
von IDLE, wie sie in Abschnitt 4.1 spezifiziert
wurde, drückt sich in der Codesequenz von ProcessMessage()
aus: Die Abfolge besteht aus:
1. Überprüfung der Zuordnung von Agenten zu Rollen,
2. Nachrichtenaustausch während der Verhandlungen über
die Rolle,
3. möglicher Tausch der Rolle am Ende der Verhandlungen.
Details der Implementierung wurden hier weggelassen.
Die vorgestellte Realisierung der agentenorientierten
Eisenbahnsteuerung hat prototypischen Charakter. Sie ist
keineswegs auf Geschwindigkeit oder minimalen Speicherbedarf
optimiert. Die implementierten Algorithmen sind
stark vereinfacht und sehen in der realen Eisenbahnsteuerung
komplexer aus [26]. Das Implementierungsbeispiel orientiert
sich nicht an existierenden Standards für Agentensysteme
(z.B. FIPA), da die Realisierung der dafür notwendi-

29
gen Infrastruktur den Rahmen gesprengt hätte. In diesem
Beispiel ging es uns vielmehr darum, die grundsätzlichen
Schritte und Mechanismen zu verdeutlichen, die zur „Übersetzung“
eines agentenorientierten Modells in ein agentenorientiertes
System notwendig sind.
4.3 Szenarien beim Einsatz des Systems
Im Folgenden sollen die Merkmale der entwickelten agentenorientierten
Steuerung anhand einiger Szenarien verdeutlicht
werden. In jedem Szenario wird gezeigt, wie sich
die grundlegenden Agentenkonzepte aus Analyse und Entwurf
im Verhalten des Systems widerspiegeln.
Zu Beginn der Ausführung wird das Element roleDB
erzeugt, in dem die Rollen der Agenten abgelegt sind. Im Fall
der Züge wertet jeder Agent seine eigene Transportkapazität
aus und ermittelt die passende Rolle (siehe Abschnitt
4.1, IDLE Rolle). Nach einer anfänglichen Phase von Interaktionen
zwischen den Agenten zur Festlegung der Rollen
wird die effizienteste Konfiguration erreicht: Die beiden langen
Züge sind der Rolle S1 zugeordnet und einer der kurzen
Züge, z.B. K1 ist S2 zugeordnet. Die restlichen Züge K2 und K3
warten im Betriebswerk (Bild 7).
Szenario 1: Erreichen gemeinsamer Ziele
Erreicht der Zug K1 auf der Linie S2 aus irgendeinem Grund
verspätet den Stadtbahnhof, so ist sein Fahrplan nicht mehr
synchron zu S1. Dies würde für Fahrgäste, die vom Landbahnhof
zum Hafenbahnhof fahren wollen, eine längere
Wartezeit bedeuten. In diesem Fall informiert der Zug von
S2 den Stadtbahnhof über die Verzögerung, der diese Information
wiederum an alle Züge weiterleitet, die im Stadtbahnhof
halten oder in naher Zukunft ankommen werden.
Diese Züge können dann bestimmen, ob sie ihre Fahrpläne
ändern, um auf den verspäteten Zug zu warten. Wird beispielsweise
der Zug K1 in der Rolle S2 zwei Minuten später
als geplant am Stadtbahnhof ankommen, leitet dieser die
Information an L1 weiter, der gerade dort ankommt. Jede
Stunde muss L1 drei Mal zwischen Land und Stadt verkehren,
braucht jedoch nur 54 Minuten (jede 18 Minuten). L1
L
K
= 60 Plätze
= 30 Plätze
Hafenbahnhof
S2
8 min.
180 P./Std.
analysiert seine Ziele und entscheidet, dass eine Verspätung
von zwei Minuten wegen des Zeitpuffers im Fahrplan
annehmbar ist. Die Änderung seines Fahrplans wird vorgenommen
und das gemeinsame Ziel, die Wartezeit für die
Fahrgäste zu reduzieren, wird erreicht.
Szenario 2: Reaktionsfähigkeit auf Fehler im System
Nehmen wir an, dass L2, der in der Rolle S1 eingesetzt ist
(siehe Bild 7), defekt ist und zur Reparatur ins Betriebswerk
gefahren werden muss. Die Anforderungen an die Transportkapazität
von S1 sind nicht mehr erfüllt, da L1, der zweite
lange Zug mit der Rolle S1, maximal 180 Personen pro
Stunde befördern kann.
Auf seinem Weg ins Betriebswerk gibt L2 die Rolle S1 auf
und ändert die Information in roleDB.Die freien Züge K2 und
K3 (in der Rolle IDLE) erkennen den Wechsel der Zuordnungen
und übernehmen gemeinsam mit L1 die Rolle S1. Die
drei Züge müssen nun ihre Aktionen koordinieren, um die
Anforderungen von S1 so gut wie möglich zu erfüllen. Die
Agenten interagieren über das negotiateGoals Protokoll, bis
sie die geeignete Anordnung gefunden haben: Die beiden
kurzen Züge fahren im Gegentakt auf den unteren parallelen
Strecken zwischen Land, Stadt und zurück. Das heißt ein Zug
startet im Landbahnhof und der andere gleichzeitig im
Stadtbahnhof (da in den Bahnhöfen für beide nur ein Gleis
zur Verfügung steht). Mit diesem Fahrplan werden insgesamt
360 Personen befördert, allerdings nicht gleichmäßig
auf beide Richtungen verteilt (150 zu 210). Im Mittel von
zwei Stunden wird das Ziel erreicht und damit die Anforderung
fast erfüllt.
Szenario 3: Optimierung der Ressourcennutzung
Nach einer gewissen Zeit für die Wartung ist L2 wieder fahrbereit.
Er nimmt die Rolle IDLE an und prüft die Zuordnungen
von Agenten zu Rollen. Dabei stellt L2 fest, dass K2 und
K3 für S1 eingesetzt werden und beginnt mit beiden das
negotiateRole Protokoll, um die Rolle S1 wieder anzunehmen.
Nachdem die Transportkapazitäten verglichen wurden,
entscheiden K1 und K2, ihre Rollen aufzugeben, da sie die
Anforderung der Transportkapazität
nicht vollständig erfüllen und zusätzlich
mehr Ressourcen – zwei Strecken
gleichzeitig – als L2 für dieselbe Aufgabe
benötigen. Nachdem sie die Rolle
S1 aufgegeben haben, nehmen K1 und
K2 wieder die Rolle IDLE an.
K1
L1
Landbahnhof
L2
S1
Bild 7: Ausgangssituation des Eisenbahnbetriebs
Stadtbahnhof
18 min.
360 Personen/Stunde
K2
K3
Szenario 4: Anpassung an eine sich
ändernde Umgebung
Nachdem die Linie S1 jetzt wieder
durch die beiden langen Zügen L1 und
L2 bedient wird, tritt eine weitere Fehlersituation
auf: Die obere Strecke zwischen
Landbahnhof und Stadtbahnhof
ist nicht mehr verfügbar. Zuvor hatte L1
die obere Strecke für die Verbindung

30
zwischen Land und Stadt benutzt und befindet sich gerade
im Landbahnhof. Nachdem L1 und L2 das Problem erkannt
haben, initiieren sie das negotiateGoals Protokoll, um die
Benutzung der noch verfügbaren Ressourcen abzustimmen
(hier die unteren Strecken). Die Lösung ist die Benutzung der
zweiten unteren Strecke durch L1 im Gegentakt zu L2. Ab
hier sind die Anforderungen der Rolle S1 wieder erfüllt, da
drei Fahrten in jeder Richtung jede Stunde stattfinden.
Die vorgestellten Szenarien zeigen einen Ausschnitt, aber
keine umfassende Demonstration der Möglichkeiten des
agentenorientierten Transportsystems. Weitere Fehlerszenarien,
gegebenenfalls auch bisher unbekannte, können flexibel
gehandhabt werden. Gerade die Anpassungsfähigkeit
des Systems an unerwartete Situationen ist ein Vorteil des
agentenorientierten Ansatzes. Sicherlich können in diesem
Beitrag nicht alle Aspekte des Systems detailliert dargestellt
werden. Dies betrifft insbesondere die genaue Beschreibung
der Entscheidungsprozesse innerhalb eines Agenten, die
den Rahmen dieses Beitrags sprengen würde. Vielmehr soll
das Beispiel einen Eindruck über den gesamten Entwicklungsprozess
eines agentenorientierten Systems geben, die
Denkweise bei der agentenorientierten Softwareentwicklung
veranschaulichen und die spezifischen Merkmale hervorheben.
4.4 Agentenspezifische Merkmale des Systems
Die gezeigten Szenarien veranschaulichen die Umsetzung
der agentenorientierten Grundkonzepte Autonomie, Interaktion,
Reaktivität, Zielorientierung und Proaktivität in unserem
Beispiel. Sie zeigen, wie die in den Protokollen spezifizierten
Interaktionen zwischen den Agenten ablaufen, um
Verhandlungen über Ressourcen oder gemeinsame Aktivitäten
zu führen. Diese Kooperation ist ein zentrales Merkmal
des agentenorientierten Systems. Der asynchrone Nachrichtenkanal
Mqueue ermöglicht die Trennung zwischen Nachrichtenaustausch
der Agenten und der Nachrichtenbearbeitung
innerhalb eines Agenten und ist somit die Basis für das
autonome Verhalten der Agenten. Flexibles, dynamisches
Verhalten wird erreicht durch die getrennte Implementierung
der Agenten und ihrer möglichen Rollen. Die regelmäßigen
internen Nachrichten des Zeitgebers Clock an die
Agenten ermöglichen eine kontinuierliche Erfassung der
Umgebung und Verfolgung der Ziele ohne externe Aktivierung.
Dies ist der Basismechanismus zur Implementierung
von Proaktivität. In den Szenarien ist dieser Mechanismus für
die Agenten notwendig, um Fehler selbstständig zu erkennen
und das System anzupassen. Weiter steht in den Szenarien
das Konzept der Zielorientierung im Vordergrund. Das in
den verschiedenen Rollen eines Agenten spezifizierte Verhalten
beeinflusst seine Aktionen so, dass die Ziele des
Systems in der bestmöglichen Weise erfüllt werden können.
5. Zusammenfassung und Ausblick
Der letzte Schritt einer agentenorientierten Softwareentwicklung
ist die Implementierung des entwickelten Agentensystems.
Die Umsetzung der agentenorientierten Grundkonzepte
Autonomie, Interaktion, Reaktivität, Zielorientierung
und Proaktivität in ausführbare Programmstrukturen
kann auf Basis der existierenden Mechanismen und Technologien
der Softwaretechnik erfolgen. Hierfür ist ein grundlegender
Aufbau von Agentensystemen mit Elementen für die
Kommunikation und Verwaltung der Agenten erforderlich.
Existierende Standards für Agentensysteme wie der FIPA-
Standard vereinfachen ihren industriellen Einsatz.
Zur Unterstützung des Entwicklers bei der Implementierung
selbst existieren verschiedene agentenorientierte Programmiersprachen,
APIs und Frameworks, wobei APIs und
Frameworks die weitaus größere Praxistauglichkeit aufweisen.
Sie sind häufig in objektorientierten Programmiersprachen
realisiert. Dies ist jedoch kein Nachteil oder Widerspruch
in der agentenorientierten Softwareentwicklung,
weil die agentenspezifischen Konzepte durchaus auf Basis
von objektorientierten Sprachen und Technologien realisiert
werden können. Aufgrund der Verbreitung objektorientierter
Technologien ist dies sogar ein sinnvoller Weg für die
breite Einsetzbarkeit von Agentensystemen.
Nick Jennings, einer der Pioniere der Agentenorientierung,
hat diesen Zusammenhang folgendermaßen ausgedrückt
[27]: „... it is possible for proponents of other software
engineering paradigms to claim that the key concepts of agentoriented
computing can be reproduced using their technique –
this is undoubtedly true. Agent-oriented systems are, after all,
computer programs and all programs have the same set of
computable functions. However, this misses the point.The value
of a paradigm is the mindset and the techniques it provides to
software engineers.“ Entscheidend für die erfolgreiche Entwicklung
von Agentensystemen ist also die konsequente
Umsetzung der agentenorientierten Denkweise während
des gesamten Entwicklungsprozesses. Diese Denkweise
wurde anhand der agentenorientierten Modellierung und
Implementierung einer Eisenbahnsteuerung veranschaulicht.
Dabei wurden die einzelnen Schritte verdeutlicht, die
bei der agentenorientierten Softwareentwicklung wichtig
sind und es wurde gezeigt, wie sich die Agentenkonzepte im
Verhalten des Systems zur Laufzeit ausdrücken.
In dem Anwendungsbeispiel wurde auch deutlich, dass
die Methode Gaia bei der Entwicklung agentenorientierter
Systeme einige Schwächen aufweist. Es ist erkennbar, dass
die Ergebnisse der agentenorientierten Analyse und des
agentenorientierten Entwurfs mit Gaia auf einer zu hohen
Abstraktionsebene vorliegen. Sie können nicht direkt für die
Implementierung verwendet werden. Daneben können
einige wichtige Aspekte bei der Softwareentwicklung nicht
explizit im Modell ausgedrückt werden. Dazu gehören die
aus den Anforderungen abgeleiteten Ziele des Systems, die
Entscheidungsprozesse innerhalb der Agenten und Elemente
des Systems, die keine Agenten sind (wie z.B. der
Bahnhof im Anwendungsbeispiel). Für einen breiten industriellen
Einsatz der agentenorientierten Softwareentwicklung
müssen Methoden zur Verfügung stehen, die alle relevanten
Aspekte der Aufgabenstellung und des Entwicklungsprozesses
berücksichtigen. Dazu gehören auch die
besonderen Anforderungen bei der Entwicklung von Software
für technische Systeme, wie beispielsweise zeitliche
Anforderungen. Deshalb werden am Institut für Automati-

31
sierungs- und Softwaretechnik (IAS) der Universität Stuttgart
im Forschungsgebiet Agentenorientierte Echtzeitsystem Konzepte,
Methoden und Werkzeuge entwickelt, welche die Entwicklung
von agentenorientierten Automatisierungssystemen
unterstützen. Dazu gehört insbesondere die Berücksichtigung
von Echtzeiteigenschaften. Hierzu wird die
Erweiterung agentenorientierter Methoden untersucht. Dies
geschieht zum einen auf konzeptioneller Ebene unter
Berücksichtigung der spezifischen Konzepte der Automatisierungstechnik,
zum anderen auf der Ebene der konkreten
Realisierung von Systemen mit beschränkten Ressourcen
[28].
Ein weiteres Forschungsthema am IAS ist das agentenbasierte
Engineering von Automatisierungssystemen. Das
Engineering von Automatisierungssystemen ist ein umfangreicher,
vielfältiger und komplexer Vorgang mit Tätigkeiten
zur Planung, Errichtung, Inbetriebnahme, Betrieb und
Instandhaltung technischer Anlagen. Die klassische Arbeitsweise
beim Engineering ist geprägt durch getrennte Sichten
(Gewerke) der einzelnen Ingenieurdisziplinen auf die Anlage
und gewerkespezifische Engineering-Prozesse, Werkzeuge
und Daten. Die mangelnde Durchgängigkeit der Engineering-Daten,
die fehlende Unterstützung von Engineering-
Prozessen und die geringe Möglichkeit der Wiederverwendung
von erstellten Automatisierungslösungen erfordern
neue Konzepte. Komponentenbasierte Ansätze vereinfachen
den Entwurf von Automatisierungsanlagen durch die
Integration der Engineering-Daten in ein einziges Modell
unter dem übergeordneten Gesichtspunkt von technologischen
Komponenten, durch das die einzelnen Sichten integriert
werden. Um den Entwicklungsingenieur effektiv zu
unterstützen, ist eine Integration der Daten nicht ausreichend.
Ein weitergehender Ansatz ist der Einsatz von aktiven
Komponenten, die autonom ihre vielfältigen Verknüpfungen
und Abhängigkeiten zu anderen Komponenten in der
Anlage handhaben. Zudem können durch Kooperation
Arbeitsabläufe und Wiederverwendung von Engineering-
Lösungen unterstützt bzw. automatisiert werden. Basis für
die aktiven Komponenten ist die agentenorientierte
Betrachtung der Arbeitsabläufe beim Engineering. Dadurch
kann eine Engineering-Umgebung geschaffen werden, in
der die statischen Engineering-Daten durch aktive Softwareagenten
repräsentiert werden, die den Entwicklungsingenieur
bei seinen Aufgaben effektiv unterstützen und darüber
hinaus Aufgaben der technischen Betriebsbetreuung
selbstständig wahrnehmen [29].
Weitere Informationen zur Forschung am IAS auf
dem Gebiet Agenten in der Automatisierungstechnik und
zu dem in diesem Beitrag vorgestellten Anwendungsbeispiel
finden sich auf der Homepage des Instituts unter
http://www.ias.uni-stuttgart.de/agenten.
Wir danken allen Mitarbeitern und Studierenden des IAS, die uns bei der
Erstellung dieses Beitrags unterstützt haben.
Literatur + Links
Zu diesem Beitrag finden Sie sämtliche Literaturreferenzen im Internet
unter der Adresse http://www.ias.uni-stuttgart.de/agenten
Dipl.-Ing. Thomas Wagner (29) ist seit 2 Jahren als
wissenschaftlicher Assistent am Institut für Automatisierungs-
und Softwaretechnik (IAS) der Universität
Stuttgart auf dem Gebiet Agenten in der
Automatisierungstechnik tätig. Sein Aufgabenschwerpunkt
ist agentenbasiertes Engineering von
Automatisierungssystemen.
Adresse: Institut für Automatisierungs- und Softwaretechnik,
Pfaffenwaldring 47, D-70550 Stuttgart,Tel. (07
11) 6 85-72 95, E-Mail: wagner@ias.uni-stuttgart.de
Prof. Dr.-Ing. Dr. h. c. Peter Göhner (53) ist Leiter des
Instituts für Automatisierungs- und Softwaretechnik
(IAS) an der Universität Stuttgart. Hauptarbeitsgebiete:
Angewandte Softwaretechnik, Komponentenbasierte
Entwicklung von Automatisierungssystemen,
Verlässlichkeit von Prozessautomatisierungssystemen,
Web-basierte Aus- und Weiterbildung,
Web-Technologien in der Automatisierungstechnik
und Agenten in der Automatisierungstechnik.
Seit Oktober 2000 ist er Prorektor für
Lehre und Weiterbildung der Universität Stuttgart.
Adresse: Siehe oben, Tel. (07 11) 6 85-73 01, E-Mail:
goehner@ias.uni-stuttgart.de
M. Sc. Paulo G. de A. Urbano (27) ist seit 2 Jahren als
wissenschaftlicher Mitarbeiter am Institut für Automatisierungs-
und Softwaretechnik (IAS) der Universität
Stuttgart auf dem Gebiet Agenten in der
Automatisierungstechnik tätig. Sein Aufgabenschwerpunkt
sind agentenorientierte Echtzeitsysteme.
Adresse: Siehe oben, Tel. (07 11) 6 85-73 21, E-Mail:
urbano@ias.uni-stuttgart.de