Modellierung und Realisierung vonAgenten- und Komponentensystemen

im Konstruktiven Ingenieurbau

Dietrich Hartmann, Jochen BilekRuhr-Universität Bochum

Armin B. Cremers, Sascha AldaUniversität Bonn

Udo F. Meißner, Uwe Rüppel, Mirko TheißTechnische Universität Darmstadt

2Sascha Alda, Jochen Bilek, Mirko Theiß

Gliederung

• Modellierung• Agenten im Bauwesen• Eigenschaften von Agenten und Aufbau von Multiagentensystemen• Modellorientiertes Vorgehen• Organisationsorientiertes Vorgehen

• Implementierung• Standardisierung von Agentensystemen• Realisierung verschiedener Aspekte in den Projekten

• Synergien zwischen den Projekten• Gemeinsame Realisierungen• Kopplungen zwischen den Projekten

• Ausblick• Weitere Arbeiten• Zukünftige Kooperation

3Sascha Alda, Jochen Bilek, Mirko Theiß

Heterogene Bauprojektstruktur

Dokumente

(Teil-) Produktmodelle

SoftwareProzesse

(Zuständen/Aktivitäten)

Termine

Planungsbeteiligte

4Sascha Alda, Jochen Bilek, Mirko Theiß

Vernetzt-kooperative Planungsprozesse

• Gesamt-Geflecht des Bauplanungsszenarios muss für die vernetzt-kooperative Planung geordnet werden

• Problem-Dekomposition unter Nutzung von Agenten• Berücksichtigung der Prozesse, Modelle, Personen und Software

Problem-zerlegung

Teilproblem-bearbeitung

Synthese vonTeilergebnissen

Problem-definition

Gesamt-ergebnis

5Sascha Alda, Jochen Bilek, Mirko Theiß

Nutzung von Agenten und Komponenten

• Kleine spezialisierte Einheiten, die verschiedene Aufgaben wahrnehmen• Kapselung von Diensten und Daten• Dynamische Einbindung• Verknüpfung von Agenten um weitere Aufgaben zu lösen

Planungsaufgabe

? !

„Gelbe Seiten“

Planungsergebnis

6Sascha Alda, Jochen Bilek, Mirko Theiß

Agentenbasierte Informationsverarbeitung

Charakteristika autonom mobil pro-aktiv reaktiv kooperativ

!

?Regeln

Wissensakquisition

Wissensverarbeitung

Kommunikation

Modellverarbeitung

??

?

Typen Informationsagenten Kooperationsagenten Transaktionsagenten Wrapperagenten

7Sascha Alda, Jochen Bilek, Mirko Theiß

Thematische Umsetzung in der Arbeitsgruppe

• Bochum - Tragwerksplanung am Beispiel einer Bogenbrücke• Integration beteiligter Organisationen und Planer• Modellierung von Tragsystemen• Einbindung von Software

• Bonn - Brandschutzplanung im Bereich des Denkmalschutzes• Verbesserung der Koordination der Beteiligten• Bereitstellung von Daten und Diensten durch Komponenten• Zugriffsbeschränkung für Gruppen von Fachplanern

• Darmstadt - Vorbeugender baulicher Brandschutz• Dezentraler Modellverbund aus Teilmodellen• Mobile Verarbeitungsmethoden• Überwachungsfunktionen zur Vermeidung von Planungsfehlern

8Sascha Alda, Jochen Bilek, Mirko Theiß

Agentenbasierte Kooperationsunterstützung

Organisationsorientiertes Vorgehen• Gesamtsystem ist aufgaben- und

rollenorientiert • Agenten als digitale Stellvertreter

von Personen, Firmen oder Behörden

Dokumente

Termine

Software

Teilproduktmodelle

Prozesse (Zustände/Aktivitäten)

Planungsbeteiligte

Modellorientiertes Vorgehen• Gesamtsystem ist modellorientiert • Agenten organisieren den

Austausch und Verarbeitung von Fachmodellen

• Fachmodelle sind Basis der Kommunikation

9Sascha Alda, Jochen Bilek, Mirko Theiß

Beispiel: Brandschutzplanung

BrandabschnittNutzung: Wohnen

BrandabschnittNutzung: Arbeiten

Bra

nd

wan

d

• Brandabschnitte müssen durch Brandwandgetrennt werden.

• Brandwände müssen spezielle Anforderungen erfüllen• Nicht brennbares Material• Mindest-Betondeckung• Mindest-Dicke der Wand

• Tragwerk muss umgeplant werden.d

c

nicht brennbaresMaterial

10Sascha Alda, Jochen Bilek, Mirko Theiß

Brandschutz Regelmodell

Anforderungen an BauteilBrandschutzwissen

Verteilte Modelle

ArchitekturmodellWandgeometrieBeziehung zu anderen ObjektenMaterial

BrandschutzmodellDefinition „Wand ist Brandwand“GebäudestandortGebäudetyp

Tragwerksmodell Bauliche Durchbildung

11Sascha Alda, Jochen Bilek, Mirko Theiß

BrandschutzModell

RegelModell

Verteilte Modellverarbeitung

GebäudeModell

TragwerksModell

ermitteln

Brandschutzelement

ermitteln notwendige

Brandschutzanforderungen für Brandwand

ermitteln der Geometrie-Informationen der Wand

ermitteln der Statik-Informationen der Wand

verarbeiten derInformationen

verarbeiten derInformationen

Brandwand(b23)

Regeln für Brandwand bei Gebäudetyp

Länge, Breite, Höhe, Material

Bewehrungsgrad, Betondeckung

12Sascha Alda, Jochen Bilek, Mirko Theiß

Verteilter agentenbasierter Modellverbund

Kommunikationsbedarf:

• Agent zu Mensch• Aufgabenübertragung• Problembehebung

• Agent zu Fachsoftware• Informationsermittlung• Informationsbereitstellung• Informationsdarstellung

• Agent zu Agent• Informationsaustausch• Informationsverarbeitung

Netzwerk

Brandschutzmodell

Brandschutz Regelmodell

TragwerksmodellArchitekturmodell

13Sascha Alda, Jochen Bilek, Mirko Theiß

Fachspezifische Ontologien

Gebäudemodell

Brandschutz Ontologie

vertrittArchitekt

vertrittBrandschutzplaner

Identifikation der Brandwand

Ident. der verknüpften Wand

Brandschutzmodell

• Dimensionen• Betondeckung• Material

• Wand ID• Brandschutzklasse

14Sascha Alda, Jochen Bilek, Mirko Theiß

Information-Wrapping

StationärerWrapper-Agent

DatenbankXML-Beschreibung

Gebäudemodell

XQuery / SQL

XML-Doc / Resultset

MobilerSuch-Agent

?

ACL

ACL

OntologieDienst

• Zur Verarbeitung müssen Informationendurch Such-Agenten gesammelt werden

• Datenbanken sind räumlich verteilt und durchunterschiedliche Datenbankschematabeschrieben

• Such- und Wrapper-Agenten benutzen diegleiche Ontologie

• Wrapper-Agent setzt die Anfrage in eineDatenbankspezifische Abfrage um.

• Das Resultat wird dem Such-Agentenin dem gewünschten Formatbereitgestellt

15Sascha Alda, Jochen Bilek, Mirko Theiß

Informationsverarbeitung

Regelbasiertes Expertensystem

Wissensbasis

Inferenzmaschine

FaktenRegeln

Kontrollsystem (Protokoll)

• Regeln• Bereitstellung durch Regelserver• Hierarchisch gegliedert

• Bundesland• Gebäudetyp• Brandschutzelement

• Zielgerichte Suche nach notwendigen Fakten möglich

• Fakten• Elemente der Teilproduktmodelle• Bereitstellung durch verteilte

Datenbanken mit Teilprodukt-modellen

• Kontrollsystem erlaubt Protokollierung der Prüfung.

Flag in Brandschutzmodell kennzeichnet erfolgreiche Überprüfung

16Sascha Alda, Jochen Bilek, Mirko Theiß

Modellbasiertes Multi-Agentensystemfür den baulichen Brandschutz

WHERE?

BrandschutzplanungAgent

Architektur Modell Agent

Brandschutz Modell Agent

Tragwerksplanung Modell Agent

Regel Modell Agent

Verzeichnisdienst“Gelbe Seiten”

17Sascha Alda, Jochen Bilek, Mirko Theiß

Wahrnehmung von Planungsaktivitäten

Ansatz

• Anwendung des Awareness Modells aus der CSCW

• Adoption des Modells auf wesentliche Anforderungen des KIB

Definition „Awareness“ / Eigenschaften

• Wahrnehmung von Planungsaktivitäten innerhalb einer Gruppe von Fachplanern,

die zusammen an ein gemeinsames Fachmodell arbeiten.

Information über Zustand und Fortschritt

Kontext für weitere, eigene Entscheidungen und Aktionen

• Dezentrale Architektur (Peer-to-Peer):

Keine zentralen Service-Einrichtungen

Gleichberechtigte Partner

18Sascha Alda, Jochen Bilek, Mirko Theiß

Wahrnehmung von Planungsaktivitäten

Ereignisbasiertes Modell

• Entwurfs-Zeit: Abbildung von Planungsaktivitäten auf Ereignistypen.

<data> <item> </item> ...</data

ändert öffnet

Modell DB

Fachplaner X Brandschutzmodell

Festlegung der Planungsaktivitäten

Definition der Ereignistypen

Deployment in CoBE

Registrierung

Anpassung betr. Software

CoBE DB

Abbildung

<applications> <application name = „Editor">

<activities> <activity name = „open">

</activity> <activity name = „change"> </activity>

</activities> ....

</applications>

z.B. Produktmodell

Editor

19Sascha Alda, Jochen Bilek, Mirko Theiß

Wahrnehmung von Planungsaktivitäten

Ereignisbasiertes Modell

• Benutzungs-Zeit: Die Ausführung einer Planungsaktivität löst ein Ereignis aus.

<data> <item> </item> ...</data

bearbeitet

Fachplaner X

Brandschutzmodell (model.dat)

Ausführen einer Planungsaktivität

Erhalt eines zeitbezogenen Ereignis

Benachrichtigung der Subscriber

Ermittlung

EreignistypZum Zeitpunkt t

Ermittlung

Subscriber

CoBE CoBE

Netzwerk

<event client = "Alex" application = "Whiteboard„ urgent = "false" date = "22.04.2003 16:29:40" type = "1" message = "Logged In" comment = "nothing„ id = "3"> </event>

20Sascha Alda, Jochen Bilek, Mirko Theiß

Beispiel: Tragwerksplanung

Verteilte Planung einer Fußgängerbogenbrücke

Technische Details:

Standort: Stadt Dessau

Zweck: Fußgängerbrücke über die Mulde

Länge: ca. 100m

Neigung: ca. 22°

Material: Stahl

Bauzeit: 1.3.-31.10.2000

21Sascha Alda, Jochen Bilek, Mirko Theiß

Verteilte Planung einer Fußgängerbrücke

Netzwerk

• Kommunikation (Telefon, Fax, Email)

• Termin- und Planungskoordination

• Austausch und Änderung von Planungsdaten

• Konflikt-Behebung

Stahlbetonbau Firma

Behörde Bauamt Dessau

Verpresspfahl FirmaBauherr

Stadt Dessau

Stahlbau Firma

Tragwerk-planungsbüro

22Sascha Alda, Jochen Bilek, Mirko Theiß

Agentenmodell und Ontologien

Produktmodell-Agenten

Wrapper-Agenten

Ontologien/ Produkt-Modelle:

• geometrisches Grundmodell

• statisches System

• Konstruktives Modell

Ontologien:

• CAD Ontologie

• FE Ontologie

• DB Ontologie

persönliche Agenten

Ontologien:

• Terminkoordination

• Datenaustausch

• Kommunikation

Kooperations-Agenten

CAD-Software

FE-Software

Datenbanken

unpersönliche (Organisations-) Agenten

Ontologien:

• Bürodaten

• Projektdaten/ Workflow

Büro-Agent

Projekt-Agent

23Sascha Alda, Jochen Bilek, Mirko Theiß

Organisations-Agent Projekt „Bogenbrücke“

virtuelle Projektorganisation „Bogenbrücke“

Agentenbasiertes Kooperationsmodell

Behörde Bauamt Dessau

Stahlbau Firma

Tragwerk-planungsbüro

Rolle „Projektleiter“ und „Statiker“ Stahlbau

1 Dipl.-Ing.

BauherrStadt Dessau

Rolle „Bauherr“

1 Mitarbeiterin

Verpresspfahl Firma

Rolle „Konstrukteur“ Stahlbau

1 Konstrukteur

Stahlbetonbau Firma

Rolle „Konstrukteur“ Betonbau

Rolle „Statiker“ Betonbau (Widerlager)

1 Dipl.-Ing. 1 Konstrukteurin

Rolle „Gast“ Fahrbahn1 Mitarbeiter

Rolle „Statiker“ Pfähle1 Dipl.-Ing.

7 persönliche Agenten und 7 Organisationen

24Sascha Alda, Jochen Bilek, Mirko Theiß

Agentenbasiertes Produktmodell

Produktmodell-Agent (PMA) "Gesamttragwerk"

Teiltragsystem-Ebene

Tragwerksdaten-Ebene

Tragstruktur-Ebene

XML-Dateien Objekte Datenbanken

PMA "Widerlager Fahrbahn"

PMA "Widerlager

Bogen"PMA "Fahrbahn"

PMA "Bogen"

25Sascha Alda, Jochen Bilek, Mirko Theiß

CAD-Agent

CAD-Agent

Agentenbasiertes Modell zur Softwareintegration

CAD-Software FE-Software

Datenbanken sonstige Software

Produkt-modell-Agenten

Projektdaten

Produkt-

modelldaten

Projekt-Agent

SQL Datenbank

Datenbank-AgentXML- Datenbank

sonstige Daten

persönliche AgentenGUI

FE-Agent

Finite Element Light

GUI

GUI

GUI

26Sascha Alda, Jochen Bilek, Mirko Theiß

Petrinetz als Wissensbasis

Modellierung des Workflows

Vorentwurf

Berechnung

• Berücksichtigung der Planungsphasen

• dynamische (offene) Petrinetze

• Berücksichtigung iterativer Planungsabläufe

• Sub-Petrinetze an persönliche Agenten

Persönliche Agenten der Fachplaner bearbeiten Teil-Netze

Projekt-Agent

Aufgaben-zuweisung

Bemessung

Konstruktion

27Sascha Alda, Jochen Bilek, Mirko Theiß

Implementierung

2. Teil

Realisierung

28Sascha Alda, Jochen Bilek, Mirko Theiß

Basis der technischen Zusammenarbeit

Komponente

Komponente

Komponente

Bonn

Bochum Darmstadt

Agentensysteme beruhen auf dem FIPA1-Standard

LARSHIVE

JADE/SEMOA

ACL

Nachrichtenaustausch basiert auf FIPA-ACL2

Implementierung der Agenten und Komponenten in Java

Wissensdarstellung und –verarbeitung durch XML

1 Foundation for Intelligent Physical Agents2 FIPA Agent Communication Language

29Sascha Alda, Jochen Bilek, Mirko Theiß

Die FIPA und die FIPA-Spezifikationen

Gründung 1996, Sitz Genf

Mitglieder Firmen (Siemens, IBM, Sun, NASA, Intel, HP, British Telecom, u.a.) und Universitäten (University of Helsinki, Westflorida, u.a.)

Ziel Entwicklung von Software-Standards für heterogene und interaktive Agenten und agenten-basierte Systeme

Ergebnisse 93 Spezifikationen, FIPA-konforme Agentenplattformen

Applications

Abstract Architecture

Agent Communication

Agent Management

Agent Message Transport

u.a. FIPA Agent Software Integration Specification

u.a. FIPA Abstract Architecture Specification

Aufbau von Agentenplattformen (z.B. JADE, FIPA-OS, ZEUS)

Interaction Protocols

Content Languages

Communicative Acts

u.a. FIPA Contract Net Interaction Protocol Specification,

FIPA Request Interaction Protocol Specification

FIPA Communicative Act Library Specification

u.a. FIPA CCL und FIPA KIF Content Language Specification

Foundation for Intelligent

Physical Agents

30Sascha Alda, Jochen Bilek, Mirko Theiß

FIPA Agentensystem Standard

Agentenplattform

MTS

DF

AMSDomäne

Agentenplattform

DF

AMS

registrierter Dienst

ACL

DF: Directory Facilitator, Yellow Pages Service, Dienstevermittlung

AMS: Agent Management System, White Pages, Agentenverwaltung und -steuerung

ACC: Agent Communication Channel, zentraler Kommunikationsdienst einer Plattform

MTS: Message Transport System, derzeit spezifiziert sind WAP, IIOP, HTTP

ORB: Object Request Broker, CORBA-basierter Kommunikationskanal

durch die FIPA spezifiziert

ACCACC

MTS

Kommunikationskanal (ORB/HTTP/WAP)

steuert

31Sascha Alda, Jochen Bilek, Mirko Theiß

Agentensysteme in den Projekten

Projekt Bonn:

- Agentensystem HIVE4

- stark an FIPA angelehnt

1 Secure Mobile Agents Project 2 Java Agent Development Environment 3 Living Agents Runtime System 4 engl.: Schwarm

Projekt Darmstadt:

- Agentensystem SEMOA1

- Agentensystem JADE2

- 100% FIPA konform

Nachrichten-austausch nicht

100% FIPA kompatibel

Mobilität

Projekt Bochum:

- Agentensystem LARS3

- stark an FIPA angelehnt

MASDF AMS

32Sascha Alda, Jochen Bilek, Mirko Theiß

Agentensysteme in den Projekten

Projekt Darmstadt:

- Agentensystem SEMOA1

- Agentensystem JADE2

- 100% FIPA konform

Projekt Bochum:

- Agentensystem LARS3

- stark an FIPA angelehnt

Projekt Bonn:

- Agentensystem HIVE4

- stark an FIPA angelehnt

1 Secure Mobile Agents Project 2 Java Agent Development Environment 3 Living Agents Runtime System 4 engl.: Schwarm

MASDF AMS

Implementierung von MTS-Agenten

• Funktion als Messagerouter

• Nachrichtenkonvertierung

ACL

33Sascha Alda, Jochen Bilek, Mirko Theiß

Projekt Bochum:Realisierung mit LARS

• Agentensystem LARS (Living Agents Runtime System) – Living Systems AG

• vollständig in Java implementiert, Agentenserver sehr stabil

• FIPA-konforme Architektur (DF, AMS, MessageRouter)

• Kommunikation läuft über System-Agenten (Listener-Agenten):

• AgentJMSListener : Kommunikation über die Java Message Service API

• AgentSecureSocketListener : verschlüsselte Kommunikation

• AgentSocketListener : rein Socket-basierter Nachrichtenaustausch

• AgentJSocketListener : serialisierte Kommunikation (Versand von Java-Objekten)

• AgentRMIListener : Java RMI basierte Kommunikation

• AgentHTTPListener : HTTP basierte Kommunikation

• Nachrichten basieren auf FIPA-ACL

• Unterstützt uneingeschränkte Mobilität

• Behaviour-/Capabilities-Klassen (Multithreading)

• weitere System-Agenten (Timer, etc.)

• wird kommerziell eingesetzt (über 30 agentenbasierte

Lösungen u.a. für die Deutsche Börse, Deutsche Post, Ebay)

• Client-like Agents (Applets, Servlets, etc.)

34Sascha Alda, Jochen Bilek, Mirko Theiß

Projekt Bochum:FE-Wrapper Agent

Ziel: Nutzung verschiedener Rechner und Server für Finite-Element Berechungen

Thread

Bestätigung/ Fehler/ Status der Berechnung

Thread

Realisierung stationärer FE-Wrapper-Agent

FE-Daten in XML Java-Runtime Prozess

Ansys 5.6Datenkonvertierung XML -> Ansys/FElt

Java-FE Bibliothek

Agent als FE-Modell Server

FE-XML Outputstream

XML-Schemata für 2d/3d-Berechnung

FE-XML Inputstream XSLT-

Transformation (hier: ansys.xsl)

Ansys Eingabedaten Inputstream

Ansys Ausgabedaten Outputstream

Client Agent

Übergabe FE-Daten

FE-Programm

1. Möglichkeit: mobiler FE-Agent

FE-Agent FE-Agent FE-Daten

Berechnung

2. Möglichkeit: stationärer FE-Agent

FE-AgentClient Agent

Ergebnisse

Nutzung FE-Resourcen

35Sascha Alda, Jochen Bilek, Mirko Theiß

Projekt Bochum:CAD-Wrapper-Agent

Ziel: Integration von AutoCAD2000

1. als reines Visualisierungstool zur Darstellung von Daten

2. als Instrument zur parallelen Bearbeitung von Zeichnungen auf entfernten Rechnern

1 Component Object Model

XML-Daten (z.B. FEM-Daten)

ACAD-COM1-Schnittstelle

Nachrichten-verarbeitung

Bestätigung/ Fehler

Steuerung/

Kontrolle

Zeichnen

Fachplaner 1

Sessionkontrolle

und -informationen

ACAD-Event-

Handling +

Zeichnen

Planer 2

Planer 3

Internet/ LAN

36Sascha Alda, Jochen Bilek, Mirko Theiß

Projekt Bochum:CAD-Wrapper Agent

JAVA Framework com2acad

- Kapselung der 421 Methoden der ACAD-COM-Schnittstelle und COM-Objekte in einer leicht anwendbaren JAVA-API1

- Implementierung einer XML-Import/ Export- Schnittstelle

- Realisierung eines Event-Handlings für die Klassen Application und Document

Agenten-Aufbau

1 Application Programming Interface

AgentTemplate

AcadCommModule

rub.bi.inginf. com2acad

Java ACAD Framework

Anbindung weitere CAD-Systeme möglich

Sitzungsinfor-mationen in XML

MessagesSitzungs-teilnehmer

37Sascha Alda, Jochen Bilek, Mirko Theiß

• JADE - Java Agent DEvelopment Framework – Telecom Italia Labs• Umsetzung der FIPA Spezifikationen• Vollständig in Java implementiert• Umfangreiche Unterstützung der Kommunikationsmechanismen

• Kommunikation basiert auf Java RMI• Unterstützung aller gängigen Interaktionsprotokolle• Integriert ACL-Parser und Ontology-Checker• Kann durch eigene Ontologien erweitert werden

Projekt Darmstadt:Realisierung mit dem Agentensystem JADE

• Umfangreiche Verhaltensweisen für bestimmte Aufgaben sind vorhanden und können erweitert werden(z.B. Nachrichtenempfang / -versand)

• Agent kann mehrere Aufgaben gleichzeitig ausführen

• Die Integration von Jess (Java Expert System Shell) wird unterstützt zur Erstellung „intelligenter Agenten“

38Sascha Alda, Jochen Bilek, Mirko Theiß

Projekt Darmstadt: Kommunikation unter Nutzungfachspezifischer Ontologien

• Agenten sind Java-Objekte und verarbeiten objektorientierte Strukturen• In Nachrichten werden jedoch in Strings übertragen• Informationen (Objekte) müssen in Nachricht kodiert werden• Durch die Registrierung einer Ontologie übernimmt das System die Konvertierung

Objekt Nachrichteninhalt und umgekehrt• Ein Agent kann seine registrierten Ontologien beim Verzeichnisdienst melden bzw.

abfragen, ob andere Agenten eine bestimmte Ontologie registrieren

JADEUnterstützungfür benutzer-

definierte Ontologie

Nachrichten-Inhalt

(Wand:ID 1007:Dicke 24:Material Beton)

Sender:

Empfänger:

Agenten-Name

Agenten-Name(n)

Sprechakt: FIPA-Sprechakt

Protokoll: FIPA-Interkationsprotokoll

class wand {private int id;private double dicke;private Material mat;

public int getID();public void setDicke(double d);public double getDicke();public void setMaterial(Material m);public Material getMaterial();

}

ACL-Nachricht Nachricht als Agenten-Quelltext

39Sascha Alda, Jochen Bilek, Mirko Theiß

Projekt Darmstadt: Modell des Datenbank-Wrapper

DatenbankAgent

DatenbankAgent

OntologieAgent

OntologieAgent

OntologieDienst

MobilerSuch Agent

MobilerSuch Agent

FIPA-ACL

XQuery

XQuery

SQL-Query

Service

Registrierung

SicherheitsAgent

SicherheitsAgent

AnfrageBerechtigungs-

check

AnfrageBearbeitung

ErgebnisBearbeitung

:SuchAgent :DBAgent :Datenbank

AnfrageCommit

Ergebnis-verarbeitung

FIPA-ACL

FIPA-ACL

XQuery

XML-Doc SQL-Result

SQL-Query

40Sascha Alda, Jochen Bilek, Mirko Theiß

Projekt Darmstadt:Implementierung der Brandschutzagenten

• In Brandschutzagenten wurde das regelbasierte Expertensystem Jess (Java Expert System Shell) integriert

• Agent kann von jedem Kooperationsserver angefordert und instanziiert werden

• Agent bezieht seine Regelbasis von zentralen Regelservern

• Regeln werden mit einem Regeleditor in Protégé erstellt und direkt mit den Klassen der Ontologie verknüpft

• Regeln sind in CLIPS (C Language Integrated Production System), einem LISP ähnlichem Syntax definiert

Regeleditor

41Sascha Alda, Jochen Bilek, Mirko Theiß

Software Komponenten

Definition „Software Komponente“ / Eigenschaften

• Abgeschlossene Kompositionseinheiten mit (vertraglich) fest definierten

Schnittstellen

• Kapselung von

- Daten (z.B. Brandschutzmodell)

- Diensten (z.B. Konsistenzprüfung auf Modellierungsfehler)

• Einbindung (Deployment) zur Laufzeit

Abgrenzung zu Agenten (im Kontext der gemeinsamen Arbeiten):

• Keine Mobilität, kein aktives Verhalten

• Komponente entspricht im engeren Sinne Wrapper-Agent (Kapselung)

42Sascha Alda, Jochen Bilek, Mirko Theiß

Modell eines komponentenbasierten Kooperationsverbunds

Fachplaner stellen über Komponenten Dienste und Daten dem Kooperations-verbund zur Verfügung

Architekt

Fachplaner

Brandschutz Experte

Besitzer

Fach modell

Fachplaner

Brand schutz regeln

Konsistenz-

prüfung

Datenaustausch / Abstimmung

Wahrnehmung Beratung

FachplanerNEU

Denkmalschutz Experte

Kein Zugriff für nicht-autorisierte Leute!!

Fach modell

Fach modell

43Sascha Alda, Jochen Bilek, Mirko Theiß

Resultierende Anforderungen an eine Software Plattform

• Integration von neuen Teilnehmern in die Umgebung

• Integration und Anpassung von Komponenten zur Laufzeit

• Laufzeitumgebung besitzt Client & Server Funktionalität (Peer-to-Peer)

• Bildung von virtuellen Gruppen

• Beschränkung beim Zugriff auf Komponenten

• Unterstützung des Endbenutzers

• Möglichst generischer Zugriff auf Komponenten

• Meta-Beschreibung von Komponenten

• Mediator-Konzepte zur Einbindung von

Fremd-Komponenten

• Koordination (Wahrnehmung) beim Zugriff auf Komponenten

• Berücksichtigung der Privatsphäre

• Filterung von Informationen

Component Architecture

Component Model

Awareness Framework

44Sascha Alda, Jochen Bilek, Mirko Theiß

Peer-to-Peer Modell als Basis Modell

Definition „Peer-to-Peer“

Teilen (Sharing) von Computer Ressourcen durch den direkten Austausch zwischen

gleichberechtigten Rechnern (Peers).

Eigenschaften• Peers haben Client und Server Funktionalität

• Selbst-Organisation der Peers in virtuellen Gruppen

• Kenntnis von anderen Peers

• Virtuelles Netzwerk (eigene Adressdomäne)

Standards

• Weniger verbreitet als z.B. bei Web Services (SOAP, WSDL, UDDI)

• JXTA von SUN ist zur Zeit der De Facto Standard

45Sascha Alda, Jochen Bilek, Mirko Theiß

Peer-to-Peer Modell als Basis Modell

JXTA

• Protokoll Sammlung zur Entwicklung von Peer-to-Peer Applikationen

• Programmiersprachen- und plattformunabhängig

• Meta-Beschreibung von Ressourcen durch Advertisements (XML-basiert)

• Wichtigste Protokolle:

- Discovery Protocol (Suche nach Advertisements)

- Rendesvouz Protocol (realisiert u.a. die Verteilung von Advertisements)

- Group Membership Protocol (Organisation von Gruppen)

- Pipe Protocol (XML-basiertes Übertragunsprotokoll, ähnlich SOAP)

• Referenz-Implementierung in Java

46Sascha Alda, Jochen Bilek, Mirko Theiß

FlexiBeans Komponente

• Zwei Interaktionsprimitive: Event and Shared Object

• Entfernter Zugriff durch Remote Method Invocation (RMI) Technik

• Externalisierung der Komponente durch JXTA-Advertisement

• Peer Service: FlexiBeans Komponente, die durch ein Advertisement beschrieben

ist und gefunden werden kann.

<jxta:ModuleAdvertisement xmlns:jxta=„http://jxta.org“>

<ID> Urn:jxta:uuid-D61784748374E473....</ID>

<Type>Peer Service</Type>

<Name> Wrapper für Datenmodell ‚model.dat‘ </Name>

<Param>Name = „Sascha Alda“</Param>

</jxta>

Component Model

47Sascha Alda, Jochen Bilek, Mirko Theiß

• Dezentrale Peer-to-Peer Komponenten-Architektur, basierend auf Client-Server

Architektur FreEvolve (Uni Bonn 2000-2003) und JXTA

FreEvolve PeerFreEvolve Peer

FreEvolve PeerFreEvolve PeerFreEvolve PeerFreEvolve Peer

Anbieter eines Peer ServiceKonsument eines Peer Service

• FlexiBeans Komponentenmodell (+ Erweiterung Peer Service)

• Komposition von lokalen und entfernten Komponenten durch Kompositionssprache

DeCAT

• Integration von (adaptiven) Anpassungsstrategien

Component Architecture

Laufzeitumgebung

48Sascha Alda, Jochen Bilek, Mirko Theiß

Neue Management-Tools

• GUI-Oberfläche zur Suche & Integration

- Komponenten (Daten & Diensten)

- Peers (Fachplaner)

- Peer Gruppen (Bauprojekte)

• Definition und Verwaltung von Gruppen

Component Architecture

• Anpassung von Komponenten in

einem visuellen Editor (Tailoring-Client)

49Sascha Alda, Jochen Bilek, Mirko Theiß

FachplanerNEU Architekt (Admin) Fachplaner

findAdvertisement( Param par)

initialRequest( Data data )

Credential::object

apply( Credential c )

join()

(Xml-Advertisments)*

true

useService( String Name )

Compoment-Plan, Components

Gruppe „Bauprojekt X“

....

Dis

cove

ry

P

roto

col

Mem

ber

ship

Pro

toco

lF

reE

volv

e

events / access to shared object

Zusammenspiel Jxta und FreEvolve:Einbindung eines Planer in eine Gruppe

2

3

1

50Sascha Alda, Jochen Bilek, Mirko Theiß

Awareness Framework

• Java-basiertes Komponenten-Framework (FlexiBeans-Komponenten)

Awareness Framework

Applikation (z.B. Produktmodell

Editor)

Zuordnung Ereignisse Ermittlung Subscriber

Persistente Speicherung von Ereignissen

Ereignis-

Historie

(XML)

Benutzer DB

(XML)

Synchrone Übermittlung (Subscriber Online)

Popup-Fenster

Mail in Mail-Client

Kontrolldialog für das Framework (z.B. Filtereinstellungen, Benutzerauswahl)

Netzwerk

Asynchrone Übermittlung (Subscriber Offline)

51Sascha Alda, Jochen Bilek, Mirko Theiß

Filter-Agent

Wahrnehmung von Planungsaktivitäten

Filtern von Ereignissen

• Schutz insbesondere der Privatsphäre für Publisher (Privatsphären-Filter)

• Pre-Selektion für den Subscriber (Interessen-Filter)

• Vereinheitlichung / Anonymisierung von Daten (Organisations-Filter)

• Filter werden als Software Agenten realisiert (Agenten-System HIVE)

Erhalt eines zeitbezogenen Ereignis

Benachrichtigung der Subscriber

Ermittlung Subscriber

Awareness Framework

...

+ Filter-Agent

Benachrichtigung

evtl. modifiziert

Verwerfung

Filtern eines Ereignis

Netzwerk

<event client = "Alex" application = "Whiteboard„ urgent = "false" date = "22.04.2003 16:29:40" type = "1" message = "Logged In" comment = "nothing„ id = "3"> </event>

Filter-Agent

52Sascha Alda, Jochen Bilek, Mirko Theiß

CoBE Awareness Framework

Modell

DBWrapper-Agent

Modell DBModell DBNetwork

Weitergabe von Ereignissen

Einschreibung (über mobilen Transportagent)

Fachplaner Y

Einschreibung (direkt)

Synergien: Projekt Darmstadt und Projekt Bonn

Produkt- Modell

Editor

Awareness Framework

Wrapper-Agent

Transport-Agent

CoBECoBE

Fachplaner XFachplaner X

Fachplaner X

Transport-Agent„„Brandschutz- Brandschutz- Agent“Agent“

• Integration des Awareness Frameworks in den agentenbasierten Modellverbund zur kollaborativen Brandschutzplanung

(Gemeinsame Publikation: Alda, Cremers, Meißner, Rüppel, Theiß: „Wahrnehmung

und Verarbeitung von Ereignissen bei der verteilten Planung im baulichen Brandschutz“, in: Ergebnisband der IKM 2003. Weimar. 2003)

• Technische Realisierung in Form von Vertiefer-/Diplomarbeiten ist geplant

53Sascha Alda, Jochen Bilek, Mirko Theiß

Synergien: Projekt Bonn und Projekt Bochum

Produkt-modell

DBWrapper-Agent

DatenbankenDatenbanken Network

Weitergabe von Ereignissen

Einschreibung (über ACL-Nachrichten)

Fachplaner Y

Einschreibung (direkt)Awareness Framework

Wrapper-Agent

CoBECoBE

Fachplaner X

• Mögliche Integration des Awareness Frameworks in das Agentenmodell für die

Tragwerksplanung (Workflow, Produktmodell)

• Technische Realisierung in Form von Diplomarbeiten ist geplant

Workflow

DB

Workflow Editor

Projekt-Agent

Produktmodell-Agenten

com2acad Framework

ACAD 2000

54Sascha Alda, Jochen Bilek, Mirko Theiß

MySQL DB

Synergien: Projekt Darmstadt und Bochum

• Vertiefer-/Diplomarbeitarbeit zur gemeinsamen Weiterentwicklung des Datenbank-Wrapper-Agenten Einsatzes in den Projekten

• Einsatz des in Bochum entwickelten com2acad Frameworks für einen CAD-Agenten im Darmstädter-Projekt

• Übernahme des Produktmodell-Editor Konzepts aus Darmstadt im Bochumer Projekt

LARSLARS

SeMOA/JADE SeMOA/JADE

rub.bi.inginf. com2acad

Tamino XML-DB

XIndice XML-DB

DB-Wrapper-Agent

DB-Wrapper-Agent

CAD-Wrapper-Agent

MTS-Agent

MTS-Agent

Agent Fachplaner Darmstadt

Agent Fachplaner

Bochum

ACL/ Ontologie

55Sascha Alda, Jochen Bilek, Mirko Theiß

Gemeinsames Web-Portal zur Präsentation der Ergebnisse

56Sascha Alda, Jochen Bilek, Mirko Theiß

Ausblick

Weiteres Vorgehen:

• Prototypische Umsetzungen in den Einzelprojekten werden forciert

• Technische Umsetzung der Verknüpfungspunkte zwischen den Teilprojekten

• Evaluierung der Modelle und Konzepte anhand der Prototypen

• Überprüfung der Skalierbarkeit anhand der Prototypen

Modellierung und Realisierung vonAgenten- und Komponentensystemen

im Konstruktiven Ingenieurbau

Dietrich Hartmann, Jochen BilekRuhr-Universität Bochum

Armin B. Cremers, Sascha AldaUniversität Bonn

Udo F. Meißner, Uwe Rüppel, Mirko TheißTechnische Universität Darmstadt

58Sascha Alda, Jochen Bilek, Mirko Theiß

59Sascha Alda, Jochen Bilek, Mirko Theiß

BACKUP

60Sascha Alda, Jochen Bilek, Mirko Theiß

Component Architecture

• Dezentrale Peer-to-Peer Komponenten-Architektur

• Basierend auf Komponenten-Architektur EVOLVE (Uni Bonn 2000-

2003)

• FlexiBeans Komponentenmodell

• Durch Integration von JXTA erweitere Möglichkeiten

- Suche nach Komponenten (Fachmodellen, Dienste)

- Suche nach Peers (Fachplanern)

- Suche nach Peer Gruppen (Projekte)

• Entwicklung von neuen Management-Tools

• Suche, Integration, Anpassung von Komponenten

• Definition und Verwaltung von Gruppen

• Weiterentwicklung der Kompositionssprache

61Sascha Alda, Jochen Bilek, Mirko Theiß

Awareness Framework

Nicht alle wesentlichen Anforderungen lassen sich durch die

Komponententechnologie realisieren:

Resultierende Anforderungen an eine Software Plattform

Agent Support

• Koordination (Wahrnehmung) beim Zugriff auf Komponenten

• Berücksichtigung der Privatsphäre

• Filterung von Informationen

62Sascha Alda, Jochen Bilek, Mirko Theiß