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

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ß

Heterogene Bauprojektstruktur (Teil-) Produktmodelle Planungsbeteiligte Dokumente Prozesse (Zuständen/ Aktivitäten) Software Termine Sascha 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 von Teilergebnissen Problem- definition Gesamt- ergebnis Sascha 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 „Gelbe Seiten“ ! ? Planungsaufgabe Planungsergebnis Sascha Alda, Jochen Bilek, Mirko Theiß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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 = "22.04.2003 16: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ß

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

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, Email) Termin- und Planungskoordination Austausch und Änderung von Planungsdaten Konflikt-Behebung Sascha Alda, Jochen Bilek, Mirko Theiß

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ß

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ß

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ß

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ß

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ß

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

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

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ß

FlexiBeans Komponente Component Model <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> 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ß

Component Architecture Dezentrale Peer-to-Peer Komponenten-Architektur, basierend auf Client-Server Architektur FreEvolve (Uni Bonn 2000-2003) 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ß

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ß

.... 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ß

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ß

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 = "22.04.2003 16: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ß

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 2003. Weimar. 2003) Technische Realisierung in Form von Vertiefer-/Diplomarbeiten ist geplant Sascha Alda, Jochen Bilek, Mirko Theiß

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ß

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ß

Gemeinsames Web-Portal zur Präsentation der Ergebnisse Sascha 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 Sascha Alda, Jochen Bilek, Mirko Theiß

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

Sascha Alda, Jochen Bilek, Mirko Theiß

BACKUP Sascha Alda, Jochen Bilek, Mirko Theiß

Dezentrale Peer-to-Peer Komponenten-Architektur 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 Sascha Alda, Jochen Bilek, Mirko Theiß

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ß

Sascha Alda, Jochen Bilek, Mirko Theiß