Dietrich Hartmann, Jochen Bilek Ruhr-Universität Bochum

Präsentation zum Thema: "Dietrich Hartmann, Jochen Bilek Ruhr-Universität Bochum"—  Präsentation transkript:

1 Modellierung und Realisierung von Agenten- und Komponentensystemen im Konstruktiven Ingenieurbau
Dietrich Hartmann, Jochen Bilek Ruhr-Universität Bochum Armin B. Cremers, Sascha Alda Universität Bonn Udo F. Meißner, Uwe Rüppel, Mirko Theiß Technische Universität Darmstadt

2 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 Sascha Alda, Jochen Bilek, Mirko Theiß

3 Heterogene Bauprojektstruktur
(Teil-) Produktmodelle Planungsbeteiligte Dokumente Prozesse (Zuständen/ Aktivitäten) Software Termine Sascha Alda, Jochen Bilek, Mirko Theiß

4 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 von Teilergebnissen Problem- definition Gesamt- ergebnis Sascha Alda, Jochen Bilek, Mirko Theiß

5 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 „Gelbe Seiten“ ! ? Planungsaufgabe Planungsergebnis Sascha Alda, Jochen Bilek, Mirko Theiß

6 Agentenbasierte Informationsverarbeitung
Charakteristika autonom mobil pro-aktiv reaktiv kooperativ ! ? Regeln Wissensakquisition ü û Wissensverarbeitung Kommunikation Modellverarbeitung Typen Informationsagenten Kooperationsagenten Transaktionsagenten Wrapperagenten Sascha Alda, Jochen Bilek, Mirko Theiß

7 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 Sascha Alda, Jochen Bilek, Mirko Theiß

8 Agentenbasierte Kooperationsunterstützung
Modellorientiertes Vorgehen Gesamtsystem ist modellorientiert Agenten organisieren den Austausch und Verarbeitung von Fachmodellen Fachmodelle sind Basis der Kommunikation Prozesse (Zustände/Aktivitäten) Teilproduktmodelle Termine Dokumente Organisationsorientiertes Vorgehen Gesamtsystem ist aufgaben- und rollenorientiert Agenten als digitale Stellvertreter von Personen, Firmen oder Behörden Planungsbeteiligte Software Sascha Alda, Jochen Bilek, Mirko Theiß

9 Beispiel: Brandschutzplanung
Brandabschnitt Nutzung: Wohnen Nutzung: Arbeiten Brandwand Brandabschnitte müssen durch Brandwand getrennt werden. Brandwände müssen spezielle Anforderungen erfüllen Nicht brennbares Material Mindest-Betondeckung Mindest-Dicke der Wand Tragwerk muss umgeplant werden. nicht brennbares Material d c Sascha Alda, Jochen Bilek, Mirko Theiß

10 Verteilte Modelle Brandschutz Regelmodell
Anforderungen an Bauteil Brandschutzwissen Brandschutzmodell Definition „Wand ist Brandwand“ Gebäudestandort Gebäudetyp Architekturmodell Wandgeometrie Beziehung zu anderen Objekten Material Tragwerksmodell Bauliche Durchbildung Sascha Alda, Jochen Bilek, Mirko Theiß

11 Verteilte Modellverarbeitung
Brandschutz Modell Regel Modell Gebäude Modell Tragwerks Modell ermitteln Brandschutzelement Brandwand(b23) verarbeiten der Informationen ermitteln notwendige Brandschutzanforderungen für Brandwand Regeln für Brandwand bei Gebäudetyp verarbeiten der Informationen ermitteln der Geometrie-Informationen der Wand Länge, Breite, Höhe, Material ermitteln der Statik-Informationen der Wand Bewehrungsgrad, Betondeckung Sascha Alda, Jochen Bilek, Mirko Theiß

12 Verteilter agentenbasierter Modellverbund
Netzwerk Brandschutzmodell Brandschutz Regelmodell Tragwerksmodell Architekturmodell Kommunikationsbedarf: Agent zu Mensch Aufgabenübertragung Problembehebung Agent zu Fachsoftware Informationsermittlung Informationsbereitstellung Informationsdarstellung Agent zu Agent Informationsaustausch Informationsverarbeitung Sascha Alda, Jochen Bilek, Mirko Theiß

13 Fachspezifische Ontologien
vertritt Brandschutzplaner vertritt Architekt Identifikation der Brandwand Ident. der verknüpften Wand Brandschutz Ontologie Brandschutzmodell Gebäudemodell Wand ID Brandschutzklasse Dimensionen Betondeckung Material Sascha Alda, Jochen Bilek, Mirko Theiß

14 Information-Wrapping
Zur Verarbeitung müssen Informationen durch Such-Agenten gesammelt werden Datenbanken sind räumlich verteilt und durch unterschiedliche Datenbankschemata beschrieben Such- und Wrapper-Agenten benutzen die gleiche Ontologie Wrapper-Agent setzt die Anfrage in eine Datenbankspezifische Abfrage um. Das Resultat wird dem Such-Agenten in dem gewünschten Format bereitgestellt Ontologie Dienst ACL XQuery / SQL ACL ? XML-Doc / Resultset Datenbank XML-Beschreibung Gebäudemodell Stationärer Wrapper-Agent Mobiler Such-Agent Sascha Alda, Jochen Bilek, Mirko Theiß

15 Informationsverarbeitung
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 Regelbasiertes Expertensystem Wissensbasis Regeln Fakten Inferenzmaschine Kontrollsystem (Protokoll) Sascha Alda, Jochen Bilek, Mirko Theiß

16 Modellbasiertes Multi-Agentensystem für den baulichen Brandschutz
WHERE? Verzeichnisdienst “Gelbe Seiten” Brandschutz Modell Agent Regel Modell Agent Brandschutzplanung Agent Tragwerksplanung Modell Agent Architektur Modell Agent Sascha Alda, Jochen Bilek, Mirko Theiß

17 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 Bei dem hier verwendeten Modell zur Wahrnehmung von Planungsaktivitäten handelt es sich um die Anwendung des bekannten Awareness Modells aus dem Bereich der CSCW (Computer Supported Cooperative Work). Das Bonner Projekt hat es sich zur Aufgabe gemacht, dieses bekannte Modell auf wesentliche Anforderungen des konstruktiven Ingenieurbaus anzupassen. Im Kontext des KiB definieren wir Awareness als die „Wahrnehmung von ....“ Eine solche Wahrnehmung liefert zu einen grundlegende Informationen über den Zustand und Fortschritt von Planungsaktivitäten. Zu anderen liefern diese Informationeneinen Kontext für weitere, eigene Entscheidungen und Aktionen. Im Gegensatz zu anderen Ansätzen aus dem Bereich der Awareness obliegt der Bonner Ansatz auf einer dezentralen Architektur. In dieser Architektur sind sämtliche Planer gleichberechtigt, d.h. ein Planer kann eigenständig entscheiden, welche Planungsaktivität er wahrnehmen will bzw. welche anderen Planer ihn wahrnehmen dürfen. Diese Architektur kommt dabei ohne zentralen Service-Einrichtungen aus, die für die Weiterreichung von Informationen über Aktivitäten zuständig sind. Sascha Alda, Jochen Bilek, Mirko Theiß

18 Wahrnehmung von Planungsaktivitäten
Ereignisbasiertes Modell Entwurfs-Zeit: Abbildung von Planungsaktivitäten auf Ereignistypen. Modell DB Registrierung CoBE DB <applications> <application name = „Editor"> <activities> <activity name = „open"> </activity> <activity name = „change"> </activity> </activities> </applications> ändert öffnet Abbildung <data> <item> </item> ... </data z.B Produktmodell Editor Anpassung betr. Software Fachplaner X Brandschutzmodell Das (Bonner) Modell zur Wahrnehmung von Planungsaktivitäten basiert grundlegend auf ein ereignisbasiertes Modell: die Ausführung einer Planungsaktivität entspricht der Auslösung eines Ereignis, das fortan zur weiteren Bearbeitung zur Verfügung steht. Bei der Umsetzung des Modells muss man zwei verschiedene Zeiträume betrachten: Während der Entwurfs-Zeit des Modells gilt es, konkrete Planungsaktivitäten zu identifizieren (Beispiel: Fachplaner X öffnet ein Brandschutzmodell aus einer Modell-DB) und diese auf konkrete Ereignistypen abzubilden. Hat man sämtliche Ereignistypen identifiziert, so muss man diese, wie in dem Bonner Projekt vorgesehen, zentral in der CoBE DB registrieren. Daneben muss man die entsprechende Software anpassen, aus der später konkrete Ereignisse heraus erzeugt werden. Festlegung der Planungsaktivitäten Definition der Ereignistypen Deployment in CoBE Sascha Alda, Jochen Bilek, Mirko Theiß

19 Wahrnehmung von Planungsaktivitäten
Ereignisbasiertes Modell Benutzungs-Zeit: Die Ausführung einer Planungsaktivität löst ein Ereignis aus. CoBE CoBE <event client = "Alex" application = "Whiteboard„ urgent = "false" date = " :29:40" type = "1" message = "Logged In" comment = "nothing„ id = "3"> </event> bearbeitet <data> <item> </item> ... </data Ermittlung Ereignistyp Ermittlung Subscriber Netzwerk Zum Zeitpunkt t Brandschutzmodell (model.dat) Fachplaner X Zur eigentlichen Laufzeit oder Benutzungs-Zeit des Modells löst die Ausführung einer Planungsaktivität ein konkretes, zeitbezogenes Ereignis aus. Die Ereignisse, die während einer Planungsaktivität aus der angepassten Software heraus erzeugt werden, gelten als Indikatoren für die Ermittlung eines konkreten Ereignistyps. Aus dem ermittelten Ereignistyp wird dann eine Instanz erzeugt, die dann einem zeitbezogenen Ereignis entspricht. Anschließend wird die Liste der Subscriber ermittelt, die sich für eine bestimmte Planungsaktivität im Vorfeld eingeschrieben haben. Die in dieser Liste enthaltenen Subscriber erhalten dann eine Benachrichtigung über das ausgelöste Ereignis. Ausführen einer Planungsaktivität Erhalt eines zeitbezogenen Ereignis Benachrichtigung der Subscriber Sascha Alda, Jochen Bilek, Mirko Theiß

20 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: Sascha Alda, Jochen Bilek, Mirko Theiß

21 Verteilte Planung einer Fußgängerbrücke
Stahlbetonbau Firma Verpresspfahl Firma Bauherr Stadt Dessau Behörde Bauamt Dessau Netzwerk Stahlbau Firma Tragwerk-planungsbüro Kommunikation (Telefon, Fax, ) Termin- und Planungskoordination Austausch und Änderung von Planungsdaten Konflikt-Behebung Sascha Alda, Jochen Bilek, Mirko Theiß

22 Agentenmodell und Ontologien
Kooperations-Agenten Produktmodell-Agenten Büro-Agent Ontologien/ Produkt-Modelle: geometrisches Grundmodell statisches System Konstruktives Modell Projekt-Agent Wrapper-Agenten unpersönliche (Organisations-) Agenten Ontologien: CAD Ontologie FE Ontologie DB Ontologie persönliche Agenten CAD-Software FE-Software Datenbanken Ontologien: Terminkoordination Datenaustausch Kommunikation Ontologien: Bürodaten Projektdaten/ Workflow Sascha Alda, Jochen Bilek, Mirko Theiß

23 Agentenbasiertes Kooperationsmodell
Organisations-Agent Projekt „Bogenbrücke“ virtuelle Projektorganisation „Bogenbrücke“ Tragwerk-planungsbüro Stahlbetonbau Firma Rolle „Konstrukteur“ Betonbau Rolle „Statiker“ Betonbau (Widerlager) 1 Dipl.-Ing. 1 Konstrukteurin Rolle „Projektleiter“ und „Statiker“ Stahlbau 1 Dipl.-Ing. Rolle „Bauherr“ 1 Mitarbeiterin Bauherr Stadt Dessau Stahlbau Firma Rolle „Konstrukteur“ Stahlbau 1 Konstrukteur Verpresspfahl Firma Rolle „Statiker“ Pfähle 1 Dipl.-Ing. Behörde Bauamt Dessau Rolle „Gast“ Fahrbahn 1 Mitarbeiter 7 persönliche Agenten und 7 Organisationen Sascha Alda, Jochen Bilek, Mirko Theiß

24 Agentenbasiertes Produktmodell
Tragstruktur-Ebene Produktmodell-Agent (PMA) "Gesamttragwerk" PMA "Widerlager Fahrbahn" PMA "Widerlager Bogen" PMA "Fahrbahn" PMA "Bogen" Teiltragsystem-Ebene XML-Dateien Objekte Datenbanken Tragwerksdaten-Ebene Sascha Alda, Jochen Bilek, Mirko Theiß

25 Agentenbasiertes Modell zur Softwareintegration
CAD-Software FE-Software Datenbanken sonstige Software SQL Datenbank Datenbank-Agent XML- Datenbank sonstige Daten Produkt-modell-Agenten Projektdaten Produkt-modelldaten Projekt-Agent persönliche Agenten GUI CAD-Agent GUI FE-Agent Finite Element Light GUI Sascha Alda, Jochen Bilek, Mirko Theiß

26 Modellierung des Workflows
Petrinetz als Wissensbasis Vorentwurf Projekt-Agent Aufgaben-zuweisung Berechnung Persönliche Agenten der Fachplaner bearbeiten Teil-Netze Bemessung Konstruktion Berücksichtigung der Planungsphasen dynamische (offene) Petrinetze Berücksichtigung iterativer Planungsabläufe Sub-Petrinetze an persönliche Agenten Sascha Alda, Jochen Bilek, Mirko Theiß

27 2. Teil Realisierung Implementierung
Sascha Alda, Jochen Bilek, Mirko Theiß

28 Basis der technischen Zusammenarbeit
Komponente Bonn Bochum Darmstadt ACL LARS HIVE JADE/SEMOA Agentensysteme beruhen auf dem FIPA1-Standard Nachrichtenaustausch basiert auf FIPA-ACL2 Implementierung der Agenten und Komponenten in Java Wissensdarstellung und –verarbeitung durch XML 1 Foundation for Intelligent Physical Agents 2 FIPA Agent Communication Language Sascha Alda, Jochen Bilek, Mirko Theiß

29 Die FIPA und die FIPA-Spezifikationen
Foundation for Intelligent Physical Agents 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 u.a. FIPA Agent Software Integration Specification u.a. FIPA Abstract Architecture Specification Aufbau von Agentenplattformen (z.B. JADE, FIPA-OS, ZEUS) Abstract Architecture Agent Communication Agent Management Agent Message Transport Interaction Protocols u.a. FIPA Contract Net Interaction Protocol Specification, FIPA Request Interaction Protocol Specification Communicative Acts FIPA Communicative Act Library Specification Content Languages u.a. FIPA CCL und FIPA KIF Content Language Specification Sascha Alda, Jochen Bilek, Mirko Theiß

30 FIPA Agentensystem Standard
Agentenplattform durch die FIPA spezifiziert Agentenplattform registrierter Dienst DF DF Domäne AMS AMS steuert ACC ACC MTS MTS ACL Kommunikationskanal (ORB/HTTP/WAP) 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 Sascha Alda, Jochen Bilek, Mirko Theiß

31 Agentensysteme in den Projekten
Projekt Darmstadt: - Agentensystem SEMOA1 Agentensystem JADE2 100% FIPA konform Projekt Bochum: Agentensystem LARS3 stark an FIPA angelehnt MAS DF AMS Mobilität Projekt Bonn: Agentensystem HIVE4 stark an FIPA angelehnt Nachrichten-austausch nicht 100% FIPA kompatibel 1 Secure Mobile Agents Project 2 Java Agent Development Environment 3 Living Agents Runtime System 4 engl.: Schwarm Sascha Alda, Jochen Bilek, Mirko Theiß

32 Agentensysteme in den Projekten
Projekt Darmstadt: - Agentensystem SEMOA1 Agentensystem JADE2 100% FIPA konform Projekt Bochum: Agentensystem LARS3 stark an FIPA angelehnt ACL Implementierung von MTS-Agenten Funktion als Messagerouter Nachrichtenkonvertierung Projekt Bonn: Agentensystem HIVE4 stark an FIPA angelehnt DF MAS AMS 1 Secure Mobile Agents Project 2 Java Agent Development Environment 3 Living Agents Runtime System 4 engl.: Schwarm Sascha Alda, Jochen Bilek, Mirko Theiß

33 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.) Sascha Alda, Jochen Bilek, Mirko Theiß

34 Projekt Bochum: FE-Wrapper Agent
Ziel: Nutzung verschiedener Rechner und Server für Finite-Element Berechungen FE-Daten Berechnung 2. Möglichkeit: stationärer FE-Agent FE-Agent Client Agent Ergebnisse Nutzung FE-Resourcen Client Agent Übergabe FE-Daten FE-Programm 1. Möglichkeit: mobiler FE-Agent FE-Agent Thread Bestätigung/ Fehler/ Status der Berechnung Realisierung stationärer FE-Wrapper-Agent FE-Daten in XML Java-Runtime Prozess Ansys 5.6 Datenkonvertierung 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 Sascha Alda, Jochen Bilek, Mirko Theiß

35 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 XML-Daten (z.B. FEM-Daten) ACAD-COM1-Schnittstelle Nachrichten-verarbeitung Bestätigung/ Fehler Steuerung/ Kontrolle Zeichnen Planer 2 Planer 3 Internet/ LAN Fachplaner 1 Sessionkontrolle und -informationen ACAD-Event-Handling + Zeichnen 1 Component Object Model Sascha Alda, Jochen Bilek, Mirko Theiß

36 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 Messages Sitzungs-teilnehmer AgentTemplate AcadCommModule Sitzungsinfor-mationen in XML rub.bi.inginf. com2acad Java ACAD Framework Anbindung weitere CAD-Systeme möglich 1 Application Programming Interface Sascha Alda, Jochen Bilek, Mirko Theiß

37 Projekt Darmstadt: Realisierung mit dem Agentensystem JADE
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 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“ Sascha Alda, Jochen Bilek, Mirko Theiß

38 Nachricht als Agenten-Quelltext
Projekt Darmstadt: Kommunikation unter Nutzung fachspezifischer 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 ACL-Nachricht Nachricht als Agenten-Quelltext 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(); } Sender: Agenten-Name Empfänger: Agenten-Name(n) Sprechakt: FIPA-Sprechakt JADE Unterstützung für benutzer- definierte Ontologie Protokoll: FIPA-Interkationsprotokoll Nachrichten-Inhalt (Wand :ID 1007 :Dicke 24 :Material Beton) Sascha Alda, Jochen Bilek, Mirko Theiß

39 Projekt Darmstadt: Modell des Datenbank-Wrapper
Service Registrierung Ontologie Agent Ontologie Dienst FIPA-ACL Mobiler Such Agent FIPA-ACL XQuery Datenbank Agent XQuery SQL-Query FIPA-ACL Sicherheits Agent :SuchAgent :DBAgent :Datenbank Anfrage Berechtigungs- check Datenbank-Wrapper-Agent kapselt die Informationsbereitstellung für mobile Such-Agenten. Wrapper-Agent ist stationär. Die Kommunikation zwischen allen Agenten im Agentensystem erfolgt über FIPA-ACL. Die Anfrage wird innerhalb der Kooperationsverbundes generell durch XQuery durchgeführt. Als gemeinsames Schema wird die Ontologie genutzt. Sicherheits-Agent regelt die Berechtigung zur Anfrage durch den mobilen Such-Agent Datenbank-Agent übersetzt allgemeine Anfrage in eine Anfrage gemäß des vorhandenen Datenbank-Schemas DB-Agent liefert Ergebnis als XML-Dokument an Scuh-Agent zurück Im Schema allgemein für SQL- und XML-DBs dargestellt – ooDBMS entsprechend Im Aktivitäten Diagramm wird eine SQL-DB dargestellt XQuery Anfrage Bearbeitung Anfrage Commit SQL-Query Ergebnis- verarbeitung Ergebnis Bearbeitung XML-Doc SQL-Result Sascha Alda, Jochen Bilek, Mirko Theiß

40 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 Sascha Alda, Jochen Bilek, Mirko Theiß

41 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) Sascha Alda, Jochen Bilek, Mirko Theiß

42 Modell eines komponentenbasierten Kooperationsverbunds
Fachplaner stellen über Komponenten Dienste und Daten dem Kooperations-verbund zur Verfügung Brand schutz regeln Konsistenz prüfung Brandschutz Experte Fach modell Fachplaner Denkmalschutz Experte Datenaustausch / Abstimmung Kein Zugriff für nicht-autorisierte Leute!! Fach modell Wahrnehmung Beratung Fach modell Architekt Besitzer Fachplaner FachplanerNEU Sascha Alda, Jochen Bilek, Mirko Theiß

43 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 Sascha Alda, Jochen Bilek, Mirko Theiß

44 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 Sascha Alda, Jochen Bilek, Mirko Theiß

45 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 Sascha Alda, Jochen Bilek, Mirko Theiß

46 FlexiBeans Komponente
Component Model <jxta:ModuleAdvertisement xmlns:jxta=„ <ID> Urn:jxta:uuid-D E </ID> <Type>Peer Service</Type> <Name> Wrapper für Datenmodell ‚model.dat‘ </Name> <Param>Name = „Sascha Alda“</Param> </jxta> 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. Sascha Alda, Jochen Bilek, Mirko Theiß

47 Component Architecture
Dezentrale Peer-to-Peer Komponenten-Architektur, basierend auf Client-Server Architektur FreEvolve (Uni Bonn ) und JXTA FreEvolve Peer FreEvolve Peer FreEvolve Peer Anbieter eines Peer Service Konsument eines Peer Service Laufzeitumgebung FlexiBeans Komponentenmodell (+ Erweiterung Peer Service) Komposition von lokalen und entfernten Komponenten durch Kompositionssprache DeCAT Integration von (adaptiven) Anpassungsstrategien Sascha Alda, Jochen Bilek, Mirko Theiß

48 Neue Management-Tools
Component Architecture Neue Management-Tools GUI-Oberfläche zur Suche & Integration Komponenten (Daten & Diensten) Peers (Fachplaner) Peer Gruppen (Bauprojekte) Definition und Verwaltung von Gruppen Anpassung von Komponenten in einem visuellen Editor (Tailoring-Client) Sascha Alda, Jochen Bilek, Mirko Theiß

49 .... Zusammenspiel Jxta und FreEvolve:
Einbindung eines Planer in eine Gruppe FachplanerNEU Architekt (Admin) Fachplaner findAdvertisement( Param par) Discovery Protocol Gruppe „Bauprojekt X“ (Xml-Advertisments)* 1 initialRequest( Data data ) Credential::object Membership Protocol apply( Credential c ) 2 true 3 join() useService( String Name ) FreEvolve Compoment-Plan, Components events / access to shared object .... Sascha Alda, Jochen Bilek, Mirko Theiß

50 Ereignis- Historie (XML)
Awareness Framework Java-basiertes Komponenten-Framework (FlexiBeans-Komponenten) Benutzer DB (XML) Zuordnung Ereignisse Ermittlung Subscriber Applikation (z.B Produktmodell Editor) Synchrone Übermittlung (Subscriber Online) Netzwerk Awareness Framework Popup-Fenster Ereignis Historie (XML) Persistente Speicherung von Ereignissen Asynchrone Übermittlung (Subscriber Offline) Mail in Mail-Client Kontrolldialog für das Framework (z.B. Filtereinstellungen, Benutzerauswahl) Sascha Alda, Jochen Bilek, Mirko Theiß

51 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) Awareness Framework ... <event client = "Alex" application = "Whiteboard„ urgent = "false" date = " :29:40" type = "1" message = "Logged In" comment = "nothing„ id = "3"> </event> Ermittlung Subscriber Filter-Agent Benachrichtigung evtl. modifiziert Filter-Agent Netzwerk + Filter-Agent Verwerfung Erhalt eines zeitbezogenen Ereignis Filtern eines Ereignis Benachrichtigung der Subscriber Sascha Alda, Jochen Bilek, Mirko Theiß

52 Synergien: Projekt Darmstadt und Projekt Bonn
Modell DB Transport-Agent „Brandschutz Agent“ Einschreibung (über mobilen Transportagent) Wrapper-Agent Modell DB Fachplaner X Network Transport-Agent Fachplaner X Produkt Modell Editor Wrapper-Agent CoBE Weitergabe von Ereignissen CoBE Awareness Framework Awareness Framework Fachplaner Y Einschreibung (direkt) 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 Weimar. 2003) Technische Realisierung in Form von Vertiefer-/Diplomarbeiten ist geplant Sascha Alda, Jochen Bilek, Mirko Theiß

53 Produktmodell-Agenten
Synergien: Projekt Bonn und Projekt Bochum Workflow DB Produkt-modell DB Einschreibung (über ACL-Nachrichten) Wrapper-Agent Projekt-Agent Fachplaner X Datenbanken Network ACAD 2000 Produktmodell-Agenten Wrapper-Agent CoBE Workflow Editor com2acad Framework Weitergabe von Ereignissen Fachplaner Y Einschreibung (direkt) Awareness Framework Mögliche Integration des Awareness Frameworks in das Agentenmodell für die Tragwerksplanung (Workflow, Produktmodell) Technische Realisierung in Form von Diplomarbeiten ist geplant Sascha Alda, Jochen Bilek, Mirko Theiß

54 Agent Fachplaner Darmstadt Agent Fachplaner Bochum
Synergien: Projekt Darmstadt und Bochum rub.bi.inginf. com2acad Agent Fachplaner Darmstadt CAD-Wrapper-Agent DB-Wrapper-Agent Tamino XML-DB SeMOA/JADE ACL/ Ontologie SeMOA/JADE DB-Wrapper-Agent Agent Fachplaner Bochum XIndice XML-DB MTS-Agent MTS-Agent LARS MySQL DB LARS 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 Sascha Alda, Jochen Bilek, Mirko Theiß

55 Gemeinsames Web-Portal zur Präsentation der Ergebnisse
Sascha Alda, Jochen Bilek, Mirko Theiß

56 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 Sascha Alda, Jochen Bilek, Mirko Theiß

57 Modellierung und Realisierung von Agenten- und Komponentensystemen im Konstruktiven Ingenieurbau
Dietrich Hartmann, Jochen Bilek Ruhr-Universität Bochum Armin B. Cremers, Sascha Alda Universität Bonn Udo F. Meißner, Uwe Rüppel, Mirko Theiß Technische Universität Darmstadt

58 Sascha Alda, Jochen Bilek, Mirko Theiß

59 BACKUP Sascha Alda, Jochen Bilek, Mirko Theiß

60 Dezentrale Peer-to-Peer Komponenten-Architektur
Component Architecture Dezentrale Peer-to-Peer Komponenten-Architektur Basierend auf Komponenten-Architektur EVOLVE (Uni Bonn ) 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 Sascha Alda, Jochen Bilek, Mirko Theiß

61 Resultierende Anforderungen an eine Software Plattform
Nicht alle wesentlichen Anforderungen lassen sich durch die Komponententechnologie realisieren: Koordination (Wahrnehmung) beim Zugriff auf Komponenten Berücksichtigung der Privatsphäre Filterung von Informationen Awareness Framework Agent Support Sascha Alda, Jochen Bilek, Mirko Theiß

62 Sascha Alda, Jochen Bilek, Mirko Theiß