Konzeption und Realisierung eines agentenbasierten Sensornetzwerks zur automatischen Zustandsermittlung von Geschäftsprozessen

Inhaltsverzeichnis

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

Abstract

Für die Koordination der Zusammenarbeit von unterschiedlichen Organisationseinheiten ist es für das Management von modernen Unternehmen wichtig den aktuellen Bearbeitungszu­stand der Einzelaktivitäten zu kennen um eine Überwachung der Abläufe und damit eine wei­tere 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 Informa­tionssystemen 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 Ent­wicklung 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 inte­griert wird um die dortigen Abläufe transparenter zu gestalten

A Abbildungsverzeichnis

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

B Listings

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

C Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Teil I. Einführung und Grundlagen

1. Einführung in die Thematik

In Folge der fortschreitenden Globalisierung sind vor allem international agierende Unterneh­men 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 Mit­arbeiter verteilt werden. Weiterhin werden in vielen Unternehmen solche Aktivitäten auf In­formationssystemen bearbeitet, die sich technisch voneinander unterscheiden, da sie für unter­schiedliche 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 Kos­ten 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ätigkei­ten ist ein typisches Anwendungsgebiet des Workflow-Managements (WM).

1.1 Problemstellung und Ziele

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 momen­tanen 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 Informa­tionsquellen herangezogen werden. Als Resultate von Bearbeitungsvorgängen kommen Ände­rungen in Frage, die elektronisch nachvollziehbar sind, z.B. Änderungen in Dateien, Dateisys­temen, 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 Infor­mationen zur Erkennung herangezogen werden können, die auf unterschiedlichen Informa­tionssystemen vorliegen. Weiterhin wird das System so konzipiert, dass es über eine univer­selle 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 Wirtschaftsinforma­tik 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 ei­nes 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.

1.2 Aufbau des Dokumentes

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 Kom­munikation 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 geeig­nete Agentenarchitekturen für die verschiedenen Komponenten gewählt, die Details der Kom­munikation zwischen den Agenten geklärt und Methoden entwickelt, die die verteilten Infor­mationen zusammenführen, repräsentieren und so verarbeiten, dass der Bearbeitungszustand von Workflows bestimmt werden kann. Weiterhin wird eine universelle Schnittstelle entwor­fen, um das Netzwerk an externe Systeme anzubinden, eine spezielle Schnittstelle zur Kopp­lung der Software an das CAKE-Framework sowie eine grafische Benutzerschnittstelle. Ab­schließ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 analy­siert.

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, an­hand der Daten für die Evaluation zusammengetragen werden. Der letzte Abschnitt fasst die wichtigsten Gedanken dieser Arbeit zusammen und gibt einen Ausblick über Erweiterungs­möglichkeiten für das entwickelte Sensornetzwerk.

2. Workflow-Management

In diesem Kapitel werden verschiedene Aspekte des WfM betrachtet. Zunächst werden grundlegende Begriffe geklärt und darauf aufbauend Techniken zur Darstellung von Work­flows und weitere Fachbegriffe vorgestellt. Abschließend wird eine allgemeine Architektur für WfM-Systeme sowie das CAKE-Framework als agentenbasierte Architektur dargestellt.

2.1 Begrifflichkeiten

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.

2.1.1 Geschäftsprozess und Workflow

Die Begriffe Workflow und Geschäftsprozess werden oft als Synonyme verwendet, obwohl in der Literatur durchaus unterschiedliche Definitionen gefunden werden können. Ein Ge­schäftsprozess ist eine Abfolge von Aktivitäten in einem Unternehmen, die der Erzeugung ei­nes 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 Be­friedigung 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 zu­mindest teilweise von IT-Systemen unterstützt werden kann. Inwiefern der Aufbau von Work­flows 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].

2.1.2 Geschäftsprozess-Management und Workflow-Management

Ebenso gibt es einen Unterschied zwischen den Begriffen Workflow-Management und Ge­schäftsprozess-Management (GpM). Ziel des GpM ist es, den Arbeitsablauf so zu organisie­ren, 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, doku­mentiert, ausgeführt und kontrolliert werden [AHW03]. Das WfM stellt dagegen die Unter­stü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 auto­matisieren [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 analy­siert 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 herauszu­stellen. Aufbauend auf der daraus resultierenden Darstellung der Logik eines Geschäftspro­zesses wird dieser nun implementiert, d.h. es werden IT-Systeme so konfiguriert und mitein­ander 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].

2.1.3 Workflow-Management-System

Die Workflow-Management Coalition (WfMC), eine internationale Organisation, die seit 1993 Standardisierungen für Schnittstellen von WfM-Systemen und für die Terminologie im Be­reich WfM anstrebt, definiert ein WfM-System folgendermaßen: „A system that defines, cre­ates 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 work­flow 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 gegrif­fen 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 Manage­ment-System reagiert dabei auf Signale seiner Umwelt, versorgt den Benutzer mit relevanten Informationen und kann das Ausführen von automatisierten Aufgaben auslösen. Die Anwen­dungen unterstützen den Benutzer beim Ausführen von verschiedenen Aufgaben und kommu­nizieren 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, Steige­rung 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 gese­hen, da es zum erhöhten Austausch von möglicherweise sensiblen Daten kommt.

2.1.4 Weitere Begriffe

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 Fol­genden 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 Prozess­Definition 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-Defi­nition entsteht während der Design-Phase und kann Teilprozesse enthalten, die getrennt definiert werden. Eine Aktivität ist die Beschreibung mehrerer Arbeitsschritte, die einen lo­gisch zusammengehörigen Block innerhalb eines Prozesses darstellen und für ihre Aus­fü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-In­stanz eine Repräsentation einer einzelnen Ausführung einer Aktivität, die ebenfalls einen Zu­stand 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. Die­se 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 be­zieht sich meist auf Informationen, die für den aktuellen Workflow relevant sind sowie für Umgebungsdaten wie Zeit oder Datum.

2.3 Workflow- und Aktivitätszustände

Der Begriff des Workflowzustandes ist für diese Arbeit wichtig, da das zu entwickelnde Sys­tem diesen Zustand anhand der Resultate von Bearbeitungsvorgängen automatisch erkennen soll. Die WfMC beschreibt den Workflowzustand als eine Repräsentation der internen Bedin­gungen, 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, so­bald ihre Vorbedingungen erfüllt sind.
- Aktiv: Eine oder mehrere Aktivitäten werden bearbeitet, indem Elementaraufgaben durch Bearbeiter ausgeführt werden oder Anwendungen zur automatisierten Bearbei­tung aufgerufen werden.
- Gestoppt: Die Ausführung des Workflows kann manuell ausgesetzt werden, wenn kei­ne 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 ab­geschlossen und die Instanz kann vernichtet werden.
- Beendet: Der Workflow wurde aus einem bestimmten Grund vor seinem regulären Ab­schluss 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 kei­ne 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.

2.4 Das Workflow-Referenzmodell der WfMC

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 standar­disierten 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 inte­grieren. Die folgende Abbildung stellt eine Übersicht über die Komponenten und Schnittstel­len des Workflow-Referenzmodells dar:

Demnach besteht ein WfM-System aus einem Workflow Enactment Service. Dies ist ein Soft­ware-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 meh­rere 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 inter­pretiert 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 An­bindung von Programmen zur Analyse, der Modellierung und der Beschreibung von Prozessen dient. Solche Programme können als Teil eines WfM-Systems oder als Ein­zelprodukt vorliegen und erzeugen die Prozess-Definition, die von den Workflow-En­gines interpretiert und instantiiert werden. Für den erfolgreichen Austausch der Prozess-Definitionen müssen beide Seiten die gleiche Sprache für die Prozessbe­schreibung 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 ent­hä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 verbin­den. Dies können Programme sein, die selbstständig Aufgaben erledigen oder der Aus­lagerung 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.

2.5 Anforderungen an WfM-Systeme

Die meisten auf dem Markt verfügbaren WfM-Systeme wurden aus den Richtungen Compu­ter Supported Cooperative Work, Projekt-Management, Software-Entwicklung, GpM oder dem traditionellem WfM entwickelt [BT98]. Dadurch entstanden eine Menge von Program­men, die aus unterschiedlichen Perspektiven implementiert wurden und unterschiedliche An­sä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 fle­xibel 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 Pro­zessmodellierung- bzw. Optimierung uvm. umfassen. Dies führt dazu, dass diese Gruppen eine unterschiedliche Darstellung der Aktivitäten und Prozesse und Zugang zu unterschied­lichen Informationen benötigen. Ebenso ist es nötig, dass die Systeme in unterschiedliche Or­ganisationsformen 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 er­fordert eine Definition von Schnittstellen, die Möglichkeit der multi-direktionalen und syn­chronen Kommunikation und die Kenntnis unterschiedlicher Sprachen zur Kommunikation zwischen den Komponenten. Weiterhin müssen unterschiedliche Plattformen unterstützt wer­den.

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 durchge­führt werden können (Unterstützung von agilen Workflows).
- WfM-Systeme sollten objektorientiert implementiert werden, so dass Objekte der rea­len Welt anschaulich dargestellt und von den Benutzern und Entwicklern einfach ver­standen 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 wer­den 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 unter­gliedern 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 Schwer­punkt auf einen oder mehrere dieser Punkte.

2.6 Das CAKE-Framework

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-Ma­nagement einer Feuerwehr und dem in dieser Arbeit betrachteten Anwendungsszenario aus dem Bereich Geoinformationen. Im Zuge dessen wurden folgende Gemeinsamkeiten heraus­gestellt:

- Es bestand ein hoher Bedarf zur Koordination kollaborativer Aktivitäten.
- Zur Unterstützung der Ausführung von Aktivitäten müssen verschiedenartige Wis­sensquellen 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 gene­rischen Frameworks beschlossen. Dieses Framework wird seit 2005 am Lehrstuhl für Wirt­schaftsinformatik 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 Im­plementierung des Systems wurde die Integration von Informationen, Personen und Prozessen sowie vielseitige Suchmöglichkeiten als Anforderungen in den Mittelpunkt gestellt [MM07].

2.6.1 Architektur

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 da­durch zu einer Integrationsplattform, die es ermöglicht Personen, Informationen und Prozesse einheitlich und sukzessive zu integrieren. Die drei Schlüsseltechnologien benutzen das glei­che, objektorientierte Datenmodell, das zur Spezifikation von domänenabhängigen Datenklas­sen 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 Ge­schäftsprozessen, die durch das auf CAKE basierende System unterstützt werden sollen. Da­bei 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 Work­flow-Definition abgewandelt werden muss. Der Workflow Engine Manager dient als Work­flow 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-Da­tenmodell 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. Benutzer­agenten dagegen können nur Daten lesen und werden vorwiegend als Verbindung zu Benut­zer-Schnittstellen wie grafischen Oberflächen benutzt. Jeder CAKE-Agent hat eine Beschrei­bung, 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 gespei­chert werden. Tritt ein neues Problem auf, so wird in der Fallbasis anhand von Ähnlichkeits­maßen nach vergleichbaren Problemen gesucht. Anschließend wird versucht das aktuelle Pro­blem zu lösen, indem die Lösung zu einem der ähnlichsten Probleme an die neue Situation an­gepasst wird [Kol93]. Die Datenbanken, in denen die Beschreibungen der Workflow-Defini­tionen und der Agenten gespeichert werden, stellen die Fallbasis im CAKE-System dar. Da­durch 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 Ähnlichkeits­maß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].

2.6.2 Workflow-Repräsentation

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

2.2 beschriebenen, grundlegenden Steuermuster Sequenz, AND-Split, AND-Join, XOR-Split und XOR-Join benutzt. Zur Erhöhung der Flexibilität wurde die Workflow-Darstellung um weitere Elemente wie Iteration, Anhaltepunkte, Meilensteine und Platzhalter erweitert. Die ei­gentliche Modellierung des Kontrollflusses eines Workflows wird im XML-Format gespei­chert und erfolgt anhand der folgenden Bausteine: Sequenz-, AND-, XOR- und Iteration-Bau­steine. Diese Bausteine dürfen sich nicht überschneiden, können aber wiederum weitere Bau­steine beinhalten, woraus sich eine Baumstruktur ergibt [MTS+07].

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 Sequenz­block angegeben werden, bestimmt die Abfolge ihrer Ausführung. Zunächst wird also die Ite­ration 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 Auf­gaben 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.

3. Sensorik

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 vor­verarbeiten, 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 ei­nem 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 un­terschiedliche Anforderungen an die Sicherheit innerhalb des Netzwerks, z.B. Verfüg­barkeit, Vertraulichkeit, Integrität und Aktualität der Daten.
- Low-Power-Ansatz: Sensorknoten sind in drahtlosen Netzwerken meist batteriebetrie­ben. Daher sollten verschiedene Stromsparfunktionen implementiert werden.

In dieser Arbeit wird von dem klassischen Verständnis für Sensor und Sensornetzwerk grund­legend abgewichen, da es sich bei der hier behandelten Anwendungsdomäne nicht um Meß­größen handelt, sondern um Informationen, die in unterschiedlichen Formen auf unterschied­lichen IT-Systemen vorliegen. Diese Informationen geben Hinweise auf das Eintreten von Er­eignissen, die wiederum Aufschluss auf den Zustand einer bestimmten Tätigkeit innerhalb ei­nes 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 Sensornetz­werke viele Gemeinsamkeiten mit dem zu entwickelnden Netzwerk aufweisen. Ihre Aufgabe liegt ebenfalls im Bewachen der Umgebung und dem Zusammenführen der gewonnenen In­formationen. Daher können allgemeine Architekturen für Sensornetzwerke wertvolle Erkennt­nisse für den Aufbau eines agentenbasierten Sensornetzes zur Erkennung von Workflowzu- ständen geben.

3.1 Architekturen für Sensornetzwerke

Für die Kommunikation in einem Sensornetzwerk gibt es zwei vorherrschende Architekturen: die hierarchische und die flache Netzwerkarchitektur [ABJ+06]. Bei der hierarchischen Ar­chitektur werden die Sensorknoten in Cluster aufgeteilt, die sich auf unterschiedlichen Ebe­nen 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 wieder­um 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.

3.2 Netzwerktypen

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 Inter­vall 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.

4. Multi-Agenten-Technik

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 er­läutert. Danach werden Aspekte der Interaktion unter Agenten und Standards aus dem Bereich der MAS betrachtet.

4.1 Der Begriff Software-Agent

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 zu­nehmend 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 Mittel­punkt gerückt:

1) Flexibilität: Die Agenten können reaktiv und proaktiv handeln, d.h. auf Ereignisse ih­rer Umwelt reagieren und von sich aus planend und zielorientiert agieren.
2) Interaktivität: Agenten haben die Fähigkeit mit ihrer Umwelt, also auch mit menschli­chen Akteuren und anderen Agenten, zu interagieren. Dies kann z.B. in Form von Ver­handlungen zur Koordination von Tätigkeiten stattfinden. Voraussetzung dafür ist, dass der Agent in der Lage ist seine Umwelt durch eine bestimmte Sensorik wahrzu­nehmen und sie durch seine Aktorik verändern kann. Weiterhin muss er z.B. mit ande­ren 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 Um­welt. 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 wer­den. Dies hängt davon ab, inwieweit der Agent fähig ist autonom, rational, sozial, re­aktiv 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.

4.2 Multi-Agenten-Systeme

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 ver­bunden 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 unter­schiedliche Agentenarchitekturen und Prinzipien der Agentenkoordination und -kommunika­tion vorgestellt und diskutiert, inwiefern sie für den Einsatz in Sensornetzwerken in Frage kommen.

4.3 Netzwerktopologien

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-Protokoll­stapel ermöglicht es auf der Anwendungsebene verschiedene Typen von Netzwerken zu konfi­gurieren. 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

4.3.1 Client-Server

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 Kom­munikation zwischen den Clients statt. Mit dieser Netzwerkstrukur lassen sich hierarchische Sensornetze realisieren. Der Sensorknoten stellt den Client dar: Er sammelt proaktiv oder re­aktiv 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 die­sem 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 unterschiedli­che Server-Funktionen zu kapseln. Dabei sind folgende Ansätze denkbar:

- Der Server wird in Komponenten aufgeteilt, die jeweils eine wichtige Funktion über­nehmen 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 weite­res 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 gegebe­nenfalls 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 Anwendungs­domä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 Einzelak­tivitä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 auf­grund ihrer Spezialisierung wiederverwendbar. Durch die Zentralisierung einzelner Funktio­nen kann es allerdings dazu kommen, dass die Funktionalität des Netzes bei Ausfall von Komponenten, die wichtige Aufgaben übernehmen, beeinträchtigt wird.

4.3.2 Peer-to-Peer

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 gleichberech­tigt und gleich wichtig für das gesamte Netz. Er kann gleichzeitig Client sein und auch Ser­ver-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 Sen­sornetz eine eindeutige Schnittstelle nach Außen geben muss kommt schon aus diesem Grun­de 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 herausstel­len. 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 dezen­tralen Struktur und der damit vorhandenen Redundanz von Funktionsmodulen und Datenhal­tung 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].

4.4 Agentenarchitekturen

Die Funktionalitäten von Software-Agenten unterscheiden sich zum Teil stark, da sie abhän­gig 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 Klassi­fikation von Agententypen werden Agentenarchitekturen benutzt. Diese beschreiben den in­ternen Aufbau des Agenten, die benutzten Datenstrukturen, die Operationen, die auf diesen Datenstrukturen ausgeführt werden können und die Steuerung zwischen den einzelnen Kom­ponenten. Den unterschiedlichen Agententypen ist gemeinsam, dass ihr Aufbau durch drei Bauteile beschrieben werden kann: die Sensorik, die Schlussfolgerungskomponente und die Aktorik.

[...]