A Abbildungsverzeichnis
B Listings
C Abkürzungsverzeichnis
Teil I. Einführung und Grundlagen
1. Einführung in die Thematik
1.1 Problemstellung und Ziele
1.2 Aufbau des Dokumentes
2. Workflow-Management
2.1 Begrifflichkeiten
2.1.1 Geschäftsprozess und Workflow
2.1.2 Geschäftsprozess-Management und Workflow-Management
2.1.3 Workflow-Management-System
2.1.4 Weitere Begriffe
2.2 Terminologie und Darstellung von Workflow-Diagrammen
2.3 Workflow- und Aktivitätszustände
2.4 Das Workflow-Referenzmodell der WfMC
2.5 Anforderungen an WfM-Systeme
2.6 Das CAKE-Framework
2.6.1 Architektur
2.6.2 Workflow-Repräsentation
3. Sensorik
3.1 Architekturen für Sensornetzwerke
3.2 Netzwerktypen
4. Multi-Agenten-Technik
4.1 Der Begriff Software-Agent
4.2 Multi-Agenten-Systeme
4.3 Netzwerktopologien
4.3.1 Client-Server
4.3.2 Peer-to-Peer
4.4 Agentenarchitekturen
4.4.1 Reaktive Agenten
4.4.2 Kognitive Agenten
4.4.3 Schichtenarchitektur
4.5 Interaktion von Agenten
4.5.1 Kooperation
4.5.2 Wettbewerb
4.6 Agentenkommunikation
4.6.1 Spechakttheorie
4.6.2 KQML
4.6.3 Der FIPA-Standard
4.7 Ontologien
Teil II. Konzept
5. Anforderungsananlyse
6. Konzeption des Sensornetzwerkes
6.1 Architektur und Typ des Sensornetzes
6.2 Agententypen
6.3 Interaktion der Agenten
6.4 Konzeption der Agententypen
6.4.1 Sensoragent
6.4.2 Aktivitätsagent
6.4.2.1 Verhaltensweisen und Eigenschaften
6.4.2.2 Mechanismus zur Berechnung der Aktivitätszustände
6.4.3 Workflowagent
6.4.3.1 Verhaltensweisen und Eigenschaften
6.4.3.2 Algorithmus zur Zustandberechnung
6.5 Ontologie
6.6 Schnittstellen
6.6.1 Grafische Benutzeroberfläche
6.6.2 Schnittstelle zu externen WfM-Systemen
6.6.3 Kopplung mit CAKE
7. Die Anwendungsdomäne
7.1 Workflows für das Datenmanagement
7.2 Workflow zur Ersterfassung einer Gemeinde
Teil III. Praktische Entwicklung und Evaluation
8. Programmierwerkzeuge
8.1 Agenten-Framework
8.2 Graphen-Framework
9. Agentendesign
10. Implementierung des Frameworks
10.1 Sensoragent
10.1.1 Konfiguration und Verhaltensweisen
10.1.2 Analyse des reaktiven Verhaltens
10.2 Aktivitätsagent
10.2.1 Verhaltensweisen
10.2.2 Konfiguration und Berechnung der Aktivitätszustände
10.3 Workflowagent
10.3.1 Konfiguration und Verhaltensweisen
10.3.2 Algorithmus zum Aufbau des Sequenzgraphen
10.3.3 Algorithmus zur Berechnung des Zustandes eines Sequenzgraphen
10.3.4 Grafische Oberfläche
10.4 Schnittstelle zu CAKE
10.5 Schnittstelle zu externen WfM-Systemen
11. Test und Evaluation
11.1 Kriteri en zur Evaluation
11.2 Ablauf der Evaluation
11.3 Implementierung der Sensoren und Konfiguration der Agenten
11.4 Ergebnisse der Evaluation
12. Fazit und Ausblick
D Literaturverzeichnis
E Anhang
Für die Koordination der Zusammenarbeit von unterschiedlichen Organisationseinheiten ist es für das Management von modernen Unternehmen wichtig den aktuellen Bearbeitungszustand der Einzelaktivitäten zu kennen um eine Überwachung der Abläufe und damit eine weitere Planung zu ermöglichen. Zum automatischen Erkennen des Zustandes einer Tätigkeit eignen sich vor allem die Ergebnisse der Ausführung, soweit diese in elektronischer Form vorliegen.
Da die einzelnen Tätigkeiten oft zeitlich und räumlich voneinander getrennt durchgeführt werden, liegen die Ergebnisse meist in verteilter Form auf jeweils spezialisierten Informationssystemen vor. Um solche Daten zusammentragen und homogenisieren zu können, bietet sich die Technik der Multi-Agenten-System an. In dieser Arbeit wird die Konzeption und Entwicklung eines Sensornetzwerks beschrieben, das auf der Basis eines Agenten-Frameworks entwickelt wird. Weiterhin wird dargestellt, wie dieser Ansatz in die Anwendungsdomäne des Unternehmens rjm Business Solutions GmbH aus dem Bereich Geoinformationssysteme integriert wird um die dortigen Abläufe transparenter zu gestalten
Abb. 1: Geschäftsprozess-Management und Workflow-Management, Quelle: [AHW03]
Abb. 2: Trennung zwischen Ausführung und Management von Workflows, Quelle: [Aal02].
Abb. 3: Beziehungen zwischen den Grundbegriffen, angelehnt an: [WFM99]
Abb. 4: Begriffe und Symbole, angelehnt an: [WFM99]
Abb. 5: Workflowzustände mit ihren Übergängen, angelehnt an: [WFM95]
Abb. 6: Aktivitätszustände mit ihren Übergängen, angelehnt an: [WFM95]
Abb. 7: Das Workflow-Referenzmodell der WfMC, Quelle: [WFM95]
Abb. 8: CAKE-Architektur, Quelle: [SMM+06]
Abb. 9: Baumstruktur der Kontrollfluss-Darstellung, Quelle: [MTS+07]
Abb. 10: Hierarchische Architektur mit 2 Ebenen, Quelle: [ABJ+06]
Abb. 11: Netzwerktopologien
Abb. 12: Mehrschichtige Client-Server-Architekturen
Abb. 13: Aufbau eines Software-Agenten, angelehnt an: [Fer01]
Abb. 14: Aufbau von reaktiven Agenten
Abb. 15: Architektur des BDI-Agenten
Abb. 16: Schichtenarchitekturen, angelehnt an: [MPT95]
Abb. 17: FIPA-Standard Agent Management Reference Model, Quelle: [FIP04]
Abb. 18: FIPA-Standard für den Lebenszyklus von Agenten, Quelle: [FIP04]
Abb. 19: Hierarchischer Aufbau eines Workflows
Abb. 20: Kommunikationsmodelle des Sensornetzes
Abb. 21: Aufbau des Sequenzgraphen
Abb. 22: Baumstruktur zur Berechnung des Zustandes eines Sequenzgraphen
Abb. 23: Das Informationsportal DenkXWeb, Quelle: [LDH07]
Abb. 24: Workflow zur Ersterfassung einer Gemeinde
Abb. 25: JADE über mehrere Rechner verteilt, Quelle: [BCT+07a]
Abb. 26: Zusammenspiel der Komponenten eines Agenten
Abb. 27: Packagediagramm des Frameworks
Abb. 28: Klassendiagramm des Sensoragenten
Abb. 29: Klassendiagramm des Aktivitätsagenten
Abb. 30: Klassendiagramm des Workflowagenten
Abb. 31: Darstellung eines Workflowzustandes
Abb. 32: Darstellung eines Sequenzgraphen
Abb. 33: Grafische Oberfläche des Transformations-Programms
Abb. 34: Workflow für die Evaluation
Abb. 35: Grafische Darstellung der Evaluationsergebnisse
Listing 1: Struktur einer KQML-Nachricht
Listing 2: Beispiel zur Konfiguration des Sensoragenten
Listing 3: Beispiel zur Konfiguration des Aktivitätsagenten
Listing 4: Beispiel zur Konfiguration des Workflowagenten
Listing 5: Beispiel eines Workflowzustands im XML-Format
Listing 6: Verknüpfung von zwei Ereignissen in der Konfiguration des Aktivitätsagenten
Listing 7: Zusammenfassung der Evaluationsergebnisse
Abbildung in dieser Leseprobe nicht enthalten
In Folge der fortschreitenden Globalisierung sind vor allem international agierende Unternehmen dazu gezwungen, ihre arbeitsteiligen Abläufe weltweit zu verteilen. Aber auch schon bei kleineren Unternehmen kommt es zunehmend dazu, dass logisch zusammengehörige Aktivitäten räumlich voneinander getrennt durchgeführt werden, wodurch sie meist auf mehrere Mitarbeiter verteilt werden. Weiterhin werden in vielen Unternehmen solche Aktivitäten auf Informationssystemen bearbeitet, die sich technisch voneinander unterscheiden, da sie für unterschiedliche Aufgaben konzipiert wurden. Für das erfolgreiche Umsetzen der Geschäftziele ist es daher oft nötig diese verteilten Aktivitäten so zu koordinieren, dass die Gesamtprozesse einheitlich, flexibel und transparent gestaltet sind. Dadurch wird zum einen die Qualität der Prozesse verbessert, was sich positiv auf die Bearbeitungszeiten und damit auch auf die Kosten auswirkt. Zum anderen wird die Verfügbarkeit von Informationen erhöht, wodurch unter anderem eine zuverlässige Planung weiterer Abläufe erreicht wird und Kunden bzw. Partner den aktuellen Status eines Projektes einsehen können. Diese Abstimmung von Einzeltätigkeiten ist ein typisches Anwendungsgebiet des Workflow-Managements (WM).
Diese Arbeit beschäftigt sich vor allem mit dem Aspekt der Informationsverfügbarkeit. Der aktuelle Bearbeitungszustand der Aktivitäten eines Gesamtprozesses soll zu jedem Zeitpunkt vorliegen um so die genannten Verbesserungen zu erreichen. In den meisten herkömmlichen Systemen wird zur Gewinnung von Informationen zum Ermitteln der Bearbeitungszustände die Person, die die jeweilige Aktivität durchführt, von dem System proaktiv zu ihrer momentanen Tätigkeit befragt. Dabei besteht die Gefahr, dass das System z.B. durch Ignorieren der Anfragen falsche Daten erhält und die Bearbeiter einer Mehrbelastung ausgesetzt werden. Diese Vorgehensweise soll ersetzt werden, indem die Ergebnisse der Bearbeitung als Informationsquellen herangezogen werden. Als Resultate von Bearbeitungsvorgängen kommen Änderungen in Frage, die elektronisch nachvollziehbar sind, z.B. Änderungen in Dateien, Dateisystemen, Datenbanken und anderen Anwendungen. Da es eine Vielzahl solcher Informationen gibt, die oft räumlich voneinander getrennt auf verschiedenen Rechnersystemen vorliegen, muss hier eine Technologie benutzt werden, die sich für solche verteilte Systeme eignet.
Das Hauptziel dieser Arbeit ist die Konzeption und Umsetzung eines domänenunabhängigen Sensornetzwerkes, das die automatische Erkennung von Workflowzuständen ermöglichen soll. Dazu soll eine agentenbasierte Architektur verwendet werden, so dass heterogene Informationen zur Erkennung herangezogen werden können, die auf unterschiedlichen Informationssystemen vorliegen. Weiterhin wird das System so konzipiert, dass es über eine universelle Schnittstelle an existierende WfM-Systeme angebunden werden kann. Eine zweite Schnittstelle soll garantieren, dass die Workflow-Darstellung des Frameworks Collaborative
Agent-based Knowledge Engine (CAKE), das seit 2004 am Lehrstuhl für Wirtschaftsinformatik II der Universität Trier entwickelt wird, für das Sensornetz verwendet werden kann. Dazu ist zu klären, welche Netzwerktopologien und Agentenarchitekturen sich für die Realisierung des Systems eignen und welche Form der Interaktion zwischen den Agenten eine effiziente Zustandserkennung ermöglicht. Die praktische Umsetzung des Konzepts erfolgt auf Basis eines vorhandenen Java-Frameworks für Agentensysteme, so dass Informationen kombiniert werden können, die auf unterschiedlichen Betriebssystemen vorliegen. Für die Evaluation der Software werden Datenquellen benutzt, die für ein Projekt zum Erstellen und Pflegen von geobezogenen Fachdaten eingesetzt werden. Dieses Projekt wird von dem Unternehmen rjm Business Solutions GmbH für eine hessische Landesbehörde durchgeführt.
Im ersten Teil der Arbeit werden grundlegende Begriffe geklärt und Technologien detailliert erläutert, die in der gesamten Arbeit Verwendung finden. Zunächst wird die Technik des WfM und ihre Umsetzung im CAKE-Framework beschrieben. Anschließend werden Begrifflichkei- ten aus dem Bereich der Sensorik verdeutlicht. Zuletzt wird die Technologie der Multi-Agen- ten-Systeme (MAS) vorgestellt, indem relevante Agentenarchitekturen, Interaktion und Kommunikation von Agenten sowie weitere Aspekte beschrieben werden.
Im zweiten Teil wird die Entwicklung eines Konzepts für das Sensornetzwerk beschrieben. Dazu wird vorab eine Methodik zum Erstellen des Konzepts festgelegt. Demnach werden zunächst die Anforderungen herausgestellt und die einzelnen Komponenten, aus denen sich das zu entwickelnde Agentensystem zusammensetzt, spezifiziert. Anschließend werden geeignete Agentenarchitekturen für die verschiedenen Komponenten gewählt, die Details der Kommunikation zwischen den Agenten geklärt und Methoden entwickelt, die die verteilten Informationen zusammenführen, repräsentieren und so verarbeiten, dass der Bearbeitungszustand von Workflows bestimmt werden kann. Weiterhin wird eine universelle Schnittstelle entworfen, um das Netzwerk an externe Systeme anzubinden, eine spezielle Schnittstelle zur Kopplung der Software an das CAKE-Framework sowie eine grafische Benutzerschnittstelle. Abschließend wird die Anwendungsdomäne, in die das System integriert werden soll betrachtet. Das Unternehmen rjm Business Solutions GmbH wird vorgestellt und die Arbeitsabläufe, die sich im Rahmen des Projektes DenkXWeb ständig wiederholen, werden strukturiert und analysiert.
Im dritten Teil der Arbeit wird die Implementierung des Systems beschrieben, indem zunächst geeignete Werkzeuge zur Unterstützung der Entwicklung ausgewählt und vorgestellt werden. Daraufhin wird der Aufbau aller Komponenten des Netzwerks dargelegt und die benutzten Methoden und Algorithmen werden erklärt. Anschließend wird die Adaption des Netzwerkes an die Anwendungsdomäne des Unternehmen rjm Business Solutions GmbH beschrieben, anhand der Daten für die Evaluation zusammengetragen werden. Der letzte Abschnitt fasst die wichtigsten Gedanken dieser Arbeit zusammen und gibt einen Ausblick über Erweiterungsmöglichkeiten für das entwickelte Sensornetzwerk.
In diesem Kapitel werden verschiedene Aspekte des WfM betrachtet. Zunächst werden grundlegende Begriffe geklärt und darauf aufbauend Techniken zur Darstellung von Workflows und weitere Fachbegriffe vorgestellt. Abschließend wird eine allgemeine Architektur für WfM-Systeme sowie das CAKE-Framework als agentenbasierte Architektur dargestellt.
Dieses Kapitel befasst sich mit Grundbegriffen des WfM, die für das weitere Verständnis von Bedeutung sind. Dazu werden die Begriffe erläutert und Gemeinsamkeiten bzw. Unterschiede herausgestellt.
Die Begriffe Workflow und Geschäftsprozess werden oft als Synonyme verwendet, obwohl in der Literatur durchaus unterschiedliche Definitionen gefunden werden können. Ein Geschäftsprozess ist eine Abfolge von Aktivitäten in einem Unternehmen, die der Erzeugung eines Produktes oder einer Dienstleistung dienen um die Geschäftsziele des Unternehmens zu erreichen [RS04]. Im Mittelpunkt steht dabei der Output als Wert für den Kunden und die Befriedigung des Kundens durch das Produkt, das ihm geliefert wird oder die Dienstleistung, die erbracht wird [Sch96].
Der Begriff Workflow tauchte zunächst im Bereich Dokumenten-Management auf. Das Work- flow-Konzept sollte den Ablauf von Büroarbeiten unterstützen und automatisieren und führte zu der Idee des papierlosen Büros [BT98]. Heute versteht man unter einem Workflow einen zusammenhängenden, rechnergestützten Teil eines Geschäftsprozesses [RS04]. Dieser ist also eine technische Abstraktion eines Teils eines Geschäftsprozesses und enthält ebenfalls eine Folge von Aktivitäten, deren Abfolge jedoch im Vorhinein definiert wurde und dadurch zumindest teilweise von IT-Systemen unterstützt werden kann. Inwiefern der Aufbau von Workflows a priori vordefiniert werden kann, hängt von der Strukturiertheit des Workflows ab. Ist ein Workflow stark strukturiert, so ist es möglich den Ablauf der Einzelaktivitäten sowie die Bearbeiter vorher festzulegen. Bei einem unstrukturiertem bzw. schwach strukturiertem Workflow (sog. Ad-Hoc-Workflows oder agile Workflows) wird die Reihenfolge der Aktivitäten und werden die Bearbeiter erst während des Ablaufs des Workflows festgelegt [RS04]. Systeme, die solche Workflows unterstützen, müssen Funktionen zur Verfügung stellen, die es dem Benutzer ermöglichen die Workflow-Definitionen schnell und einfach zu erstellen und zu ändern [All02].
Ebenso gibt es einen Unterschied zwischen den Begriffen Workflow-Management und Geschäftsprozess-Management (GpM). Ziel des GpM ist es, den Arbeitsablauf so zu organisieren, dass die anfallenden Einzelaktivitäten zum richtigen Zeitpunkt von bzw. mit den richtigen Ressourcen ausgeführt werden [RS04]. Dazu müssen die Prozesse mit verschiedenen Metho- den, Techniken und Software-Systemen erkannt, analysiert, gestaltet bzw. verbessert, dokumentiert, ausgeführt und kontrolliert werden [AHW03]. Das WfM stellt dagegen die Unterstützung der Prozesse durch IT-Systeme in den Vordergrund. Die Logik der Geschäftsprozesse soll mit verschiedenen Werkzeugen explizit dargestellt werden, um zunächst den gesamten Prozess durch IT zu unterstützen und anschließend die Teilaktivitäten gegebenenfalls zu automatisieren [RS04].
Abb. 1: Geschäftsprozess-Management und Workflow-Management, Quelle: [AHW03]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1 zeigt die einzelnen Phasen des GpM nach van der Aalst et al. Diese werden wie folgt nur zum Teil dem WfM zugeschrieben. Die Diagnose-Phase, in der die Prozesse analysiert und verbessert werden, wird im traditionellen Workflow-Management selten unterstützt. Die Design-Phase wird oft darauf begrenzt verschiedene Werkzeuge zur Verfügung zu stellen, um die Prozesse darzustellen und Abhängigkeiten zwischen einzelnen Tätigkeiten herauszustellen. Aufbauend auf der daraus resultierenden Darstellung der Logik eines Geschäftsprozesses wird dieser nun implementiert, d.h. es werden IT-Systeme so konfiguriert und miteinander verknüpft, dass der Gesamtprozess unterstützt wird. Das Ausführen der Prozesse wird von traditionellen WfM-Systemen ebenfalls nur zum Teil unterstützt [AHW03]. Jedoch wird die Unterstützung dieser Phase zunehmend in den sog. Workflow Enactment Service von WfM-Systemen integriert [HJK+04].
Die Workflow-Management Coalition (WfMC), eine internationale Organisation, die seit 1993 Standardisierungen für Schnittstellen von WfM-Systemen und für die Terminologie im Bereich WfM anstrebt, definiert ein WfM-System folgendermaßen: „A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications“ [All02]. Diese Definition legt den Fokus auf das Ausführen der Workflows, was jedoch zu weit gegriffen ist. Laut van der Aalst muss klar unterschieden werden zwischen dem Management und dem Ausführen der Workflows [Aal02].
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2: Trennung zwischen Ausführung und Management von Workflows, Quelle: [Aal02]
Aufgabe des WfM-Systems ist es also, den Ablauf eines Workflows zu unterstützen, indem es die Arbeit zur richtigen Zeit der richtigen Person bzw. Anwendung zuordnet. Das Management-System reagiert dabei auf Signale seiner Umwelt, versorgt den Benutzer mit relevanten Informationen und kann das Ausführen von automatisierten Aufgaben auslösen. Die Anwendungen unterstützen den Benutzer beim Ausführen von verschiedenen Aufgaben und kommunizieren mit dem WfM-System.
Durch die Einführung von WfM-Systemen versprechen sich Unternehmen eine Reihe von Vorteilen [RS04]:
- Verbesserung der Prozessabwicklung durch Verkürzung der Durchlaufzeiten, Steigerung der Flexibilität, bessere Arbeitsvorratsverwaltung etc.,
- Rationalisierung und damit verbundene Kostenersparnis,
- Kontrolle der Prozessabwicklung durch Transparenz der Arbeitssituation und bessere Qualitätssicherung,
- Verteilte Prozessabwicklung durch vereinfachte Koordination räumlich oder zeitlich verteilter Bearbeitung,
- besserer Kundenservice, Investitionsschutz uvm.
Nachteile von WfM-Systemen werden vorallem im Bereich Datensicherheit und -schutz gesehen, da es zum erhöhten Austausch von möglicherweise sensiblen Daten kommt.
In diesem Kapitel werden weitere wichtige Bezeichnungen geklärt, die in Zusammenhang mit dem Begriff Workflow stehen und ebenfalls in der Literatur bzw. der Praxis auftreten. Im Folgenden werden die Begriffe Workflow und Prozess als Synonym für Geschäftsprozess bzw. Workflow benutzt, da eine Unterscheidung in diesem Zusammenhang nicht weiter nötig ist. Die folgende Abbildung gibt einen Überblick über verschiedene Begrifflichkeiten und ihre Beziehungen zueinander:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3: Beziehungen zwischen den Grundbegriffen, angelehnt an: [WFM99]
Dieser Darstellung kann entnommen werden, dass eine Trennung zwischen der ProzessDefinition und der Prozess-Instanz wichtig ist. Eine Prozess-Definition ist eine Darstellung eines Prozesses in einer bestimmten Form, die die Modellierung und das Ausführen des Prozesses durch ein WfM-System unterstützt. Sie besteht aus einer Menge von (manuellen und/oder automatisierten) Aktivitäten und ihren Beziehungen zueinander, Informationen über den Start und das Ende des Prozesses und über die einzelnen Aktivitäten. Eine Prozess-Definition entsteht während der Design-Phase und kann Teilprozesse enthalten, die getrennt definiert werden. Eine Aktivität ist die Beschreibung mehrerer Arbeitsschritte, die einen logisch zusammengehörigen Block innerhalb eines Prozesses darstellen und für ihre Ausführung menschliche und/oder maschinelle Ressourcen benötigt.
Eine Prozess-Instanz hingegen ist eine Darstellung einer einzelnen Ausführung eines Prozessdurchlaufs und enthält Daten, die nur für diese Abwicklung gültig sind. Sie wird von einem WfM-System in Anlehnung an eine Prozess-Definition erzeugt und verwaltet und hat einen Zustand, der interne Daten wie den Abarbeitungsfortschritt und andere Bedingungen zu einem bestimmten Zeitpunkt enthält. Analog versteht man unter dem Begriff Aktivitäts-Instanz eine Repräsentation einer einzelnen Ausführung einer Aktivität, die ebenfalls einen Zustand hat, der eine Aussage über den Fortschritt der Durchführung dieser Aktivität zu einem bestimmten Zeitpunkt macht [WFM99].
Abb. 4: Begriffe und Symbole, angelehnt an: [WFM99]
Abbildung in dieser Leseprobe nicht enthalten
Die am häufigsten anzutreffende Anordnung von Aktivitäten ist die Sequenz, eine einfache Abfolge von Tätigkeiten, die nacheinander ausgeführt werden. Komplexere Muster sind der AND-Split, durch den es zum parallelen Ablauf mehrerer Aktivitäts-Instanzen kommen kann, sowie der XOR-Split, durch den einer der nachfolgenden Zweige ausgewählt wird, so dass nur die Aktivitäten des selektierten Pfades ausgeführt werden. Wird eine Verzweigung durch einen AND-Join wieder zusammengeführt, so spricht man von Synchronisierung. Asynchrone Zusammenführung erfolgt durch den XOR-Join. Diese fünf Abfolgen von Aktivitäten werden von van der Aalst et al. als grundlegende Steuermuster bezeichnet und detailliert beschrieben [AHK+03]. Eine weiteres, häufig benutztes Gefüge ist die Iteration, die eine oder mehrere Aktivitäten mehrmals wiederholt ausführt.
Ein ergänzender Aspekt sind Vor- bzw. Nachbedingungen von Prozessen und Aktivitäten. Diese werden meist nicht in Diagrammen dargestellt, können den Ablauf der Prozesse jedoch maßgeblich beeinflussen. Eine solche Bedingung ist ein logischer Ausdruck, der bestimmt, ob eine Prozess- oder Aktivitäts-Instanz gestartet bzw. beendet werden darf. Dieser Ausdruck bezieht sich meist auf Informationen, die für den aktuellen Workflow relevant sind sowie für Umgebungsdaten wie Zeit oder Datum.
Der Begriff des Workflowzustandes ist für diese Arbeit wichtig, da das zu entwickelnde System diesen Zustand anhand der Resultate von Bearbeitungsvorgängen automatisch erkennen soll. Die WfMC beschreibt den Workflowzustand als eine Repräsentation der internen Bedingungen, die den Zustand einer Prozess-Instanz zu einem bestimmten Zeitpunkt definieren [WFM99]. Sie schlägt die Unterscheidung folgender Menge von Workflowzuständen vor [WFM95]:
- Initialisiert: Eine Instanz des Workflows wurde erstellt, allerdings kann sie noch nicht ausgeführt werden, da mindestens eine der Vorbedingungen des Workflows noch nicht erfüllt wird.
- Laufend: Die Vorbedingungen des Workflows werden eingehalten und die Ausführung wurde gestartet. Es wurde jedoch noch keine der Aktivitäten begonnen, allerdings kann die Bearbeitung einer oder mehrerer Aktivitäten jederzeit gestartet werden, sobald ihre Vorbedingungen erfüllt sind.
- Aktiv: Eine oder mehrere Aktivitäten werden bearbeitet, indem Elementaraufgaben durch Bearbeiter ausgeführt werden oder Anwendungen zur automatisierten Bearbeitung aufgerufen werden.
- Gestoppt: Die Ausführung des Workflows kann manuell ausgesetzt werden, wenn keine Aktivitäten bearbeitet werden. Der Workflow kann entweder wiederaufgenommen und an einer bestimmten Stelle fortgesetzt werden oder neu gestartet werden, indem er in den Zustand Initialisiert zurückversetzt wird.
- Abgeschlossen: Alle Aktivitäten, die zur erfolgreichen Fertigstellung des Workflows durchgeführt werden müssen, wurden bearbeitet. Der Workflow wurde also regulär abgeschlossen und die Instanz kann vernichtet werden.
- Beendet: Der Workflow wurde aus einem bestimmten Grund vor seinem regulären Abschluss beendet und die Workflow-Instanz wird ebenfalls vernichtet.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 5: Workflowzustände mit ihren Übergängen, angelehnt an: [WFM95]
Da eine solche detaillierte Unterscheidung für die hier verfolgten Ziele nicht nötig ist, werden bei der Konzeptentwicklung nur die Zustände Inaktiv, Aktiv und Abgeschlossen betrachtet. Unter inaktiven Workflow-Instanzen werden dabei Instanzen verstanden, bei denen noch keine der Aktivitäten begonnen wurde, oder Instanzen, die noch nicht initialisiert wurden. Um den Workflowzustand genauer zu beschreiben werden zusätzlich die Zustände der Aktivitäten angegeben. Dadurch wird bei aktiven Workflow-Instanzen der Abarbeitungsstand deutlich. Analog zu den Workflowzuständen unterscheidet die WfMC folgende Aktivitätszustände:
Bei der Konzepterstellung wird auf den Zustand Gestoppt verzichtet. Bei dem Zustand Aktiv wird zusätzlich der Bearbeitungsstand der jeweiligen Aktivität angegeben.
Eines der ersten Projekte der WfMC war die Ausarbeitung des Workflow-Referenzmodells [WFM95]. Ausschlaggebend für die Umsetzung dieses Modells war die Entwicklung auf dem Markt für WfM-Systeme, der immer mehr proprietäre Systeme zum Vorschein brachte. Das Workflow-Referenzmodell definiert eine zentrale Architektur für WfM-Systeme mit standardisierten Komponenten und Schnittstellen, so dass die einzelnen Bausteine von WfM-Syste- men austauschbar werden. Damit wird es für Anwender von Systemen, die diesem Standard entsprechen, möglich sich eine Anwendung aus mehreren Komponenten von verschiedenen Anbietern zusammenzustellen und diese in eine schon existierende IT-Infrastruktur zu integrieren. Die folgende Abbildung stellt eine Übersicht über die Komponenten und Schnittstellen des Workflow-Referenzmodells dar:
Demnach besteht ein WfM-System aus einem Workflow Enactment Service. Dies ist ein Software-Modul, das aus einer oder mehreren Workflow-Engines besteht und Workflow-Instanzen erzeugt, verwaltet und ausführt. Er kann aus einem zentralen Modul bestehen oder über mehrere Systeme verteilt sein. Andere Anwendungen können mit diesem Service über das sog. Workflow Application Programming Interface kommunizieren. Eine Workflow-Engine ist ein Software-Dienst, der die Laufzeit-Umgebung für Workflow-Instanzen darstellt. Er interpretiert die Workflow-Definition, kontrolliert die Ausführung der Instanzen und bietet weitere Dienste an. Um die Interoperabilität des Systems zu weiteren WfM-Systemen und externen Anwendungen zu gewährleisten wurden fünf Schnittstellen zur Interaktion der Systeme festgelegt:
1) Interface 1 ist eine Schnittstelle zum Austausch von Prozess-Definitionen, die der Anbindung von Programmen zur Analyse, der Modellierung und der Beschreibung von Prozessen dient. Solche Programme können als Teil eines WfM-Systems oder als Einzelprodukt vorliegen und erzeugen die Prozess-Definition, die von den Workflow-Engines interpretiert und instantiiert werden. Für den erfolgreichen Austausch der Prozess-Definitionen müssen beide Seiten die gleiche Sprache für die Prozessbeschreibung beherrschen. Für diese Beschreibungen wurde von der WfMC der auf der Auszeichnungssprache Extensible Markup Language (XML) basierende Standard XML Process Definition Language entwickelt.
2) Interface 2 dient der Anbindung von Client-Anwendungen, die der Endbenutzer zum Ausführen von (Teil-) Aktivitäten nutzt, und ermöglicht somit, dass Desktop-An- wendungen wie E-Mail-Programme in das WfM-System integriert werden können. Es nutzt das Konzept der Eingangskorb-Steuerung (worklist handler), eine Liste, die von der Workflow-Engine versorgt wird und Aufgaben für einen bestimmten Nutzer enthält. Dieses Interface ist sehr flexibel gehalten, da eine große Menge unterschiedlicher Daten, die zum Teil anwendungsspezifisch sind, übertragen werden.
3) Interface 3 hat den Zweck, weitere Anwendungen mit dem WfM-System zu verbinden. Dies können Programme sein, die selbstständig Aufgaben erledigen oder der Auslagerung von anwendungsspezifischer Logik dienen, die nicht in dem WfM-System enthalten ist. Dabei kann es sich um Programme handeln, die Daten in eine bestimmte Form transformieren, so dass Client-Anwendungen diese verarbeiten können.
4) Interface 4 soll der Verknüpfung von unterschiedlichen WfM-Systemen dienen, indem zum einen Prozess-Definitionen ausgetauscht und gleich interpretiert werden und zum anderen die Abarbeitung der Prozesse durch den Austausch von Anwendungs- und Steuerdaten unterstützt wird.
5) Interface 5 dient der Anbindung von Programmen zum Verwalten, Beobachten und Überwachen von Workflows.
Komponenten von WfM-Systemen, die nach diesem Schema aufgebaut sind, können somit beliebig ausgetauscht werden. Dies soll die Akzeptanz von WfM-Systemen erhöhen und ihre Verbreitung fördern.
Die meisten auf dem Markt verfügbaren WfM-Systeme wurden aus den Richtungen Computer Supported Cooperative Work, Projekt-Management, Software-Entwicklung, GpM oder dem traditionellem WfM entwickelt [BT98]. Dadurch entstanden eine Menge von Programmen, die aus unterschiedlichen Perspektiven implementiert wurden und unterschiedliche Ansätze verfolgen um z.B. das Problem der Abhängigkeiten zwischen Aktivitäten zu lösen. Da diese Programme in einen domänenabhängigen Kontext eingebunden werden, müssen sie flexibel gestaltet werden und eine Menge von Anforderungen erfüllen um weitgehend akzeptiert und verbreitet zu werden. Dieses Kapitel stellt einige wichtige Aspekte der Anforderungen, die von Bolcer und Taylor detailliert beschrieben werden, heraus [BT98] .
Ein wichtiger Punkt ist die Unterstützung von unterschiedlichen Personengruppen, da oft Menschen mit variierendem Wissen an dem selben Prozess teilnehmen. Dieses Wissen kann technisches und domänenabhängiges Wissen, Kenntnisse über den Gesamtprozess und Prozessmodellierung- bzw. Optimierung uvm. umfassen. Dies führt dazu, dass diese Gruppen eine unterschiedliche Darstellung der Aktivitäten und Prozesse und Zugang zu unterschiedlichen Informationen benötigen. Ebenso ist es nötig, dass die Systeme in unterschiedliche Organisationsformen integriert werden können, da diese oft schon innerhalb von Unternehmen variieren.
Ein weiterer wichtiger Aspekt ist die Möglichkeit externe Tools in das System einzubinden, damit der Endbenutzer Programme bei der Einführung von WfM-Systeme weiter benutzen kann und sich das WfM-System nahtlos in die Desktop-Umgebung integrieren lässt. Dies erfordert eine Definition von Schnittstellen, die Möglichkeit der multi-direktionalen und synchronen Kommunikation und die Kenntnis unterschiedlicher Sprachen zur Kommunikation zwischen den Komponenten. Weiterhin müssen unterschiedliche Plattformen unterstützt werden.
Folgende weitere Faktoren sollten bei der Implementierung von WfM-Systemen beachtet werden [BT98]:
- In verschiedenen Anwendungsdomänen ist es nötig, dass Änderungen an dem System und der Workflow-Definition dynamisch während der Laufzeit des Systems durchgeführt werden können (Unterstützung von agilen Workflows).
- WfM-Systeme sollten objektorientiert implementiert werden, so dass Objekte der realen Welt anschaulich dargestellt und von den Benutzern und Entwicklern einfach verstanden werden können.
- Die Komponenten eines WfM-Systems sollten so implementiert werden, dass sie ohne viel Aufwand an das jeweilige Anwendungsgebiet angepasst und wieder benutzt werden können.
- Ein WfM-System sollte sich sukzessive einführen lassen, so dass schon vorhandene Prozesse schrittweise in das System integriert werden können. Dazu ist es nötig, dass nicht nur gesamte Prozesse, sondern auch Teilprozesse unterstützt werden.
- Das System muss unterschiedliche Plattformen und Netzwerktypen unterstützen um die Bearbeitung verteiler Prozesse zu ermöglichen.
Da die Anforderungen ohnehin schon sehr zahlreich sind und sich zudem noch weiter untergliedern lassen, ist es kaum möglich, dass ein einziges System all diesen Anforderungen in gleich hohem Maße gerecht wird. Die meisten WfM-Systeme setzen daher einen Schwerpunkt auf einen oder mehrere dieser Punkte.
Am Lehrstuhl für Wirtschaftsinformatik II der Universität Trier wurden gegen Ende des Jahres 2004 Anforderungen aus unterschiedlichen Anwendungsgebieten betrachtet. Dabei handelte es sich um Projekte aus der Medizin, dem Software-Engineering, dem Notfall-Management einer Feuerwehr und dem in dieser Arbeit betrachteten Anwendungsszenario aus dem Bereich Geoinformationen. Im Zuge dessen wurden folgende Gemeinsamkeiten herausgestellt:
- Es bestand ein hoher Bedarf zur Koordination kollaborativer Aktivitäten.
- Zur Unterstützung der Ausführung von Aktivitäten müssen verschiedenartige Wissensquellen integriert werden.
- Die Geschäftsprozesse müssen flexibel gestaltet werden, so dass eine Anpassung der Prozesse an die aktuelle Situation auch während der Ausführung möglich ist.
Da der Aufwand zur Implementierung von Individuallösungen für jedes der Einsatzgebiete als höher eingeschätzt wurde als der Aufwand zur Entwicklung und Anpassung einer Software, die an die einzelnen Domänen adaptiert werden kann, wurde die Umsetzung eines generischen Frameworks beschlossen. Dieses Framework wird seit 2005 am Lehrstuhl für Wirtschaftsinformatik II der Universität Trier unter dem Namen Collaborative Agent-based Knowledge Engine (CAKE) entwickelt. CAKE ist ein domänenunabhängiges Framework zur Entwicklung von Unterstützungssystemen mit dem Ziel, die Kommunikation, Koordination und Kooperation menschlicher Akteure, die an einem gemeinsamen Prozess beteiligt sind, zu unterstützen und elektronische Wissensquellen in diesen Prozess zu integrieren. Bei der Implementierung des Systems wurde die Integration von Informationen, Personen und Prozessen sowie vielseitige Suchmöglichkeiten als Anforderungen in den Mittelpunkt gestellt [MM07].
In der CAKE-Architektur werden drei Technologien miteinander verknüpft: Workflow- und Agententechnologie sowie fallbasiertes Schließen (engl. Case-based Reasoning, CBR). Durch die Kombination dieser Techniken im Hinblick auf die Anforderungen an das Gesamtsystem werden die in Abschnitt 2.5 erläuterten Anforderungen größtenteils erfüllt. CAKE wird dadurch zu einer Integrationsplattform, die es ermöglicht Personen, Informationen und Prozesse einheitlich und sukzessive zu integrieren. Die drei Schlüsseltechnologien benutzen das gleiche, objektorientierte Datenmodell, das zur Spezifikation von domänenabhängigen Datenklassen benutzt wird. Die folgende Abbildung zeigt den Aufbau der CAKE-Architektur und die Interaktion der Komponenten:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 8: CAKE-Architektur, Quelle: [SMM+06]
Die Workflow-Technologie dient der Modellierung und Ausführung von flexiblen Geschäftsprozessen, die durch das auf CAKE basierende System unterstützt werden sollen. Dabei werden Workflow-Definitionen und Workflow-Instanzen voneinander getrennt, damit die Instanzen während der Laufzeit des Workflows geändert werden können, ohne dass die Workflow-Definition abgewandelt werden muss. Der Workflow Engine Manager dient als Workflow Enactment Service und ist für die Initialisierung der Workflow-Instanzen zuständig, wozu er jeweils genau eine Workflow-Definition verwendet. Die Workflow-Instanzen werden durch jeweils eine Workflow-Engine ausgeführt. Eine Datenbank speichert Beschreibungen aller verfügbaren Workflow-Definitionen als spezielle CAKE-Objekte, die dem CAKE-Datenmodell entspechen.
Das Agentenframework wird zur Anbindung von Agenten an das CAKE-System verwendet. Es werden zwei Arten von Agenten unterschieden: Informationsagenten und Benutzeragenten. Informationsagenten dienen der Anbindung von externen Datenquellen an das CAKE-System und können Daten aus diesen Quellen auslesen und gegebenenfalls manipulieren. Benutzeragenten dagegen können nur Daten lesen und werden vorwiegend als Verbindung zu Benutzer-Schnittstellen wie grafischen Oberflächen benutzt. Jeder CAKE-Agent hat eine Beschreibung, die in einer zweiten Datenbank abgelegt ist. Auch diese Beschreibungen werden als spezielle CAKE-Objekte gespeichert, die dem CAKE-Datenmodell entsprechen.
CBR ist ein Verfahren, bei dem Probleme und ihre Lösungen in einer sog. Fallbasis gespeichert werden. Tritt ein neues Problem auf, so wird in der Fallbasis anhand von Ähnlichkeitsmaßen nach vergleichbaren Problemen gesucht. Anschließend wird versucht das aktuelle Problem zu lösen, indem die Lösung zu einem der ähnlichsten Probleme an die neue Situation angepasst wird [Kol93]. Die Datenbanken, in denen die Beschreibungen der Workflow-Definitionen und der Agenten gespeichert werden, stellen die Fallbasis im CAKE-System dar. Dadurch wird eine Auswahl von Agenten und Workflow-Definitionen möglich, die am besten auf eine bestimmte Situation passen. Für die Vergleiche wird eine Vielzahl von Ähnlichkeitsmaßen vorgegeben, es können aber auch eigene Maße definiert werden. Weiterhin kann die CBR-Technologie selbst als Wissensquelle verwendet werden. Dazu muss eine Menge von CAKE-Datenobjekten als Fallbasis definiert werden und diese mit einem geeigneten Agenten an das CAKE-System angebunden werden [MM07] [SMM+06].
Bei der Konzeption von CAKE wurde viel Wert auf die Unterstützung von agilen Workflows gelegt. Um solche Workflows zu modellieren und zu repräsentieren ist es wichtig, dass eine flexible und nicht zu komplizierte Sprache gewählt wird, mit der Änderungen zur Laufzeit der Workflows möglich werden. Zur Darstellung der Workflows wurden daher die in Abschnitt
Abbildung in dieser Leseprobe nicht enthalten
Abb. 9: Baumstruktur der Kontrollfluss-Darstellung, Quelle: [MTS+07]
Diese Abbildung stellt einen Sequenz-Baustein dar, der eine Iteration, einen Anhaltepunkt und die elementare Aufgabe T3 enthält. Die Reihenfolge, in der diese Elemente in dem Sequenzblock angegeben werden, bestimmt die Abfolge ihrer Ausführung. Zunächst wird also die Iteration ausgeführt. Diese enthält wiederum einen Sequenz-Baustein, der die zwei elementaren Aufgaben T1 und T2 nacheinander ausführt. Das Schleifen-Konstrukt führt die beiden Aufgaben so oft nacheinander aus, bis eine bestimmte Bedingung erfüllt ist. Anschließend wird zunächst der Anhaltepunkt durchlaufen und abschließend die Aufgabe T3 ausgeführt.
Ein Sensor ist ein technisches Element, das physikalische, chemische oder biologische Meßgrößen in elektrische Signale umwandelt, die mit den Meßwerten in eindeutigen oft linearen Zusammenhängen stehen. In dem Sensor sind oft Messgeräte integriert, die die Signale vorverarbeiten, d.h. in ein normiertes, analoges Meßsignal verstärken und anschließend durch einen Prozessor in ein digitales Signalformat umwandeln und über eine Schnittstelle nach Außen weitergeben [Trä98]. Unter einem Sensornetzwerk versteht man laut Golatowski et al. eine Vielzahl von kleinen Sensorknoten, die drahtlos miteinander kommunizieren und ihre Umgebung mittels Sensoren überwachen. Durch die Vernetzung der Sensoren ergeben sich verschiedene Anforderungen an das System, die abhängig vom Einsatzgebiet sind und somit teilweise nur in bestimmtem Maße erfüllt werden müssen [GBH+03]:
- Selbstorganisation: Die Netzwerkinfrastruktur soll durch Interaktion der Sensorknoten selbstständig aufgebaut werden.
- Netzwerkfunktionalität: Eine Veränderung in der Umgebung soll automatisch von einem Sensorknoten erkannt werden und den Datensenken im Netz zugeleitet werden. Die Knoten sollen durch kooperative Algorithmen effektiv zusammenwirken.
- Sicherheitsmechanismen: Je nach Umgebung und Anwendungsgebiet ergeben sich unterschiedliche Anforderungen an die Sicherheit innerhalb des Netzwerks, z.B. Verfügbarkeit, Vertraulichkeit, Integrität und Aktualität der Daten.
- Low-Power-Ansatz: Sensorknoten sind in drahtlosen Netzwerken meist batteriebetrieben. Daher sollten verschiedene Stromsparfunktionen implementiert werden.
In dieser Arbeit wird von dem klassischen Verständnis für Sensor und Sensornetzwerk grundlegend abgewichen, da es sich bei der hier behandelten Anwendungsdomäne nicht um Meßgrößen handelt, sondern um Informationen, die in unterschiedlichen Formen auf unterschiedlichen IT-Systemen vorliegen. Diese Informationen geben Hinweise auf das Eintreten von Ereignissen, die wiederum Aufschluss auf den Zustand einer bestimmten Tätigkeit innerhalb eines Workflows geben. Unter einem Sensor wird im Weiteren ein Software-Agent verstanden, der sich in einem auf dem TCP/IP-Protokoll basierenden Netzwerk befindet. Dieser hat die gleichen Aufgaben wie der klassische Sensor: das Aufnehmen, Verarbeiten und Weitergeben von Sensordaten. Trotz der Unterschiede zwischen diesen Begriffen werden im Folgenden Netzwerktypen und Architekturen für Sensornetzwerke genauer betrachtetet, da Sensornetzwerke viele Gemeinsamkeiten mit dem zu entwickelnden Netzwerk aufweisen. Ihre Aufgabe liegt ebenfalls im Bewachen der Umgebung und dem Zusammenführen der gewonnenen Informationen. Daher können allgemeine Architekturen für Sensornetzwerke wertvolle Erkenntnisse für den Aufbau eines agentenbasierten Sensornetzes zur Erkennung von Workflowzu- ständen geben.
Für die Kommunikation in einem Sensornetzwerk gibt es zwei vorherrschende Architekturen: die hierarchische und die flache Netzwerkarchitektur [ABJ+06]. Bei der hierarchischen Architektur werden die Sensorknoten in Cluster aufgeteilt, die sich auf unterschiedlichen Ebenen des Netzwerkes befinden. Auf der untersten Ebene könnten sich z.B. Sensorknoten befinden, die nach ihrer räumlichen Anordnung in Cluster aufgeteilt sind. Typischerweise hat dabei einer der Knoten des Clusters die Aufgabe, die von den Sensorknoten bereitgestellten Informationen zu sammeln und zur nächsten Ebene weiterzugeben. Dieser Knoten wird auch Cluster Head genannt. Auf den darüber liegenden Ebenen befinden sich nur noch Knoten, die die Informationen entgegennehmen, weiterverarbeiten und gegebenenfalls an die nächste Ebene weiterreichen. Je nach Höhe der Hierarchie sind diese wiederum in Cluster aufgeteilt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 10: Hierarchische Architektur mit 2 Ebenen, Quelle: [ABJ+06]
Eine solche Architektur hat die Vorteile, dass der Datenverkehr minimiert wird und kritische Funktionen wie die Weitervermittlung bzw. Aggregation der Daten auf wenige Knoten des Netzes beschränkt wird und somit besser zu kontrollieren ist.
In der flachen Architektur befinden sich alle Knoten auf derselben Ebene und sind somit gleichrangig. Zur Kommunikation wird das sog. Flooding benutzt. Dabei wird eine Nachricht von einem Ursprungsknoten an alle erreichbaren Knoten geschickt, die die Nachricht wiederum an alle von ihnen aus erreichbaren Knoten weitersenden. Der Nachrichtenaustausch wird beendet, sobald der Ursprungsknoten die Nachricht zurückbekommt oder alle Knoten die Nachricht erhalten haben. Um die Netzwerkkommunikation zu begrenzen, müssen bestimmte Protokolle entwickelt werden, die verhindern, dass Knoten eine Nachricht mehrmals erhalten. Durch das Versenden von Nachrichten über mehrere Wege werden die Daten im Netzwerk verteilt und nicht an einem bestimmten Knoten im Netz gesammelt. Dadurch stellt sich diese Architektur als robust und kaum fehleranfällig heraus.
Sensornetzwerke können nach der Funktionsweise der Sensorknoten in zwei Typen eingeteilt werden [ABJ+06]:
1) proaktive Netzwerke: Die Sensorknoten tasten in einem festgelegten zeitlichen Intervall ihre Umgebung ab und übertragen die gewonnenen Informationen danach an ihre Datensenken. Dieser Netzwerk-Typ eignet sich, wenn die Sensorik der Knoten nur dazu in der Lage ist Ist-Werte aufzunehmen, also keine Veränderungen wahrnehmen kann.
2) reaktive Netzwerke: Die Sensoren reagieren auf Veränderungen in dem von ihnen zu beobachtenden Abschnitt der Umwelt, nehmen diese wahr und transferieren anschließend die Ergebnisse weiter. Dazu muss die Sensorik der Knoten dafür ausgelegt sein, Veränderungen zu erkennen und zu quantifizieren.
Werden diese beiden Typen von Sensorknoten in einem Netz kombiniert, so erhält man ein sog. hybrides Netzwerk. Alternativ zu diesem Ansatz können auch Sensorknoten verwendet werden, die zur reaktiven und zur proaktiven Arbeitsweise in der Lage sind.
Dieser Abschnitt beschäftigt sich mit der Technik der MAS, die in der Informatik zum ersten Mal etwa Mitte der 70er Jahre im Bereich der Künstlichen Intelligenz erwähnt wurde. Zunächst werden grundlegende Begriffe, Netzwerktopologien und Agentenarchitekturen erläutert. Danach werden Aspekte der Interaktion unter Agenten und Standards aus dem Bereich der MAS betrachtet.
Der Begriff Agent wird heutzutage oft als Schlagwort benutzt, um den unterschiedlichsten Systemen die Verwendung von innovativer und neuartiger Technik zuzuschreiben [BR05]. Daher ist es wichtig, diesen Begriff genau abzugrenzen, was sich aber als äußerst schwierig herausstellt, da in der Literatur eine Vielzahl von Definitionen existieren, die sich zum Teil stark voneinander unterscheiden. Jakob und Weiß beschreiben eine Charakterisierung, die zunehmend akzeptiert wird [JW05]: Ein Software-Agent wird beschrieben als eine abgrenzbare Software-Einheit, die in der Lage ist die ihr vorgegebenen Aufgaben flexibel, interaktiv und autonom zu verfolgen. Dabei werden drei Eigenschaften von Software-Agenten in den Mittelpunkt gerückt:
1) Flexibilität: Die Agenten können reaktiv und proaktiv handeln, d.h. auf Ereignisse ihrer Umwelt reagieren und von sich aus planend und zielorientiert agieren.
2) Interaktivität: Agenten haben die Fähigkeit mit ihrer Umwelt, also auch mit menschlichen Akteuren und anderen Agenten, zu interagieren. Dies kann z.B. in Form von Verhandlungen zur Koordination von Tätigkeiten stattfinden. Voraussetzung dafür ist, dass der Agent in der Lage ist seine Umwelt durch eine bestimmte Sensorik wahrzunehmen und sie durch seine Aktorik verändern kann. Weiterhin muss er z.B. mit anderen Agenten kommunizieren können.
3) Autonomie: Agenten sind zu eigenständigem Handeln in der Lage. Sie können also selbst Entscheidungen treffen und haben eine bestimmte Handlungsfreiheit.
Neben diesen Kern-Eigenschaften findet man in der Literatur eine Reihe weiterer Kriterien, die der Charakterisierung und Abgrenzung von Software-Agenten dienen:
- Er ist in seinem Umfeld situiert bzw. eingebettet, d.h. er interagiert sensorisch und/oder aktorisch mit seiner Umwelt. Er ist also direkt mit seiner sozio-technischen Umwelt gekoppelt und interagiert nicht nur mit einem abstrakten Modell dieser Umwelt. Weiterhin kann er sich seinem Umfeld anpassen [JW05].
- Durch Kommunikation mit anderen Agenten und Menschen ist der Software-Agent zu sozialem Verhalten und Wohlwollen in der Lage [BR05].
- Einem Software-Agent kann ein bestimmter Grad von Intelligenz zugesprochen werden. Dies hängt davon ab, inwieweit der Agent fähig ist autonom, rational, sozial, reaktiv bzw. proaktiv zu handeln [Woo00].
- weitere Eigenschaften wie ständige Verfügbarkeit, Abgeschlossenheit, Lernfähigkeit, Zielgerichtetheit, Mobilität etc.
Diese zusätzlichen Charakterisierungen müssen nicht zwangsläufig erfüllt sein, damit ein Software-Programm als Agent bezeichnet werden kann. Ob und wie stark diese Eigenschaften zutreffen ist abhängig von der Anwendungsdomäne und somit auch der Umwelt des Agenten.
Der Begriff Multi-Agenten-System wird von Ferber genauer beschrieben [Fer01]. Demnach besteht ein MAS aus folgenden Teilaspekten:
- Umwelt: Diese ist ein Raum, in dem Objekte, die durch Beziehungen miteinander verbunden sind, situiert sind. Diese Objekte können von den Agenten wahrgenommen, verändert, erzeugt und gelöscht werden.
- Eine Menge von Agenten, die ebenfalls Objekte der Umwelt verkörpern. Sie sind aktiv und haben eine bestimmte Menge von Operationen, mit denen sie andere Objekte wahrnehmen, verändern, erzeugen und löschen können.
- Eine Menge von Operatoren: Dies sind die Gesetze der Universums, die die Reaktion der Umwelt auf Operationen der Agenten darstellen.
Die Umwelt der Agenten ist typischerweise ein offenes Systen, das u.a. eine Infrastruktur zur Kommunikation und Interaktion der Agenten zur Verfügung stellt [HS00]. Somit wird klar, dass beim Erstellen eines MAS zunächst die Umwelt definiert werden muss, die bei einem Sensornetzwerk durch den zu beobachtenden Sachverhalt bestimmt wird. Für die Realisierung eines Sensornetzwerks anhand eines MAS muss festgelegt werden, welche Architektur und welcher Typ eines Sensornetzwerks für das vorliegende Anwendungsgebiet am sinnvollsten ist. Für eine weitergehende Spezifikation müssen die Anforderungen aus der Sicht der MAS betrachtet werden. Dies bedeutet, dass zunächst eine geeignete Netzwerktopologie gefunden werden muss. Anschließend wird eine Menge von Agententypen bestimmt, für die jeweils festgelegt werden muss, welche Aktionen der einzelne Agent in seiner Umwelt ausführen kann. Anhand der zu implementierenden Fähigkeiten eines Agenten wird eine geeignete Agentenarchitektur gewählt. Weiterhin muss festgelegt werden, auf welche Art und Weise die Agenten miteinander interagieren.
Um für diese Entscheidungen eine sinnvolle Auswahl zu treffen, ist es nötig, sich mit den technischen Aspekten von MAS zu befassen. In den folgenden Abschnitten werden zunächst Netzwerktopologien betrachtet, die bei MAS zum Einsatz kommen. Weiterhin werden unterschiedliche Agentenarchitekturen und Prinzipien der Agentenkoordination und -kommunikation vorgestellt und diskutiert, inwiefern sie für den Einsatz in Sensornetzwerken in Frage kommen.
Die Software-Agenten, die hier von Interesse sind, befinden sich in einer Umwelt, die u.a. aus einem Rechnernetz besteht, das auf dem TCP/IP-Protokoll basiert. Daher ist das MAS eine Anwendung, die das TCP/IP-Netzwerk zur Kommunikation nutzt. Der TCP/IP-Protokollstapel ermöglicht es auf der Anwendungsebene verschiedene Typen von Netzwerken zu konfigurieren. Die für diese Arbeit relevanten Netzwerktopologien werden im Folgenden grafisch dargestellt, kurz erläutert und in Verbindung zu Sensornetzwerken gebracht.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 11: Netzwerktopologien
Bei dem Client-Server-Konzept gibt es einen oder mehrere zentrale Rechner (Server) der Dienste für die Arbeitsstationen (Clients) zur Verfügung stellt. Es findet keine direkte Kommunikation zwischen den Clients statt. Mit dieser Netzwerkstrukur lassen sich hierarchische Sensornetze realisieren. Der Sensorknoten stellt den Client dar: Er sammelt proaktiv oder reaktiv Informationen aus seiner Umgebung und schickt sie zu einem Server. Dieser nimmt die Daten entgegen, verarbeitet sie und gibt sie über eine Schnittstelle nach Außen weiter. In diesem Fall ist es nicht möglich, dass die Sensorknoten kooperativ zusammenarbeiten, da die Aggregation und Kombination der Sensordaten alleinige Aufgabe des Servers wäre.
Durch die Verwendung einer mehrschichtigen Server-Architektur ist es möglich unterschiedliche Server-Funktionen zu kapseln. Dabei sind folgende Ansätze denkbar:
- Der Server wird in Komponenten aufgeteilt, die jeweils eine wichtige Funktion übernehmen und über wohldefinierte Schnittstellen zusammenwirken. So könnte z.B. ein Modul für die Kommunikation mit den Sensorknoten zuständig sein. Eine zweite Komponente sammelt diese Daten, trägt sie zusammen und speichert sie. Eine weiteres Bauteil des Servers ist für den Datenaustausch nach Außen verantwortlich.
- Der Server wird wiederum als Client-Server-Anwendung realisiert, so dass eine tiefere hierarchische Netzwerkstruktur entsteht. Dazu müssen die Sensoragenten und gegebenenfalls auch Agenten auf höheren Ebenen in Cluster aufgeteilt werden. Jeder Agent ist in diesem Fall für eine bestimmte Funktion zuständig. Auf den mittleren Ebenen entstehen dabei Agenten, die sowohl Server als auch Client sind. In der Anwendungsdomäne dieser Arbeit wäre es denkbar, dass ein Cluster aus Sensoragenten für jede Einzelaktivität eines Workflows gebildet wird. Die Agenten auf der darüberliegenden Ebene nehmen die Sensor-Informationen eines Agenten-Clusters entgegen und tragen diese zusammen. Dabei ist jeder Agent für genau eine Aktivität zuständig und fungiert als Client für die Agenten der nächsten Ebene. Diese erhalten Daten über die Einzelaktivitäten und kombinieren sie, so dass daraus der Zustand eines gesamten Workflows erkannt werden kann.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 12: Mehrschichtige Client-Server-Architekturen
Als Vorteil der mehrschichtigen Client-Server-Architektur bei Sensornetzen ist anzuführen, dass einzelne Komponenten durch die Kapselung von Funktionen innerhalb von Modulen bzw. Agenten und durch die Benutzung von wohldefinierten Schnittstellen ohne viel Aufwand ausgetauscht und verändert werden können. Weiterhin werden die einzelnen Bauteile aufgrund ihrer Spezialisierung wiederverwendbar. Durch die Zentralisierung einzelner Funktionen kann es allerdings dazu kommen, dass die Funktionalität des Netzes bei Ausfall von Komponenten, die wichtige Aufgaben übernehmen, beeinträchtigt wird.
In einem Peer-to-Peer-Netzwerk gibt es keine zentrale Komponente, die die Interaktion der einzelnen Mitglieder (Peers) des Netzes steuert oder koordiniert. Jeder Peer ist gleichberechtigt und gleich wichtig für das gesamte Netz. Er kann gleichzeitig Client sein und auch Server-Dienste zur Verfügung stellen und mit allen anderen Peers des Netzes kommunizieren. Ein solches Netz ist typischerweise selbstorganisierend [YWW+06]. Eine Variante dieser Netzwerkstruktur sind hybride Peer-to-Peer-Systeme, in denen es einen oder mehrere Peers gibt, die Serverfunktionalitäten übernehmen.
Ein reines Peer-to-Peer-System eignet sich für ein flaches Sensornetzwerk, in dem es nur eine Art Agent gibt, der eine Vielzahl von Funktionen in sich vereinen muss. Da es bei einem Sensornetz eine eindeutige Schnittstelle nach Außen geben muss kommt schon aus diesem Grunde diese Architektur nicht in Frage. Weiterhin muss es in einem Sensornetzwerk eine oder mehrere Komponenten geben, die die Daten zusammenführt und weiterverarbeitet. Diese in einem solchen dezentralen System zu realisieren könnte sich als äußerst schwierig herausstellen. Demzufolge ist es sinnvoller für diese Art von Sensornetz eine hybride Peer-to-Peer- Struktur zu verwenden.
Peer-to-Peer-Netze haben den Vorteil, dass sie hoch skalierbar sind und aufgrund der dezentralen Struktur und der damit vorhandenen Redundanz von Funktionsmodulen und Datenhaltung robuster und weniger fehleranfällig als Client-Server-Architekturen sind [YWW+06]. In den meisten Peer-to-Peer-Netzwerken werden Flooding-Mechanismen zur Kommunikation genutzt, die zu erhöhtem Datenaustausch führen [YM01]. Durch den Einsatz eines hybriden Systems wird zwar zum einen die Skalierbarkeit und die Robustheit verringert, zum anderen kann aber die Performance erhöht werden, weil verschiedene Aufgaben über zentrale Dienste effizienter erledigt werden können [YM01].
Die Funktionalitäten von Software-Agenten unterscheiden sich zum Teil stark, da sie abhängig sind von der jeweiligen Anwendungsdomäne, der Umwelt des MAS und der Funktion der Agenten innerhalb des Systems. Daher gibt es eine Vielzahl von Agententypen, die sich in der Art und Weise, wie ihr Verhalten beschrieben und ausgeführt wird, unterscheiden. Zur Klassifikation von Agententypen werden Agentenarchitekturen benutzt. Diese beschreiben den internen Aufbau des Agenten, die benutzten Datenstrukturen, die Operationen, die auf diesen Datenstrukturen ausgeführt werden können und die Steuerung zwischen den einzelnen Komponenten. Den unterschiedlichen Agententypen ist gemeinsam, dass ihr Aufbau durch drei Bauteile beschrieben werden kann: die Sensorik, die Schlussfolgerungskomponente und die Aktorik.
[...]
