AGENTENBASIERTES NETZMANAGEMENT FÜR INNERSTÄDTISCHE ABWASSERSYSTEME

Transkript

1 AGENTENBASIERTES NETZMANAGEMENT FÜR INNERSTÄDTISCHE ABWASSERSYSTEME Arnim Marx Lehrstuhl für Ingenieurinformatik im Bauwesen, Ruhr-Universität Bochum, Kurzfassung: Das Netzmanagement für Abwassersysteme ist systembedingt durch eine hohe technische und gleichzeitig organisatorische Komplexität geprägt, die mit der erforderlichen Zusammenarbeit diverser Fachexperten und den sich daraus ableitenden Interaktionen zusammenhängt. Die in der Informatik zunehmend an Bedeutung gewinnende Agententechnologie ist bei dieser Sachlage geradezu dazu prädestiniert, als Grundlage zur Lösung von Problemstellungen im Netzmanagement zu dienen. Im Folgenden wird ein Lösungsansatz vorgestellt mit dem durch Nutzung des Leistungspotentials der Agenten- bzw. Multiagententechnologie komplexe Kanalsanierungsmaßnahmen in Bezug auf Kosten optimiert und marode Kanäle wirtschaftlich sowie technisch effizient saniert werden können. Der Lösungsansatz beruht im Wesentlichen auf der Abbildung charakteristischer Bereiche des Netzmanagements (bzgl. Experten / Organisationen, Software und Prozesse) mit fachspezifisch zugeschnittenen Softwareagenten. 1 Einführung Ein modernes, professionelles und umfassendes Netzmanagement für Abwassersysteme ist systembedingt durch eine hohe technische und gleichzeitig organisatorische Komplexität geprägt. Die technische Komplexität liegt in der Vielzahl der auszuführenden technischen Vorgänge, wie Beobachtung, Überwachung, Diagnose, Bewertung, Prognose, Sanierungs- und Qualitätssicherung der Abwassersysteme. Die organisatorische Komplexität resultiert sowohl aus der erforderlichen Zusammenarbeit diverser Experten als auch aus den sich daraus ergebenden Interaktionen. 2 Projektbeschreibung An der Ruhr-Universität Bochum wird in Zusammenarbeit mit dem Industriepartner Stein und Partner [1], Ingenieurgesellschaft für unterirdische Infrastruktur und Umwelttechnik, Bochum, ein Softwaresystem für das agentenbasierte Netzmanagement für innerstädtische Kanalsysteme entwickelt [2], [3], [4]. Das Netzmanagement basiert auf folgendem Lösungskonzept: Im Spannungsfeld zwischen Substanzverzehr, Budgetrestriktionen und rechtlichen Vorgaben wird eine fundierte Netzbewertung durchgeführt.

2 Hierauf aufbauend werden auf das jeweilige Kanalnetz zugeschnittene Instandhaltungsund Investitionskonzepte erarbeitet. Grundlage der Netzbewertung bildet das Modell STATUS-Kanal [1], [5]. Das Modell setzt sich aus den nachfolgend abgebildeten sechs Stufen zusammen. 1. Stufe: Datenmanagementsystem Hier werden bestehende Informationen über das betreffende Kanalnetz gesammelt und verwaltet, die in unterschiedlichen Datenformen (verschiedene Datenbanken, einzelne Tabellen, Karten, Schriftform, etc.) vorliegen. 2. Stufe: Qualitätsmanagement in der Datenhaltung Vorhandene Daten, die bereits in einer Datenbank vorliegen, werden zur Erhöhung der Planungssicherheit einem Qualitätsmanagement bzgl. der Datenhaltung unterworfen. 3. Stufe: Bewertung des baulichen Ist-Zustandes Überprüfte, aber bislang noch nicht bewertete Inspektionsdaten werden über die marktüblichen Klassifizierungssysteme hinausgehend evaluiert und verfeinert klassifiziert. 4. Stufe: Vermögensbewertung Aufbauend auf den vorangehenden Stufen erfolgt eine beweiskräftige Vermögensbewertung mit Angabe des aktuellen Verkehrswerts des Netzes unter Berücksichtigung des bereits eingetretenen Substanzverzehrs. 5. Stufe: Prognosegestütztes Netzmanagement Die bisher gewonnenen Ergebnisse erlauben eine kurz-, mittelund langfristige Abschätzung der Netzentwicklung mit Angabe geeigneter Handlungsstrategien für die Netznutzung. 6. Stufe: Optimale und robuste Instandhaltungsplanung Erstellung des Vorschlags für eine optimale Planungsstrategie für zukünftige Reinigungs- und Inspektionsintervalle sowie Sanierungsmaßnahmen.

3 Das zurzeit entwickelte Softwaresystem für das agentenbasierte Netzmanagement soll die ersten drei Stufen, soweit wie möglich und sinnvoll, in ein Multiagentensystem einbetten. Im Rahmen dieses Beitrags wird das Konzept und die Umsetzung der 1. Stufe, das Datenmanagementsystem, vorgestellt. 3 Datenmanagementsystem 3.1 Teilprozesse des Datenmanagements Bei der Datenhaltung bringt es die regelmäßige Zustandserfassung der öffentlichen Abwasserkanäle zur Umsetzung der Eigenkontroll- bzw. Selbstüberwachungsverordnungen der Länder mit sich, dass sehr große Mengen an Daten anfallen. Im Rahmen durchgeführter Erst- und Wiederholungsinspektionen vergrößert sich dieser Datenbestand laufend durch neu hinzukommende Daten. Angesichts des Umfangs und der Bedeutung der Inspektionsdaten als Entscheidungsgrundlage für zukünftige Instandhaltungs- und Investitionsplanungen, kommt dabei der Richtigkeit bzw. Konsistenz, und damit der Aussagefähigkeit dieser Daten, tragende Bedeutung zu. Systematische Datenkontrollen zur Sicherstellung der Datenqualität (Datensicherung) sind, wie in der ATV-DVWK-M [6] gefordert, infolgedessen unverzichtbar. Aufgrund der bisher gemachten Erfahrungen in der Praxis muss sogar davon ausgegangen werden, dass der Anteil nicht plausibler oder fehlerhafter Inspektionsdaten bis zu 50 % des Datenbestandes betragen kann. Eine manuelle Kontrolle und Korrektur der Daten ist dabei jedoch aufgrund der Komplexität und der Menge der zu prüfenden Daten sehr zeitintensiv und fehleranfällig. Die automatisierte Überprüfung und Korrektur der Daten ist nur auf der Grundlage eines strukturierten und logisch schlüssigen Datenbanksystems (DBS) möglich. Zur Beurteilung der zu sanierenden Abwassersysteme müssen sowohl schon lange bestehende Daten, wie die Geographie und Topologie der zu betrachtenden Schächte und Kanäle, als auch aktuelle Daten, aus neuen Messungen bzw. Inspektionen und dem Kanal- Monitoring gewonnene Daten, in dieses DBS integriert werden. Abhängig vom Alter der Daten und dem Datenmanagement des Netzbetreibers werden für die Datenhaltung unterschiedliche Datenstrukturen verwendet. Die Vielfalt der möglichen Datenformate für die Datenhaltung, die vom Netzbetreiber abhängig verwendet werden, schließt folgende Datenformate mit ein: Datenbanksysteme (MySQL, Microsoft Access, Oracle Database); Geoinformationssysteme (GIS) (S&K-TIFFANY, BaSYS, ArcGIS); Tabellenkalkulationsprogramme (Microsoft Excel, StarOffice Calc); Plaintext Dokumente (ohne einheitliches Format bezüglich des Inhalts) (Textdateien, CSV-

4 Dateien); Plaintext Dokumente (mit einheitlichem Format bezüglich des Inhalts) (ISY- BAU-Format); Auszeichnungssprachen (Extensible Markup Language (XML); Geographic Markup Language (GML); Keyhole Markup Language (KML)) Das Übertragen von Daten der einzelnen Abwassersysteme in ein wohl strukturiertes DBS erfolgte bisher noch manuell. Dieser Vorgang soll zukünftig mit Hilfe eines Datenmanagementsystems automatisiert werden. Abbildung 1 zeigt ein Beispielszenario. Die Städte A bis D möchten ihre Kanalnetze sanieren. Die Daten der entsprechenden Netzbetreiber liegen in unterschiedlichen Formaten vor. Mit Hilfe des MAS sollen die Daten in eine relationale Datenbank überführt werden. Quellen Multiagentensystem Datenmanagementsystem Stadt A ISYBAU Relationale Datenbank (RDB) node Stadt B MSAccess line manhole basedata Stadt C ISYBAU MSAccess Stadt D MSExcel Plaintext section basedata section inspection manhole inspection Abb. 1: Agentenbasiertes Datenmanagement Neben der automatisierten Unterstützung bei der Zusammenstellung der vorliegenden Daten soll für die Datenquellen eines Abwassersystems ein wieder verwertbares Konvertierungsschema erzeugt werden. Hierdurch können Änderungen und Aktualisierungen der Quelldaten schnell und einfach eingearbeitet werden. Ebenso lassen sich die Änderungen in den Einträgen automatisiert dokumentieren. 3.2 Computer-basierte Abbildung des Datenmanagements Das Datenmanagement basiert auf einem aus fünf Teilschritten bestehenden Prozess (s. Abb. 2). Dieser Prozess wird, mit Hilfe eines lernfähigen Multiagentensystems, als weitgehend automatisierter Prozess umgesetzt.

5 Aufbauend auf der Struktur der Zieldatenbank erfolgt die Weiterverarbeitung der Projektdaten. Die Zieldatenbank ist ein flexibles und wohl strukturiertes DBS, das beim Industriepartner im Laufe der Zeit anhand von Sanierungsprojekten mit dem Fachwissen verschiedener Experten entwickelt wurde sowie ständig erweitert wird und auf die Gegebenheiten und Anforderungen von zukünftigen Projekten abgestimmt wird. Ein flexibles Datenmanagementsystem extrahiert die Daten aus den Datenquellen aus ihrer eigenen Struktur und überführt sie in die Struktur der Zieldatenbank. Zur Abbildung der Datenquellen auf die Zieldatenbank muss dabei für eine passende Abbildungsfunktion gesorgt werden. Die Abbildungsfunktion wird in Teilschritt vier formuliert (siehe unten). Datenmanagement Datenquellen definieren Datenquellen analysieren Felder identifizieren ETL - Regeln definieren ETL - Prozess initiieren << datastore >> Datenmanagementsystem Abb. 2: Aktivitätsdiagramm Datenmanagement Die Initialisierung eines neuen DBS für ein Abwassersystem beginnt im 1. Teilschritt mit der Definition der Datenquellen. Dieser Schritt wird von einem Experten durchgeführt und ist nicht automatisierbar. Bei der Initialisierung werden die Daten des Netzbetreibers, welche im Idealfall die Grunddaten, Inspektionsdaten, Randbedingungen und Kosten umfassen, an das Datenmanagementsystem übergeben. Im 2. Teilschritt (Datenquellen analysieren), wird die den Quelldaten zu Grunde liegende Struktur identifiziert und in Felder unterteilt. Felder sind Datenkonstrukte, die Daten aus einer Quelle so zusammenfassen, dass diese einer Spalte in der Zieldatenbank

6 zugeordnet werden können. Ein Feld hat einen Feldbezeichner, über den es eindeutig identifiziert werden kann. Ist das Quelldatenformat tabellenbasiert, entspricht ein Feld einer Spalte aus der Quelltabelle, z.b. einer Spalte in einer MS Access Datenbank oder einer Spalte in einem MS Excel Tabellenblatt. Bei einem textbasierten Datenformat werden die Felder dem Textformat entsprechend zusammengesetzt. Bei einer CSV- Datei bilden die durch das Trennzeichen separierten Werte die Felder. Aus einer XML- Datei hingegen werden die Felder über die verschiedenen XML-Tags zusammengesetzt. Die extrahierten Felder werden an den 3. Teilschritt (Felder identifizieren) weitergereicht. Felder identifizieren Feldnamen extrahieren Felder in den Kontext des DBMS setzen Kontext abfragen Wissensbasis Kontext empfangen Ziel DB Struktur [Struktur vollständig = true] << centralbuffer >> Ziel DB Struktur [evtl. unvollständig] [Struktur vollständig = false] Benutzerabfrage Wissensbasis aktualisieren Daten übermitteln Wissensbasis Fehlenden Kontext vervollständigen Kontext abfragen Wissensbasis Kontext empfangen Ziel DB Struktur << centralbuffer >> Ziel DB Struktur [vollständig] Abb. 3: Aktivitätsdiagramm Datenmanagement Teilschritt 3: Felder identifizieren Die Identifikation der Daten sorgt für die Zuordnung der Feldbezeichner von Datenquellen zu den Spalten der Zieldatenbank und erfolgt im 3. Teilschritt (Felder identifizieren).

7 Die Zuordnung erfolgt mit Hilfe einer Wissensbasis, die Informationen über die Struktur der Zieldatenbank und für das Mapping der Feldbezeichner auf die Spalten der Zieldatenbank bereitstellt bzw. neu aufnimmt. Die Strukturinformationen beschreiben den Aufbau der Zieldatenbank anhand der Schemata, Tabellen, und Spalten, sowie den Primärund Sekundärschlüsseln. Wie in Abbildung 3 dargestellt, werden für die Feldbezeichner in der Wissensbasis die entsprechenden Spaltennamen sowie die zugehörigen Strukturinformationen des DBS erfragt. Kann ein Feldbezeichner nicht zugeordnet werden, so ist eine Benutzereingabe erforderlich. Die vom Benutzer eingegebenen Daten werden wiederum in die Wissensbasis integriert. Sind alle Felder eindeutig identifiziert wird im 4. Teilschritt (ETL-Regeln definieren), die Abbildungsfunktion formuliert. ETL ist die Abkürzung für Extraction, Transformation and Loading und bezeichnet ein Konzept zur Konvertierung von Daten aus verschiedenen Datenquellen in eine oder mehrere Zieldatenbanken. Die Daten werden aus den Quellen extrahiert, dann falls erforderlich transformiert und anschließend in die Zieldatenbank geladen. Als Werkzeug wird dazu die die Open Source Software Pentaho Kettle eingesetzt. Aus folgenden Gründen: Pentaho Kettle unterliegt der GNU Lesser General Public License und verursacht somit keinerlei Lizenzkosten. Wie auch das zu entwickelnde Multiagentensystem ist Pentaho Kettle vollständig in Java implementiert. Mit Pentaho Kettle werden so genannte Transformationen erstellt. Eine Transformation stellt dabei eine Abbildungsfunktion dar, mit deren Hilfe Daten aus den Quellen gelesen, evtl. verändert und dann in die Zieldatenbank geschrieben werden können. Transformationen ermöglichen es einen ETL-Prozess beliebig oft zu wiederholen, zu überwachen und auf Fehler zu reagieren, zu protokollieren und gegebenenfalls teilweise oder ganz rückgängig zu machen. Für jedes der möglichen Formate ist eine eigene Datenschnittstelle erforderlich. Pentaho Kettle ist als Plug-in System konzipiert, das Schnittstellen zu den gängigsten Datenformaten, z.b. MySQL, Microsoft Access, Microsoft Excel etc. bereits mitliefert. Darüber hinaus ist es möglich für weitere Datenformate, relativ schnell und einfach, eigene Plug-ins zu implementieren. Für das manuelle Erzeugen oder die Korrektur von Transformationen steht eine umfangreiche grafische Benutzungsschnittstelle zur Verfügung.

8 Innerhalb des Datenmanagementsystems wird die grafische Benutzungsschnittstelle lediglich zu Korrekturzwecken eingesetzt. Die Formulierung der Abbildungsfunktion erfolgt automatisiert und wird von einem Expertensystem gesteuert. Das verwendete regelbasierte System ist dabei die Open Source Software JBoss Rules, auch bekannt als Drools. Drools unterliegt der GNU Lesser General Public License und ist vollständig in Java implementiert. Die Anwendung der Abbildungsfunktion, der eigentliche Vorgang des Extrahierens, Transformierens und Ladens der Daten, erfolgt im 5. Teilschritt (ETL-Prozess initiieren) und wird von dem Programm Pentaho Kettle durchgeführt. 4 Agentenbasierte Umsetzung Ein neuartiges, flexibles und dynamisches Konzept, mit dem ein autonomes und lernfähiges System umgesetzt werden kann, sind Multiagentensysteme (MAS) [7]. Ein Multiagentensystem setzt sich aus mehreren, dem jeweiligen Anwendungskontext angepassten Softwareagenten zusammen, die mit anderen, im Rechnernetz befindlichen Softwareagenten vorgegebene Problemstellungen kooperativ bearbeiten und die erarbeiteten Teilergebnisse synergetisch zu einer Gesamtlösung zusammenführen. Ein Software-Agent kann dabei als eine gekapselte, in einer dynamischen Umgebung situierte Softwareeinheit, die im Auftrag personeller und nicht-personeller Auftraggeber wohldefinierte Aufgaben in Kooperation mit anderen Softwareagenten autonom und proaktiv löst definiert werden [8]. Das komplexe Zusammenwirken von Experten, Softwareagenten und eingesetzten, spezifischen Ressourcen der Domäne des Netzmanagements lässt sich anschaulich in einem hierarchischen Drei-Ebenen-Ansatz darstellen (s. Abb. 4). Die oberste Ebene der Hierarchie, die Ebene der realen Welt, repräsentiert die Experten und die beteiligten Organisationen. Die Ebene der realen Welt ist durch dynamische Beziehungsgeflechte, Gruppenstrukturen, Rollen, Pflichten, Aufgaben- und Zuständigkeitsbereiche sowie kooperative Teamarbeit geprägt. Auf der mittleren Ebene, der A- gentensystem-ebene, werden die agentifizierbaren Teilbereiche des Netzmanagements, ihre Wechselwirkungen und Abhängigkeiten identifiziert, analysiert und anschließend auf fachspezifische Softwareagenten abgebildet; diese unterstützen in ihrem Zusammenspiel die Experten. Auf der Ressourcen-Ebene befinden sich die für das Netzmanagement benötigten Ressourcen, auf die sowohl die Softwareagenten als auch die Experten zur Lösung zu bearbeitender Probleme zurückgreifen. Netzmanagementrelevante Ressourcen sind z.b. spezifische Ingenieur- oder Standardsoftware, Regelbasiertes Fachwissen, technische Regelwerke, etc.

9 Experte Ingenieur Netz- Persönliche-Agenten Team management Sachbearbeiter ETL-Agenten Ebene der realen Welt Aktivitäten, Rollen Fachplaner Organisationen Unterstützung Experten- Agenten Wissens- Agenten Wrapper- Agentensystem - Ebene Agenten fachspezifisch zugeschnittene Software-Agenten Datenbanken Wissensbasen DIN/ EC Normen ETL-Software Expertensysteme Zugriff/Einbettung Ressourcen - Ebene Daten Software Wissen Abb. 4: Drei Ebenen Modell des agentenbasierten Netzmanagements Im Rahmen dieses Beitrags wird ein Ausschnitt aus der Agenten-System Ebene dargestellt. Die Agentifizierung des in Abschnitt 3.2 erläuterten Konzepts führt zu vier verschiedenen Softwareagententypen: Die Schnittstelle zu den beteiligten Experten bilden die Persönlichen-Agenten. Persönliche-Agenten stellen grafische Benutzungsschnittstellen bereit, über die der Benutzer Zugriff auf die Funktionalitäten des Multiagentensystems erlangt. Die Problemstellungen, die das MAS für den Experten bearbeiten soll, werden von sogenannten Experten-Agenten behandelt. Experten-Agenten sind proaktive Softwareagenten, die in Kooperation mit anderen Softwareagenten die eigentliche, quasi kognitive Arbeit in dem MAS übernehmen. Wissens-Agenten sind reaktive Softwareagenten, welche Wissen, in Form von Fakten, im MAS verfügbar machen. Wrapper-Agenten sind reaktive Softwareagenten, welche die eingesetzte, heterogene Ingenieur- und Standardsoftware für die beteiligten Experten und andere Softwareagenten im MAS verfügbar machen. Nachfolgend wird die Funktionsweise der einzelnen Softwareagenten anhand des agentifizierten Lösungskonzepts aus Kapitel 3.2 erläutert. Für jedes neue Projekt bekommt jeder der beteiligten Mitarbeiter einen Personal-Agent zugeordnet. Personal-Agents sind vom Typ Persönliche-Agenten. In Abhängigkeit von

10 der Position des Mitarbeiters und den dazugehörigen Befugnissen ist der Mitarbeiter über seinen Personal-Agent autorisiert Problemstellungen vom MAS bearbeiten zu lassen, Daten oder Expertenwissen in das MAS einzubinden oder abzufragen. Für das Definieren der Datenquellen (s. Abb. 2) stellt der Personal-Agent eine grafische Benutzungsschnittstelle zur Verfügung. Der entsprechende Mitarbeiter wählt die Dateien für die Quelldaten aus und gibt die gewünschte Struktur der Zieldatenbank an. Die Struktur der Zieldatenbank kann entweder aus einem vorgegebenen Fundus von Datenbankstrukturen ausgewählt oder aus einem Datenbankschema ausgelesen werden. Gegebenenfalls wird manuell eine neue Datenbankstruktur angelegt. Da der Personal- Agent nur die Schnittstelle zum MAS darstellt, delegiert er die ihm aufgetragene Aufgabe an einen Experten-Agenten. Dazu sucht er im MAS nach einem für diese Aufgabe geeigneten Experten-Agenten, übergibt die ausgewählten Parameter und erteilt den Auftrag zur Lösung des gegebenen Problems. Für das Datenmanagement steht im MAS ein Datamanagement-Expert-Agent zur Verfügung. Als Experten-Agent ist dieser proaktiv ausgerichtet und kann somit die ihm übertragenen Aufgaben zielgerichtet und in Kooperation mit anderen Softwareagenten bearbeiten. Die erforderlichen Interaktionen im MAS für die Bearbeitung der Teilschritte zwei (Datenquellen definieren) bis fünf (ETL-Prozess initiieren) (s. Abb. 2) werden vom Datamanagement-Expert-Agent koordiniert. Wie oben erläutert werden die vier Teilschritte mit der Software Pentaho Kettle umgesetzt. Im 2. Teilschritt erstellt der Datamanagement-Expert-Agent eine neue Transformation, die im 3. und 4. Teilschritt erweitert und im 5. Teilschritt ausgeführt wird. Für das Erstellen einer Transformation muss die Struktur der Quelldaten identifiziert werden, die der Zieldatenbank muss bekannt sein und verschiedene Regeln für das Formulieren einer solchen Abbildungsfunktion müssen befolgt werden. Hierbei interagiert der Datamanagement-Expert-Agent mit einem Kettle-Wrapper-Agent und einem Database-Knowledge-Agent. Der Kettle-Wrapper-Agent ist vom Typ Wrapper-Agent und stellt die Funktionalitäten der Software Pentaho Kettle im MAS zur Verfügung. Hierzu gehören Funktionen für das Erstellen von Transformationen, die Bereitstellung bereits existierender Transformationen, sowie das Ausführen von Transformationen. Transformationen sind Abbildungsfunktionen die aus sequenziell ablaufenden Teilschritten bestehen. Das Erstellen dieser Teilschritte ist die Aufgabe des Datamanagement-Expert-Agents. Hierfür hat der Datamanagement-Expert-Agent ein regelbasiertes (Experten)System (XPS) implementiert. Mit Hilfe dieser Regeln wird der Kettle-Wrapper-Agent delegiert. Die Auswertung der Regeln basiert auf dem Wissen über die Zieldatenbank. Dieses Wissen erfragt der Datamanagement-Expert-Agent bei dem Database-Knowledge-Agent.

11 Der Database-Knowledge-Agent ist ein Wissens-Agent, der über Informationen zur Struktur einer Zieldatenbank im MAS verfügt. Er besitzt eine Wissensbasis. Neues Wissen kann jederzeit aufgenommen werden. Neben Wissen zur Struktur der Zieldatenbank verwaltet der Database-Knowledge-Agent auch Metainformationen zur Identifikation und Integration von Daten aus neuen Quelldaten in die vorgegebene Zieldatenbankstruktur. Die Zuordnung der extrahierten Felder erfolgt über die Feldbezeichner und die Spaltennamen in der Zieldatenbank. Da diese in den seltensten Fällen identisch sind werden in der Wissensbasis Aliasse für die Spaltennamen der Zieldatenbank vorgehalten, mit denen die Zuordnung zu neuen Daten ermöglicht wird. Spalte.table.primärschlüssel.status == nicht erzeugt Inferenzmaschine Spalte FIPA-ACL Nachricht Sender: Empfänger: Sprechakt: Protokoll: Encoding: Inhaltssprache: Ontologie: Datamanagement-Expert-Agent Kettle-Wrapper-Agent Anforderung (request) FIPA-Request-Protokoll als Text (String) FIPA-SL Datamanagement-Ontologie Nachrichteninhalt: (( action (agent-identifier :name (AddSequence :Stepp_name Section_ID_erzeugen :Name_of_value SECTION_ID :Start_at_value 1 :Increment_by 1 :Maximum_value ))) Abb. 5: Ausschnitt aus dem Regelbasiertem System des Experten-Agenten Ein Beispiel für die Arbeitsweise des Datamanagement-Expert-Agents ist in Abbildung 5 skizziert. Der Datamanagement-Expert-Agent hat beim Database-Knowledge-Agent Zieldatenbank Strukturinformationen zu einem Feldbezeichner angefragt. Die verfügbaren Daten, die ihm zurückgeliefert wurden, sind in Abbildung 5 als Spalte bezeichnet. Jede Spalte in einer Datenbank ist Teil einer Tabelle, die über einen Primärschlüssel identifiziert wird. Die aufzustellende Transformation muss folglich die Primärschlüssel für alle Tabellen erzeugen. Eine der im Datamanagement-Expert-Agent implementierten Regeln befasst sich mit der Frage, ob der Primärschlüssel zu der Tabelle einer einkommenden Spalte erzeugt wird. Sollte dies nicht der Fall sein, schickt der Datamanagement-Expert-Agent, als Resultat der Auswertung der Inferenzmaschine, eine Nachricht an den Kettle-Wrapper-Agenten. Diese enthält eine Anforderung (request), eine Aktion auszuführen. Es soll z.b. die Aktion AddSequence ausgeführt werden. AddSequence erstellt dann mit den mitgeschickten Parametern einen Teilschritt der

12 Transformation, der eine Zahlenfolge, beispielsweise den Primärschlüssel einer Tabelle, hinzufügt. Sobald die vollständige Abbildungsfunktion in Form einer Transformation aufgestellt worden ist, kann sie ausgeführt werden. Die Daten werden dann aus den Quelldateien ausgelesen und in die Zieldatenbank geladen. 5 Zusammenfassung und Ausblick Das skizzierte Konzept und die agentenbasierte Umsetzung verbessert das zurzeit in der Praxis durchgeführte Netzmanagement erheblich. Durch die modulare Struktur des Konzepts und durch die Integration modernster Software-Technologie wird ein äußerst effizientes, schnelles und kontinuierliches Netzmanagement möglich. Hierdurch kann insbesondere das Datenmanagement über die gesamte Lebenszeit eines Kanalnetzes hinweg kontinuierlich überwacht und erweitert werden. Ebenso wird die Zustands- und Sanierungsprotokollierung erheblich verbessert. Teile des Gesamtkonzepts sind bereits prototypisch umgesetzt worden. Als nächster Schritt ist geplant, alle erarbeiteten o.g. Konzepte und Modelle in Software zu übertragen, die im Hinblick auf ihre Leistungsfähigkeit und auch Leistungsgrenzen zu überprüfen ist. 6 Danksagung Wir danken der Deutschen Forschungsgemeinschaft für die Förderung des Projektes Agentenbasiertes Netzmanagement für innerstädtische Abwassersysteme. Literatur [1] Prof. Dr.-Ing. Stein und Partner GmbH, Consulting Engineers URL [2] D. Hartmann, J. Bilek, R. Stein, R. Trujilo Alvarez: Antrag zur Förderung des Transferprojekts Agentenbasiertes Netzmanagement für innerstädtische Abwassersysteme. - Transferbereich aus dem DFG-Schwerpunktprogramm 1103 [3] Transferbereich aus dem DFG-Schwerpunktprogramm 1103: Agentenbasiertes Netzmanagement für innerstädtische Abwassersysteme. URL

13 [4] DFG SPP1103: Vernetzt-kooperative Planungsprozesse im Konstruktiven Ingenieurbau. URL DFG Schwerpunktprogramm 1103 [5] R. Stein: Effektiver Kanalnetzbetrieb durch optimierte Netzinstandhaltung mit STATUS-Kanal. In: NRW Referenzen Wasserwirtschaft. Wasserwirtschaftsinitiative NRW, [6] ATV-DVWK-M 143-1: Sanierung von Entwässerungssystemen außerhalb von Gebäuden Teil 1: Grundlagen, 08/2004. [7] G. Weiss (Hrsg.): Multiagent Systems. MIT Press, Massachusetts, [8] J. Bilek: Vernetzt-kooperative Tragwerksplanung mit ingenieurspezifischen Softwareagenten. Dissertation. Lehrstuhl für Ingenieurinformatik im Bauwesen, Ruhr-Universität Bochum, Mai 2006.